Wrong string highlighting in AutoLISP file on lines with a slash in UltraEdit v24.20 to v26.20 (fixed)

Wrong string highlighting in AutoLISP file on lines with a slash in UltraEdit v24.20 to v26.20 (fixed)

1581
Power UserPower User
1581

    Dec 12, 2019#1

    My UEW file for AutoLISP has these main lines:

    Code: Select all

    /L9"AutoLISP" Nocase Line Comment Num = 2;  Block Comment On = ;| Block Comment Off = |; Escape Char = \ String Chars = " EnableCFByIndent File Extensions = LSP MNL SCR PRP PRV XBS SHP MNU ISS
    /TGBegin "Function"
    /TGFindStr = "^{(defun ^}^{^[[~^]]+^]^}"
    /TGFindStr = "; ^(#####*^)$"
    /TGFindStr = "; ^(-----*^)$"
    /TGFindStr = "; ^(^*^*^*^*^**^)$"
    /TGEnd
    /Delimiters = ~!@%^&()=|\{}[]:;"'<> ,    .?
    /Indent Strings = "(" "(progn" "(if" "(cond"
    /Unindent Strings = ")"
    /Strip Comments = No
    /C1"Operatoren"
    *
    +
    -
    // /
    <
    =
    >
    ~
    Example:

    ( = / test "Mystring") works fine and colors Mystring.

    (/ =  test "Mystring") works NOT for the string, because I have a bracket followed by a slash. Code syntax and other stuff is highlighted fine, but "string" fails.

    Why?
    UE 26.20.0.74 German / Win 10 x 64 Pro

    6,686585
    Grand MasterGrand Master
    6,686585

      Dec 12, 2019#2

      I copied the posted wordfile snippet into a new ASCII file, replaced the spaces between comma and dot on /Delimiters = line by a tab, and saved the file with name AutoLISP.uew into the wordfiles directory.

      Next I copied the three lines below into a new ASCII file.

      Code: Select all

      ( = / test "Mystring") works fine and colors Mystring
      
      (/ =  test "Mystring") works NOT for the string, because I have a bracket followed by a slash. Code syntax and other stuff is highlighted fine, but "string" fails.
      I saved this file with name Test.lsp. In both lines Mystring was highlighted as string.

      So the issue was not reproducible by me with UE v22.20.0.49. I will try it tomorrow with UE v26.20.0.68.

      Does AutoLISP support multi-line strings?

      If the answer is no, it would be better to add to first line after String Chars = " the keyword DisableMLS to disable multi-line string highlighting.

      Code: Select all

      /TGFindStr = "; ^(#####*^)$"
      /TGFindStr = "; ^(-----*^)$"
      could be optimized to

      Code: Select all

      /TGFindStr = "; ^(^{#####^}^{-----^}*^)$"
      Less regular expressions in wordfile means less regular expression searches to run on entire file to find the strings for the function list.

      Please look on status bar if the active file is really syntax highlighted with the wordfile.

      Best would be to pack the wordfile and an example AutoLISP file on which the string highlighting is wrong for second line into a 7-Zip, RAR or ZIP archive file and attach the archive file to the next post. Then I would have the same files as you which could be helpful on this syntax highlighting issue.
      Best regards from an UC/UE/UES for Windows user from Austria

      1581
      Power UserPower User
      1581

        Dec 13, 2019#3

        So, here is my (reduced) UEW file and a Lisp file. In line 8 the string "SEQEND" should be recognized as string like "INSERT" and the others.
        autolisp.uew (753 Bytes)   0
        lispsyntax.lsp (815 Bytes)   0
        UE 26.20.0.74 German / Win 10 x 64 Pro

        6,686585
        Grand MasterGrand Master
        6,686585

          Dec 13, 2019#4

          Thank you for the two files.

          I could not reproduce the issue with UltraEdit v22.20.0.49 on Windows XP using your files. But I see the same wrong string highlighting as you using UltraEdit v26.20.0.68 on Windows 7.

          This is a syntax highlighting issue which must be reported to IDM support by email which I will do this weekend after having found out since which version of UltraEdit for Windows this issue exists.

          It does not matter where exactly the character / is positioned on line 8 of lispsyntax.lsp between the first two opening round brackets. Further, it is interesting that the string highlighting with one / between the first two round brackets does not even work on using a wordfile containing just one line with /L9"AutoLISP" File Extensions = LSP and nothing else. I could see also that adding one more / between the first two round brackets like using /=/ results in getting the string in double quotes highlighted again. That is a very strange syntax highlighting issue.
          Best regards from an UC/UE/UES for Windows user from Austria

          1581
          Power UserPower User
          1581

            Dec 13, 2019#5

            Thanks for checking, confirming and reporting 👋

            BTW:
            You asked: "Does AutoLISP support multi-line strings?"
            Do you mean for comment or what ....???
            UE 26.20.0.74 German / Win 10 x 64 Pro

            6,686585
            Grand MasterGrand Master
            6,686585

              Dec 13, 2019#6

              A multi-line string is a string starting with " on line X and ending with one more " on a line below line X.

              The values of HTML attributes like title= or style= enclosed in " or ' can span over multiple lines.

              In C/C++ it is possible to define a string over multiple lines with escaping the line break with a backslash.

              A very simple C/C++ example:

              Code: Select all

              const char csText[] = "Example of a C string\
               which spans over three lines \
              because it is quite long (not really true here).";
              Well, I would write in C/C++ a long strong not using this method. I prefer the very old syntax most C/C++ programmers don't know:

              Code: Select all

              const char csText[] = 
                 "Example of a C string "
                 "which spans over three lines "
                 "because it is quite long (not really true here).";
              A C/C++ compiler concatenates these three single line strings with just spaces/tabs/newline characters between to one string during compilation. I like this syntax more as the lines can be proper indented. This syntax has also the big advantage that it is possible to compile a program with a constant version string on which the version number inside the string is a preprocessor macro defined in a different source code file (a header file) or even better outside of any source file.

              The default for string highlighting is EnableMLS if the wordfile does not contain this keyword or the keyword DisableMLS in first line. For that reason UltraEdit searches for next not escaped " in entire file on typing just one " and highlights everything between these two quotes on really finding one. Most languages do not support multi-line strings. The interpreter/compiler of the file with such a language would report an error if a line contains " and there is no matching " on same line. It is better to add to first line of a language not supporting multi-line strings the keyword DisableMLS which results in searching for matching " by UltraEdit only up to end of current line and not highlighting the characters after " if there is no " on same line not escaped with the defined escape character.

              On the other hand it can be useful to have EnableMLS defined in the wordfile although the language does not really support it because in this case UltraEdit highlights suddenly a larger block when a quote is missing on a line in code. C/C++ supports multi-line strings, but I usually don't make use of it using first syntax example above. But I have nevertheless in my C/C++ wordfile EnableMLS to quickly see when a code block is highlighted as string because of a missing quote. Then I can easily see on which line a quote is missing obviously to get a correct syntax highlighting.

                Dec 17, 2019#7

                I sent the following issue report by email to IDM support yesterday.

                Forum member Peter detected a strange string highlighting issue and asked for help with topic Wrong string highlighting in AutoLISP file on lines with a slash in UltraEdit v24.20 to v26.20

                I analyzed that issue further by creating an example demonstrating this issue, see the attached image strings.png.

                Please save the attached wordfile strings.uew into the directory in %APPDATA%\IDMComp\UltraEdit\wordfiles and the other attached file strings.txt into any other directory. Then start UltraEdit and open the file strings.txt.

                "SEQEND" in second line and in all lines of second block is not highlighted as string for no real reason since UltraEdit for Windows v24.20.0.27. There is no such syntax highlighting issue with even older versions like with v24.10.0.35 or with v22.20.0.49 according to my tests.

                The wrong string highlighting issue caused by forward slash occurs even with wordfile containing just the line:

                Code: Select all

                /L19"Strings" File Extensions = TXT
                "SEQEND" in line 16 is correct syntax highlighted with just this line in the wordfile.

                I received as reply that this very strange bug could be reproduced and is logged into issue database.
                strings.png (13.83KiB)
                Image showing the string highlighting issue on using the other two files
                strings.uew (456 Bytes)   1
                Syntax highlighting wordfile to reproduce this string highlighting issue
                strings.txt (2.41 KiB)   0
                File to open in UltraEdit for Windows v26.20 to see the string highlighting issue

                  May 23, 2020#8

                  This syntax highlighting issue is fixed with UltraEdit for Windows v27.00.
                  Best regards from an UC/UE/UES for Windows user from Austria