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

RE: comment feature request

Expand Messages
  • Dave Eggum
    ... Well... I think this would be a generic solution that almost always works. ... Agreed. Perhaps a better solution is to add a c flag (horrors!) which
    Message 1 of 9 , Sep 6, 2002
    • 0 Attachment
      > From: Bram@... [mailto:Bram@...]

      > > But the whole point is to avoid writing something special for
      > each filetype.
      >
      > Turning something into a comment is filetype specific. There is no
      > generic solution that always works.

      Well... I think this would be a generic solution that almost always works.
      :)

      > Using the first s/m/e entry of 'comments' is just guessing. Why not the
      > second or the last one? What if there isn't an s/m/e entry/
      >
      > It also creates a link between the ordering of items in 'comments' and
      > what happens with the ":comment" command. That is undesired, they
      > should be independent.

      Agreed. Perhaps a better solution is to add a 'c' flag (horrors!) which
      determines which comments to use. i.e.

      comments=s0:* -,m0:* ,ex0:*/,s1c:/*,mb:*,ex:*/,c://

      > When 'comments' is given a value, it's not difficult to define a
      > ":Comment" command as well.

      Well... the script would have to correctly parse 'comments', which isn't
      trivial. Vim has already interpreted the string internally (quickly in C),
      it would be a shame to have a slow vim script do it again.

      > Using "//" for comments is illegal in C files, it's a C++ item. Some
      > compilers do allow it though. And some people might want to use "//"
      > comments also for blockwise selection. This soon turns into another
      > options to be selected...

      If they want to use "//" for block comments, then they would be sure to not
      have a "c" flag in the s,m,e group.

      > > This methodology would also be useful for uncommenting a block. If the
      > > specified line(s) begin with any of the comments shown in
      > 'comments', then
      > > :[range]uncomment removes them.
      >
      > This is actually something that can be done with 'comments', because it
      > does specify how comments are recognized, and what is recognized can be
      > removed.

      *cheers*

      > > Also, :[range]iscomment would return a 1 or 0, determining whether the
      > > line(s) begin with a comment character or not.
      >
      > Let's not get carried away with all nice things we could add to Vim!

      Perhaps I am... though I can see how many plugins (and syntax files) could
      use this command when parsing files for their own purposes. Also, adding
      this command would be a no-brainer, since :uncomment would need to determine
      which line is a comment anyway.
    • Piet Delport
      ... My 2 cents: A builtin :(un)comment command is a bad idea. Having a semi-standard filetype-specific :(Un)Comment user command for the filetypes which
      Message 2 of 9 , Sep 7, 2002
      • 0 Attachment
        On Fri, 06 Sep 2002 at 15:08:14 -0700, Dave Eggum wrote:
        >> From: Bram@... [mailto:Bram@...]
        >>
        >> Let's not get carried away with all nice things we could add to Vim!
        >
        > Perhaps I am... though I can see how many plugins (and syntax files) could
        > use this command when parsing files for their own purposes. Also, adding
        > this command would be a no-brainer, since :uncomment would need to determine
        > which line is a comment anyway.

        My 2 cents:

        A builtin :(un)comment command is a bad idea. Having a semi-standard
        filetype-specific :(Un)Comment user command for the filetypes which
        choose to implement it is more flexible and extensible without requiring
        changes to vim itself.

        For one, consider filetypes whose comments can't be easily described by
        'comments', such as (X|SG|HT)ML:

        <!-- test --
        -- foo --
        -- bar -->

        :(un)comment would never be able to handle this[1], but a user command
        could be written to handle it.

        Also, consider C/C++ with its two types of comments. With a user
        command you could have it take an argument to choose whether to comment
        a block using // or /* * */ -style comments[2], but how would :comment
        know which to use? You could have it take an argument too, but since it
        has to be universal, how would the argument work for other filetypes?

        (Now that i think about it, there's also #if 0 in C/C++, which
        effectively works like a comment, and could be supported as such by a
        user :(un)Comment command.)


        [1] barring big changes in the functionality of 'comments'.

        [2] To make it easier to use, you could have the filetype plugin map
        <LocalLeader>/ and <LocalLeader>* to each style of commentifying.

        --
        Piet Delport
        Today's subliminal thought is:
      • Dave Eggum
        ... Agreed. However, this also means that VIM cannot format comments for these file types, as it stands today. ( comments is only used for formatting comments
        Message 3 of 9 , Sep 9, 2002
        • 0 Attachment
          > From: Piet Delport [mailto:pjd@...]
          ...
          > For one, consider filetypes whose comments can't be easily described by
          > 'comments', such as (X|SG|HT)ML:
          >
          > <!-- test --
          > -- foo --
          > -- bar -->
          >
          > :(un)comment would never be able to handle this, but a user command
          > could be written to handle it.

          Agreed. However, this also means that VIM cannot format comments for these
          file types, as it stands today. ('comments' is only used for formatting
          comments so far.) Does this mean that 'comments' shouldn't have been
          implemented? Should we have left it up to each of the filetype plugins to
          format comments?

          > Also, consider C/C++ with its two types of comments. With a user
          > command you could have it take an argument to choose whether to comment
          > a block using // or /* * */ -style comments[2], but how would :comment
          > know which to use?

          Basically, my proposed answer is to modify the 'comments' setting to allow
          for a 'c' flag, which would specify which format to use. If both formats are
          selected, then block-style comments are used if a range is specified, and
          the single line format is used otherwise. See earlier threads for a
          discussion of this.
        Your message has been successfully submitted and would be delivered to recipients shortly.