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!
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.