Regex question regarding a CustomEditField definition

General
1

I’m trying to write a Markdown highlight definition for the CustomEditfield open source editor. Unless I’m misunderstanding, I think I have found a bug in the highlight engine.

This is a really simple definition that should highlight text flanked with __:

<?xml version="1.0" encoding="UTF-8"?>
<highlightDefinition version="1.0">
	<name>Markdown</name>
	
	<contexts defaultColor="#000000" caseSensitive="no">		
		<highlightContext name="BoldUnderscore" highlightColor="#326510">
			<startRegEx>\s__[^ \t]</startRegEx>
			<endRegEx>__</endRegEx>
		</highlightContext>
	</contexts>
	
</highlightDefinition>

Note that the context should begin with a __ that is preceded by whitespace with at least one non-space or non-tab character. This fails to work on this text:

a __bold__

which it should. If I remove \s and replace it with [ ], same thing. If I change the regex to __[^ \t] then it highlights the bold text but this is an incorrect pattern as I need to assert that there is whitespace before the __.

I’ve looked through the code of CustomEditfield to make sure that the engine isn’t trimming spaces between matches but I don’t think it is.

Am I misunderstanding something here?

2

Garry,
When you look at HighlightDefinition.Highlight and step through it, you’ll find that when it checks for a mContextRegex, it contains a whitespace check at the start. With that, it will eat away the space before your bold-context gets a chance.

So yes, that could be considered a bug.

I tried around a bit (please note: I’m not the author (that’s Alex Restrepo) of it, but only the one that took over to maintain it as best as I could after the author abandoned it and Xojo) and found that if move the code that adds this “blankSpaceContext” rule from HighlightDefinition.Constructor to the end of HighlightDefinition.LoadFromXml(string) as boolean, it’ll work with your test, while it still also works with the realbasic template (have not double checked the others). When you move the code, make sure to include the append (which should have had a blank line after, not before it).

Thanks for creating the ticket for it - I’ve now fixed it, added a Markdown stub file, and pushed it as v1.11.0

Give that a try.

3

Thank you Thomas. That seems to fix my use case. I’ll play around with the other definitions to see if it breaks anything else.