User to user discussion and support for UltraEdit, UEStudio, UltraCompare, and other IDM applications.

Syntax highlighting, code folding, brace matching, code indenting, and function list
3 posts Page 1 of 1
I have a similar struggle to new C++14 single quotation marks in binary literals with IDL (Interactive Data Language) which is a data analysis language. It allows strings to be delimited with ' or " but also uses the " to represent an octal integer. So "aaa18" is a string but "18" is an invalid octal number! So not only does UltraEdit mark the octal number as the start of a string, but the language itself will error off when it thinks you mean an octal value even if you don't. Because these otherwise valid strings are not considered strings by the language but anything else inside of double quotes is correctly identified as a string, I would love for UltraEdit to allow me to have a regex string that identifies double quote strings that start with a number so I can go back and put single quotes on that string.
I think, there is no solution to get highlighted a double quoted string consisting only of digits with a different color as being interpreted by IDL as octal number instead of a string.

I have tried this (with character between & and ' being a horizontal tab):

Code: Select all
/L20"IDL (Interactive Data Language)" Line Comment = ; Nocase String Chars = ' DisableMLS File Extensions = PRO
/Delimiters = % &   '()*+,-./:;<=>?@[\]^{|}~
/Function String = "^{Function^}^{Pro^} "
/Indent Strings = "Begin"
/Unindent Strings = "End"
/Marker Characters = """"
/C6"Octal Numbers"
** "0 "1 "2 "3 "4 "5 "6 "7 "8 "9
/C7"Double Quoted"

But it does not work because of marker characters have a higher priority on syntax highlighting than substrings or keywords. I have no further idea how to get a different highlighting for strings being interpreted by IDL has octal numbers.

Well, my philosophy on writing code is always for any language: Don't use language capabilities which can easily result in wrong interpretation. For example for C/C++ this means I use:

Code: Select all
if(uNumber < 5U) iValue = 13;
if(uNumber > 10U)
    iValue = 18;

But I use never:

Code: Select all
if(uNumber < 5U)
    iValue = 13;
if(uNumber > 10U) {
    iValue = 18;

For IDL as described by you I would never use double quotes for strings, just single quotes to avoid possible misinterpretation.

However, I agree that there are some (not well defined) languages were regular expression based syntax highlighting would be really useful as other text editors have nowadays. The computers are nowadays already fast enough to scan displayed text block with lots of regular expression finds for syntax highlighting.

But I think there are two main problems on enhancing syntax highlighting of UltraEdit with regular expressions:

  1. How to keep compatibility with existing wordfiles?
    Other editors developed on regular expression based syntax highlighting from the beginning do not have this problem.
    A solution would be having two syntax highlighting engines embedded in UltraEdit: the current one using *.uew files and a another one being used when the language is defined for example in a *.uer file. Or there is a keyword in a *.uew file which must be on first line which results in usage of regular expression based syntax highlighting.
  2. How to solve syntax highlighting conflicts caused by multiple regular expressions matching partly or entirely the same strings?
    For IDL such a conflict would be occur on using ".*" and "\d+" for syntax highlighting.
    It is clear that the author of the syntax highlighting file has to fix this conflict caused by not good first regular expression. But the text editor has nevertheless to handle this case somehow.
Best regards from Austria
Thanks Mofi. I try to avoid using double-quoted strings when I can, limiting them to enclosing strings containing single quotes and format statements. I did try a color group of "Octal Numbers" just like you did, with the same results.I am stuck letting IDL fail on the syntax check and find the strings that way but it is thankfully a rare occurrence.
3 posts Page 1 of 1