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...
I notice something similar when editing a new file. Create a new file and enter code such as the following:
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.
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.
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.
Hmm, good point about the << operator, I forgot about the <<EOF; syntax. I guess the only thing I could suggest is an option to right-click on a given line and manually force syntax highlighting on that line and the lines following it (manual distinction between the usage of a given operator)? Although, this could be a pain to implement and since it doesn't seem to affect many people I would understand not bothering with it. :(
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...
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.)"
"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 ActiveStates Perl) although its 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, Id 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).
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
Tokens before <<: Sure, thats why I didnt 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 <<aaa is not the same as << aaa.
Just to put together the facts:
There are exactly 3 types of quotes allowed to quote the delimiter: ", ' and `.
So it should have been
<<(optional whitespace)["'`] ==> 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 <<HEAD . $text . <<FOOT; # Wrap text
### My header ...
### My footer ...
Here $text should be coloured as variable and the (2nd) here-is-documents exceeds up to FOOT.
Ok, I admit this probably would require heavy coding, because you have to defer coloring until the next line and keep a list of delimiters to search for (up to HEAD first, then up to FOOT).
Forgotten to mention:
Delimiter like '##' are allowed => if there is an 'invalid' delimiter, nevertheless the colouring will be done like a regular delimiter!