Thank you!

I don't think we need any special glyphs. They create their own set of challenges.


Current Behavior:

Let's say you're typing a new paragraph. When you're in the middle of a line (or
at least not at the end of the line) you type a word then a space--the space is
visible and the cursor is between the space and the pilcrow. <- (good)

You keep typing so that the last letter typed is at the end of the line (or
perhaps I should say still "within the zone where text goes" and just barely
touching the margin). If you type another letter the word will snap down to the
next line. <- (good) But if you type a space the word stays and the new word
will start down on the next line. <- (also good) However, what the typist sees
in the current rev is that when you type that space it's invisible and the
cursor remains planted at the end of the word, apparently waiting until you type
the first letter of the next word before it snaps down to the next line. <-
(troublesome, counter intuitive behavior) If you continue to type spaces the
cursor stays stuck at the end of the line (and word), the spaces invisible, and
the cursor doesn't snap down to the new line until the typist types the first
letter of the new word. <- (troublesome, no clue as to how many spaces exist)

For a multi-line existing paragraph, none of the spaces at the ends of the lines
(where the word-wrap happens) are visible. <- (troublesome, no clue as to how
many spaces exist)


Proposed Changes in Behavior:

Let's say you're typing a new paragraph. The first part, where you're not yet at
the edge of the text area, remains with the same behavior. Word, space, and
pilcrow, with the cursor between the space and the pilcrow. <- (no change)

You keep typing so that the last letter typed is at the end of the line. If you
type another letter the word will snap down to the next line. <- (no change) But
if you type a space the word stays and the cursor snaps down to the next line,
waiting for the typist to start the next word. <- (new behavior) The space
character should be visible at the end of the previous line even when that means
it's outside the text zone and in the margin. <- (new behavior)

Now if the typist types the first letter of a new word, no problem. The letter
appears in the first position of the new line and the cursor moves over so it's
between the letter and the pilcrow. <- (the change is that the cursor was at the
beginning of the line before typist started the new word)

However, if the typist types a second space, the cursor remains planted at the
beginning of the new line. <- (new behavior) And a second space appears on the
previous line so that both are visible at the end of the previous line. <- (new
behavior) If the typist types dozens more spaces, they will all appear at the
end of the previous line, filling up the margin. <- (new behavior)

However, if you have a bunch of spaces it should not be necessary to show all of
them. With "View/Print Layout" enabled you could show the spaces going to the
edge of the page (and those in the gray become invisible). With "View/Web
Layout" enabled there's a bit more of a problem because the margin outside the
text box is very narrow, so normally only one space may be visible (depending on
font size, etc.). The simplest for "Web Layout" may be to just go with it, if
only one or two spaces are visible, then only one or two are visible. For
"View/Web Layout" if there is some element that controls the width of the text
area then it maybe possible to show dozens of extra spaces, if they exist.

For a multi-line existing paragraph, make the spaces at the ends of the lines
visible. <- (new behavior)


Editing Existing Text:

When there is one space at the end of the line: The back-arrow will take the
cursor to the beginning of the line (before the first letter of the first word
on the line), then another back-arrow will jump up to the end of the previous
line and skip over that last space so the cursor is at the end of the last word
on the line.

When there are multiple spaces at the end of the line: The back-arrow will take
the cursor to the beginning of the line (before the first letter of the first
word on that line), then another back-arrow will jump up to the end of the
previous line so the cursor is before the last space on that line... that is,
with two spaces it will be between the spaces. In some cases this means the
cursor will be in the margin. If the view doesn't let the typist see the spaces
around the cursor then the cursor should be up against the edge of the view-pane
so that it's visible.

It this case where the cursor is between space characters which are in the
margin, it should be possible to insert a character. If the character is a
space, the space is inserted into the margin area. If the character is a letter
or punctuation (any non-space character) then the cursor and the new character
will snap down to the beginning of the next line with the character at the start
of the line followed by the spaces, and with the cursor between the new
character and those spaces.


Selecting Text:

Currently when you select a block of text, the select zone (shown as reverse
video) is from margin to margin--irregardless of the justification used, and
instead of following the boundaries of the actual text selected. I suggest this
be changed to follow the actual selected text to prevent user confusion,
especially with the "dangling" spaces visible--which could very well be outside
the text zone and in the margins. For example when selecting a paragraph, we
want to select the whole paragraph including the spaces at the ends of the lines
(even with multiple spaces there). Going to ragged edges on the select zone is
more intuitive.


Close:

If you'd like, I could dummy up some screen shots, and maybe even create a
little web page if I feel I need more than a few illustrations.