-
Subroutine prototypes fail in the same way too, however it was not immediately evident because the difference is only italics vs non-italics. Fix follows.
Examples:
s/[\n\r]//g;split /\t/;
s/[\n\r]//g;sub foo (@@@) {};
A two-line update that adds sc.Complete() in the appropriate places:
http://groups.google.com/group/scintilla-interest/web/LexPerl-fixes-20090630.zip
Fixed bug for '/' special...
2009-06-30 04:02:37 UTC in Scintilla
-
My bad, the last whitespace's style did not get completed before the flush, due to code rearrangement. The glitch still happens for a one-liner "s/[\n\r]//g;split /\t/;".
An "sc.Complete();" before the "styler.Flush();" appears to fix it, though I need to check why styleCheckSubPrototype(), which uses Flush() also, worked by accident... will try to settle it before 20090701.
2009-06-30 03:33:20 UTC in Scintilla
-
Preliminary: Apparently styler.Flush() on line #966 in LexPerl.cxx no longer works.
The '/' special casing on #1028 to 1040 needs to know the type of token lexed just before it, hence the need for styler.Flush(). In the test case, when the extra '\' is deleted (as in the test case step 3), the lines are restyled, and styling is returned to the 'original' state right up to the '/'.
At '/', when...
2009-06-29 14:44:22 UTC in Scintilla
-
Sorry, ignore what I said about the SciTE ~1.74, I'm probably just confusing myself. I'll report back when I have something more useful to share. ;-)
2009-06-19 19:41:39 UTC in Scintilla
-
I tried this on a SciTE ~1.74, compiled 2008-12-22, and it does not exhibit this problem. Most of the major changes I made to LexPerl was done by 20080917, so it is possible that this could be due to some new code interacting differently with LexPerl. I'll take a closer look over the weekend.
2009-06-19 19:28:44 UTC in Scintilla
-
I agree that there is something wrong when the highlighting is re-done (in step 3). '/' is supposed to be special-cased for 'split', so it ought to be an unambiguous regex. However, recognition of 'split' is dependent on several things, one of which perhaps borked on us. I'll take a look at it.
2009-06-19 18:59:54 UTC in Scintilla
-
If the problem starts when >=300 bytes are involved, '300' appears in PositionCache.h.
2009-04-27 16:41:04 UTC in Scintilla
-
I see it on MinGW/Win32 with the CVS head. With the sample utf8_problem.zip, the rendering changes if a part of the glitched line is selected. The UTF-8 bytes (E2 94 XX) are valid. With up to 99 3-byte UTF-8 characters, everything is fine. Add one more UTF-8 or 3 more ASCII characters, the glitch starts.
2009-04-27 16:36:53 UTC in Scintilla
-
LexPerl.cxx[247]: isMatch() always tries to find and remove the '\r', which is potentially fatal if the string is of zero length. Patch adds length test in isMatch().
No change to styling output. perl-test-cases.pl checked with CR, LF, and CRLF line endings. No regressions (hopefully).
2009-02-28 09:54:25 UTC in Scintilla
-
Patch for this bug:
http://groups.google.com/group/scintilla-interest/web/LexBash-fixes-20090228.zip
LexBash.cxx[336] sc.GetCurrent(s,...) picks up an extra CR, which needs to be removed. Wanted to find an elegant way using strncmp, but can't seem to, the HEREDOC delimiter needed an exact match.
Test files for CR, LF and CRLF attached. Also checked bashref-tests.sh also for CR, CRLF, no...
2009-02-28 09:29:31 UTC in Scintilla
