RE: comment feature request
> From: Bram@... [mailto:Bram@...]Well... I think this would be a generic solution that almost always works.
> > 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.
> Using the first s/m/e entry of 'comments' is just guessing. Why not theAgreed. Perhaps a better solution is to add a 'c' flag (horrors!) which
> 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.
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 aWell... the script would have to correctly parse 'comments', which isn't
> ":Comment" command as well.
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. SomeIf they want to use "//" for block comments, then they would be sure to not
> 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...
have a "c" flag in the s,m,e group.
> > This methodology would also be useful for uncommenting a block. If the*cheers*
> > 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
> > Also, :[range]iscomment would return a 1 or 0, determining whether thePerhaps I am... though I can see how many plugins (and syntax files) could
> > line(s) begin with a comment character or not.
> Let's not get carried away with all nice things we could add to Vim!
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.
- On Fri, 06 Sep 2002 at 15:08:14 -0700, Dave Eggum wrote:
>> From: Bram@... [mailto:Bram@...]My 2 cents:
>> 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.
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, 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, 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.)
 barring big changes in the functionality of 'comments'.
 To make it easier to use, you could have the filetype plugin map
<LocalLeader>/ and <LocalLeader>* to each style of commentifying.
Today's subliminal thought is:
> From: Piet Delport [mailto:pjd@...]...
> For one, consider filetypes whose comments can't be easily described byAgreed. However, this also means that VIM cannot format comments for these
> '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.
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
> Also, consider C/C++ with its two types of comments. With a userBasically, my proposed answer is to modify the 'comments' setting to allow
> command you could have it take an argument to choose whether to comment
> a block using // or /* * */ -style comments, but how would :comment
> know which to use?
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.