[vim/vim] runtime: Remove 'formatprg' from ftplugins (PR #19108)
dkearns
Effective use of 'formatprg' requires both an understanding of the
specific capabilities of the formatting tool and Vim's formatting
commands. This is overly burdensome for some users.
Rather than address each complaint on a filetype by filetype basis,
remove 'formatprg' settings from all ftplugins.
It is expected that formatter plugins will be available in the near
future as a better solution. See #17145 (Add "formatter" feature using
"compiler" as a template).
See: #18650 (rust.vim: stop setting formatprg to rustfmt)
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19108
Commit Summary
- 866647e runtime: Remove 'formatprg' from ftplugins
File Changes
(6 files)
- M runtime/ftplugin/awk.vim (6)
- M runtime/ftplugin/gleam.vim (4)
- M runtime/ftplugin/go.vim (4)
- M runtime/ftplugin/lprolog.vim (10)
- M runtime/ftplugin/modula3.vim (6)
- M runtime/ftplugin/racket.vim (6)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- f0aad7f runtime: Remove 'formatprg' from ftplugins
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#19108)Racket: I'm willing to accept this change in Vim's default ftplugins, but I'll probably keep it upstream for now. When the newer mechanism is available, I'll convert. That said, is #17145 still moving?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#19108)Effective use of 'formatprg' requires both an understanding of the
specific capabilities of the formatting tool and Vim's formatting
commands. This is overly burdensome for some users.
Those who prefer predictable behavior use gw instead, which is almost always what was intended when gq is used. The latter is likely just better known as it came first. Without formatprg/expr, what's the value provided by gq over gw ? So I'd rather argue for the opposite coupled with a recommendation of gw
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Phạm Bình An
brianhuster left a comment (vim/vim#19108)While I think that Vim shouldn't have to chase the ecosystem (development tools) of every language, hence Vim shouldn't set formatprg by default for any languages without one yet, wouldn't this PR be a breaking change? People already familiar with formatprg of those filetypes will suddenly be presented with something as dumb as gw.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#19108)This PR is simply following through on the decision already made in the referenced PR (see #18650 (rust.vim: stop setting formatprg to rustfmt)).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19108)I agree with this approach in principle. However to not surprise users too much, let's merge this after the release.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#19108)For what it's worth @ychin 's proposition of an opt-in in #18650
Alternatively, we could have a general let g:enable_filetype_formatter=1 type setting in vimrc that will turn on all formatprg / formatexpr settings in all file types by convention. The reason why this may make sense at least within formatting's context is that a user who is aware of this should already know that gq is specifically designed for using these options, and gw is for using Vim's own formatter
is in-line with existing (inofficial) standards such as g:no_plugin_maps and helps showcase gq's capability to respect syntax. (In an ideal world, gq would likely do what gw does and gw respect formatprg, but by now users mainly expect gq to add line breaks to comments.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#19108)I agree with this approach in principle. However to not surprise users too much, let's merge this after the release.
The ftplugins for go and gleam are adding the setting with this release like rust. So, it would be a good idea not to add it only to remove it in the future.
The awk ftplugin has also generated complaints.
I'm willing to bet lprolog and modula3 aren't getting too much use and the formatter for the latter is quirky enough that anyone using it probably knows what they're doing. racket is probably the only one likely to cause surprise if it's removed.
I'm not sure what difference it makes if users are surprised this release or the next, other than pushing the complaints out into the murky future. :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19108)Okay fair fine then
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> Those who prefer predictable behavior use gw instead, which is almost always
> what was intended when gq is used. The latter is likely just better known as it
> came first. Without formatprg/expr, what's the value provided by gq over gw ?
> So I'd rather argue for the opposite coupled with a recommendation of gw
cursor is handled.
A value of gq over gw is that gqj can be executed repeatedly over
a range of lines to reformat them because after each operation, the
cursor is well-positioned for the next operation. That is not true
for gw.
Regards,
Gary
vim-dev ML
vim-ml left a comment (vim/vim#19108)—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.