Google Groups

Re: [PATCH] Convert formatprg to a global-local option.

Sung Pae Aug 13, 2011 8:38 PM
Posted in group: vim_dev
Thank you for your reply.


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`. [1]

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` [1]) 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`.


Compare the usage of both options on Github:


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:

1) setlocal formatexpr=autofmt#japanese#formatexpr()
2) setlocal formatexpr=googlecodewiki#FormatExpr()
3) setlocal formatexpr=

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` [2], while results for `formatexpr` are
limited to references to Autofmt [3], 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.

Sung Pae

[1]: `keywordprg` and `makeprg` are also global-local, but are not
     filter programs. `cscopeprg` is global-only, but that makes sense.

[2]: Perhaps due to being recently popularized by the Vimcasts episode,
     "Formatting text with par".