Optional whitespace not working in the absence of a suffix

[tlotze]

I have the following situation: In order for magit-todos to recognise things like # TODO without a mandatory colon, e.g. at the end of a line, I customised the suffix regex to be empty. This will, however, result in keywords being found even if they're part of a word, like HACK inside a capitalised occurrence of the word HACKSPACE. In the magit todos section, it is even listed as HACK SPACE including spurious whitespace. The same happens if I don't empty the suffix regex but make it optional as a whole. While IMO, it would be fine for the keyword to be found as part of something like "(HACK)SPACE", it should at least require to be bounded by non-letters or the start or end of a line.

[alphapapa]

it should at least require to be bounded by non-letters or the start or end of a line.

Have you tried setting the suffix to match such?

[tlotze]

On the one hand, I figured out a workaround in the process of writing this reply: Use \b as the suffix regex, describing a word boundary that occurs as the consequence of non-alphanumerics following, but without actually including those characters in the suffix.

On the other hand, the code that builds the search regex should still be improved in order for the suffix regex to really only be concerned with the content of the suffix rather than the details of delimiting matches. See PR #136.

This changes the code that builds the regex which is ultimately passed to the scanner. The keyword-plus-suffix expression is basically wrapped between optional blanks, which in turn are followed by an expression that may optionally match anything. This works out if the suffix regex describes a word boundary, e.g. in the form of some string containing at least one required non-alphanumeric character.

If, however, the suffix may match the empty string (or consists of letters, which it is unlikely to do, though), the whole combination of suffix and optional whitespace may amount to nothing that describes a word boundary after the keyword. So, it is desirable to add a word boundary when constructing the regex, but the question is, where? Without making assumptions about the content of keyword and suffix, the only safe place would be at the start of the capture group if and only if its first character is one with word syntax. See the first commit of the PR.

The crucial thing here is to require the line-end: Otherwise, an optional construct would match the empty string in the middle of the word and the rest of the word containing the keyword is never taken into account. (Also, I simplify a bit by leaving out the capture group and folding the optional whitespace into the (not word) case of the new subexpression. I may have missed the place where the group is used, though.)

[alphapapa]

IIRC, the current arrangement is a result of having solved some other users' bug reports and/or feature requests. I'm not sure the changes you propose are the best solution or even necessary. In order to proceed, please be specific with examples of what doesn't currently work as you need and what changes could accommodate you. Once we agree on what needs to be changed and how, then patches could be proposed and reviewed. Thanks.