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