Unmatched quote in Perl

Unmatched quote in Perl

19
Basic UserBasic User
19

    Mar 22, 2013#1

    Is there a way to prevent UE or the Perl syntax highlighter from highlighting all code after an unmatched quote (single or double) with the string highlighting reversed (all code outside quotes highlighted as a string and all code inside quotes highlighted as commands etc.)?

    For example, the following Perl code causes all code after the double quote to have string highlighting reversed

    Code: Select all

    	$repString =~ s/"//g;
    I can amend the line above to

    Code: Select all

    	$repString =~ s/"//g; #'
    which sorts the issue for all subsequent lines, but i don't want to litter communal code with odd looking comments just to keep UE happy.

    I know there's the EnableMLS/DisableMLS wordfile command but this switches off (when disabled) valid multiline strings. Other editors i've tried (vi!!!, Notepad++) seem to cope with this situation better.

    Can someone suggest a way around this?

    Thanks, PG.

    I'm using UE version 19.00.0.1025 but i think it's a long standing issue.

    6,686585
    Grand MasterGrand Master
    6,686585

      Mar 23, 2013#2

      UltraEdit is not taking the context around a string to highlight into account as some other editors do. Syntax highlighting of UltraEdit is a simple word based highlighting which makes it possible to create syntax highlighting for nearly every file type very easily. But the simplicity is to be disadvantage for syntax highlighting file types with a very complex structure. And the Perl scripting language is most likely the most complicated language of all scripting and programming languages.

      Text editors supporting syntax highlighting more or less perfect for Perl scripts have been either coded especially for Perl scripts or use Perl regular expressions for syntax highlighting Perl scripts (Notepad++) or use even both - special code with conditions plus regular expressions (vi).

      I have 2 suggestions for your syntax highlighting issue:
      1. Write an email to IDM support with an enhancement request for string highlighting of Perl scripts. There is already the language marker PERL_LANG. So it would be possible to code directly in UltraEdit rules for ignoring double quote characters depending on context around on files highlighted with a syntax highlighting language containing PERL_LANG in the first line. Of course you need to tell IDM also the rules which should be used for determining when a double quote is the begin/end of a string and when this is not the case as most likely the IDM developers are not experts in Perl scripting language. I could see on other editors supporting syntax highlighting Perl scripts better than UltraEdit that the rules and regular expressions came from users having deep knowledge of Perl scripting language and not by the authors of the editors.
      2. As workaround to avoid wrong syntax highlighting use an alternate character sequence for a double quote character which is not the begin of a string. For example in your examples you could use \x22 instead of " to specify a double quote character in the regular expression which does not result in wrong syntax highlighting. You might think that \x22 is more difficult to read than ", but remember that at beginning of your life you could not read anything. It is a matter of time for your brain to give \x22 the same meaning as ". It would be of course better UltraEdit would take context around a double quote character for Perl scripts into account for a better string highlighting support on Perl scripts, but that is currently not the case.

      19
      Basic UserBasic User
      19

        Mar 25, 2013#3

        Mofi

        Thank you for taking the time to reply and for suggesting possible solutions to my problem.

        Unfortunately it's difficult for me to change code to get around the issue as the code is 'communal' and I believe I'm the only team member using UE. However, I will give some thought to forwarding the problem on to IDM support.

        Thanks again for your response.