This is something I noticed years ago, but I never took the time to figure out a
reproducible example until now.

In Windows at least, POV-Ray's multiple-line comment indicators show a purely
visual problem in the editor window, when they are nested: Some of the
'contained' text looks to be commented-out, but some doesn't (although
apparently this doesn't affect the rendering of a scene, even though the scene's
text 'looks' like there's a syntax mistake somewhere.) This assumes that you've
set up POV-Ray to show different colors for different kinds of SDL text entries,
like I have. (For example, all comments in a particular exclusive color.)

Here's a short example scene. Just copy and SAVE this as a scene file, and
notice the apparent 'non'commented-out lines (which should show up as
differently-colored text.) Is this expected behavior? It gives a false
impression that something's 'not correct.' (In the past, I used to spend hours
looking through complex scenes to find what I thought was a coding error I may
have made-- before even attempting to render the scene-- until I realized that
it was these nested comments that were to blame.)

-------
#version 3.7;

global_settings{assumed_gamma 1.0 max_trace_level 5}

/*
#declare A = 0;
#declare B = 1;
#declare C = 2;
#declare D = 3;


/*
blah blah blah
blah blah blah
blah blah blah
*/


#declare E = 4;
#declare F = 5;
#declare G = 6;
*/

// Another example: The following is from the in-built documentation
// at 3.3.1.4 Comments...

// ...comments can be nested, the following is legal:
/* This is a comment
// This too
/* This also */
*/

Post a reply to this message

Am 30.11.2017 um 13:42 schrieb Kenneth:

> In Windows at least, POV-Ray's multiple-line comment indicators show a purely
> visual problem in the editor window, when they are nested: Some of the
> 'contained' text looks to be commented-out, but some doesn't (although
> apparently this doesn't affect the rendering of a scene, even though the scene's
> text 'looks' like there's a syntax mistake somewhere.) This assumes that you've
> set up POV-Ray to show different colors for different kinds of SDL text entries,
> like I have. (For example, all comments in a particular exclusive color.)

This is a known issue.

In the POV-Ray SDL, block comments extend from the initial `/*` to the
/matching/ `*/`, allowing them to be nested (which is handy if you want
to comment-out part of your scene but that part already contains block
comments).

This differs from most other programming languages, where a block
comment extends only to the /next/ matching end token, and can not be
nested.

The editor component used in POV-Ray for Windows (which is also
responsible for the syntax highlighting) is a 3rd party component, which
was not specifically designed to cater to the peculiarities of POV-Ray's
SDL, so I suspect it would be difficult to coax its syntax highlighting
into colouring POV-Ray SDL block comments properly.

Since we want to get rid of that 3rd party component anyway, I don't
think we will do anything about this issue (except possibly re-define
the POV-Ray SDL itself, as I suspect the nested block comments may be an
issue with other syntax-highlighting editors as well).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Since we want to get rid of that 3rd party component anyway, I don't
> think we will do anything about this issue (except possibly re-define
> the POV-Ray SDL itself, as I suspect the nested block comments may be an
> issue with other syntax-highlighting editors as well).

I like that idea, and would find it useful to have several methods of
"commenting" text - much like there is (, [, and { to bracket/parenthesize
expressions in math.

Then these could be nested without interference.
It would also give a scene author the ability to _highlight_ certain parts of
their comments.

With regard to nesting, and rewriting SDL, I do understand the desire/necessity
to maintain backwards compatibility, however #end is used to close so many
different directives, that it can seriously hamper debugging.

#endif
#next
#endswitch

or other directives to close an open directive block might be useful, and if
it's possible to recognize one of those command OR an old-syntax #end, then
backward compatibility would be maintained.

Either that, or the ability to have command aliases such as
#alias "#endif" = "#end";

Post a reply to this message

hi,

wrt nested comments

On 30/11/2017 15:52, clipka wrote:
> Since we want to get rid of that 3rd party component anyway, I don't
> think we will do anything about this issue (except possibly re-define
> the POV-Ray SDL itself, as I suspect the nested block comments may be an
> issue with other syntax-highlighting editors as well).

perhaps the SDL could get a (multi line) #comment ... #end construct?  I
think that would make commented-out comments (if support continues) easy
to use and see, and "look" tidy.

regards, jr.

Post a reply to this message

Am 30.11.2017 um 18:52 schrieb jr:
> hi,
> 
> wrt nested comments
> 
> On 30/11/2017 15:52, clipka wrote:
>> Since we want to get rid of that 3rd party component anyway, I don't
>> think we will do anything about this issue (except possibly re-define
>> the POV-Ray SDL itself, as I suspect the nested block comments may be an
>> issue with other syntax-highlighting editors as well).
> 
> perhaps the SDL could get a (multi line) #comment ... #end construct?  I
> think that would make commented-out comments (if support continues) easy
> to use and see, and "look" tidy.

I presume you would use `#comment ... #end` to temporarily disable code.[*]

We can already use `#if(0) ... #end` for that purpose, which has pretty
much the same semantics as a `#comment ... #end` would presumably have.


([*] Introducing a new `#comment ... #end` block comment syntax for
actual comments, just to facilitate co-opting the already-existing `/*
... */` block comment syntax for purposes it wasn't originally designed
for, would be perverting things, IMO.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> The editor component used in POV-Ray for Windows (which is also
> responsible for the syntax highlighting) is a 3rd party component, which
> was not specifically designed to cater to the peculiarities of POV-Ray's
> SDL...

Yeah, I suspected so.

When I finally discovered that it was a purely visual problem (i.e., the scene
would parse OK anyway), I no longer experienced the panic/brain hemorrhages that
I used to.  :-P

Post a reply to this message

hi,

On 30/11/2017 20:12, clipka wrote:
> Am 30.11.2017 um 18:52 schrieb jr:
>> wrt nested comments
>> perhaps the SDL could get a (multi line) #comment ... #end construct?  I
>> think that would make commented-out comments (if support continues) easy
>> to use and see, and "look" tidy.

> I presume you would use `#comment ... #end` to temporarily disable
code.[*]
> We can already use `#if(0) ... #end` for that purpose, which has pretty
> much the same semantics as a `#comment ... #end` would presumably have.

yes.  like #if(0) ... #end, but semantically meaningful.

> ([*] Introducing a new `#comment ... #end` block comment syntax for
> actual comments, just to facilitate co-opting the already-existing `/*
> ... */` block comment syntax for purposes it wasn't originally designed
> for, would be perverting things, IMO.)

see above.


regards, jr.

Post a reply to this message

jr <cre### [at] gmailcom> wrote:

> yes.  like #if(0) ... #end, but semantically meaningful.

#if (Code)

SDL .....

#else

Comments ....

#end

Post a reply to this message

hi,

On 01/12/2017 12:37, Bald Eagle wrote:
> jr <cre### [at] gmailcom> wrote:
>> yes.  like #if(0) ... #end, but semantically meaningful.
> 
> #if (Code)
> SDL .....
> #else
> Comments ....
> #end

yes, with good naming + discipline one can get close.

Post a reply to this message