WikiExtrasPlugin delimiters adjacent to a phrase

[Clemens Feige]

Hello

I suspect there is a regression with the popular WikiExtrasPlugin, see
[1]. After upgrading from TRAC 1.4 to 1.6 the handling delimiters
adjacent to a phrase seems affected.

Here is a quote of what WikiExtrasPlugin advertises, and what is
accomplished in code with method `add_style` in file `phrases.py`; see [2]:

> Any delimiter ():<> adjacent to a phrase will not be presented. This makes it possible to naturally write FIXME:, for example, but view the phrase highlighted without the colon (:) which would not look natural.

However, in TRAC 1.6 for a phrase like FIXME: the colon is not removed,
but it should be. For dual colons i.e. :FIXME: both colons are removed,
which is correct.
TRAC 1.4, all colons in FIXME: and in :FIXME: are removed.

If you are using the WikiExtrasPlugin and the new TRAC 1.6, then please
tell me: What comes out if you write a phrase with trailing adjacent
delimiter i.e. "FIXME:"?

Anybody who can comment on this?
Depending on other people's feedback I would file a bug ticket.

Unfortunately I do not understand the code in method `add_style` in file
`phrases.py`; see [2]. What is `self.text` for example?

Thanks
Clemens


P.S.

[1]
https://trac-hacks.org/wiki/WikiExtrasPlugin

[2]
https://trac-hacks.org/browser/wikiextrasplugin/trunk/tracwikiextras/phrases.py?rev=16718#L90

[Dan]

I'm using this plugin with a pre-release version of 1.6 (which I will hopefully get the time to update soon).  Now that you mention it, I see that phrases like TODO: will come out showing the trailing colon.  I am mostly having it highlight custom words for which there isn't punctuation I'm asking it to change.

- Dan

[Jun Omae]

Hi,

That is caused by the generated regular expression from the plugin.
The longer symbols in (...|...|...) of the regular expression should
come first.

Please try the following patch:

[[[
Index: tracwikiextras/util.py
===================================================================
--- tracwikiextras/util.py (revision 18650)
+++ tracwikiextras/util.py (working copy)
@@ -35,7 +35,7 @@
unicode = str

def prepare_regexp(d):
- syms = sorted(d.keys(), key=lambda a: len(a))
+ syms = sorted(d.keys(), key=lambda a: len(a), reverse=True)
return "|".join([r'%s%s%s'
% (r'\b' if re.match(r'\w', s[0]) else '',
re.escape(s),
]]]

--
Jun Omae <jun...@gmail.com> (大前 潤)

[Clemens Feige]

Hello

The patch works well. Great! Thanks, Jun.
Using `reverse=True` inside `prepare_regexp` seems to cure the issue.

SVN-blame tells us: The affected line 38 in tracwikiextras/util.py has
been recently edited in 2022 with the objective to make this plug-in
compatible with Python 3.

How shall we continue? If desired I can still create a ticket for the
maintainer of the plug-in and append Jun's patch. Or the maintainer or
somebody else with write permissions commits the change ...

Thanks
Clemens

[Jun Omae]

On 2024/08/08 19:08, Clemens Feige wrote:
>
> Hello
>
> The patch works well. Great! Thanks, Jun.
> Using `reverse=True` inside `prepare_regexp` seems to cure the issue.
>
> SVN-blame tells us: The affected line 38 in tracwikiextras/util.py has
> been recently edited in 2022 with the objective to make this plug-in
> compatible with Python 3.

Hum, before [18475], the prepare_regexp sorts longer symbols before
shorter ones.

[[[
def prepare_regexp(d):
- syms = d.keys()
- syms.sort(lambda a, b: cmp(len(b), len(a)))
+ syms = sorted(d.keys(), key=lambda a: len(a))

return "|".join([r'%s%s%s'
% (r'\b' if re.match(r'\w', s[0]) else '',
re.escape(s),
]]]

> How shall we continue? If desired I can still create a ticket for the
> maintainer of the plug-in and append Jun's patch. Or the maintainer or
> somebody else with write permissions commits the change ...

Could you please add a comment to https://trac-hacks.org/ticket/14133 or
create new ticket about this issue?

I have commit right to the entire of trac-hacks. I'll push the changes
and re-close the ticket.

[Clemens Feige]

Jun Omae wrote on 08.08.2024 at 12:44:
> On 2024/08/08 19:08, Clemens Feige wrote:
>>
>> The patch works well. Great! Thanks, Jun.
>> Using `reverse=True` inside `prepare_regexp` seems to cure the issue.

[snip]

>> How shall we continue? If desired I can still create a ticket for the
>> maintainer of the plug-in and append Jun's patch. Or the maintainer or
>> somebody else with write permissions commits the change ...
>
> Could you please add a comment to https://trac-hacks.org/ticket/14133 or
> create new ticket about this issue?
>
> I have commit right to the entire of trac-hacks. I'll push the changes
> and re-close the ticket.

I https://trac-hacks.org/ticket/14133#comment:7

The issue and the patch is now mentioned in ticket #14133:

https://trac-hacks.org/ticket/14133#comment:7

Clemens

[Clemens Feige]

> [snip]
>
> Thanks
> Clemens



Just for the records.
The issue is fixed with TRAC hacks SVN revision 18651, as mentioned in
the related ticket:

https://trac-hacks.org/ticket/14133#comment:10

Thanks
Clemens