Sorry, but I think what you want is not possible with UltraEdit v16.20.0.1011 because of following reasons:
- You can define function groups with the names Section, Dates, RUNSPEC, GRID, etc. But the group name is not a search string expression for finding the start of a block. It would be possible to define a group with name Sections which finds the blocks EDIT, END, GRID, OPTIMIZE, PROPS, REGIONS, RUNSPEC, SCHEDULE, SOLUTION, SUMMARY. However, even with the blocks listed in group Sections and therefore having the first requirement fulfilled, there are further problems for your list.
- UltraEdit is supporting currently Perl regular expressions on top level. The open and close tags and the regular expression strings in second and lower levels must be UltraEdit regular expressions. I don't know if any user has this issue already reported to IDM or not. I think the first time documented was it in forum topic Subgroups in function list using Perl regular expressions. I don't have a problem with this for my own syntax highlighting languages and therefore did not report this issue. When no other user reported it, IDM perhaps even don't know that the Perl engine is not used for the regular expression strings in subgroups and the open/close tag strings.
- With only the UltraEdit regular expression engine there is the problem that a case sensitive search is not possible. Only the Perl engine has modifiers for changing the case sensitivity in the search string itself.
- With only the UltraEdit regular expression engine it is not possible to add more than 2 strings into an OR expression, but we would need definitely an OR expression with more than 2 strings.
- But even when the Perl engine could be used for the open/close tags and the regular expressions in the subgroups the last problem is that UltraEdit currently does not support block definitions like in your file where a block ends where next block starts. The grouped function list feature currently requires that an open and a close tag (regular expression string) defines where the content of a (function) block starts and where this block ends, a requirement which is no problem for languages like C, C++, C#, Javascript. UltraEdit is smart enough to take nesting of those open/close tags into account because those programming languages require it. But the grouped function list feature mainly designed for programming languages with a good structure can't be easily applied to other file types where a block is not defined with an open and close tag. It would be currently necessary to help UltraEdit with marker strings in comments to mark begin and end of a block which most users don't accept. "Why should I add additional information to MY files or use a restricted subset of the rules supported by the syntax of MY files to help the editor to show me the informations I would like to see? The editor should be coded to highlight MY files like I want it and to show me the information I want to see according to MY rules!" Sure, a legitimate wish from a users point of view, but a requirement which can't be fulfilled by any programmer for any general text editor. Such a requirement can be fulfilled only by a text editor written for editing only the type of file such a user edits.
You can and should report by email to IDM that
/Regexp Type = Perl is not also used for the open/close tag expressions and for the regular expressions for subgroups.
And you can suggest a feature request for an option like
First level function strings define blocks which when enabled should result in splitting a file into blocks according to following rules:
- The line below the line(s) a string is found with an expression of a top level function string group is the first line of this function block.
- The line above the (first) line a string is found with an expression of a top level function string group is the last line of the previous function block if there is one.
- The end of the file is the end of the last function block if any top level function string is found.
- All lines from top of the file to first found top level function string do not belong to a block.
It would be good to have this option for every top level group because in your case the group
Sections would make use of this option, but the group
Dates would not make use of it. Of course with multiple top level function groups the user would need to be careful with the function definitions and with usage of that option to avoid overlapping blocks for subgroup function string searches.