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

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

Expand Messages
  • 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 1 of 9 , Apr 24 3:52 PM
    • 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 2 of 9 , Apr 24 5:02 PM
      • 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 3 of 9 , Apr 24 5:38 PM
        • 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.