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

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

[Drew Adams]

From: Joost Kremers To: help-gnu-emacs@gnu.org
Subject: Re: How to get hours from hh:mm

> >   (let ((timelist (split-string time ":")))
> > When I dan give M-x getMinutes and on the prompt give: 00:18, I get:
> > Symbol's function definition is void: let
>
> most likely because there's a hard space after let.

This makes me wonder if hard-space chars shouldn't act as whitespace as far
as Lisp is concerned, as opposed to having symbol syntax (or whatever - I
didn't check this). I don't have an opinion on the matter, but I think this
is not the first question of this sort I've seen on help-gnu-emacs: users
are surprised when what they see as whitespace does act as they expect
whitespace to ace.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> From: Joost Kremers To: help-gnu-emacs@gnu.org
> Subject: Re: How to get hours from hh:mm
>
>> >   (let ((timelist (split-string time ":")))
>> > When I dan give M-x getMinutes and on the prompt give: 00:18, I get:
>> > Symbol's function definition is void: let
>>
>> most likely because there's a hard space after let.
>
> This makes me wonder if hard-space chars shouldn't act as whitespace as far
> as Lisp is concerned, as opposed to having symbol syntax (or whatever - I
> didn't check this). I don't have an opinion on the matter, but I think this
> is not the first question of this sort I've seen on help-gnu-emacs: users
> are surprised when what they see as whitespace does act as they expect
> whitespace to ace.

Actually, I would not want to have code riddled with unintended
unbreakable spaces (introduced by KNode here, but possible also with
other tools) without Lisp complaining.  There are enough
whitespace-related problems (like trailing space, or tab/space
conversions) already without adding more to it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Drew Adams]

> >> >   (let ((timelist (split-string time ":")))
> >> > When I dan give M-x getMinutes and on the prompt give: 00:18, I get:
> >> > Symbol's function definition is void: let
> >>
> >> most likely because there's a hard space after let.
> >
> > This makes me wonder if hard-space chars shouldn't act as
> whitespace as far
> > as Lisp is concerned, as opposed to having symbol syntax (or
> whatever - I
> > didn't check this). I don't have an opinion on the matter, but
> I think this
> > is not the first question of this sort I've seen on
> help-gnu-emacs: users
> > are surprised when what they see as whitespace does act as they expect
> > whitespace to ace.
>
> Actually, I would not want to have code riddled with unintended
> unbreakable spaces (introduced by KNode here, but possible also with
> other tools) without Lisp complaining.  There are enough
> whitespace-related problems (like trailing space, or tab/space
> conversions) already without adding more to it.

I don't even know if this is a problem with Emacs 22. The OP said something
about intending to upgrade to 22 with the hope of alleviating this problem.

I don't think anyone is suggesting that users should riddle their code with
unbreakable spaces. The question is how Lisp should react when you, say, cut
and paste code that contains them, say from a Web page. When you do that,
you are usually not aware that the spaces are nonbreakable whitespace is,
well, invisible stuff.

Currently, Lisp does not complain in a manner that makes it obvious what the
problem is. The user thinks that Lisp is complaining, say, that `let' is
undefined, when in fact it might be complaining that `let ' is undefined,
where the ` ' is an unbreakable space.

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.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

If we treat nonbreakable spaces as whitespace when people cut&paste
from something like KNode, this means that the mangling of spaces will
go unnoticed.  Since they can occur not only in code itself but also
in strings and character constants, this is an excessively bad idea.

It is better when the code breaks completely rather than when it works
superficially, but delivers different results.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

    If we treat nonbreakable spaces as whitespace when people cut&paste
    from something like KNode, this means that the mangling of spaces will
    go unnoticed.

Users will notice them if they edit with Emacs 22, because they are
highlighted.

		   Since they can occur not only in code itself but also
    in strings and character constants, this is an excessively bad idea.

The error to be eliminated does not occur when they are used in
strings and character constants, and the change has no effect on
such usage.

Would someone please make the change and ack?

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

[Richard Stallman]

[I sent this message a few weeks ago but did not get a response.]

    If we treat nonbreakable spaces as whitespace when people cut&paste
    from something like KNode, this means that the mangling of spaces will
    go unnoticed.

Users will notice them if they edit with Emacs 22, because they are
highlighted.

		   Since they can occur not only in code itself but also
    in strings and character constants, this is an excessively bad idea.

The error to be eliminated does not occur when they are used in
strings and character constants, and the change has no effect on
such usage.

Would someone please make the change and ack?

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

[Stephen Berman]

On Sat, 16 Jun 2007 13:32:49 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:

>> >> >   (let ((timelist (split-string time ":")))
>> >> > When I dan give M-x getMinutes and on the prompt give: 00:18, I get:
>> >> > Symbol's function definition is void: let
[...]
>
> I don't even know if this is a problem with Emacs 22. The OP said something
> about intending to upgrade to 22 with the hope of alleviating this problem.
[...]
> 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.

Steve Berman

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.

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

[Stephen Berman]

On Sat, 16 Jun 2007 15:27:59 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:

> 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).

Whoops.  I did check customize-face and saw that it inherited from
escape-glyph but didn't bother to look that face up.  On my monitor it
does look reddish.  Among the colors shown by list-colors-display,
which comes from X's rgb.txt, the one that looks "brownest" to me is
saddle brown, which is RGB hex 8b4513 (brown is RGB hex a52a2a).  Out
of curiosity, I looked up "brown" in Wikipedia, and there it is
identified with RGB hex 964b00, which on my monitor looks somewhere
between saddle brown and sienna (though Wikipedia's source doesn't
appear to be any kind of standard).

Steve Berman

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

[Richard Stallman]

    This makes me wonder if hard-space chars shouldn't act as whitespace as far
    as Lisp is concerned, as opposed to having symbol syntax 

That seems like a good idea to me.