Walter schrieb:

>> Shouldn't the compiler neglect "/+" and "+/" in included comments and strings when processing nested comments?
> The behavior works as intended, although the manual could say it better.

Of course, that was only a proposal.

So long.
-- 
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ 2EA56D6D4DC41ABA311615946D3248A1

J C Calvarese wrote:

[..]
> Actually, I'm not aware are any syntax editor that treats nested comments as nested comments instead of as block comments. (Please let know if you've found one.)

vim does. I am working on a syntax file for vim. But there is a bug in vim, so that multiple endings must be separated by spaces. Thats how I invented the example.

[...]
> That's a pretty neat idea, but I'm still going to vote for the status quo since I'm lazy and don't want to add any complexity d2html if I don't have to.

If d2html is properly designed, then it should be neglectible work, as in vim. The declaration for the nestable comment is:

| syn region  CommentSlashPlus	start="/+" end="+/"
| contains= CommentSlashPlus

Adding the other comments and strings would change it to

| syn region  CommentSlashPlus	start="/+" end="+/"
| contains= Comment, String

Do you really think, that this is a complex task?

So long.
-- 
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ 2EA56D6D4DC41ABA311615946D3248A1

Walter wrote:

[...]
>> An unimplemented compiler is an unpopular one.
> Yes.

Don't get me wrong.
The message subject contains "[Style Guide]".
I wouldn't have posted it, when the style guide wouldn't contain the
proposal of commenting out comments and strings.

Nested comments are a beautiful idea by itself.

So long.
-- 
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ 2EA56D6D4DC41ABA311615946D3248A1

J C Calvarese wrote:

>>
>>> On the other hand, I consider them to be a gift. In fact, nested commments is one of the reasons that I'm involved in D.  They can be left in code permanently, but what I really like to use them for is temporary situations (where I want to leave code out and see what happens).  I guess I haven't coded anything with code like this in it:
>>>     printf("/+");

I find the situation stupid. I think it has to be classified as a bug. With */, strings and line comments are also left out, so they should with +/.

>> I agree.  Now the question is: is TextPad going to support nested comments soon?
> 
> 
> Actually, I'm not aware are any syntax editor that treats nested comments as nested comments instead of as block comments. (Please let know if you've found one.)

If i recall correctly, in CREdit, when entering a syntax definition, you may specify that a comment be a nesting comment.

Generally, i don't believe that multi-language editors don't support nesting comments, since Borland Pascal's neat {} comments nest.

> Currently, if I mess up the nested comments so that it doesn't run, I use d2html (available at my website) to see where it went wrong.
> 
> Apparently, Programmers Notepad allows the use of a parser plug-in, so that might be the easiest way to bring comprehensive nested comment support to an editor.  But it would probably still involve some effort and I'm pretty lazy.

Hmmm... Maybe it's time to extend SciTE lexer. ;)

>>
>> Just looking at the style guide, and the /+++++ ... +++++/ in the example, I suppose it could have been designed so that, if you have / followed by a number of +s at the beginning, you need the same number of +s followed by a / to end it.  Maybe this is WUTB now....

NO WAY!  The excess +s are an artistic mean to give value to comments and have to simply be ignored! ;)

-eye

Walter wrote:
> "Manfred Nowak" <svv1999@hotmail.com> wrote in message
> news:bupvr8$14eo$1@digitaldaemon.com...
> 
>>Shouldn't the compiler neglect "/+" and "+/" in included comments and
>>strings when processing nested comments?
> 
> The behavior works as intended, although the manual could say it better.

It's counterintuitive. In all other languages all comment tokens within comments and strings are ignored, including /* */ in C.

In article <butv4d$1j5n$1@digitaldaemon.com>, Manfred Nowak says...
>
>vim does. I am working on a syntax file for vim. But there is a bug in vim, so that multiple endings must be separated by spaces. Thats how I invented the example.
>
>If d2html is properly designed, then it should be neglectible work, as in vim. The declaration for the nestable comment is:
>
>| syn region  CommentSlashPlus	start="/+" end="+/"
>| contains= CommentSlashPlus
> 
>Adding the other comments and strings would change it to
>
>| syn region  CommentSlashPlus	start="/+" end="+/"
>| contains= Comment, String
>
>Do you really think, that this is a complex task?
>
>So long.

I made a Vim syntax file for Lua 5 (it comes with vim 6.2), where long strings are delimited by [[ bla bla ]] and they nest. Long comments are --[[ bla bla ]] and they can have nested [[ bla bla ]]'s too.

Now Lua authors are thinking of making delimiters like this [***[ bla bla ]***] (same number of *'s). Do you know if it's implementable in Vim? It's been a somewhat long time since i read Vim docs about syntax highlighting...

marcus wrote:

[...]
> Now Lua authors are thinking of making delimiters like this [***[ bla bla ]***] (same number of *'s). Do you know if it's implementable in Vim?
[...]

It is easy. Have a look at the docs with `:help ext-match'.

Something like:
| syn region C start="\[\z(\*\+\)\[" end="\]\z1\]" contains=C,...
should do the work.

So long.
-- 
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ 2EA56D6D4DC41ABA311615946D3248A1

In article <buue60$2abf$1@digitaldaemon.com>, marcus says...
>Now Lua authors are thinking of making delimiters like this [***[ bla bla ]***] (same number of *'s). Do you know if it's implementable in Vim? It's been a somewhat long time since i read Vim docs about syntax highlighting...

You could always define [*[, [**[ and [***[, etc, as separate comment types. Of course, this wouldn't work with an arbitrary number of stars, only what you've explicitly defined. I think it would take much thinking to get this work for all possible numbers of stars.

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:buu141$1lr4$2@digitaldaemon.com...
> Walter wrote:
> > "Manfred Nowak" <svv1999@hotmail.com> wrote in message news:bupvr8$14eo$1@digitaldaemon.com...
> >
> >>Shouldn't the compiler neglect "/+" and "+/" in included comments and strings when processing nested comments?
> >
> > The behavior works as intended, although the manual could say it better.
>
> It's counterintuitive. In all other languages all comment tokens within comments and strings are ignored, including /* */ in C.

That's not correct for C.

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:bv17ej$eim$1@digitaldaemon.com...
| Yeah, C doesn't even have /* */.
|
| --
| -Anderson: http://badmama.com.au/~anderson/

Wrong there: /* */ is the only way to comment C code.

-----------------------
Carlos Santander Bernal