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

Patch: formatoptions in ftplugins

Expand Messages
  • David Barnett
    I ve found the built-in ftplugin files are all over the place with respect to handling formatoptions . Some ftplugins don t touch it, many clobber useful user
    Message 1 of 14 , Sep 30, 2013
    • 0 Attachment
      I've found the built-in ftplugin files are all over the place with respect to handling 'formatoptions'. Some ftplugins don't touch it, many clobber useful user preferences. I put together a patch that batch-changes the ftplugin files to stop clobbering anything that might be a user preference.

      Rationale: Most 'formatoptions' options affect interactive editing behavior that vim shouldn't manage per-filetype, and doesn't currently manage consistently.

      The 't' option in particular seems like it could vary by filetype: it does insane things for almost every filetype just blindly jamming in newlines at a certain width, and should be forced disabled in most cases. But for the text filetype or unspecified filetype, it makes perfect sense. I think maybe it should never be explicitly enabled but should be explicitly disabled for most filetypes.

      The 'o' and 'r' options determine whether to automatically insert the comment leader when starting a new line after a comment line. I want +o -r everywhere, but most ftplugin files force +croql, so I have to fight with them by creating after/ files to force -r again. These weren't per-filetype settings and should have been left alone. Same for 'l'.

      The 'c' option also seems like it never needs to vary by filetype because comments are a specific case and there's no per-filetype reason you would want to auto-wrap comments.

      Then there are some I'm not sure about. I don't understand the value of ever disabling 'q', the option to 'Allow formatting of comments with "gq"'. And 'm1' is set for certain filetypes like verilog… I don't follow if that's because of something specific to verilog syntax, or if it's just the authors' preferred configuration.

      David

      --
      --
      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
      ... I m sympathetic to the problem, but I think your patch is not going to succeed. The procedure for changing a plugin is to first propose the change to the
      Message 2 of 14 , Sep 30, 2013
      • 0 Attachment
        On 2013-09-30, David Barnett wrote:
        > I've found the built-in ftplugin files are all over the place with
        > respect to handling 'formatoptions'. Some ftplugins don't touch
        > it, many clobber useful user preferences. I put together a patch
        > that batch-changes the ftplugin files to stop clobbering anything
        > that might be a user preference.

        I'm sympathetic to the problem, but I think your patch is not going
        to succeed.

        The procedure for changing a plugin is to first propose the change
        to the plugin's author, whose contact information can be found at
        the top of the plugin.

        > The 'o' and 'r' options determine whether to automatically insert
        > the comment leader when starting a new line after a comment line.
        > I want +o -r everywhere, but most ftplugin files force +croql, so
        > I have to fight with them by creating after/ files to force -r
        > again. These weren't per-filetype settings and should have been
        > left alone. Same for 'l'.

        Interesting. I much prefer having 'r' all the time and never 'o'.
        In any case, this is what I've put in my ~/.vimrc (after the
        :filetype command) to fix the 'o' problem. No need for a huge
        number of tiny after files.

        au FileType * setlocal formatoptions-=o
        " Override any filetype plugin's attempt
        " to set the 'fo' 'o' option.

        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.
      • glts
        ... I support this initiative. A bulk patch won t be accepted though. The line setlocal formatoptions-=t formatoptions+=croql has become boilerplate for
        Message 3 of 14 , Sep 30, 2013
        • 0 Attachment
          On Mon, Sep 30, 2013 at 9:57 AM, David Barnett <daviebdawg@...> wrote:
          > I've found the built-in ftplugin files are all over the place with respect to handling 'formatoptions'. Some ftplugins don't touch it, many clobber useful user preferences. I put together a patch that batch-changes the ftplugin files to stop clobbering anything that might be a user preference.
          >
          > Rationale: Most 'formatoptions' options affect interactive editing behavior that vim shouldn't manage per-filetype, and doesn't currently manage consistently.
          >
          > The 't' option in particular seems like it could vary by filetype: it does insane things for almost every filetype just blindly jamming in newlines at a certain width, and should be forced disabled in most cases. But for the text filetype or unspecified filetype, it makes perfect sense. I think maybe it should never be explicitly enabled but should be explicitly disabled for most filetypes.
          >
          > The 'o' and 'r' options determine whether to automatically insert the comment leader when starting a new line after a comment line. I want +o -r everywhere, but most ftplugin files force +croql, so I have to fight with them by creating after/ files to force -r again. These weren't per-filetype settings and should have been left alone. Same for 'l'.
          >
          > The 'c' option also seems like it never needs to vary by filetype because comments are a specific case and there's no per-filetype reason you would want to auto-wrap comments.
          >
          > Then there are some I'm not sure about. I don't understand the value of ever disabling 'q', the option to 'Allow formatting of comments with "gq"'. And 'm1' is set for certain filetypes like verilog… I don't follow if that's because of something specific to verilog syntax, or if it's just the authors' preferred configuration.

          I support this initiative. A bulk patch won't be accepted though.

          The line

          setlocal formatoptions-=t formatoptions+=croql

          has become boilerplate for ftplugins, but unlike settings such as
          'commentstring' or 'matchpairs' or whathaveyou, these are not settings
          that pertain to the domain of the *file type*. They're user settings.
          (By the way, see the comment in ftplugin/clojure.vim for a similar
          sentiment!)

          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.

          Best,

          --
          --
          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
          +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
          Message 4 of 14 , Oct 1, 2013
          • 0 Attachment
            +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-=t" 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.

            David


            On Mon, Sep 30, 2013 at 10:27 AM, glts <676c7473@...> wrote:
            On Mon, Sep 30, 2013 at 9:57 AM, David Barnett <daviebdawg@...> wrote:
            > I've found the built-in ftplugin files are all over the place with respect to handling 'formatoptions'. Some ftplugins don't touch it, many clobber useful user preferences. I put together a patch that batch-changes the ftplugin files to stop clobbering anything that might be a user preference.
            >
            > Rationale: Most 'formatoptions' options affect interactive editing behavior that vim shouldn't manage per-filetype, and doesn't currently manage consistently.
            >
            > The 't' option in particular seems like it could vary by filetype: it does insane things for almost every filetype just blindly jamming in newlines at a certain width, and should be forced disabled in most cases. But for the text filetype or unspecified filetype, it makes perfect sense. I think maybe it should never be explicitly enabled but should be explicitly disabled for most filetypes.
            >
            > The 'o' and 'r' options determine whether to automatically insert the comment leader when starting a new line after a comment line. I want +o -r everywhere, but most ftplugin files force +croql, so I have to fight with them by creating after/ files to force -r again. These weren't per-filetype settings and should have been left alone. Same for 'l'.
            >
            > The 'c' option also seems like it never needs to vary by filetype because comments are a specific case and there's no per-filetype reason you would want to auto-wrap comments.
            >
            > Then there are some I'm not sure about. I don't understand the value of ever disabling 'q', the option to 'Allow formatting of comments with "gq"'. And 'm1' is set for certain filetypes like verilog… I don't follow if that's because of something specific to verilog syntax, or if it's just the authors' preferred configuration.

            I support this initiative. A bulk patch won't be accepted though.

            The line

                    setlocal formatoptions-=t formatoptions+=croql

            has become boilerplate for ftplugins, but unlike settings such as
            'commentstring' or 'matchpairs' or whathaveyou, these are not settings
            that pertain to the domain of the *file type*. They're user settings.
            (By the way, see the comment in ftplugin/clojure.vim for a similar
            sentiment!)

            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.

            Best,

            --
            --
            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.
          • Ben Fritz
            ... Or when users want to set &textwidth for use with automatic formatting of comments with c in the formatoptions. -- -- You received this message from the
            Message 5 of 14 , Oct 1, 2013
            • 0 Attachment
              On Tuesday, October 1, 2013 10:16:38 AM UTC-5, David Barnett wrote:
              >
              > 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.
              >

              Or when users want to set &textwidth for use with automatic formatting of comments with 'c' in the formatoptions.

              --
              --
              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
              Even if the language syntax mandates maximum line lengths, you probably don t want to force +t. This will insert line breaks even in the middle of string
              Message 6 of 14 , Oct 1, 2013
              • 0 Attachment
                Even if the language syntax mandates maximum line lengths, you probably don't want to force +t. This will insert line breaks even in the middle of string literals, and it's a pain for users to figure out what happened, undo the bad linebreak, then fix the long lines properly. It would be better to find a syntax-aware method of breaking long lines, or failing that, leave it up to users. Anyway, the default is 'tcq', so forcing +t won't do anything except fight with users who have explicitly disabled it.

                I've seen lots of HighlightLongLines hacks floating around, and they're all brittle (e.g., they don't catch updates to &textwidth, and they don't cooperate well with other syntax files). It would be nice if vim officially supported something for it in addition to &colorcolumn (e.g. highlighting ONLY long lines so you can give them a screaming red color and not make other lines look ugly). Then if it's truly part of the standard, you have options to bake that into the built-in files.

                David


                On Tue, Oct 1, 2013 at 9:46 AM, Ajit Thakkar <thakkar.ajit@...> wrote:
                On Tuesday, October 1, 2013 12:16:38 PM UTC-3, David Barnett wrote:
                > I'm confident we can get consensus to at least remove a few of those formatoptions modifications. You should also add "setlocal formatoptions-=t" in pretty much every case (unless your syntax is fine with any arbitrary space being converted to a newline).

                The concept above is right. Most fo options should not be set in an ftplugin file. Only fo+=t is needed for Fortran code where the ISO standard mandates maximum line lengths. I have incorporated this change along with other unrelated ones I was planning to make in ftplugin/fortran.vim. I have sent the updated file to Bram.

                Ajit

                --
                --
                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.
              • Ben Fritz
                ... I once used a variant of this: http://vim.wikia.com/wiki/Highlight_long_lines#Toggle_matching_based_on_textwidth which would fire on autocmds (I think it
                Message 7 of 14 , Oct 1, 2013
                • 0 Attachment
                  On Tuesday, October 1, 2013 12:04:06 PM UTC-5, David Barnett wrote:
                  > Even if the language syntax mandates maximum line lengths, you probably don't want to force +t. This will insert line breaks even in the middle of string literals, and it's a pain for users to figure out what happened, undo the bad linebreak, then fix the long lines properly. It would be better to find a syntax-aware method of breaking long lines, or failing that, leave it up to users. Anyway, the default is 'tcq', so forcing +t won't do anything except fight with users who have explicitly disabled it.
                  >
                  >
                  >
                  > I've seen lots of HighlightLongLines hacks floating around, and they're all brittle (e.g., they don't catch updates to &textwidth, and they don't cooperate well with other syntax files). It would be nice if vim officially supported something for it in addition to &colorcolumn (e.g. highlighting ONLY long lines so you can give them a screaming red color and not make other lines look ugly). Then if it's truly part of the standard, you have options to bake that into the built-in files.
                  >

                  I once used a variant of this:

                  http://vim.wikia.com/wiki/Highlight_long_lines#Toggle_matching_based_on_textwidth

                  which would fire on autocmds (I think it was WinEnter and CursorHold) to re-apply the highlight based on textwidth.

                  But then colorcolumn was introduced and I got rid of it.

                  --
                  --
                  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.
                • guns
                  ... 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,
                  Message 8 of 14 , Oct 1, 2013
                  • 0 Attachment
                    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
                  • Bram Moolenaar
                    ... 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
                    Message 9 of 14 , Oct 2, 2013
                    • 0 Attachment
                      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

                      --
                      Not too long ago, unzipping in public was illegal...

                      /// 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 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
                      ... I don t think that s a valid distinction. The user s preference may be the default values, so he had no need to set any. The user expects the filetype
                      Message 10 of 14 , Oct 2, 2013
                      • 0 Attachment
                        On 2013-10-02, Bram Moolenaar 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.

                        I don't think that's a valid distinction. The user's preference may
                        be the default values, so he had no need to set any. The user
                        expects the filetype plugin to change what it has to to facilitate
                        editing that file type and no more. A plugin should not choose to
                        make a setting depending on whether the user has already set it.

                        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.
                      • glts
                        Bram, ... 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
                        Message 11 of 14 , Oct 2, 2013
                        • 0 Attachment
                          Bram,

                          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.

                          Best,



                          --
                          David Bürgin

                          --
                          --
                          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.
                        • Bram Moolenaar
                          ... 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
                          Message 12 of 14 , Oct 5, 2013
                          • 0 Attachment
                            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 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
                            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 13 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 14 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.