Lance Birch wrote:
>>>I can confirm this bug exists in 3.7.0.beta.11c as well.
>>
>>  It's not so much a bug (ie. a programming error) than a limitation
>>of the editor. Limitations are not bugs.
> 
> I suppose, but the behaviour surely isn't intended

It most certainly is intended. IIRC I vaguely remember it actually being 
documented somewhere (older release notes maybe?) or having been discussed 
before. It is just that nested comments cannot be colored correctly for 
computational complexity reasons. It is not a bug, and anyway the way it was 
"reported" and where it was "reported" were simply unacceptable.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> It is just that nested comments cannot be colored correctly for 
> computational complexity reasons.

  If nested comments can be *parsed* correctly (as povray does), they
certainly can be colored correctly.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>>It is just that nested comments cannot be colored correctly for 
>>computational complexity reasons.
> 
>   If nested comments can be *parsed* correctly (as povray does), they
> certainly can be colored correctly.

Carefully re-read my sentence ;-)

	Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:4425c372$1@news.povray.org...
> Warp wrote:
> >>It is just that nested comments cannot be colored correctly for
> >>computational complexity reasons.
> >
> >   If nested comments can be *parsed* correctly (as povray does), they
> > certainly can be colored correctly.
>
> Carefully re-read my sentence ;-)

Heh... yes but it can't be that computationally intenstive because there are
other editors that handle nested comments (e.g. "ED", emacs, etc).

However, it's probably a lot of work to implement for very little gain.  On the
other hand issues like artifacts with +b2 are more important to resolve (btw the
render time difference that it makes can be significant - 30% faster in many
cases, which is fantastic).

Lance.

thezone - thezone.firewave.com.au

Post a reply to this message

Lance Birch <-> wrote:
> However, it's probably a lot of work to implement for very little gain.

  I don't understand why. Parsing them is quite trivial, so coloring them
correctly should be too. Just increase a counter when /* is encountered
and decrease it when */ is encountered, When the counter gets back to 0,
that's the end of the comment.

  Of course there may be ambiguous cases like this:

/*
#debug "Comments end with the */ symbol\n"
*/

  However, I don't think it would be so difficult to make the syntax-coloring
algorithm to interpret that like the parser does (and in fact, if it does so,
it helps the user to immediately spot a potential problem with comments
if there exists one, as might be the case here).

  In fact, I just checked and the above causes a syntax error in POV-Ray
because it doesn't "parse" strings inside comments. Thus coloring that
becomes quite simple, as I described above (ie. with a simple counter).
And as I said, the user would immediately spot the problem while editing
the text because the syntax coloring clearly shows that the comment is
ending somewhere he didn't expect.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:442638df@news.povray.org...
> Lance Birch <-> wrote:
> > However, it's probably a lot of work to implement for very little gain.
>
>   I don't understand why.

I don't have any idea how the editor currently does its syntax highlighting, so
I don't know what's involved in implementing this - I assume it mustn't be as
easy as I thought it would be if it hasn't been done already.

Obviously I agree with what you're saying though because I'd like to see it
"fixed"/implemented.
As I mentioned, there are other editors that seem to be able to do it without
any problems, but I'm also willing to accept that it's a low priority in the
scheme of things.

Lance.

thezone - thezone.firewave.com.au

Post a reply to this message

Lance Birch <-> wrote:
> I don't have any idea how the editor currently does its syntax highlighting, so
> I don't know what's involved in implementing this - I assume it mustn't be as
> easy as I thought it would be if it hasn't been done already.

  The explanation may be as simple as:
  The editor code has been made by someone else, and trying to figure out
from someone else's code exactly where the comment-coloring code is and
how it works and how it should be modified is too much trouble taking into
account the enormous amount of more important other work yet to be done.

  Trying to figure out someone else's code is often a rather appalling
prospect. I know this from personal experience. :)

  For example, I once, many years ago, tried to compile mplayer for
Sparc/Solaris. At that time the support for that platform was not very good,
but after some tweaking I got it compiled and running. The only problem
was that the program made a check that the target architecture byte
endianess was not supported (ultrasparc is a high-endian processor, unlike
intels, which are low-endian) and refused to continue.
  Well, I located the check (it was easy to find by just searching the
error message and then the place where it was being used) and removed it.
  Presto, the video started showing. The only problem was that the red and
blue channels were swapped.
  In the end, the solution was rather simple: It was enough to swap the
