Description:
When editing a wiki page, single words can usually be selected by double-clicking. In most browsers, this will also select the subsequent whitepsace after the word that has been double-clicked. Now hitting a GUI button to format the selected text will insert the closing wiki tag at the end of the selection (which is after the trailing space), instead of just encapsulating the selected word. This seems a bit unusual, it's more difficult to read the wiki page source, and the resulting XHTML also seems a bit "untidy" (at least HTML Tidy would correct this...).

Example from PmWiki when formatting a double-clicked word using the GUI buttons:

This ''word ''has been formatted by double-clicking.

Expected behaviour:

This ''word'' has been formatted by double-clicking.

Update: in the first example, it's also difficult to select the next word (has) by double-clicking, as this will also select the leading '' tag.

There's those weak moments when I'm using Internet Explorer, still... (if only Firefox would start up as fast as IE). I'm sorry I didn't notice the behaviour in Firefox is different. On Windows however, it's usual that trailing spaces are also selected when double-clicking words, so I thought it would make sense to consider this for the GUI buttons.

In Firefox it's also that the trailing spaces are selected when double-clicking words also; but the GUI button doesn't enclose the trailing spaces when it puts the markup around the selected text. So it has to be something in the Javascript that is different for IE than for Firefox.

In particular, the Javascript code explicitly removes the trailing spaces from the highlighted text when it does

while (p1 > p0 && tarea.value.substring(p1-1, p1) == ' ') p1--;

so I'm left to conclude that the substring function isn't working here, or else there's something else bizarre taking place.