Anyone have feedback on this band-aid of a patch? The
problem only shows up when a line starts with a regex
immediately after a function header.
@@ -776,6 +819,7 @@
- } else if (ch == '/' && preferRE) {
+ } else if (ch == '/' && (preferRE || (firstTokenOnLine(i, styler) &&
strchr("^[./", chNext)))) {
*or*
+ } else if (ch == '/' && (preferRE || strchr("^[./", chNext))) {
I haven't written firstTokenOnLine yet, and am not sure it's completely
necessary.
There are about four other characters a regex can start with that cannot follow
a division operator, but the above four are common characters that can
appear at the start of a regex. I tested the code without a firstTokenOnLine
routine, and couldn't get any false negatives.
Just to recap, the problem occurs in this context:
def function_name ( args ) # args optional
/regex/ =~ pattern
...
- Eric
Eric Promislow wrote:
Looks like I own this problem. Here's some quick analysis...
In Ruby (and Perl) the following operators are ambigous:
/ : <<
I prefer not to do full parsing of Ruby (and Perl) to
get these ambiguous operators right 100%. Here are the
problems:
1. Ruby (and Perl) doesn't require a return statement
in a function. If you preface the regex with "return",
or put the whole thing in parens, coloring is correct.
2. The "preferRE" variable is used to determine whether
the three above operators are binary ops or unary. If
unary then "/" starts a regex, "<<" a heredoc, and ":"
is part of a conditional expression.
3. From the behavior of cutting and pasting it looks like
a new colorise call comes in at the line starting with
a regex, and doesn't move back to synchronize (look for an
unambiguous point in the document to begin a colorise
run at). I can't think of a valid expression at that point
that would start with ":" or "<<" as a unary operator.
Changing the indentation on that line doesn't change the coloring.
I'll have a closer look to see if it is a synchronization
problem, in which case a line where the first non-whitespace
char is ambiguous should never be accepted by the synchronizer.
A second check would look at the character after a leading "/"
to see if it could be the start of a regex even if preferRE
is false.
- Eric
Kein-Hong Man wrote:
Hi all,
Here is a Ruby lexer glitch. This was snipped from ruby on rails,
mem_cache_store.rb.
begin
class MemCacheStore
def check_id(id) #:nodoc:#
/[^0-9a-zA-Z]+/ =~ id.to_s ? false : true
end
end
end
Initial styling fails to lex the regexp properly. However, if you do a
pagedown (in the original file) or edit any line after the regexp,
styling becomes correct after the refresh. I am running SciTE 1.74 on
Win32.
I've also got a file rkernel.rb (lost the project name) where the
lexer borks on:
def `(command) #:nodoc:
I know too little of Ruby to deal with these, so guess I will be of
little help. I've got all the Ruby docs downloaded but I'm too
comfortable with Lua and Perl at the moment.
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
