Handling of tag style [[code]]
| Project: | GeSHi Filter for syntax highlighting |
| Version: | 6.x-1.x-dev |
| Component: | Filtering |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
I'm using GeSHi Filter aside PEAR Wiki Filter (well, a custom implementation thereof - but the error creeps up when using PEAR Wiki Filter, too), which enables mediawiki-syntax input. I've set GeSHi Filter to accept both angle brackets as well as square brackets. The filter workflow processes input first through PEAR Wiki Filter, then through GeSHi Filter (where PEAR Wiki Filter ignores code and blockcode tags).
The bug shows when creating an interwiki link that starts with the word code. The input:
link to [[code conventions]] wikipage.(or even just "[[code]]") is incorrectly assumed by GeSHi Filter to be a code-block. As now closing tag is found, the rest of the page is rendered as code, too.
The output is
link to geshifilter-code wikipage.[/geshifilter-code]and it's rendered HTML code:
<p>link to <a href="/node/add/wiki" class="wiki-link-new" title="Geshifilter-code">geshifilter-code</a> wikipage.[/geshifilter-code]
</p>The expected output would be for GeSHi filter to ignore the link, and let it be rendered by PEAR Wiki filter:
<p>link to <a href="/node/add/wiki" class="wiki-link-new" title="Code">code</a> wikipage.
</p>A possible fix could be to adapt the regular expression in gheshifilter.pages.inc in _geshifilter_prepare, but I'm not that versed in regular expressions. A quick test adapting the pattern resulted in a correctly rendered link - but a regular code block wasn't getting highlighted anymore.
#1
A friend of mine came up with a regular expression that fixes this behaviour.
Please review the attached patch.
#2
Why don't you use only the angle brackets? There wouldn't be a problem then for you, I guess.
(I don't say you should, I'm just asking why you use both.)
Here's another take at the issue (to make it a bit more general than just your use case).
Right now we have a select list for the tag style to choose between "<foo>", "[foo]" and both.
But what about changing that to check boxes to select the desired styles from:
I expect this would make the code and regular expressions cleaner too.
#3
I'm using both styles as a favor to our users: some might be familiar using angle brackets because they're familiar with HTML, others are more familiar with square brackets that they know from bulletin boards or wikipedia.
Choosing this with checkboxes surely gives the administrator more freedom, but as long as there's only two different styles to choose from, using dropdowns is fine.
But introducing double square brackets as block markers for GeSHi Filter is exactly the opposite of what this issue is about: I wan't to disallow these expressions, not add them as block markers. If GeSHi Filter allows double square brackets, we won't be able to distinguish between wiki-links and code blocks at all.
#4
I know, that's not what I mean.
Now, we have the "[foo]" tag style and feeding it with "[[foo]]" style input gives the expected result: it replaces the inner "[foo]" part (so it's not a bug or something, but by design).
However, in your use case, it breaks things. Fixing it for you (so "[[foo]]" would not fire GeSHi) is more a hack than a solution IMHO, because it introduces a special case. Why should "?[foo]?" or "([foo])" trigger GeSHi but "[[foo]]" not?
So, if the only options are "<foo>" and "[foo]" I don't feel like "special casing" the regular expression for "[foo]", because it undermines the predictability of the behavior.
The point of explicitly offering options "[foo]" and "[[foo]]" is that this makes it (more) obvious to the user/admin that the "[foo]" tag style would not trigger on "[[foo]]" input.
This way we can fix your problem, while keeping things work as expected/predictable for the user.
#5
Here is a first patch to implement the proposal of #2
Still some work to do (mainly updating the filter tips and providing an upgrade path), but the core of the feature is implemented.
be welcome to try it out
#6
second iteration
updated filter tips stuff
provided upgrade path (only for global tag settings mode though)
there are some small things that can be done, but I would prefer to do them in a separate CVS commit
#7
committed:
http://drupal.org/cvs?commit=233410
#8
Automatically closed -- issue fixed for 2 weeks with no activity.