On 13 Aug 2011, at 3:06 PM, Tony Mechelynck wrote:
> Even with a global 'formatprg', you can use buffer-local 'formatexpr' > (which overrides it). 'formatexpr' can do whatever it wants with, for > instance, values of Vim options, and, if necessary, call system() or a > !filter with any arguments it wants to.
Yes, except `formatexpr` is called on every keystroke in Insert mode, even when `formatoptions` is empty. This suggests to me that the primary purpose of `formatexpr` is for fine-grained control over automatic formatting, rather than to be a simple, on demand paragraph formatter like `fmt` or `par`. 
Also, it is wasteful to set `formatexpr` if you wish to only use it for `gq`. I would hesitate to hook into `InsertCharPre`, so I am hesitant to set `formatexpr`.
Now, you can set `textwidth` to zero to avoid calling the expr on every insertion, but then you would have to store your desired line length in another variable.
### DEFENSE OF A LOCAL formatprg ###
> IOW I'm not convinced that the change is necessary.
If `formatprg` is meant to be set to an external program like `fmt`, is it not reasonable that one would want different parameters (like line length) for different file types?
The other filterprg options (`equalprg` and `grepprg` ) are global-local for exactly this reason; `formatprg` is an incomplete feature as exists now.
It is true that `filterexpr` is a superset of `formatprg`, but it comes with a large performance and complexity cost. This discourages its use, compared to the easily understood `formatprg`.
### REGARDING REAL-WORLD USAGE OF BOTH OPTIONS ###
If you dive into the search results, you'll find that people set `formatprg` to variations of `fmt`, `par`, `astyle`, `perltidy`, `perl\ -MText::Autoformat`, `PythonTidy`, `gofmt`, `xml_pp`, and so on. A few even try `exe "setlocal formatprg=par\ " . &textwidth`!
In comparison, the `formatexpr` search results reveal only three different invocations:
The third is the overwhelming majority of results, due to some common skeleton vimrc.
Doing a google search for both options reveal the same pattern: there are many users of `formatprg` , while results for `formatexpr` are limited to references to Autofmt , and questions about the proper use of `formatexpr`.
It's clear many people are very comfortable with filtering text through an external formatter, and many choose to set `filterprg` to a language-specific tidy program. This is another compelling reason to implement this small change to the option's scoping rules.
Cheers, Sung Pae
: `keywordprg` and `makeprg` are also global-local, but are not filter programs. `cscopeprg` is global-only, but that makes sense.
: Perhaps due to being recently popularized by the Vimcasts episode, "Formatting text with par".