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

'commentstring' suggestion.

Expand Messages
  • Nikolai :: lone-star :: Weibull
    lets face it...the commentstring option sucks. it only works well for C like languages, and if you need it for some other filetype you need to set it in a
    Message 1 of 23 , Apr 2, 2003
      lets face it...the 'commentstring' option sucks. it only works well for
      C like languages, 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.
      my suggestions is thus, make commentstring use the 'comments' option.
      this way it becomes language neutral. for example:
      set commentstring=s%se
      which for C would translate to '/*%s*/'. this is probably rather simple
      to implement, and the only problem is backwards compatibility. but that
      isn't really broken, for other languages than those that use comments
      that start with an 's' and end with an 'e'. one could perhaps escape
      the special 'commentstring' related characters in some way, but i
      haven't thought about a reasonable scheme for doing that.
      anyone have thoughts on this?

      enjoy,
      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);}
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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.