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

Re: Comments feature request *again*

Expand Messages
  • Mikolaj Machowski
    ... Cannot agree. In VimL is one real bottleneck: lists processing. Please, please, oh please add lists/tables functions in 6.3: split() join() tablen()
    Message 1 of 12 , Nov 18, 2003
    • 0 Attachment
      Dnia Monday 17 of November 2003 22:25, Steve Hall napisaƂ:
      > Besides, Vim's scripting language is blazing fast, I've never had a
      > problem with speed on a slowish box despite tens of thousands script
      > lines in my configuration.

      Cannot agree. In VimL is one real bottleneck: lists processing. Please,
      please, oh please add lists/tables functions in 6.3:
      split()
      join()
      tablen()
      append()
      insert()
      remove()
      sort()
      reverse()
      index()

      m.
      --
      In the beginning was The Word.
      And The Word was Content-Type: text/plain
    • Benji Fisher
      ... May I not-so-humbly suggest using matchit.vim as a model? It is customized by using buffer-local variables, which can be defined in filetype plugins.
      Message 2 of 12 , Nov 18, 2003
      • 0 Attachment
        On Mon, Nov 17, 2003 at 04:49:02PM -0600, GI wrote:
        > > It's always a good idea to return bug fixes and feature additions to a
        > > body of source code to the original author so he can incorporate them
        > > if he wants. It's also practically the best way for those of us
        > > downstream to take advantage of your valuable effort. :)
        >
        > will do! i might just rewrite from ground up, in which case i'll upload
        > it to www.vim.org/scripts
        >
        > > Commenting standards are impossible to establish since there are many
        > > justifiable methods by which code can be commented in most languages.
        > > Trying is a great way to start a flame war, however. :))
        >
        > agreed. i want no no flame wars ;)

        May I not-so-humbly suggest using matchit.vim as a model? It is
        customized by using buffer-local variables, which can be defined in
        filetype plugins. There may be some obfuscated sections of the code,
        but there are no huge if/else/endif blocks. Not only comment strings,
        but also flags for how to handle indenting, etc., can be customized this
        way. (I would suggest using the 'commentstring' option as a one
        default, to encourage ftplugin writers to set it.)

        Once the script works well, and many people start to use it, it
        makes sense to lobby for inclusion in the standard distribution. Since
        matchit.vim changes the default behavior of % , it is distributed under
        macros/ , but a script that only defines a few functions and commands
        might be made a standard plugin.

        --Benji Fisher
      • Keith Roberts
        ... I agree! I agree! I agree! ... You *definitely* want to use constructs which can be changed/set in ftplugins, because each language defines and handles
        Message 3 of 12 , Nov 18, 2003
        • 0 Attachment
          >-----Original Message-----
          >From: Benji Fisher [mailto:benji@...]
          >Sent: Tuesday, November 18, 2003 6:23 AM
          >To: Vim Dev
          >Subject: Re: Comments feature request *again*
          >
          >On Mon, Nov 17, 2003 at 04:49:02PM -0600, GI wrote:
          >>
          >> > Commenting standards are impossible to establish since there are many
          >> > justifiable methods by which code can be commented in most languages.
          >> > Trying is a great way to start a flame war, however. :))
          >>
          >> agreed. i want no no flame wars ;)
          >
          > May I not-so-humbly suggest using matchit.vim as a model? It is
          >customized by using buffer-local variables, which can be defined in
          >filetype plugins. There may be some obfuscated sections of the code,
          >but there are no huge if/else/endif blocks. Not only comment strings,
          >but also flags for how to handle indenting, etc., can be customized this
          >way. (I would suggest using the 'commentstring' option as a one
          >default, to encourage ftplugin writers to set it.)

          I agree! I agree! I agree!

          > Once the script works well, and many people start to use it, it
          >makes sense to lobby for inclusion in the standard distribution. Since
          >matchit.vim changes the default behavior of % , it is distributed under
          >macros/ , but a script that only defines a few functions and commands
          >might be made a standard plugin.

          You *definitely* want to use constructs which can be changed/set in
          ftplugins, because each language defines and handles comments differently.

          And you should allow the user to specify whether to comment at column 0 (eg,
          0i#) or at the current indent level (eg, I#) ... where # is obviously the
          comment char. [If I 'comment out' a section of code, I want the comment
          char inserted at bol, not at the current indent.] And if you have to 'move'
          current text (ie, if there is something other than a comment_char where you
          are putting it), do you add whitespace after it, attempt to align with
          previous line (if also a comment), or neither. And if there is a
          comment_char there, do you do nothing, change it to the specified
          comment_char if different, or insert a new comment_char (and maybe
          whitespace) in front of it?

          Then there's the case where more than one char can act as a comment
          identifier ... perhaps b:comment_char1 and b:comment_char2 (in my language,
          both of [*!] delimit comments if they are the 1st non-white char in a
          command.

          Some of these things it is already possible to specify (I think) via
          'comments' and 'commentstring'; some of it would have to be specified as
          function args or b:variables.
        • GI
          ... Hey. so I looked at matchit.vim. I m not sure how i can extract comment markers from the info there ... ... unless ofcourse you meant the general structure
          Message 4 of 12 , Nov 18, 2003
          • 0 Attachment
            > > will do! i might just rewrite from ground up, in which case i'll
            > > upload it to www.vim.org/scripts

            > May I not-so-humbly suggest using matchit.vim as a model?

            Hey. so I looked at matchit.vim. I'm not sure how i can extract comment
            markers from the info there ...

            > It is customized by using buffer-local variables, which can be defined
            > in filetype plugins.

            unless ofcourse you meant the general structure of buffer-local
            variables, which can be defined in filetype plugins. that sounds like a
            neat idea, and i was thinking along those lines. as you pointed out,
            defaulting to commentstrings might be a good alternative to icky huge
            if/elseif trees. this issue was raised previously, and i'll go read
            peoples objections to it. also if anyone has current objections / words
            of wisdom, please let me know. i'm a vim-dev newbie ;)

            > Not only comment strings, but also flags for how to handle indenting,
            > etc., can be customized this way.

            yep. will try and keep in mind.

            > Once the script works well, and many people start to use it, it
            > makes sense to lobby for inclusion in the standard distribution. Since
            > matchit.vim changes the default behavior of % , it is distributed under
            > macros/ , but a script that only defines a few functions and commands
            > might be made a standard plugin.

            so is that the standard coding procedure? i have a few 'vim-newbie'
            questions on that line: do you have any 'feature-list' kind of system,
            where you assign people to tasks? how's the coordination done etc. i
            searched hard on the website, and couldnt find any information.

            i updated the mail.vim syntax file to highlight url's and quoted
            signatures etc. i wasn't sure what to do with that, so i just uploaded
            it to the scripts section. that ok? or should i have sent it somewhere
            else?

            GI
          • Thomas S. Urban
            On Tue, Nov 18, 2003 at 20:13:38, GI spake thusly: ... You could send the changes to the maintainer of mail.vim; his email is an the top of the file in
            Message 5 of 12 , Nov 18, 2003
            • 0 Attachment
              On Tue, Nov 18, 2003 at 20:13:38, GI spake thusly:
              <snip>
              > i updated the mail.vim syntax file to highlight url's and quoted
              > signatures etc. i wasn't sure what to do with that, so i just uploaded
              > it to the scripts section. that ok? or should i have sent it somewhere
              > else?

              You could send the changes to the maintainer of mail.vim; his email is
              an the top of the file in my distribution. If you don't get a response,
              you can suggest to this the changes, I suppose.

              --
              Don't read everything you believe.
            • Benji Fisher
              ... I only meant the sort of thing below. ... There are feature requests as well as bugs to be fixed there. I think there is a more recent version on
              Message 6 of 12 , Nov 18, 2003
              • 0 Attachment
                On Tue, Nov 18, 2003 at 08:13:38PM -0600, GI wrote:
                > > > will do! i might just rewrite from ground up, in which case i'll
                > > > upload it to www.vim.org/scripts
                >
                > > May I not-so-humbly suggest using matchit.vim as a model?
                >
                > Hey. so I looked at matchit.vim. I'm not sure how i can extract comment
                > markers from the info there ...

                I only meant the sort of thing below.

                > > It is customized by using buffer-local variables, which can be defined
                > > in filetype plugins.
                >
                > unless ofcourse you meant the general structure of buffer-local
                > variables, which can be defined in filetype plugins. that sounds like a
                > neat idea, and i was thinking along those lines. as you pointed out,
                > defaulting to commentstrings might be a good alternative to icky huge
                > if/elseif trees. this issue was raised previously, and i'll go read
                > peoples objections to it. also if anyone has current objections / words
                > of wisdom, please let me know. i'm a vim-dev newbie ;)
                >
                > > Not only comment strings, but also flags for how to handle indenting,
                > > etc., can be customized this way.
                >
                > yep. will try and keep in mind.
                >
                > > Once the script works well, and many people start to use it, it
                > > makes sense to lobby for inclusion in the standard distribution. Since
                > > matchit.vim changes the default behavior of % , it is distributed under
                > > macros/ , but a script that only defines a few functions and commands
                > > might be made a standard plugin.
                >
                > so is that the standard coding procedure? i have a few 'vim-newbie'
                > questions on that line: do you have any 'feature-list' kind of system,
                > where you assign people to tasks? how's the coordination done etc. i
                > searched hard on the website, and couldnt find any information.

                There is a todo list:

                :help todo

                There are feature requests as well as bugs to be fixed there. I think
                there is a more recent version on ftp.vim.org . Bram Moolenaar is in
                charge of the source code: he decides what goes into the standard
                distribution, and writes more of it than anyone else. Occasionally,
                Bram asks for help with a particular feature, but most of the time,
                someone just sees a need and fills it. Then there are the runtime
                scripts at www.vim.org , a much more democratic system.

                > i updated the mail.vim syntax file to highlight url's and quoted
                > signatures etc. i wasn't sure what to do with that, so i just uploaded
                > it to the scripts section. that ok? or should i have sent it somewhere
                > else?

                That is fine. If a script is small and only does
                stuff-that-I-could-do-myself-if-I-felt-like-it, it is unlikely to get
                much notice. If it is useful and interesting and clever, then a few
                people will give it good ratings, more people will try it, and so on. A
                little promotion helps, too. If you are particularly proud of it, you
                can announce it to the vim users' list, and you can mention it whenever
                someone on that list asks for a feature that you have implemented.

                Your contribution might get used more if you send it to the
                maintainer of the default syntax file. If he likes your additions, they
                will soon be included in the standard distribution, and lots of people
                will start using your ideas.

                Vim has a good set of design goals.

                :help design-goals

                Keep these in mind when making contributions, and remember that "It
                Would Be Nice If" is not considered a good enough reason to make
                something part of the standard distribution.

                HTH --Benji Fisher
              Your message has been successfully submitted and would be delivered to recipients shortly.