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