RE: should non-breaking space chars act as whitespace for Lisp?

[Drew Adams]

> > We should be able to find some way to make things clear to a 
> > user that s?he needs to convert nonbreakable spaces to spaces,
> > or else we should treat nonbreakable spaces as whitespace for
> > Lisp code. I don't have a strong opinion about the solution,
> > but I think a problem has been pointed out to
> > which we should find a good solution.
> 
> Emacs 22 has nobreak-char-display, which by default makes the
> non-breaking space be displayed as a space with red underlining.
> That's a pretty clear sign that there's something there other than a
> normal space.

Perfect. Sounds like there is no problem in Emacs 22 then. Thanks.

I'd even suggest something more glaringly obvious than a brown underline, by 
default (it is defined as "brown", BTW, not red). 

This is especially important for newbies who might not be looking out for it. 
An underlined space is sometimes obscured by a face property underline (e.g. 
for a link), and even when it is not it is sometimes difficult to notice - 
especially an underlined space. Also, an underlined space is often 
indistinguishable from an underscore - in this case perhaps making users wonder 
why an underscore is present and why it appears brown, but not necessarily 
giving them a clue to the real problem. In some contexts they will perhaps 
think that an "underscore" is not appropriate and replace it with a normal 
space, but in, say, a complex pattern of regexp fragments or code that they 
otherwise do not understand, it might go undetected or unchallenged.

Since the characters in question are non-breaking hyphen and space, I think a 
full-size character background highlight would be more appropriate than a brown 
underline (currently the default for nbspace) and a brown foreground (currently 
the default for nbdash). Just coloring a hyphen brown does not really make it 
stand out, even for those who are not color-challenged.

I also suggest that we use a different default face for nbdash, instead of 
`escape-glyph'. It's a classic face problem: a user might well customize 
`escape-glyph' for its general escape-glyph use, and that might not also be 
appropriate for nbdash. The description of the purpose of `escape-glyph' is 
this:

 "Face for characters displayed as sequences using `^' or `\'."

I see no relation between that and a non-breaking hyphen. I see no reason for 
this inheritance as the way to define the face for non-breaking hyphen. 

If nbspace merits a face, so does nbdash. Or, if we do as I suggest and use a 
bright background as the default value, then we could perhaps use a single face 
for both - e.g. a face called `nonbreaking-character' or some such.