Hi!
IntelliTips uses built-in parser of UEStudio and not the strings found by the regular expressions in the wordfiles as far as I know. There are two definitions in some wordfiles for the internal symbol parser of UEStudio,
/Member String = and
/Variable String =. But there is no public documentation for those two definitions. I will contact IDM support to get more information about how to customize integrated parser to get better support for IntelliTips features like function tips for Xbase++.
In my opinion the Perl regular expressions for function list for Xbase++ still need some improvements (to fulfill my quality standards). I have the provided CHM file for Xbase++ now and will study it to find better regular expressions for an even better function list.
I spent some hours to improve the wordfile for Xbase++ and here are the results of my work.
Duplicate words
I checked the wordfile for duplicate words, see
the ultimate syntax highlighting tools.
I removed all duplicate words except the following:
Code: Select all
File -> in /C1
file -> in /C3
Memory -> in /C1
memory -> in /C3
Select -> in /C1
select -> in /C3
Set -> in /C1
set -> in /C3
SetPos -> in /C1
setPos -> in /C2
Type -> in /C1
type -> in /C3
I kept them in case of using auto-correction feature for this not case-sensitive language.
I made also changes on list of delimiter characters like changing sort order and removing the dot to make
.and. .f. .not. .or. .t. valid "words" in the wordfile and get better syntax highlighting for floating point numbers.
Additional color groups
The wordfiles in the RAR archive contain now 10 color groups which is supported since UE v17.00 and UES v11.00. Previous versions support only up to 8 color groups. In
*_old*.uew the number of color groups is just 8 because color group 9 and 10 and the marker character string definition are removed from those wordfiles.
Color group 8 is for parentheses and braces (and square brackets if marker characters not used).
Color group 9 is for strings in brackets (strings and elements of an array).
Color group 10 is for single quoted strings which can be highlighted now with a different color to double quoted strings. That could be useful to see easily on color of a string if
' or
" can be used inside the string.
Asterisk used as line comment
Alaska Xbase++ coding guidelines describe mainly three kinds of comments: two line comments and one block comment.
(The other 2 kinds of comments supported for compatibility reasons should not be used anymore and are therefore ignored here.)
The line comment
// and the block comment
/*...
*/ are no problem for syntax highlighting.
The second line comment type with just
* as beginning is problematic for syntax highlighting as an asterisk is used also as multiply operator in formulas. I could not find a detailed explanation on when
* is interpreted as line comment starting character and when as multiply operator. I suppose that
* is interpreted as line comment beginning if it is the first non whitespace character on a line.
I added following to first line of the wordfiles for Xbase++ syntax highlighting to avoid a wrong interpretation of
* as beginning of a line comment when used as multiply operator as much as possible:
Code: Select all
Line Comment Valid Columns Alt = [1-9] Line Comment Preceding Chars Alt = [~!-~]
The character
* is interpreted as beginning of a line comment only if
- found by UE/UES within the first 9 columns of a line (9 because of a preceding tab with standard width of 8), and
- the preceding character is not any character in ASCII table from question mark to tilde which means practically only whitespaces are allowed left of * being interpreted as line comment beginning.
It is of course possible to modify or completely remove one or both limitations.
Flat versus hierarchical (grouped, tree-style) function list
UltraEdit and UEStudio use case-insensitive regular expression searches to find strings for being displayed in the function list view. That makes it more or less easy to customize what is displayed in the function list for a text or code source file.
The UltraEdit and since UE v13.10 and UES v6.30 also more powerful Perl regular expression engine can be used for searching for strings listed in the function list. Note: The Perl regexp engine can be used for search strings in a hierarchical (tree-style) function list up to UE v19.00 and UES v13.00 only for search strings in top level. UE v19.10 or UES v13.10 is required to use Perl regexp also for second, third, ... level. The legacy Unix regexp engine can't be used for function string expressions.
The users have the choice between a flat function list and a tree-style function list since UE v16.00 and UES v10.00. It is possible to toggle via function list context menu item
Flat List between flat and grouped function list.
Most of the user contributed wordfiles are pretty old and contain therefore function list regexp strings in old definition style using UltraEdit regexp engine which are often very simple and are only for a flat function list. And that's okay for many kind of text files.
But for many programming languages a hierarchical function list is often better. But for a tree-style function list a different and more enhanced list of regular expressions are needed in the wordfile. And for programming languages it is often necessary to use the much more powerful Perl regexp engine which gives even the possibility to override case-insensitivity in the regexp search string and make a search case-sensitive.
The usage of the Perl regexp engine for function string searches has one more big advantage over UltraEdit regexp searches: It is possible to define more than one capturing group. With the UltraEdit regexp engine just one string in entire found string can be tagged for being displayed in the function list. But with the Perl regexp engine several capturing groups can be defined in the search expression and the strings found by the expressions in each capturing group are concatenated with a single space for display in the function list view. This gives users more control over what and how the strings are displayed in the function list view.
A hierarchical function list has the advantage that the function list can be quite small in width, but nevertheless display everything of interest while for a flat list the user has to decide to get only basic information displayed in the function list or see full information only when hovering mouse pointer over a string in the function list if not using a wide function list view.
The attached RAR archive contains several wordfiles. The only differences between those wordfiles are the function strings. Everything else is identical in all files.
The
*_old*.uew files are for UE < 16.00 and UES < v10.00 using Perl regexp search strings in old definition style which are not tested by me with such an old version of UE/UES.
The
*_flat*.uew files are for UE >= 16.00 and UES >= v10.00 using Perl regexp search string in new definition style for a flat list tested only with UE v21.20.0.1014 and UES v14.30.0.1008.
And last
Xbase++.uew is for a hierarchical function list view working only for UE >= 19.10 and UES >= 13.10 (most likely) tested also only with UE v21.20.0.1014 and UES v14.30.0.1008.
A small readme.txt also included in the RAR archive describes the differences for the flat list variants.
I was very tricky to find regular expressions for finding parameters of functions, methods, ... as it is possible to define them also without parentheses. Therefore it was necessary to avoid finding strings in next parentheses below the function, method, ... definition line/block if and only if a function, method, procedure is without parameters and () is also omitted in definition. But I had success as it can be seen on using
Xbase++.uew.
What is not correct listed in function list at the moment is a multi-line definition of a function, procedure, etc. with a line or block comment on each line of the definition. I have not seen such blocks in sample source file nor in help and therefore have not spent time on how to define the regular expressions to allow comments within a definition block and filter them out for function list display. So I can suggest only writing explanations for each parameter of a function, procedure, etc. above or below the block which defines the function, method, procedure, ...
Please let me know if anything is not good displayed in function list, or something from source code file is missing in function list, or something is included in function list which should not be included there, and I will look into it and try to improve the expressions accordingly.
IntelliTip function tip
I'm in contact with IDM support regarding function tip. The integrated symbol parser finds the functions in Xbase++ source files and for users of UEStudio it is not possible to customize the parsing mechanism. I could see that today on looking on the file in hidden directory
%APPDATA%\IDMComp\UEStudio\cache created by UEStudio for the project with the Xbase++ source file. The source code of the parser itself must be improved for Xbase++ parsing.
Improved wordfile(s)