Related articles |
---|
Source code for Syntax Coloring... rmikkili@us.oracle.com (micky) (1996-12-14) |
Re: Source code for Syntax Coloring... jacob@jacob.remcomp.fr (1996-12-20) |
From: | jacob@jacob.remcomp.fr (Jacob Navia) |
Newsgroups: | comp.compilers |
Date: | 20 Dec 1996 16:34:33 -0500 |
Organization: | Compilers Central |
Keywords: | analysis |
Reference: | 96-12-090 |
> Is there any public domain source code available for syntax coloring...
I have built an integrated development environment for a version of
lcc under windows. My IDE has full syntax coloring in real time,
i.e. the colors change instantly when the keywords/comments of the
text change. The languages supported are C, Pascal and Assembly.
Algorithm syntax coloring:
1. Case keywords coloring.
After you have eliminated strings and comments text, just scan each word
to see if is a keyword. If it is, paint it as you like. This is very easy
Be careful to treat the end of line as white space, and be sure.
2. Case comments coloring.
This is much more tricky. I use following algorithm:
1. When you load the file into the editor, scan all the comments and
build a list associated with the file. Each member should contain:
The starting line of the comment.
The starting column of the comment
The end line of the comment
The end column of the comment.
2. When you paint your text, see if each line painted is in the list.
If it is, use the information to paint the comment. Be aware that
that a line could be part of a comment without being explicitely
in the list: I do not keep a pointer to all lines in a comment,
just to the start/ending line. The middle lines are implicit.
3. At each character typed, look if it can modify a nearby comment.
All characters should be tested, since, for instance adding a space
between the '/' and the '*' could change the status of a line from
being a comment to being normal text.
4. Whenever text is erased, test if the deletion affects the comments
list.
3. Optimizations:
The user can not modified anything that is not in the portion of the file
being displayed in the screen. I maintain a pointer to the comment just
before the screen text. Instead of scanning the whole comments list at
each line, I start with that comment, since all comments above cannot
be modified by the user.
Block move operations (Cut, Copy and Paste commands) are VERY tricky.
I just gave up handling all cases. I destroy the comments list and
rebuild it from scratch after doing the block operation.
4. Performance.
My IDE will run without noticable slow down in a 486-66.
5. Bugs.
After having introduced this more than 2 years ago, there are still
situations where the display is not coherent. This algorithm is easy
to describe, but VERY difficult to implement. To see a proof, just use
Microsoft's IDE for a while... Sometimes you will caught it with comments
being confused as normal text.
Watch for situations of
Comments within comments.
Erasing a nested comment.
Specification ambiguities:
int i; // this is a // comment, but is followed by a /*
// and here we do not know if the comment ends or not */
:-(
Enjoy!
--
Jacob Navia Logiciels/Informatique
41 rue Maurice Ravel Tel (1) 48.23.51.44
93430 Villetaneuse Fax (1) 48.23.95.39
France
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.