Bug report: Keep multiple spaces not quite right

Here are some problems I found with some further testing of the great
new feature.  This is on the latest CVS code (9.52 Oct 19) on Debian 3.1
Stable and with the Windows binary just released (9.52 Oct 18) - however
where I mention pasting, this is only on Windows since I can't paste
from the system clipboard in Debian.


Spaces at start of line
-----------------------

A single space inserted manually at the start of a line should be a
non-breaking space (represented by a blue ~ tilde in the source view)
but it is in fact a plain space:

<p>0 spaces</p>
<p> 1 space</p>    <<< bad
<p>~ 2 spaces</p>
<p>~~ 3 spaces</p>

Browsers (Mozilla 1.7.13, Firefox 2.0, MSIE 6.0) ignore this, as they
probably should, because the space is seen as a second whitespace
character after the newline.  (I can't remember enough about XHTML and
HTML at this point, so perhaps they should recognise the <p> - but they
actually don't.)



Pasting anomalies
-----------------

When I copy the following text from a Windows text editor into the main
editing window of Amaya, I get no leading spaces visible and none in
source view either:

0 spaces
 1 space
  2 spaces
   3 spaces

becomes:

0 spaces
1 space
2 spaces
3 spaces


However pasting this:

x0 spaces
x 1 space
x  2 spaces
x   3 spaces

produces the correct results in main view and in source view:

<p>x0 spaces</p>
<p>x 1 space</p>
<p>x~ 2 spaces</p>
<p>x~~ 3 spaces</p>


Editing in a run of spaces
--------------------------

If there is a sequence of n spaces (from the user's point of view) then
in the source there is n-1 non-breaking spaces followed by a space.
Placing the cursor at the right most point (just after the last space)
and pressing or pasting spaces has good results (a larger number of
contiguous non-breaking spaces followed by a final space).  Likewise if
the cursor is between the final space and the last non-breaking space.

However if the cursor is further to the left, that is if there is a
non-breaking space to the right of the cursor, then pressing or
inserting one or more spaces creates a break in the run of non-breaking
spaces, with one ordinary space in the middle of it.

This may be render correctly (but I can't be sure), and perhaps this is
intentional to allow a plain space to be replaced by a newline in the
event that there is a long run of non-breaking spaces.

However, I think it would be more consistent if all runs of spaces, from
the point of view of the user, were converted into:

xxxxx~~~~~~~~~ yyyyyy

rather than something more complex like:


xxxxx~~~~ ~~~~ yyyyyy

For instance, by typing "xxxyyy", placing the cursor between the last x
and the first y, pasting two spaces and then moving the cursor again to
the right of the last x, then it is possible to produce source like this:

xxx~ ~ ~ ~ yyy


Ends of lines
-------------

I think that the ends of a line have the same problem as the start.  A
single space after the last printing character and the end of the line
results in:

<p>One space after </p>

when it really should be a single non-breaking space:

<p>One space after </p>



 - Robin

Received on Thursday, 19 October 2006 01:36:07 UTC