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

Re: Patch: formatoptions in ftplugins

Expand Messages
  • David Barnett
    Yeah, r and l I d think the majority of people would want, but not everyone. o has a tendency to false-positive, so I try to keep that disabled myself.
    Message 1 of 14 , Oct 5, 2013
    • 0 Attachment
      Yeah, "r" and "l" I'd think the majority of people would want, but not everyone. "o" has a tendency to false-positive, so I try to keep that disabled myself.

      But if they shouldn't be in vimrc_example, they *definitely* shouldn't be in every ftplugin. This forces them on everyone in a hit-or-miss fashion, in a way that's kind of tricky to work around.

      I'd rather the behavior be simple and predictable than fancy. I'm a little concerned about trying to automatically distinguish a default from an explicit user preference. Can you explain some scenarios of how that would work and what it would help?

      What we're discussing here is basically three categories of options:
      • Per-filetype settings (probably "-t", never "+t" and probably nothing else)
      • Vim-wide settings (probably nothing, "rol" under discussion)
      • Plain-old opt-in user preferences
      Nothing should be in an ftplugin unless it's truly filetype-specific, so let's get those things out of the ftplugins ASAP. The only catch there is if we're planning to move an option from ftplugins to a vim-wide default, we'd want to get that done first.

      BTW, the reason I think the "t" option is special is it's kind of a logical AND of a user preference (whether all text should be wrapped) and a filetype property (whether blindly wrapping text works correctly for this syntax), so we should only ever unset it.

      David


      On Sat, Oct 5, 2013 at 11:45 AM, Bram Moolenaar <Bram@...> wrote:

      David Bürgin wrote:

      > On Wed, Oct 2, 2013 at 12:52 PM, Bram Moolenaar <Bram@...> wrote:
      > >
      > > David Barnett wrote:
      > >
      > >> +Nikolai +Bram +Tim (authors of the majority of these plugins)
      > >>
      > >> I'm confident we can get consensus to at least remove a few of those
      > >> formatoptions modifications. You should also add "setlocal
      > >> formatoptions-=3Dt" in pretty much every case (unless your syntax is fine
      > >> with any arbitrary space being converted to a newline). ftplugin/python.vim
      > >> should be setting -t, for instance.
      > >>
      > >> FYI, these settings affect what happens when you set &textwidth to
      > >> non-zero, so the problem usually only comes up when users want to set
      > >> &textwidth and use &colorcolumn.
      > >
      > > I think we should make a difference between the case the user has not
      > > set any formatting options and when he did.  If there are no user
      > > preferences, the user expects the filetype plugin to do it all.  If the
      > > user did set preferences, we should indeed avoid overruling these when
      > > they are not specific for the filetype.
      > >
      > > Once we agree, an explanation needs to be added to  :help
      > > write-filetype-plugin
      >
      > yes, that's a fair solution.
      >
      > However -- what worries me is that this requires even more boilerplate
      > in all ftplugins. I understand your point about not changing what the
      > user is used to, but I don't feel this way is a step forward really.
      >
      > What we could do to mitigate the impact on the users is make the setting
      > "formatoptions+=croql" recommended boilerplate for everybody's vimrc:
      >
      >
      > diff -r 20068068e3f9 runtime/vimrc_example.vim
      > --- a/runtime/vimrc_example.vim    Wed Oct 02 18:43:06 2013 +0200
      > +++ b/runtime/vimrc_example.vim    Wed Oct 02 20:38:15 2013 +0200
      > @@ -31,6 +31,9 @@
      >  set showcmd        " display incomplete commands
      >  set incsearch        " do incremental searching
      >
      > +" Fine-tune how Vim formats comments and long lines. See ":help fo-table".
      > +set formatoptions+=croql
      > +
      >  " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
      >  " let &guioptions = substitute(&guioptions, "t", "", "g")
      >
      >
      > That way we could implement the change and just guide users to the new
      > (and better) practice. What do you think about this solution? I'd love
      > to see it happen.

      I think it is a good idea to keep vimrc_example.vim as short as
      possible.  It only contains things that "everybody should use".

      The default value for 'formatoptions' is "tcq".  You propose to add
      "rol" here.  "r" and "o" are for adding the comment leader, "l" for not
      breaking lines that were already longer than 'textwidth'.  I don't
      consider these helpful enough to set by default.

      The "l" flag has limited effect, when typing a string literal that
      crosses "textwidth" it still gets broken.

      "r" and "o" are typically for when a file type has comments and depends
      on what kind of comments could be wrapped properly.

      --
      Proverb: A nightingale that forgets the lyrics is a hummingbird.

       /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
      ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\  an exciting new programming language -- http://www.Zimbu.org        ///
       \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

      --
      --
      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 a topic in the Google Groups "vim_dev" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/EKDS1PP4rPo/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.

      --
      --
      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.
    • David Barnett
      So, this hasn t gotten a lot of traction. Clearly it s a controversial issue, maybe we can ignore all the thorny questions about the other options for now and
      Message 2 of 14 , Feb 1, 2014
      • 0 Attachment
        So, this hasn't gotten a lot of traction. Clearly it's a controversial issue, maybe we can ignore all the thorny questions about the other options for now and just focus on the fo-=t part first?

        Can we agree that every standard ftplugin should have
        setlocal formatoptions-=t
        ? I should be able to enable 'textwidth' to get a colorcolumn without bizarre side-effects.

        The only filetypes I've encountered so far that could be the exceptions are
        * text (where any space indeed can become a newline without breaking semantics)
        * gitcommit (where some buffer contents are structured but any text inserted is plaintext safe to wrap)
        * possibly markdown (very lightly-structured text, auto-wrapping is rarely a problem)

        David

        On Tuesday, October 1, 2013 2:17:56 PM UTC-7, guns wrote:
        > On Mon 30 Sep 2013 at 07:27:13PM +0200, glts wrote:
        >
        >
        >
        > > If there is an agreement that the "+=croql" setting doesn't really
        >
        > > belong in a core ftplugin, I'll remove it from the one I maintain.
        >
        > > Hopefully others feel the same way: please speak up.
        >
        >
        >
        > As the maintainer of the Clojure filetype, I will happily remove +=croql
        >
        > from our ftplugin so long as I can redirect any bug reports to a post
        >
        > from Bram, or a thread like this expressing consensus.
        >
        >
        >
        > If I were the original author of the file, I would have avoided
        >
        > adding it in the first place as I myself have Gary Johnson's 'fo-=o'
        >
        > autocommand in my vimrc.
        >
        >
        >
        > In anticipation of this change I am submitting a patch that removes
        >
        > fo+=croql from ftplugin/clojure.vim, along with a tiny bugfix to the
        >
        > syntax file that did not make it into the last runtime files update.
        >
        >
        >
        > 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

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