I don't know anything about structure of MediaWiki files and so I can't help with something verified by me.

It is most likely possible to create a syntax highlighting wordfile for MediaWiki which finds chapters/sections using 1 or more UltraEdit or Perl regular expressions and list them in Function List as flat or as hierarchical list. This makes it possible to jump to a chapter/section by clicking on item in Function List. Such a function list has also the advantage on being permanently visible to see on which chapter/section the editing is currently taking place as the selected item in function list is updated on moving caret in file.

It is also most likely possible to define in the syntax highlighting wordfile for MediaWiki open/close fold strings to be able to fold/unfold one ore more chapters/sections by key or by clicking on the appropriate symbol in code folding gutter. But collapsing/expanding from a dockable window is supported only for XML files with XML Manager.

By the way: Do you know the Document Map view and its features available via context menu?

Code folding could be really a problem because "start of line" and "end of line" can be defined for open/fold strings as it looks like would be required at least for heading 1. An equal sign with a space before/after exists usually also often anywhere in text. But two consecutive equal signs and a space does usually not exist in text (but often in a code block) and therefore the following could be already helpful.
A hierarchical function list could be also possible for the headings.

But I would really need an example MediaWiki file to be able to see the structure, make appropriate definitions in wordfile and test them out. The referenced topic contains 3 different versions of a syntax highlighting wordfile for MediaWiki, but no "real world" example for testing. This is not helpful to help you on creating a good syntax highlighting wordfile for MediaWiki files with flat or better hierarchical function list and code folding.

So one or even better more real world MediaWiki files compressed together with currently used *.uew file into a RAR or ZIP archive uploaded as attachment to your next post would be really helpful for me to help you.

The MediaWiki example file and the webpage were a big help on creating the syntax highlighting file. Thanks.

BTW: There is a typing mistake in the file in four tildes adds the data and five tildes. The word should be date and not data. You might want to report this or correct it by yourself if you have editing permissions for this website.


Explanation of the wordfile version 1 for MediaWiki:

The first line does not contain the keyword Nocase to make it case-sensitive. I think, this makes sense for the few substring definitions in the wordfile. You could nevertheless add Nocase to first line after language name if you think you need it. There would be nothing else modified in this first version of the wordfile with adding Nocase.

Noquote disable string highlighting of UltraEdit for strings with " and ' because string highlighting would be counterproductive for MediaWiki files in my point of view.

Line Comment = = Line Comment Valid Columns = [1] defines all lines starting with an equal sign as comment lines. So the color/style settings for comments defines the highlighting for headings 1-6. Of course a wrong highlighting can occur if a plain text line starts with an equal sign, but I think this is very rare in MediaWiki files.

Block Comment On Alt = [[ Block Comment Off Alt = ]] defines everything between two square brackets as link to highlight with color/style settings for alternate block comments.

The function string definitions are primary designed for a flat, unsorted function list. With Function List opened, right click into the view and uncheck Sort List and check Flat List. The equal signs at begin are included in displayed text to see in function list the heading level. A flat, unsorted function list shows the heading structure in file.

The function list would be displayed sorted by heading level and next alphabetically with having Sort List enabled.

