Synatx Highlighting Breakage (0.3.10)

Help
2005-02-14
2013-05-20
  • jason scripte
    jason scripte
    2005-02-14

    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...

     
    • Peter Guzis
      Peter Guzis
      2005-02-14

      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.

       
    • jason scripte
      jason scripte
      2005-02-14

      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
      LeO
      2005-02-15

      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.

       
    • jason scripte
      jason scripte
      2005-02-15

      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.  :(

       
      • LeO
        LeO
        2005-02-15

        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.)"

          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 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).

           
          • LeO
            LeO
            2005-02-18

            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

             
            • 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 ...
              HEAD
              ### My footer ...
              FOOT

              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).

              Oliver

               
          • LeO
            LeO
            2005-02-18

            Forgotten to mention:

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