I know this isn't the world's most interesting subject, but here we go anyway.
I've added built in support for Perl and lcc-win32 parsing. Output from lcc-win32 is actually matched as borland output by Scintilla's built-in error lexer. However, the string is sufficiently different from that used by borland that the same regex doesn't match:
Error E2034 clippert.cpp 207: message... (borland)
Error resources.rc 14 18: message (column line:) (borland)
Error blocker.c: 537 unrecognized statement
In both borland types the line number is followed by a colon. This is not the case for the lcc-win32 error. PN2 now tries to match borland and if that fails it trys the other format.
Perl output is matched by looking for the phrase "at [file] line [line]". This is actually one of the most simple matches.
Samples for the above were again supplied by Patrick and he also supplied an example for the Watcom C compiler. Scintilla doesn't support this format as a built-in error type so for the next release at least Watcom C users will need to use a custom output matcher. The following seems to do the trick:
For those wondering the errors look like this:
..\file-io.c(206): Error! E1151: Parameter count does not
It occurs to me that soon someone is going to ask whether PN supports use of Perl Compatible Regular Expressions from the search and replace dialogs. The answer, currently, is no. Programmers Notepad currently uses the regular expressions that are built in to scintilla which are nowhere near as powerful as those provided by PCRE. I haven't even looked yet at the complexities involved in integrating it properly with scintilla - it almost certainly means changes to the PCRE code to support using getter methods for characters. The only other way is to copy the entire document into a temporary buffer for search and replace and that would be bad for large documents.Posted by Simon at May 15, 2003 10:18 PM