Strict Standards: Declaration of action_plugin_jquery::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/only4mods/lib/plugins/jquery/action.php on line 14

Strict Standards: Declaration of action_plugin_captcha::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/only4mods/lib/plugins/captcha/action.php on line 137

Strict Standards: Declaration of action_plugin_wikistatistics::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/only4mods/lib/plugins/wikistatistics/action.php on line 51

Strict Standards: Declaration of action_plugin_codehighlight::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/only4mods/lib/plugins/codehighlight/action.php on line 225

Strict Standards: Declaration of action_plugin_ipban::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/only4mods/lib/plugins/ipban/action.php on line 60
talk:dokuwiki:codehighlight:en:start - Ema's plugins (WP, DW)

Unfortunately, some of the pages are now read-only, this because in the last few months some spammers decided to “contribute” to the wiki…
I'm trying to lock only the interested pages.

Discussion and feedbacks

First of all, thanks for all your efforts. Second, I would like to ask you if you have considered to wide your plugin for dokuwiki syntax. Most of the times I use VIM for editing dokuwiki, because I like the syntax highlighted very much when I build texts (I make a quite intensive use of dokuwiki).

If I can collaborate with something, just drop me a line to poliorcetes <at] gmail punto com

I didn't do so much… ^^

Do you mean a sort of WYSIWYG?
mmm…let's discuss at least… :Emanuele 2009/04/02 20:
Ok, now i get your idea!
Emanuele 2009/04/04 13:39
Here it is a demo version.
Only few syntax elements implemented: bold, italic, underline and links (text and images). I introduced also a couple of autocomplete (images and text links), but I'm not if they are useful or not…

My point would be: Wysiwyg is a dead end for wikis. For instance, google sites (ex jotspot) has it implemented as default - indeed, it has no wikitags. Although a version history is implemented, the other basic characteristic of wikis is not: easy & quick creation of new pages, nodes or whatever you want to call them. Without quickpages like thisquickpageexample, proper wiki way of work cannot run.

If you and your team use a wiki for document management, you need all the wiki way. But if you write complex & long documents with a lot of doku syntax elements, plain text is not comfortable for work a lot of hours. Therefore, doku highlighted syntax would be something which take the best of both worlds: comfortability and all the wiki way

thanks again for all the good work!

Ps.: although I'm not a developer, I'll try to look for good regexp for it if you want.
P.S.2: I have been so clever that I didn'r register myself before writing this. Therefore I am not be advised of modifications of this page, so please throw me a line when you do it
PS3.:registered. I cannot see any option of email after page modifications :(

You didn't find it because it was disabled… ^^;; 1)
Now you can find the link on top of the page, on the right of the old revision link! :-)

two more things

first, I detected an obvious fact: image&nbsp;also covers plugins like blog_namespace or iframe url_html - a lot of plugins are already covered by your definition :) second, I added two definitions that I hope that cover most of the plugins cases:

{ input ; /(&lt;.*?&gt;)(.*?)(&lt;\/.*?&gt;)/g, output : '<em>$1</em><em>$2</em><em>$3</em>' }, // any xml-tagged pluggin, like <box> or <html>
{ input ; /\~\~(.*?)\~\~/g, output : '<em>$1</em>'}, //this would work for plugins like ~~DISCUSSION~~&nbsp;

If your plugin is stable, it is going to be an amazing advancement under the wiki way: the easiness of highlighted syntax but all the power of wiki syntax. Death to WYSIWYG! jl.chulilla 2009/04/05 14:53

Here there is another beta.
I added your regexp plus: “del” tag and notes. — Emanuele 2009/04/05 17:30


bug 1 => status: hack

as u can see, as soon as highlighted syntax is activated, line adjustment disappears. Firefox 3.0.4. on Xandros (no time for make a proper distro works in this amazing eee 901 toy)

I see, I didn't notice it before because on my pc line adjustment is not working even if the plugin is disabled… :-? (seamonkey 2.0b3 on win).
Emanuele 2009/04/04 20:32
I found a "hack". Now ititalic regexp: when an italic “code” is somewhere around and you write the regexp remove one character each time the spacebar is used, anyway the data are not lost! I'll check this bug too and after I'll upload a new “demo-beta” ^^. — Emanuele 2009/04/04 21:27

bug 2 => status: see bug 3

If you change one language to another (i.e. js to doku) all that you wrote before is lost :(

bug 3 => status: testing

After changing from one language to another, some cryptic error message appears:

Don't worry, this is my fault, I was playing with another plugin…I was sort of debugging a javascript for a strange error…
I'm sorry you loose your work… :-(Emanuele 2009/04/05 15:53
Again: no, you are right, it's a bug!! Event without the message (that was my fault), when you change the language you loose the text you write. If you do a preview before change the language everything is kept.
I'm not sure how to handle it, but I'll take a look next week. — Emanuele 2009/04/05 17:30
Maybe if the «turn on highlight» button is clicked on, then the language could not be changed until the file is saved.
Found a possible solution! :-D
Just before change the language I managed to copy the content of the codepress' textarea to dokuwiki's original textarea.
function changeLang(lang){
	if (!(typeof(lang) == 'undefined')) {
		$('wiki__text_cp').value = wiki__text.getCode();

bug 4 => status: open

The toolbar doesn't work when in “highlight-mode”… — Emanuele 2009/04/05 17:30

I should find a way to “intercept” in some way the javascript command from the toolbar and pass it both to the real textarea and to codepress iframe…I don't even know if what I wrote make sense or not…it's time for me to study a little bit of javascript… ^^;; — Emanuele 2009/04/06 22:30

bug 5 => status: close

if you use printable marks like «this» then the rest of the text until EOL is green. See at the capture.

I see…
This should belong to the regexp for xml-like tags:
{ input ; /(&lt;.*?&gt;)(.*?)(&lt;\/.*?&gt;)/g, output : '<em>$1</em><em>$2</em><em>$3</em>' }, // any xml-tagged pluggin, like <box> or <html>

maybe something like:

{ input ; /(&lt;[^&lt;].*?&gt;)(.*?)(&lt;\/.*?&gt;)/g, output : '<em>$1</em><em>$2</em><em>$3</em>' }, // any xml-tagged pluggin, like <box> or <html>

should work…now it seems to behave correctly! — Emanuele 2009/04/06 22:30

very elegant solution, that is the part that I am enjoying more of regexp. — Juan Luis Chulilla 2009/04/08 00:02
Me too, but it's also why I hate them… ^_^

bug 6=> status: duplicate of 4

If you activate highlight code, then you cannot use media selector - click over “image”, media page is launched, you click over an image for building the link and… nothing happens. This happened to me when I try to upload error3.png

In fact is the same as above: the entire toolbar is unusable when the highlight is activated… and this is really bad…

bug 7=> status: open

Manage to have dokuwiki syntax as “default” syntax highlighting. — Emanuele 2009/04/09 21:58

1) I didn't know this feature exist…

Tools personali