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