Thank you for your reply.
### REGARDING THE DRAWBACKS OF formatexpr ### 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`. ### REGARDING REAL-WORLD USAGE OF BOTH OPTIONS ### Compare the usage of both options on Github: formatprg: https://github.com/search?type=Code&language=VimL&q=formatprg formatexpr: https://github.com/search?type=Code&language=VimL&q=formatexpr 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. Cheers, 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". http://vimcasts.org/episodes/formatting-text-with-par/ [3]: http://www.vim.org/scripts/script.php?script_id=1939 -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
