Re: Invisible line break

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "cmadsen"  on Mon, 3 Mar
2003 11:18:07 -0500

Chris:

> let's say the character "^"
> is non-printing... Patricia would add ^ to the
> word line in the separator table. Then, when she wanted to be able to break
> around an en dash, she would type:
>     1970^[en dash]^1976
> This [c]ould yield...:
>     1970[en dash]
>     1976

On reflection, after drinking coffee instead of beer, I just don't think it
will work, because (IMHO -- but I'd be delighted to be proven wrong) this isn't
the purpose of the separator table. As I understand it, the first line of the
separator table defines what constitutes a "word". Let me use a simpler
example. Suppose you wrote "appli^cation", continuing to pretend that
circumflex is a non-printing separator. If you issued several NextWord
functions [NW], the cursor would stop on "appli" and then on "cation", because
the circumflex represents end of word|beginning of new word. Similarly, if you
spell checked it, the speller would consider "appli" and "cation" to be
separate words. So far so good. BUT! But but but! That line will not break
(perform a wrap) between "appli" and "cation"! No way. Breaks or wraps _only_
occur on space characters. I have _never_ seen a wrap occur anywhere else,
except of course when using a discretionary hyphen with VAriable HY=1. Take
another example. Add the underscore "_" to the separator table, then write
several lines like this:

Breaks_or_wraps_only__occur_on_space_characters._I_have_never_seen_a_wrap_occur_anywhere_else,_except_of_course_with_a_discretionary_hyphen.

A long line like that, containing no space character, just wraps arbitrarily
when it reaches the maximum line length limit. If the limit is 80 chars
monospaced, it wraps thusly:

Breaks_or_wraps_only__occur_on_space_characters._I_have_never_see
n_a_wrap_occur_anywhere_else,_except_of_course_with_a_discretiona
ry_hyphen.

In other words, it is not wrapping on the underscore character -- and it never
will. IMO. Unless I'm missing something very fundamental...

All of this of course ignores the valid objection raised by Paul, that SE
rejects any table including a character outside range 0-255 (en and em dash
being [259] and [260]).

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------