Hi, I have a problem in function list for C.

If I define a function as
the function test_func will NOT be displayed in function list. But as
the function test_func is displayed in function list.

How should I modify the wordfile.txt to make function list work as that I want?

My UE-32 is v13.00.

Thank you very much.

My wordfile.txt :

/Function String = "%^([a-zA-Z_0-9^[^]*]+^)[ ^t]+([^p*&:, ^t^[^]a-zA-Z_0-9.!]++)[~;]"
/Function String 1 = "%[a-zA-Z_0-9*]*::^([a-zA-Z_0-9^~]+^)[ ^t^p]++([^p*&:, ^t^[^]/*^-'=:&a-zA-Z_0-9./(!]++)[~;]"
/Function String 2 = "%[a-zA-Z_0-9^][a-zA-Z_0-9^[^]]+[ ^t*]+^([a-zA-Z_0-9]+^)[ ^t]++^{^p(^}^{(^}[^p*&:, ^t^[^]a-zA-Z_0-9./(!]++)[~;]"
/Function String 3 = "%[a-zA-Z_0-9*&$^[^]*]+[ ^t]+[a-zA-Z_0-9*&$^[^]]+[ ^t*]+^([a-zA-Z_0-9]+^)[ ^t]++([^p*&:, ^t^[^]a-zA-Z_0-9./(!]++)[~;]"
/Function String 4 = "%[a-z_0-9^[^]*]++ [a-z_0-9*^[^]]+[ ^t]++[a-z_0-9*^[^]]+[ ^t]++^([*a-z_0-9]+^)[ ^t]++([^p*&:, ^t^[^]a-z_0-9./(!]++)[~;]"
/Function String 5 = "%^([a-zA-Z_0-9^[^]*]+^)[ ^t]++([^p*&:, ^t^[^]a-zA-Z_0-9./()!]++)[~;]"

Replace /Function String 1 = with following:

/Function String 1 = "%static +[a-zA-Z_0-9^][a-zA-Z_0-9^[^]]+[ ^t*]+^([a-zA-Z_0-9]+^)[ ^t]++^{^p(^}^{(^}[^p*&:, ^t^[^]a-zA-Z_0-9./(!]++)[~;]"

This one is identical to /Function String 2 = except "static +" is inserted before. Original function string 1 is useful only for C++. Better would be

/Function String 1 = "%[ ^t]++static[ ^t]+[a-zA-Z_0-9^][a-zA-Z_0-9^[^]]+[ ^t*]+^([a-zA-Z_0-9]+^)[ ^t]++^{^p(^}^{(^}[^p*&:, ^t^[^]a-zA-Z_0-9./(!]++)[~;]"

But this function string cannot be used in UE prior v13.00 or UES prior v6.20 because it exceeds the maximum of 119 characters for a function string. So the first one with 118 characters must be used for such versions of UE / UES which works only when static is at start of a line and 1 or more spaces follows, but not tabs.

I am using UltraEdit 16.30.0.1001. Where is the wordfile stored? When I go to the "Configuration" panel, the "apply" button is greyed out. I am using a network install. The following is a sample of what shows up and what does not:

The button Apply is disabled as long as no setting is changed. Once you change a setting, the button Apply is enabled.

What most Windows users don't know is that Apply and OK do the same in configuration dialogs. Both save all settings of all the configuration tabs, not just active tab. That is Windows standard behavior. If applications have a dialog with multiple tabs where Apply does not save all settings from all tabs, the programmer of this application has made a mistake. The only difference between Apply and OK is that after saving the settings, the dialog is closed on OK while the dialog remains open on Apply giving the user the possibility to see the effect of the new configuration if there is a visible effect and perhaps change the configuration again. Because button OK results always in saving all settings, it is always better to exit a dialog with Cancel if just opened for looking for something. OK should be clicked only if something has been changed. Good application programmers skip saving all settings on OK if nothing changed by the user in the dialog.

After opening Advanced - Configuration - Editor Display - Syntax Highlighting you see the path to the wordfiles directory. Further you can select language C/C++ (if not already preselected) and click on button Open to open the wordfile containing the syntax highlighting language definition for C/C++. After opening the wordfile, exit the configuration dialog with button Cancel (nothing changed in the dialog).

