danieldietrich
commented
12 years ago Looking at your proposed languages, the common nature of comments is:
- protected regions are denoted in comments (start and end of protected region)
-
comments have a start and an end character sequence
(This behavior implies that subsequent occurrences of comment start characters are somehow 'ignored' within comments.)
Providing a ProtectedRegionRecognizer in this way should be sufficient.
A ProtectedRegionConsumer just consumes characters (with a look ahead functionality somehow) and depends on a ProtectedRegionRecognizer which provides the needed information about the ongoing character stream. In the ProtectedRegionConsumer plays the music it has the functionality of the current DefaultDocumentWriter + the functionality of the specific Antlr parser.
interface IProtectedRegionConsumer { setProtectedRegionRecognizer(IProtectedRegionRecognizer r); IDocument parse(InputStream) throws MalformedInputException; }
interface IProtectedRegionRecognizer { java.util.Pattern getCommentStart(); // Pattern allows to differentiate by different comment styles in one language java.util.Pattern getCommentEnd(); boolean isProtectedRegionStart(String comment); boolean isProtectedRegionEnd(String comment); }
Example:
class ClojureProtectedRegionRecognizer implements IProtectedRegionRecognizer {
@Override public java.util.Pattern getCommentStart() { return Pattern.compile(";"); } @Override public java.util.Pattern getCommentEnd() { return Pattern.compile("[\n\r]"); }
private static final String ID = "([a-zA-Z$][a-zA-Z\d$].)[a-zA-Z$][a-zA-Z\d$]_"; private static final Pattern PR_START = Pattern.compile("\s_PROTECTED\s_REGION\sID\s(\s" + ID + "\s)\s_START\s*"); @Override public boolean isProtectedRegionStart(String s);
private static final Pattern PR_END = Pattern.compile("\s_PROTECTED\s_REGION\sEND\s"); @Override public boolean isProtectedRegionEnd(String s) { PR_END.matcher().matches(s); } }
Starting implementation later today!
Regards, Daniel
ceefour
Hi Daniel,
Iam not familiar with Antlr. Itd be awesome if you could add support for other comment styles:
Although it may be generified (support for exotic languages or custom uses), perhaps separate lexer for each of the most common comment styles is best considering performance.
Thank you.
Regards, Hendy