1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
My backported ikiwiki 1.48 converts smileys in the block code incorrectly.
I can see the HTML code of smileys image, instead of smileys image.
For example, I'd like to save interesting for me thread of courier-users
mailing list. Please looks below to see what ikiwiki does with that smileys:
From: Bernd Wurst <bernd@bw...>
Subject: Re: [courier-users] Uploaded my SRS implementation for courier to
the web
To: courier-users@li...
Date: Sat, 17 Mar 2007 19:02:10 +0100
Hi.
Am Samstag, 17. Mrz 2007 schrieb Matthias Wimmer:
> See the graphic on http://www.openspf.org/SRS at the bottom on the left
> side. You will find an example there how rewriting an already rewritten
> address works.
Ah, ok, didn't know that. :)
Thanks for the pointer!
cu, Bernd
BTW, maybe converting smileys in the block code should be disabled at all?
--[[Paweł|ptecza]]
> Looks similar to [[wiki_links_still_processed_inside_code_blocks]]; in both
> cases, substitution happens in a code block, which it shouldn't.
> --[[JoshTriplett]]
----
> Has there been any progress or ideas on this bug recently? I use an
> expanded CamelCase regexp, and without much escaping in freelink text, or
> url links, or in codeblocks I get IkiWiki's attempt at creating a "link
> within a link".
>
> I have no ideas other than perhaps once IkiWiki encounters \[\[ or the
> position is reset with a backreference from a CamelCased word, further
> processing of wikilinks is disabled until the position is reset and a "no
> not makelinks" flag or variable is cleared.
>
> I've come up with some _really_ ugly workarounds to handle case specific
> stuff like codeblocks but the problem creeps up again and again in
> unexpected places. I'd be happy to come up with a patch if anyone has a
> bright idea on a nice clean way (_in theroy_) to fix this. I'm out of ideas.
>
> --CharlesMauch
|