Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Chiel92
    ... 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
    Message 1 of 9 , Jan 24, 2013
    • 0 Attachment
      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
    • Sung Pae
      ... While I hesitate to campaign against my own patch, I think a _code_ formatting plugin should either use formatexpr or provide it s own functionality for
      Message 2 of 9 , Jan 24, 2013
      • 0 Attachment
        On Thu, Jan 24, 2013 at 08:45:45AM -0800, Chiel92 wrote:

        > Is there any progression on this subject? I'm currently writing a code
        > format plugin, which heavily relies on this issue.

        While I hesitate to campaign against my own patch, I think a _code_
        formatting plugin should either use 'formatexpr' or provide it's own
        functionality for the gq command. I don't know the specifics of your
        plugin of course, so this is certainly not an absolute maxim.

        'formatprg' is meant to be a replacement for the default internal
        formatter used by the gq command (and always by gw), which is used
        primarily for editing prose, not code.

        That said, I still stand behind my argument for switching 'formatprg' to
        a buffer-local option and have been happily using it in my own build of
        Vim without issue.

        Sung Pae

        --
        --
        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
      • Chiel92
        ... The plugin I m talking about can be found right here: https://github.com/Chiel92/vim-autoformat I thought that it was a good idea to utilize formatprg,
        Message 3 of 9 , Apr 24, 2013
        • 0 Attachment
          On Friday, January 25, 2013 3:36:21 AM UTC+1, Sung Pae wrote:
          > On Thu, Jan 24, 2013 at 08:45:45AM -0800, Chiel92 wrote:
          >
          >
          >
          > > Is there any progression on this subject? I'm currently writing a code
          >
          > > format plugin, which heavily relies on this issue.
          >
          >
          >
          > While I hesitate to campaign against my own patch, I think a _code_
          >
          > formatting plugin should either use 'formatexpr' or provide it's own
          >
          > functionality for the gq command. I don't know the specifics of your
          >
          > plugin of course, so this is certainly not an absolute maxim.
          >
          >
          >
          > 'formatprg' is meant to be a replacement for the default internal
          >
          > formatter used by the gq command (and always by gw), which is used
          >
          > primarily for editing prose, not code.
          >
          >
          >
          > That said, I still stand behind my argument for switching 'formatprg' to
          >
          > a buffer-local option and have been happily using it in my own build of
          >
          > Vim without issue.
          >
          >
          >
          > Sung Pae

          The plugin I'm talking about can be found right here: https://github.com/Chiel92/vim-autoformat
          I thought that it was a good idea to utilize formatprg, since it looks like it exists for this one purpose: to format text using an external application, whatever the text maybe. Why do you think formatexpr should be used for this instead?

          --
          --
          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

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Sung Pae
          ... Looking now at vim-autoformat, I confess that I was being a bit unimaginative. If there exist nice external tools for formatting code like astyle,
          Message 4 of 9 , Apr 24, 2013
          • 0 Attachment
            On Wed, Apr 24, 2013 at 03:52:26PM -0700, Chiel92 wrote:

            > On Friday, January 25, 2013 3:36:21 AM UTC+1, Sung Pae wrote:
            >
            > > On Thu, Jan 24, 2013 at 08:45:45AM -0800, Chiel92 wrote:
            > >
            > > > Is there any progression on this subject? I'm currently writing a
            > > > code format plugin, which heavily relies on this issue.
            > >
            > > While I hesitate to campaign against my own patch, I think a _code_
            > > formatting plugin should either use 'formatexpr' or provide it's own
            > > functionality for the gq command. I don't know the specifics of your
            > > plugin of course, so this is certainly not an absolute maxim.
            > >
            > > 'formatprg' is meant to be a replacement for the default internal
            > > formatter used by the gq command (and always by gw), which is used
            > > primarily for editing prose, not code.
            > >
            > > That said, I still stand behind my argument for switching
            > > 'formatprg' to a buffer-local option and have been happily using it
            > > in my own build of Vim without issue.
            >
            > The plugin I'm talking about can be found right here:
            > https://github.com/Chiel92/vim-autoformat I thought that it was a good
            > idea to utilize formatprg, since it looks like it exists for this
            > one purpose: to format text using an external application, whatever
            > the text maybe. Why do you think formatexpr should be used for this
            > instead?

            Looking now at vim-autoformat, I confess that I was being a bit
            unimaginative. If there exist nice external tools for formatting code
            like astyle, jsbeautify, autopep8, and tidy, then it seems burdensome
            to have to wrap these commands in formatexprs, or rewrite them in
            vimscript.

            I think I was under the impression that your plugin was trying to
            achieve automatic insert mode formatting, which is only possible with
            formatexpr. I'm not sure why I thought this, since you did not mention
            anything of the sort.

            So I retract my last response: a global-local formatprg is clearly
            useful for both prose and code, and comes at the cost of a small
            non-breaking change.

            Tony Mechelynck's criticism is that it is superfluous. I disagree¹, but
            you will have to convince him before Bram will pay any attention. :)

            Sung Pae

            ¹ Why have formatprg at all then?

            --
            --
            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

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Gary Johnson
            ... formatprg existed in Vim 6 and possibly in earlier versions; formatexpr did not appear until Vim 7. Vim seems to be moving away from relying on
            Message 5 of 9 , Apr 24, 2013
            • 0 Attachment
              On 2013-04-24, Sung Pae wrote:

              > So I retract my last response: a global-local formatprg is clearly
              > useful for both prose and code, and comes at the cost of a small
              > non-breaking change.
              >
              > Tony Mechelynck's criticism is that it is superfluous. I disagreeน, but
              > you will have to convince him before Bram will pay any attention. :)
              >
              > Sung Pae
              >
              > น Why have formatprg at all then?

              'formatprg' existed in Vim 6 and possibly in earlier versions;
              'formatexpr' did not appear until Vim 7.

              Vim seems to be moving away from relying on external programs to
              expand functionality and toward having more capability built-in.
              One of the reasons for this is to accommodate Windows users who
              don't have access to the rich set of tools available in Unix.
              Another reason is that built-in tools have access to Vim's variables
              and functions and allow for better integration with Vim.

              I think that 'formatexpr' offers better functionality than
              'formatprg', including the ability to run external programs, which
              is probably why Tony says that it's superfluous. 'formatprg' is
              simpler to use in some cases and, more importantly, must be kept for
              backwards compatibility.

              Regards,
              Gary

              --
              --
              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

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            Your message has been successfully submitted and would be delivered to recipients shortly.