indexing values in two lines of code in one file (I used #ifdefs for better
compatibility). However, it took me over an hour to actually locate those
two lines. mplayer is such an enormously complex program that it was
really hard to try to figure out its inner workings.

  Locating and understanding the syntax-coloring code in the winpov
editor is probably not this hard, but given that there are more urgent
issues at hand, it's probably a quite low-priority task.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I don't understand why. Parsing them is quite trivial, so coloring them
> correctly should be too. Just increase a counter when /* is encountered
> and decrease it when */ is encountered,

The way (most) editors do it is by just looking at what is visible when 
printing a line, i.e. you can determine most commenting coloring based on 
what is on screen. This just leaves the case of the first line visible on 
screen, and for that you just have to search up until the first comment 
opening or closing and can then decide what to do. With recursive comments, 
you always need to parse the whole file when a comment is changed. For small 
files nobody will notice, but for i.e. a 20 MB file even today you would 
probably notice some lag when editing. And of course, five years ago that 
was just plain impossible to do efficiently for a plain text editor (it is 
different if you have an editor that support styles or a specifically built 
comment-tracking). The trouble is that this again makes a generic syntax 
highlighting engine a lot more complex to implement and even more complex to 
set up.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> The way (most) editors do it is by just looking at what is visible when 
> printing a line, i.e. you can determine most commenting coloring based on 
> what is on screen. This just leaves the case of the first line visible on 
> screen, and for that you just have to search up until the first comment 
> opening or closing and can then decide what to do. With recursive comments, 
> you always need to parse the whole file when a comment is changed. For small 
> files nobody will notice, but for i.e. a 20 MB file even today you would 
> probably notice some lag when editing. And of course, five years ago that 
> was just plain impossible to do efficiently for a plain text editor (it is 
> different if you have an editor that support styles or a specifically built 
> comment-tracking). The trouble is that this again makes a generic syntax 
> highlighting engine a lot more complex to implement and even more complex to 
> set up.

  I do understand that syntax-coloring block comments in general can be
inefficient due to exactly what you mention: It can't be done in a
line-by-line basis but the beginning and the end of the comment has
to be searched in order for the editor to know what to color. However,
the current editor does that, and nobody has complained about its speed,
so I suppose it does it at a reasonable one.

  Is adding support for nested comments really that much heavier than
supporting single comments? I can't fathom the possible reason for that,
unless the current block-comment coloring has some kind of optimization
which relies on not having nested comments, such as marking the beginning
and end lines of a comment block and re-scanning the file only if one of
these two lines is modified or if in the current line the end-of-comment
symbol is written (trivially detectable by the program, obviously).

  Now that I think about it, that might actually be quite reasonable.
I don't know how editors do perform block-comment coloring, but such
an optimization as I mentioned above could very well be a common
technique, and one which gets more complex with nested comments.

  OTOH, I can't really think of why nested comments would make it any
more inefficient. Granted, it would require a bit more of coding and
actually supporting nested marks for beginning/ending lines, but I don't
think that's computationally expensive at all (ie. not more expensive
than single block comment coloring).

  Anyways, I do understand why it is not being done. It's a rather
low-priority issue and there are much more important things to do.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Is adding support for nested comments really that much heavier than
> supporting single comments? 

Yes, just try to think about the algorithm: It would always have to search 
the whole file in both directions to determine where it is inside nested 
comments, while the non-nested version can abort as soon as it finds the 
first closing of a comment to know it isn't inside a comment, and the first 
opening to know that it is inside an opening (all based on searching from 
the first visible line to the beginning of the file). Alternatively it would 
have to somehow keep track of comments at least on a line-by-line basis 
(comment count would do, I think, but I haven't verified that). It basically 
gets messy, and even then it would only for as long as there is one type of 
multi-line comments (I don't know of any language that has more off-hand, 
but I certainly can imagine one). Basically, the algorithm for non-nested is 
simple and fast, but the nested case is either messy and probably fast or 
simple and slow. And that is why I said coloring cannot be done due to 
computational complexity. Of course it is possible, but with much added 
complexity.

	Thorsten

PS: In the Mac version I "solved" the problem in a different way. The editor 
simply colors the comment-characters and single-line comments only. That way 
it is really fast, even on the oldest Macs it can run on. Coloring exists 
since POV-Ray 3.1 on Macs, and that could run on systems with just a MC 
68020 - meaning with less than five MIPS average performance available...

Post a reply to this message