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

Re: 'commentstring' suggestion.

Expand Messages
  • Bram Moolenaar
    ... For what language does it not work? ... Setting options like commentstring is precisely what filetype plugins are for. Other solutions may be
    Message 1 of 23 , Apr 2, 2003
      Nikolai Weibull wrote:

      > lets face it...the 'commentstring' option sucks. it only works well for
      > C like languages,

      For what language does it not work?

      > and if you need it for some other filetype you need to
      > set it in a filetype plugin. no big deal it may seem, but writing a lot
      > of filetype plugins only to support such a simple thing seems a bit
      > overkill at the very least.

      Setting options like 'commentstring' is precisely what filetype plugins
      are for. Other solutions may be smaller/quicker at first, but you
      always end up with adding more settings later and creating a mess.

      > my suggestions is thus, make commentstring use the 'comments' option.
      > this way it becomes language neutral.

      Since 'comments' is a list with possibly many entries, it's not at all
      clear which one should be used for inserting a marker with a comment.
      You could use the first entry, but that might conflict with a carefully
      tuned ordering of entries in 'comments'. For example, how would one
      specify to use "//" or "/* */" comments without changing the 'comments'
      option?

      --
      Why doesn't Tarzan have a beard?

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
    • Nikolai :: lone-star :: Weibull
      ... Yes. But generating a file that contains only this for filetypes such as screen and modconf and so on seems a bit silly. ... Well since // is :// in
      Message 2 of 23 , Apr 2, 2003
        On Wed, 02 Apr 2003 19:37:27 +0000, Bram Moolenaar wrote:
        >
        > Nikolai Weibull wrote:
        >
        > > lets face it...the 'commentstring' option sucks. it only works well for
        > > C like languages,
        >
        > For what language does it not work?
        >
        > > and if you need it for some other filetype you need to
        > > set it in a filetype plugin. no big deal it may seem, but writing a lot
        > > of filetype plugins only to support such a simple thing seems a bit
        > > overkill at the very least.
        >
        > Setting options like 'commentstring' is precisely what filetype plugins
        > are for. Other solutions may be smaller/quicker at first, but you
        > always end up with adding more settings later and creating a mess.
        >
        Yes. But generating a file that contains only this for filetypes such
        as screen and modconf and so on seems a bit silly.
        > > my suggestions is thus, make commentstring use the 'comments' option.
        > > this way it becomes language neutral.
        >
        > Since 'comments' is a list with possibly many entries, it's not at all
        > clear which one should be used for inserting a marker with a comment.
        > You could use the first entry, but that might conflict with a carefully
        > tuned ordering of entries in 'comments'. For example, how would one
        > specify to use "//" or "/* */" comments without changing the 'comments'
        > option?
        >
        Well since // is :// in comments and /* is b:/* and */ is e:*/ it's
        easy. hard to specify // though, as it doesn't have a name. but my
        point is, if you set 'comments' to something viable, 'commentstring'
        should work automatically. However, i see your point, and i spose it
        really isn't a big big deal.

        oh well,
        nikolai


        --
        ::: name: Nikolai Weibull :: aliases: pcp / lone-star :::
        ::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
        ::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
        main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
      • Dorai Sitaram
        When the lisp option is on, iskeyword implicitly includes the `- (hyphen) character. It may be similarly advisable to implicitly remove `t from
        Message 3 of 23 , Apr 2, 2003
          When the 'lisp' option is on, 'iskeyword'
          implicitly includes the `-' (hyphen) character.

          It may be similarly advisable to implicitly
          remove `t' from 'formatoptions' whenever 'lisp' is on,
          because it makes no sense to autowrap or paragraph-fill
          lisp code (or any code for that matter).

          --d

          p.s. Now that the lisp indentation is fixed with patch
          6.1.430, my earlier indent/scheme.vim plugin
          script can be removed from the vim distribution.
          Filetypes `lisp', `scheme' (and possibly `art') just
          need to have a standard or user ftplugin's that
          remember to do

          setlocal lisp

          I am in the process of reorganizing my plugins for
          `art' and `scheme'
          (http://www.ccs.neu.edu/~dorai/vimplugins/vimplugins.html),
          so that they reflect the new and improved 'lisp'
          option. Thanks, Bram.
        • Bram Moolenaar
          ... I actually don t like side effects like this. That - is added to keyword characters isn t very nice either, but this was done a long time ago and
          Message 4 of 23 , Apr 3, 2003
            Dorai wrote:

            > When the 'lisp' option is on, 'iskeyword'
            > implicitly includes the `-' (hyphen) character.
            >
            > It may be similarly advisable to implicitly
            > remove `t' from 'formatoptions' whenever 'lisp' is on,
            > because it makes no sense to autowrap or paragraph-fill
            > lisp code (or any code for that matter).

            I actually don't like side effects like this. That "-" is added to
            keyword characters isn't very nice either, but this was done a long time
            ago and removing it again is not a good idea now.

            Removing "t" from 'formatoptions' could be done in a filetype plugin.

            > p.s. Now that the lisp indentation is fixed with patch
            > 6.1.430, my earlier indent/scheme.vim plugin
            > script can be removed from the vim distribution.

            Are you sure? The scheme.vim file looks rather complicated. Is this
            now fully done by the built-in lisp indentation?

            > Filetypes `lisp', `scheme' (and possibly `art') just
            > need to have a standard or user ftplugin's that
            > remember to do
            >
            > setlocal lisp

            There is no lisp or scheme filetype plugin yet...

            > I am in the process of reorganizing my plugins for
            > `art' and `scheme'
            > (http://www.ccs.neu.edu/~dorai/vimplugins/vimplugins.html),
            > so that they reflect the new and improved 'lisp'
            > option. Thanks, Bram.

            Please submit them to me when they have been tested.

            --
            Vim is like Emacs without all the typing. (John "Johann" Spetz)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
          • Dorai Sitaram
            ... Fair enough. I don t like the fact that iskeyword gets an implicit - without isident also getting an implicit -. Essentially, a lisp ftplugin should do
            Message 5 of 23 , Apr 3, 2003
              Bram:
              >
              > Dorai wrote:
              >
              > > When the 'lisp' option is on, 'iskeyword'
              > > implicitly includes the `-' (hyphen) character.
              > >
              > > It may be similarly advisable to implicitly
              > > remove `t' from 'formatoptions' whenever 'lisp' is on,
              > > because it makes no sense to autowrap or paragraph-fill
              > > lisp code (or any code for that matter).
              >
              > I actually don't like side effects like this. That "-" is added to
              > keyword characters isn't very nice either, but this was done a long time
              > ago and removing it again is not a good idea now.
              >
              > Removing "t" from 'formatoptions' could be done in a filetype plugin.

              Fair enough. I don't like the fact that iskeyword gets
              an implicit - without isident also getting an
              implicit -. Essentially, a lisp ftplugin should do

              let &l:isident = &iskeyword

              after it sets iskeyword (because the set of identifiers
              and the set of keywords in a Lisp is identical).
              But these can be taken care of in an ftplugin as you
              say.

              > > p.s. Now that the lisp indentation is fixed with patch
              > > 6.1.430, my earlier indent/scheme.vim plugin
              > > script can be removed from the vim distribution.
              >
              > Are you sure? The scheme.vim file looks rather complicated. Is this
              > now fully done by the built-in lisp indentation?

              Yes. I wrote scheme.vim to be a bug-fixed replacement
              for the built-in lispindent, which was otherwise
              just fine. Now that you've fixed the built-in,
              scheme.vim has become obsolete, and the vim
              distribution can therefore be so much the smaller!

              > > I am in the process of reorganizing my plugins for
              > > `art' and `scheme'
              > > (http://www.ccs.neu.edu/~dorai/vimplugins/vimplugins.html),
              > > so that they reflect the new and improved 'lisp'
              > > option. Thanks, Bram.
              >
              > Please submit them to me when they have been tested.

              Will do. BTW, I notice that currently syntax/lisp.vim
              (by Dr Charles E. Campbell) sets iskeyword, which it
              looks like is not something a syntax file should do.
              (For it is conceivable that a user didn't request
              syntax-highlighting, but they would nevertheless want
              the correct iskeyword value for ordinary navigation.)

              Setting iskeyword really belongs to (a currently
              unprovided) ftplugin/lisp.vim.
            • Charles E. Campbell
              ... The problem here: has a large list of things that are recognized by syn keyword ... , including * ** + ++
              Message 6 of 23 , Apr 3, 2003
                On Thu, Apr 03, 2003 at 04:01:24PM -0500, Dorai Sitaram wrote:
                > BTW, I notice that currently syntax/lisp.vim (by Dr Charles E.
                > Campbell) sets iskeyword, which it looks like is not something a
                > syntax file should do. (For it is conceivable that a user didn't
                > request syntax-highlighting, but they would nevertheless want the
                > correct iskeyword value for ordinary navigation.)
                ---------------------------------------------------------------------

                The problem here: <lisp.vim> has a large list of things that are
                recognized by "syn keyword ...", including

                * ** + ++ < <= add-method find-symbol princ-to-string ...

                Basically, iskeyword must include a number of symbols for all the Common
                Lisp keywords to be recognized. I could put code in to check that the
                necessary additional symbols are in isk: and "finish" <lisp.vim> early
                if they aren't, but I'm sure I'd get a lot of complaints about the
                syntax highlighting not working then. Unless, of course, this
                statement

                setlocal iskeyword=42,43,45,47-58,60-62,64-90,97-122,_

                was put into a vim61/ftplugin/lisp.vim and made part of the
                distribution. In that case <syntax/lisp.vim> could have that code
                elided.

                Regards,
                C Campbell

                --
                Charles E Campbell, Jr, PhD _ __ __
                Goddard Space Flight Center / /_/\_\_/ /
                cec@... /_/ \/_//_/
                PGP public key: http://www.erols.com/astronaut/pgp.html
              • Dorai Sitaram
                I wrote ... Hm, turns out that the character / can t be in isident , even if it can be in iskeyword , so the above assignment will ruin the write to
                Message 7 of 23 , Apr 3, 2003
                  I wrote
                  > Essentially, a lisp ftplugin should do
                  >
                  > let &l:isident = &iskeyword
                  >
                  > after it sets iskeyword (because the set of identifiers
                  > and the set of keywords in a Lisp is identical).

                  Hm, turns out that the character / can't be in
                  'isident', even if it can be in 'iskeyword', so the
                  above assignment will ruin the write to .viminfo.

                  It's too bad / can't be in 'isident' for Lisps, where
                  identifiers are allowed to have /. But probably
                  not earth-shatteringly bad.
                • Dave Eggum
                  The README.txt file in the distribution has an INFORMATION section that needs to be corrected. Current: INFORMATION The latest news about Vim can be found on
                  Message 8 of 23 , Apr 3, 2003
                    The README.txt file in the distribution has an "INFORMATION" section that
                    needs to be corrected.

                    Current:

                    INFORMATION

                    The latest news about Vim can be found on the Vim home page:
                    http://vim.sf.org/

                    If you have problems, have a look at the Vim FAQ:
                    http://www.vim.org/faq/

                    Should be:

                    INFORMATION

                    The latest news about Vim can be found on the Vim home page:
                    http://vim.sf.net/

                    If you have problems, have a look at the Vim FAQ:
                    http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl

                    -- Dave
                  • Aschwin Marsman
                    ... Why not use www.vim.org? ... Is it not better to move/copy the faq to www.vim.org/faq? ... Have a nice weekend, Aschwin Marsman -- aYniK Software Solutions
                    Message 9 of 23 , Apr 4, 2003
                      On Thu, 3 Apr 2003, Dave Eggum wrote:

                      > The README.txt file in the distribution has an "INFORMATION" section that
                      > needs to be corrected.
                      >
                      > Current:
                      >
                      > INFORMATION
                      >
                      > The latest news about Vim can be found on the Vim home page:
                      > http://vim.sf.org/
                      >
                      > If you have problems, have a look at the Vim FAQ:
                      > http://www.vim.org/faq/
                      >
                      > Should be:
                      >
                      > INFORMATION
                      >
                      > The latest news about Vim can be found on the Vim home page:
                      > http://vim.sf.net/

                      Why not use www.vim.org?

                      > If you have problems, have a look at the Vim FAQ:
                      > http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl

                      Is it not better to move/copy the faq to www.vim.org/faq?

                      > -- Dave

                      Have a nice weekend,

                      Aschwin Marsman

                      --
                      aYniK Software Solutions all You need is Knowledge
                      Bedrijvenpark Twente 305 NL-7602 KL Almelo - the Netherlands
                      P.O. box 134 NL-7600 AC Almelo - the Netherlands
                      telephone: +31 (0)546-581400 fax: +31 (0)546-581401
                      a.marsman@... http://www.aYniK.com
                    • Bram Moolenaar
                      ... If you carefully read the explanation of isident you will see it is not at all related to the file being edited. ... Great, scheme.vim goes to the
                      Message 10 of 23 , Apr 4, 2003
                        Dorai wrote:

                        > Fair enough. I don't like the fact that iskeyword gets
                        > an implicit - without isident also getting an
                        > implicit -. Essentially, a lisp ftplugin should do
                        >
                        > let &l:isident = &iskeyword

                        If you carefully read the explanation of 'isident' you will see it is
                        not at all related to the file being edited.

                        > > > p.s. Now that the lisp indentation is fixed with patch
                        > > > 6.1.430, my earlier indent/scheme.vim plugin
                        > > > script can be removed from the vim distribution.
                        > >
                        > > Are you sure? The scheme.vim file looks rather complicated. Is this
                        > > now fully done by the built-in lisp indentation?
                        >
                        > Yes. I wrote scheme.vim to be a bug-fixed replacement
                        > for the built-in lispindent, which was otherwise
                        > just fine. Now that you've fixed the built-in,
                        > scheme.vim has become obsolete, and the vim
                        > distribution can therefore be so much the smaller!

                        Great, scheme.vim goes to the trashcan.

                        > Will do. BTW, I notice that currently syntax/lisp.vim
                        > (by Dr Charles E. Campbell) sets iskeyword, which it
                        > looks like is not something a syntax file should do.

                        That's right, syntax files should leave 'iskeyword' alone. But Lisp is
                        a special case...

                        > Setting iskeyword really belongs to (a currently
                        > unprovided) ftplugin/lisp.vim.

                        Considering the circumstances, 'iskeyword' needs to be set both in the
                        Lisp syntax file and the filetype plugin.

                        --
                        ARTHUR: What?
                        BLACK KNIGHT: None shall pass.
                        ARTHUR: I have no quarrel with you, good Sir knight, but I must cross
                        this bridge.
                        BLACK KNIGHT: Then you shall die.
                        The Quest for the Holy Grail (Monty Python)

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                        \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                      • Bram Moolenaar
                        ... Since the :syn keyword commands depend on this specific value of iskeyword , setting the option should be in the syntax file. Someone might avoid using
                        Message 11 of 23 , Apr 4, 2003
                          Charles Campbell wrote:

                          > The problem here: <lisp.vim> has a large list of things that are
                          > recognized by "syn keyword ...", including
                          >
                          > * ** + ++ < <= add-method find-symbol princ-to-string ...
                          >
                          > Basically, iskeyword must include a number of symbols for all the Common
                          > Lisp keywords to be recognized. I could put code in to check that the
                          > necessary additional symbols are in isk: and "finish" <lisp.vim> early
                          > if they aren't, but I'm sure I'd get a lot of complaints about the
                          > syntax highlighting not working then. Unless, of course, this
                          > statement
                          >
                          > setlocal iskeyword=42,43,45,47-58,60-62,64-90,97-122,_
                          >
                          > was put into a vim61/ftplugin/lisp.vim and made part of the
                          > distribution. In that case <syntax/lisp.vim> could have that code
                          > elided.

                          Since the ":syn keyword" commands depend on this specific value of
                          'iskeyword', setting the option should be in the syntax file. Someone
                          might avoid using the Lisp filetype plugin for some reason, or it might
                          be out-of-sync with the syntax file.

                          Best is to avoid Lisp completely! :-)

                          --
                          ARTHUR: Shut up! Will you shut up!
                          DENNIS: Ah, now we see the violence inherent in the system.
                          ARTHUR: Shut up!
                          DENNIS: Oh! Come and see the violence inherent in the system!
                          HELP! HELP! I'm being repressed!
                          The Quest for the Holy Grail (Monty Python)

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                          \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                        • Bram Moolenaar
                          ... (www.vim.org + vim.sf.net) / 2 = vim.sf.org? I ll make it www.vim.org. ... I prefer to use: http://vimdoc.sf.net/vimfaq.html I ll also make a redirection
                          Message 12 of 23 , Apr 4, 2003
                            Dave Eggum wrote:

                            > The README.txt file in the distribution has an "INFORMATION" section that
                            > needs to be corrected.
                            >
                            > Current:
                            >
                            > INFORMATION
                            >
                            > The latest news about Vim can be found on the Vim home page:
                            > http://vim.sf.org/
                            >
                            > If you have problems, have a look at the Vim FAQ:
                            > http://www.vim.org/faq/
                            >
                            > Should be:
                            >
                            > INFORMATION
                            >
                            > The latest news about Vim can be found on the Vim home page:
                            > http://vim.sf.net/

                            (www.vim.org + vim.sf.net) / 2 = vim.sf.org?

                            I'll make it www.vim.org.

                            > If you have problems, have a look at the Vim FAQ:
                            > http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl

                            I prefer to use: http://vimdoc.sf.net/vimfaq.html
                            I'll also make a redirection for http://www.vim.org/faq/.

                            Thanks for reporting these mistakes!

                            --
                            "Hegel was right when he said that we learn from history that man can
                            never learn anything from history." (George Bernard Shaw)

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                          • Dorai Sitaram
                            Bram wrote ... I ve been using [ ctrl-D to jump to definitions (in Lisp), where definitions would be something like (define lisp-is-* *+!$& body of lisp
                            Message 13 of 23 , Apr 4, 2003
                              Bram wrote
                              >
                              > Dorai wrote:
                              >
                              > > Fair enough. I don't like the fact that iskeyword gets
                              > > an implicit - without isident also getting an
                              > > implicit -. Essentially, a lisp ftplugin should do
                              > >
                              > > let &l:isident = &iskeyword
                              >
                              > If you carefully read the explanation of 'isident' you will see it is
                              > not at all related to the file being edited.

                              I've been using [ ctrl-D to jump to definitions (in
                              Lisp), where definitions would be something like

                              (define lisp-is-*</>*+!$&
                              body of lisp procedure
                              etc
                              etc
                              etc)

                              I correspondingly changed 'define' in Lisp to be

                              setl define=^\\s*(def[-a-z]*

                              I guess I've been making 'isident' == 'iskeyword' so
                              that [ ctrl-D will work.

                              Is there any reason why [ ctrl-D doesn't simply
                              use 'iskeyword' rather 'isident' to identify the target
                              token? Even in C, there is no distinction between a
                              valid variable/function name and a valid #DEFINE name.
                            • Bram Moolenaar
                              ... The define searched for here is a C-style define. The Lisp define is something completely different! Try using [ CTRL-I and similar things. ... That was
                              Message 14 of 23 , Apr 5, 2003
                                Dorai wrote:

                                > > > Fair enough. I don't like the fact that iskeyword gets
                                > > > an implicit - without isident also getting an
                                > > > implicit -. Essentially, a lisp ftplugin should do
                                > > >
                                > > > let &l:isident = &iskeyword
                                > >
                                > > If you carefully read the explanation of 'isident' you will see it is
                                > > not at all related to the file being edited.
                                >
                                > I've been using [ ctrl-D to jump to definitions (in
                                > Lisp), where definitions would be something like
                                >
                                > (define lisp-is-*</>*+!$&
                                > body of lisp procedure
                                > etc
                                > etc
                                > etc)
                                >
                                > I correspondingly changed 'define' in Lisp to be
                                >
                                > setl define=^\\s*(def[-a-z]*
                                >
                                > I guess I've been making 'isident' == 'iskeyword' so
                                > that [ ctrl-D will work.

                                The "define" searched for here is a C-style define. The Lisp define is
                                something completely different!

                                Try using [ CTRL-I and similar things.

                                > Is there any reason why [ ctrl-D doesn't simply
                                > use 'iskeyword' rather 'isident' to identify the target
                                > token? Even in C, there is no distinction between a
                                > valid variable/function name and a valid #DEFINE name.

                                That was perhaps not a good choice. Especially because 'isident' is
                                global, thus not for a specific language. Changing this now will
                                probably cause incompatibilities...

                                --
                                Trees moving back and forth is what makes the wind blow.

                                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                                \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                              • Andrew Pimlott
                                ... Not related to the original topic, but may I plead that ftplugins not mess with formatoptions? They are mostly non-language-specific, and it is quite
                                Message 15 of 23 , Apr 5, 2003
                                  On Thu, Apr 03, 2003 at 10:27:35PM +0200, Bram Moolenaar wrote:
                                  > Removing "t" from 'formatoptions' could be done in a filetype plugin.

                                  Not related to the original topic, but may I plead that ftplugins
                                  not mess with formatoptions? They are mostly non-language-specific,
                                  and it is quite frustrating to have ones preferences overridden
                                  unexpectedly. I expecte ftplugins to set up only things that are
                                  "obviously" appropriate to the language.

                                  I complained to the Perl ftplugin author about this, and he pointed
                                  out that it was copied from the C ftplugin. It seems to have spread
                                  to many others. It may be a big change to pull it out now, but I
                                  really find it unfriendly.

                                  Andrew
                                • Dorai Sitaram
                                  ... The problem is that the default value of fo , which contains t , is geared to natural-language text, while removing t is always the right thing for all
                                  Message 16 of 23 , Apr 5, 2003
                                    Andrew Pimlott wrote:
                                    >
                                    > On Thu, Apr 03, 2003 at 10:27:35PM +0200, Bram Moolenaar wrote:
                                    > > Removing "t" from 'formatoptions' could be done in a filetype plugin.
                                    >
                                    > Not related to the original topic, but may I plead that ftplugins
                                    > not mess with formatoptions? They are mostly non-language-specific,
                                    > and it is quite frustrating to have ones preferences overridden
                                    > unexpectedly. I expecte ftplugins to set up only things that are
                                    > "obviously" appropriate to the language.

                                    The problem is that the default value of 'fo', which
                                    contains "t", is geared to natural-language text, while
                                    removing "t" is always the right thing for all
                                    programming-language text. Thus, while you are right
                                    that setl fo-=t is not programming-language-specific,
                                    every programming-language filetype has perforce to do
                                    it via an ftplugin or somehow...

                                    It may be conceptually economical to have 'fo'
                                    not contain "t" by default, and then have a
                                    natural-language filetype be the only filetype that
                                    explicitly does setl fo+=t. But identifying a
                                    natural-language filetype is a nightmare.


                                    > I complained to the Perl ftplugin author about this, and he pointed
                                    > out that it was copied from the C ftplugin. It seems to have spread
                                    > to many others. It may be a big change to pull it out now, but I
                                    > really find it unfriendly.
                                    >
                                  • Andrew Pimlott
                                    ... % cat .vim/after/ftplugin/perl.vim undo obnoxious changes in the default ftplugin set formatoptions+=t set formatoptions-=o You were saying? ;-) I
                                    Message 17 of 23 , Apr 5, 2003
                                      On Sat, Apr 05, 2003 at 10:36:40PM -0500, Dorai Sitaram wrote:
                                      > The problem is that the default value of 'fo', which
                                      > contains "t", is geared to natural-language text, while
                                      > removing "t" is always the right thing for all
                                      > programming-language text. Thus, while you are right
                                      > that setl fo-=t is not programming-language-specific,
                                      > every programming-language filetype has perforce to do
                                      > it via an ftplugin or somehow...

                                      % cat .vim/after/ftplugin/perl.vim
                                      " undo obnoxious changes in the default ftplugin
                                      set formatoptions+=t
                                      set formatoptions-=o

                                      You were saying? ;-)

                                      I understand your point that there is no common place to set options
                                      for programming languages. Maybe there should be--then users could
                                      set their programming language preferences there, and ftplugins
                                      wouldn't have to worry about it. But if every programming language
                                      ftplugin takes matters into its own hands, users no longer have
                                      control of their settings.

                                      If you wonder why I like +t, it's because long lines are
                                      aesthetically offensive and a pain to work with, and I would rather
                                      (temporarily) have a line break in a random place than a long line.
                                      Either way, I have to fix it up.

                                      Andrew
                                    • Bram Moolenaar
                                      ... The idea of the filetype plugins is that they make settings works as well as possible for the specific language, and leave generic settings alone.
                                      Message 18 of 23 , Apr 6, 2003
                                        Andrew Pimlott wrote:

                                        > On Thu, Apr 03, 2003 at 10:27:35PM +0200, Bram Moolenaar wrote:
                                        > > Removing "t" from 'formatoptions' could be done in a filetype plugin.
                                        >
                                        > Not related to the original topic, but may I plead that ftplugins
                                        > not mess with formatoptions? They are mostly non-language-specific,
                                        > and it is quite frustrating to have ones preferences overridden
                                        > unexpectedly. I expecte ftplugins to set up only things that are
                                        > "obviously" appropriate to the language.
                                        >
                                        > I complained to the Perl ftplugin author about this, and he pointed
                                        > out that it was copied from the C ftplugin. It seems to have spread
                                        > to many others. It may be a big change to pull it out now, but I
                                        > really find it unfriendly.

                                        The idea of the filetype plugins is that they make settings works as
                                        well as possible for the specific language, and leave generic settings
                                        alone.

                                        'formatoptions' is both generic and specific for a language. Generally,
                                        in a programming language you would want to break comment lines, but not
                                        code lines. Thus you would remove 't' from 'formatoptions'.
                                        The 'textwidth' option should not be set, since there is no relation
                                        between a language and line lenght (well, except for Cobol perhaps).

                                        Sometimes the filetype plugin will set things that you don't like. You
                                        can either make a copy and change it, dropping it in your ftplugin
                                        directory, or write a script that just corrects the few things you don't
                                        like and drop it in after/ftplugin.

                                        --
                                        Mental Floss prevents moral decay!

                                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                        \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                                      • Andrew Pimlott
                                        ... I already explained that I disagree about this case. Given that there are people who always want t in formatoptions, don t you think that they will be
                                        Message 19 of 23 , Apr 6, 2003
                                          On Sun, Apr 06, 2003 at 12:54:16PM +0200, Bram Moolenaar wrote:
                                          > The idea of the filetype plugins is that they make settings works as
                                          > well as possible for the specific language, and leave generic settings
                                          > alone.
                                          >
                                          > 'formatoptions' is both generic and specific for a language. Generally,
                                          > in a programming language you would want to break comment lines, but not
                                          > code lines. Thus you would remove 't' from 'formatoptions'.

                                          I already explained that I disagree about this case. Given that
                                          there are people who always want 't' in formatoptions, don't you
                                          think that they will be surprised to find their setting not working
                                          when editing code? Honestly, if I were a vim novice, I would never
                                          think to look in filetype plugins, because formatoptions is
                                          "obviously" (to me) not related to filetype.

                                          I understand the desire to make things pleasant for the majority of
                                          users, but realize that some minority of users will be frustrated.

                                          Besides, would you agree at least that ftplugins shouldn't set
                                          "croql"? Since those don't adversely affect plain text editing, any
                                          user who wants them can set them in his .vimrc. Taking those out of
                                          the ftplugins would be an improvement.

                                          > The 'textwidth' option should not be set, since there is no relation
                                          > between a language and line lenght (well, except for Cobol perhaps).
                                          >
                                          > Sometimes the filetype plugin will set things that you don't like. You
                                          > can either make a copy and change it, dropping it in your ftplugin
                                          > directory, or write a script that just corrects the few things you don't
                                          > like and drop it in after/ftplugin.

                                          Yes, but for settings like formatoptions, I potentially have to do
                                          this for every single language.

                                          Andrew
                                        • Bram Moolenaar
                                          ... How text is formatted certainly depends on the kind of text to be formatted. Thus filetype plugins are expected to adjust formatoptions to how text in
                                          Message 20 of 23 , Apr 6, 2003
                                            Andrew Pimlott wrote:

                                            > On Sun, Apr 06, 2003 at 12:54:16PM +0200, Bram Moolenaar wrote:
                                            > > The idea of the filetype plugins is that they make settings works as
                                            > > well as possible for the specific language, and leave generic settings
                                            > > alone.
                                            > >
                                            > > 'formatoptions' is both generic and specific for a language. Generally,
                                            > > in a programming language you would want to break comment lines, but not
                                            > > code lines. Thus you would remove 't' from 'formatoptions'.
                                            >
                                            > I already explained that I disagree about this case. Given that
                                            > there are people who always want 't' in formatoptions, don't you
                                            > think that they will be surprised to find their setting not working
                                            > when editing code? Honestly, if I were a vim novice, I would never
                                            > think to look in filetype plugins, because formatoptions is
                                            > "obviously" (to me) not related to filetype.

                                            How text is formatted certainly depends on the kind of text to be
                                            formatted. Thus filetype plugins are expected to adjust 'formatoptions'
                                            to how text in this filetype is to be formatted. Avoiding personal
                                            preferences is also a goal, there might be a conflict here.

                                            There is always the problem that someone doesn't understand how the
                                            automatic mechanism works, but that isn't a sufficient reason to omit
                                            the automatic mechanism completely.

                                            > I understand the desire to make things pleasant for the majority of
                                            > users, but realize that some minority of users will be frustrated.
                                            >
                                            > Besides, would you agree at least that ftplugins shouldn't set
                                            > "croql"? Since those don't adversely affect plain text editing, any
                                            > user who wants them can set them in his .vimrc. Taking those out of
                                            > the ftplugins would be an improvement.

                                            The filetype plugins should set the options that make most people happy.
                                            There will always be a minority that wants it otherwise. If we would
                                            remove all settings from filetype plugins that a minority doesn't like,
                                            we probably end up with empty filetype plugins.

                                            My estimation is that most peoople do like the way how the C plugin sets
                                            'formatoptions'. This is based on the lack of comments.

                                            > > Sometimes the filetype plugin will set things that you don't like. You
                                            > > can either make a copy and change it, dropping it in your ftplugin
                                            > > directory, or write a script that just corrects the few things you don't
                                            > > like and drop it in after/ftplugin.
                                            >
                                            > Yes, but for settings like formatoptions, I potentially have to do
                                            > this for every single language.

                                            Only for those where the filetype plugin writer thought it was
                                            appropriate for the language to be formatted in a specific way. There
                                            is only a dozen currently, and you might even like some of them.

                                            --
                                            Q: How do you tell the difference between a female cat and a male cat?
                                            A: You ask it a question and if HE answers, it's a male but, if SHE
                                            answers, it's a female.

                                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                                            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                                          • Andrew Pimlott
                                            ... Good idea, thanks! Andrew
                                            Message 21 of 23 , Apr 6, 2003
                                              On Sun, Apr 06, 2003 at 01:54:09PM -0400, Dorai Sitaram wrote:
                                              > Looks to me like if you always want t in fo, then
                                              >
                                              > au filetype * setl fo+=t
                                              >
                                              > in .vimrc

                                              Good idea, thanks!

                                              Andrew
                                            • Dorai Sitaram
                                              Andrew wrote ... Looks to me like if you always want t in fo, then au filetype * setl fo+=t in .vimrc or via a plugin (not filetype-plugin), should do what you
                                              Message 22 of 23 , Apr 6, 2003
                                                Andrew wrote
                                                >
                                                > On Sun, Apr 06, 2003 at 12:54:16PM +0200, Bram Moolenaar wrote:
                                                > > 'formatoptions' is both generic and specific for a language. Generally,
                                                > > in a programming language you would want to break comment lines, but not
                                                > > code lines. Thus you would remove 't' from 'formatoptions'.
                                                >
                                                > I already explained that I disagree about this case. Given that
                                                > there are people who always want 't' in formatoptions, don't you
                                                > think that they will be surprised to find their setting not working
                                                > when editing code?
                                                >
                                                > > Sometimes the filetype plugin will set things that you don't like. You
                                                > > can either make a copy and change it, dropping it in your ftplugin
                                                > > directory, or write a script that just corrects the few things you don't
                                                > > like and drop it in after/ftplugin.
                                                >
                                                > Yes, but for settings like formatoptions, I potentially have to do
                                                > this for every single language.

                                                Looks to me like if you always want t in fo, then

                                                au filetype * setl fo+=t

                                                in .vimrc or via a plugin (not filetype-plugin), should
                                                do what you want, without your having to keep track of
                                                all the filetypes to correct for.
                                              Your message has been successfully submitted and would be delivered to recipients shortly.