Synatx Highlighting Breakage (0.3.10)

dacypher wrote on Mon Feb 14 20:59:32 CET 2005:

I've noticed two cases so far that will cause EPIC to lose its syntax highlighting
after the each case occurs in a Perl file:

1. Using a backslash character ('\') in a call to qq().

2. Using the left and right bitshift operators (<< and >> respectively).

This is quite annoying when I have one of these situations near the beginning
of a large file and the rest of the file becomes one color.  Is there any
way to workaround this?  Thanks for any suggestions...

pguzis wrote on Mon Feb 14 22:12:14 CET 2005:

I notice something similar when editing a new file.  Create a new file and
enter code such as the following:

use strict;
use warnings;
use utf8;

Note that no text is being highlighted.  Now retype the "use" on the second
line and everything from that point on is highlighted.

If you save the file, close it, and re-open it, everything works as expected.

dacypher wrote on Mon Feb 14 22:27:21 CET 2005:

Good call, I've actually noticed that as well.  I guess I forgot to mention
it since there is a workaround (close/reopen).  Thanks for pointing that
out though.

BTW, sorry for the ugly typo in the title, I don't think there is a way
for me to edit that.

leo_forge wrote on Tue Feb 15 10:45:16 CET 2005:

EPIC is not a full Perl-interpretor, therefor some restrictions. If you
keep this in mind, then workaround could be found easily, otherwise the
programmers attitude is overstressed. Sorry, but the mentioned problems
are hard to deal.

1. '\' is the Escape-Character. Hard to deal in an interpreter, when it's
an Escape-Character and when not. I have to think about it, but the chances
for this are fairly low.

2. Bitshift-operator could be only '<<'. The other >> works fine. If you
could give me a distinction, when it's a Bitshift-operator and when it's
a HERE-Document, fine. I could think about it. Otherwise - no chances to
handle it.

2a. Seems similar with the // issue. When it's an divisor and when a match.

3. The above mentioned use is fixed somehow, but not perfectly. Seems to
be still problems with Eclipse, but since it's minimal, I don't follow it.

dacypher wrote on Tue Feb 15 15:25:58 CET 2005:

Hmm, good point about the << operator, I forgot about the <

leo_forge wrote on Tue Feb 15 17:59:53 CET 2005:

I looked little bit around and the only way I could perform some check is:

a) is after '<<'  an integer?
b) is after '<<' a '$' (like $1)?

if one of these question is YES => not HERE-doc.

This makes it more closer, but only 99%. The rest... 

brusberg wrote on Thu Feb 17 16:33:44 CET 2005:

Interesting problem. From the Perl doc  I found:

"A line-oriented form of quoting is based on the shell ``here-document''
syntax.
Following a << you specify a string to terminate the quoted material, and
all
lines following the current line down to the terminating string are the
value of
the item. The terminating string may be either an identifier (a word), or
some
quoted text. ... There must be no space between the << and the identifier,
unless the identifier is quoted. (If you put a space it will be treated
as a
null identifier, which is valid, and matches the first empty line.)"

and

"A word consists only of alphanumeric characters and underline, and must
start
with an alphabetic character."
 
In fact, even <<1234 would be treated (sometimes) as Here-Is (at least by
ActiveState´s Perl) although it´s not a bare word according the above definition.


So this would break down the question to the following:

<<[A-Za-z0-9_] ==> Here-Is
<<(optional whitespace)["'] ==> Here-Is
<<[anything else] ==> not Here-Is (especially because null identifiers are
deprecated and may be/should be written as <<"")

So only <<[0-9] is ambigous and depends on the token before <<. 

As for me, I´d like to have <<111 interpreted as Here-Is, because I usually
put blanks before and after an operator (which would also be the workaround,
if implemented like this).

leo_forge wrote on Fri Feb 18 09:29:29 CET 2005:

Programmer view of the issue:

- I've never found about , what the delimiters of the HERE could consits
of. ThX.

- For syntax checking it's almost impossible to determine what is in front
of the token, i.e. <<. Could be integer, scalar (with or wo integer value),
line feed, function returning a value, etc. The only check I could do is,
if behind there is an integer.

- it makes currently no difference if you put a whitespace between '<<'
and the delimiter. interpreted the same way. => if '<<111' should be HERE,
then as well '<<   111' is HERE.

- what I could provide is a switch in the Perl.xml where you could define,
if an integer after the << should be treated as HERE or reject the HERE

LeO

brusberg wrote on Fri Feb 18 17:19:25 CET 2005:

Tokens before <<: Sure, that´s why I didn´t comment on <<[0-9] depending
on the previous token. I think, if you would take it in account you'd end
up in a semantic analysis of the code, probably by porting the perl interpreter
to java ... :o)

If you could turn off ignoring the whitespace, implementing the 3 or 4 rules
mentioned above would be best, I think. From perl's view < Here-Is 

A switch in Perl.xml would be great. I think most perl programmer either
use lots of bit-shifts or lots of here-is.

BTW, another point concerning here-is:
A here-is-document starts only at the beginning of the next line. 
That means the following code is quite usual:

print <

leo_forge wrote on Fri Feb 18 09:33:50 CET 2005:

Forgotten to mention:

Delimiter like '##' are allowed => if there is an 'invalid' delimiter, nevertheless
the colouring will be done like a regular delimiter!