Flat List not enabled would result in getting the headings listed by level in order as found in file or sorted alphabetically depending on Sort List option. If you prefer a not really hierarchical presentation of the headings in function list with the titles Heading 1 to Heading 6 it would be better to move ^( in all 6 UltraEdit regular expression search strings to the right before ?+ to get just heading text displayed in function list.

A real hierarchical presentation of the headings like in document map of Microsoft Word or as displayed on MediaWiki pages would be very difficult to achieve if it is possible at all as UltraEdit needs to know for each level where to start and where to end searching with the regular expression for example for heading 3. This is not really easy to define. For example the block start for heading 2 would be begin of the line below heading 1 line and block end would be end of line above a heading 1 line or end of file. Such a definition is very difficult to achieve with regular expression strings if it is possible at all. The recursive nature of headings can be easily handled by code with recursive function calls, but very difficult with regular expressions. That's the reason why I have quickly given up at least for the first version to get the headings listed in function list like a contents list.

The delimiters are defined as necessary for the syntax highlighting.

The brace strings are defined to help finding matching begin/end of a table or the defined HTML tags with using the auto-brace matching feature of UltraEdit.

The fold strings make it possible to fold tables, preformatted text blocks galleries and of course also chapters/sections with the exception of last chapter as there is no close fold string for last chapter. End of file can't be defined also close fold string.

The marker characters <> and [] assigned to color group 1 and color group 5 are for highlighting HTML tags and links. Note: Strings within marker characters must start and end on same line in file to be highlighted.

Color group 2 and 3 are for highlighting the markers used in lists and tables.

Color group 4 contains substring definitions for links without surrounding square brackets. Highlighting of strings starting with one of the 5 strings ends on next word delimiter which is often a space character, but could be also an ampersand as URLs often contain also an ampersand. The main goal of this color group is highlighting a link in plain text with a signal color to indicate that it would be good here to add square brackets.

Color group 5 defines the color/style settings for links in single square brackets and for image links in galleries.

Color group 6 defines HTML attributes as used in tables for getting them displayed highlighted. Other attributes often used in MediaWiki files should be added by you to this color group.

Color group 7 highlights all double quotes in file, as well as values for HTML attribute align and some HTML entities. Other attribute values and HTML entities also often used in MediaWiki files can be added by you to this color group. The complete HTML entity list as defined in color group 3 of html.uew could be added if that makes sense for MediaWiki files.

Color group 8 highlights each single quote character in file. I would be good to assign a color/style to this color group which really good highlights this small character in file to see where two, three or 5 single quotes are used in file and where just a single quote exists which might be a formatting mistake.

It would be possible to add '' to list of marker characters and add on line with ' additionally after a space also ''. This would result in highlighting everything between an odd number of single quotes within a line with color/style of color group 7, i.e. bold displayed text, bold+italic displayed text and plain text within single quotes, but not italic displayed text. This might make sense or not for MediaWiki files. Best would be you try that out and let me know if a marker character definition with '' makes sense.

Color group 9 highlights 4 or more hyphens, i.e. a horizontal rule.

And color group 10 to 12 highlight 3, 4 or 5 tildes surrounded by delimiters as defined on line starting with /Delimiters =. It would be advisable to assign to those 3 color groups extremely different colors as in this case the highlighting color makes it easy to see if there are 3, 4, or 5 tildes.


I suggest that you use this first version of a wordfile for MediaWiki files, work some time with it and add words and substrings which you think would be also useful. Please report any problem you have with the current highlighting or which you encounter in the next days here on this topic and I will look on it if something could be done to solve this highlighting problem.

Finally, after some weeks of usage, it would be good to attach once again the last version of the wordfile for MediaWiki for verification by me and when I can't find a general mistake, you or I should send the wordfile to IDM support by email for upload on their server or push it on their GitHub repository and make a pull request.

acinfo64 wrote:I guess it's not possible to make a counter in a wordfile and display it's value instead of the = signs.

That's correct. The function list just displays what was found by the regular expressions defined in the wordfile. It is not possible to modify the found strings before getting them displayed in the function list.

acinfo64 wrote:The "== Titles and subtitles ==" in the example doesn't collapse. I don't see why but it has something to do with the text below the "This looks like:". Which in practice doesn't occur.

Code folding is offered always from line with a fold string to next line with an unfold string IF there is at least 1 line between.

On the heading example block
just the last line is offered to fold for that reason.

Important: Code folding does not work like brace matching. The order and the number of unfold strings does not refer to order and number of fold strings. So the code folding for MediaWiki files is always from a heading to next heading independent on level of heading.

But the reason for no folding offered on line with == Titles and subtitles == is caused by
When an equal sign and a space is found AFTER line comment starting string which is just an equal sign, then consider this line for code folding. But on lines for heading 1 like on = This is a major title = there is just a space character after the single equal sign being interpreted as start of the comment and that causes the not expected code folding on == Titles and subtitles ==.

The solution is simple. Space and equal sign must be exchanged in the open/close comment fold strings:
The end of a heading is definitely always AFTER line comment starting string, i.e. after the equal sign in first column.

acinfo64 wrote:It would be nice, if a line starts with a space, that then all text behind that space, on the same line, will have a different color (something like gray close to white). That's RAW text and used very often. The text after the space (on same line) is not formatted anymore.

Well, the first line could be changed to
Note: There are 2 spaces after Line Comment Num = 1.

Only line comments definitions can be combined with a position information. But line comment, alternate line comment and block comment are highlighted all with same color/style settings. So headings and preformatted text are syntax highlighted with same color/style in the file with using above definition.

And now every " =" within a preformatted text block would be also interpreted as open/close comment fold string which would be definitely not good. Therefore I suggest not making use of such a definition. Let the block displayed finally as preformatted text being displayed not syntax highlighted in UltraEdit.

I agree that it would be really useful to have raw text displayed with a different color in text editor, but this is currently with UE v23.20 not really possible without bad effects for other parts of the syntax highlighting. Syntax highlighting of UltraEdit has currently not enough capabilities for column or context dependent syntax highlighting because not needed for most programming and scripting languages for which syntax highlighting is primary designed for.

acinfo64 wrote:Is it possible to give the top level chapter (e.g. = Chapter 1 =) a different color?

No because all lines starting with an equal sign are line comments. It is impossible to get heading 1 highlighted different to all other headings.

It would be possible if there would be separate color/style settings for line comment and alternate line comment and raw text is not highlighted as comment, but this is unfortunately not the case.

acinfo64 wrote:I think it would be nice if the bold/italic text will be colored also, instead of only the markers (''').

results in getting highlighted with color group 8 everything between 1 single quote, 3 single quotes, 5 single quotes, 7 single quotes, but only on same line as marker characters don't work across multiple lines in file.

Document formatting defined with a sequence of characters like used for MediaWiki, DokuWiki or Markdown can be processed only with special code using IF - ELSE IF - ELSE IF conditions. For example:

IF there is a ' AND next character is NOT ' THEN ignore
ELSE IF the next but one is NOT ' THEN display italic
ELSE IF the next but two is NOT ' THEN display bold
ELSE IF next 4 are all ' THEN display bold+italic.

Such markups can't be correct interpreted with the syntax highlighting capabilities of UltraEdit v23.20.

Also it is not possible that multiple highlighting definitions are applied on same string. For example if above definition is used to get everything within a line enclosed in 1 or 3 or 5 single quotes highlighted with settings for color group 8 like finally bold displayed text, it is not possible to highlight tags like <nowiki> within the string displayed finally bold with a different color.

Syntax highlighting is for highlighting the syntax and not for getting a plain text file displayed like a document after processing by an application. In my point of view it is much more important to see the special characters and the tags highlighted which define the final formatting on editing a MediaWiki file in the text editor to see possible mistakes on those format specifying character sequences than getting the text file in text editor already displayed like it will be displayed finally after being interpreted by MediaWiki processor converting the text file to an HTML file and being parsed by a browser.

Best would be to get '' and ''' and ''''' highlighted with 3 different colors and all other sequences of single quotes are displayed in UltraEdit as normal text. But this would require that the single quote character is not defined as word delimiter. But this is necessary as a sequence of single quotes can and must often exist immediately before or after a real word in a human language context and therefore the single quote character must be a word delimiter.