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

implicit 'formatoptions' like 'isk' when 'lisp' is on

Expand Messages
  • 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 1 of 23 , Apr 2 11:00 AM
    • 0 Attachment
      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 2 of 23 , Apr 3 12:27 PM
      • 0 Attachment
        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 3 of 23 , Apr 3 1:01 PM
        • 0 Attachment
          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 4 of 23 , Apr 3 1:33 PM
          • 0 Attachment
            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 5 of 23 , Apr 3 2:05 PM
            • 0 Attachment
              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 6 of 23 , Apr 3 2:36 PM
              • 0 Attachment
                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 7 of 23 , Apr 4 1:31 AM
                • 0 Attachment
                  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 8 of 23 , Apr 4 12:32 PM
                  • 0 Attachment
                    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 9 of 23 , Apr 4 12:32 PM
                    • 0 Attachment
                      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 10 of 23 , Apr 4 12:32 PM
                      • 0 Attachment
                        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 11 of 23 , Apr 4 1:15 PM
                        • 0 Attachment
                          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 12 of 23 , Apr 5 12:18 PM
                          • 0 Attachment
                            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 13 of 23 , Apr 5 3:26 PM
                            • 0 Attachment
                              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 14 of 23 , Apr 5 7:36 PM
                              • 0 Attachment
                                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 15 of 23 , Apr 5 8:30 PM
                                • 0 Attachment
                                  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 16 of 23 , Apr 6 3:54 AM
                                  • 0 Attachment
                                    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 17 of 23 , Apr 6 7:50 AM
                                    • 0 Attachment
                                      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 18 of 23 , Apr 6 9:11 AM
                                      • 0 Attachment
                                        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 19 of 23 , Apr 6 10:51 AM
                                        • 0 Attachment
                                          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 20 of 23 , Apr 6 10:54 AM
                                          • 0 Attachment
                                            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.