For the example you have posted there is 1 change necessary in the wordfile. You have to insert 1 ^p as you can see below to allow also line breaks between function name and opening (.

//type type name args
/TGFindStr = "%[a-z_][:a-z_0-9*&$^[^]*]++[ ^t]+[a-z_][:a-z_0-9*&$^[^]]++[ ^t*]+[*&]++^([a-z_][a-z_0-9]++^)[ ^t^p]++([^p*&:, ^t^[^]a-z_0-9./(!]++)[~;]"

You may need to make this change also on the other regular expressions except the second one for C++ functions where ^p is already present. Look for ^)[ ^t]++( and changed this expression part to ^)[ ^t^p]++( to allow line breaks on all C functions after the function name.

Mofi wrote:But this function string cannot be used in UE prior v13.00 or UES prior v6.20 because it exceeds the maximum of 119 characters for a function string.

Sorry for the off-topic mini-rant, but I sometimes wonder where these arbitrary limitations that seem to often crop up in UE come from?

Who decided it should be 119 (or 120 if you prefer), and not 100, 500 or 128? Or 10000? And why do the limits so often seem small? It's been more than a decade since worrying about 100 bytes here or there should matter.

Here are some of the various documented limitations for the syntax highlighting configuration. It's like they used a random number generator skewed to numbers that are ridiculously small for the capabilities of today's computers (except maybe for 372KB - but again, where the hell did that number come from? Was it the largest file that an IBM PC with MS-DOS 2.0 using double-sided, double-density floppies could hold?):

• The characters used for block comments may also be configured (i.e. /* … */ for 'C'). These are in the form "Block Comment On = " and "Block Comment Off = " followed by up to nineteen characters each that define the comment designators
• Up to eight groups of different recognized words
• Each file may be up to 372KB in size.
• The description may be up to 24 characters.
• There can be up to 10 column ranges.
• Up to 97 bytes may follow the "File Extensions = " declaration
• Up to 125 bytes may follow the "File Names = " declaration.

The explanation is the long history of UltraEdit. UltraEdit was not coded completely in the last 3-5 years. There was already a 16-bit UltraEdit for Windows 3.1 more than 15 years ago where computers worked with Intel 386, 486 and Pentium processors with just a few (very expensive) MB RAM. Therefore the applications written in these days worked mainly with static buffers. The main buffer for a text editor was surely the buffer for a line with line terminating characters which was often 128 or 256 characters. Even nowadays the C functions declared in stdio.h for reading strings from files work with static arrays. Modern frameworks and libraries hide that with their functions although using still those old string and file functions. Just look deeply into the source of modern libraries and you will see that.

IDM has constantly replaced most static arrays and buffers by dynamic. The maximum length of 119 characters was detected by Paolo and I by chance. I think none of IDM developers has really defined that maximum.

19 characters for block comment on/off string may be a result of a static character array with a size of 20 bytes (19 characters plus terminating NULL byte).

The up to 8 color groups are already up to 20 nowadays. See also this post for details on color group numbering.

I don't know if 372KB wordfile file size limit still exists. I have simply no wordfile coming to some extent near this limit.

The description can be already longer than 24 characters. But a wordfile creator should take into account that the drop down lists in the Syntax Highlighting configuration dialog have a fixed width as well as the field in the status bar showing the name of active syntax highlighting language. Because a proportional font is used in configuration dialog, status bar and menu View as (Highlighting File Type), a definite maximum of characters for language and color group name does not really exist.

Who has ever needed more than 2 column ranges for line comment valid columns? A static array with 10 column ranges is most likely no problem for anybody. Perhaps the first user requested that feature needed 10 column ranges.

97 bytes for File Extensions respectively 125 characters for File Names is most likely also caused by static line buffer size. And these limitations do perhaps not exist anymore. I have not tested that as I simply have no wordfile which has so many file extensions and no wordfile with a File Names definition.

Mofi: thanks for the detailed reply.

But, I'm sorry that my post provoked you to put so much effort into a response. I was really just ranting about how random (and small) the limits seemed to be. It would be nice if IDM did some work to remove or increase more of these limits, but clearly it's not a major problem in the software - just an irritant at times (I imagine more often to you than to me).