On Sunday, August 14, 2011 5:38:58 AM UTC+2, Sung Pae wrote: > 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
Is there any progression on this subject? I'm currently writing a code format plugin, which heavily relies on this issue. -- -- 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
