all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* should non-breaking space chars act as whitespace for Lisp?
@ 2007-06-16 19:45 Drew Adams
  2007-06-16 19:51 ` David Kastrup
  2007-06-17  8:54 ` Richard Stallman
  0 siblings, 2 replies; 10+ messages in thread
From: Drew Adams @ 2007-06-16 19:45 UTC (permalink / raw)
  To: Emacs-Devel

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 19:45 should non-breaking space chars act as whitespace for Lisp? Drew Adams
@ 2007-06-16 19:51 ` David Kastrup
  2007-06-16 20:32   ` Drew Adams
  2007-06-17  8:54 ` Richard Stallman
  1 sibling, 1 reply; 10+ messages in thread
From: David Kastrup @ 2007-06-16 19:51 UTC (permalink / raw)
  To: Drew Adams; +Cc: Emacs-Devel

"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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 19:51 ` David Kastrup
@ 2007-06-16 20:32   ` Drew Adams
  2007-06-16 20:42     ` David Kastrup
  2007-06-16 21:29     ` Stephen Berman
  0 siblings, 2 replies; 10+ messages in thread
From: Drew Adams @ 2007-06-16 20:32 UTC (permalink / raw)
  To: Emacs-Devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 20:32   ` Drew Adams
@ 2007-06-16 20:42     ` David Kastrup
  2007-06-17  8:54       ` Richard Stallman
  2007-07-23 18:06       ` Richard Stallman
  2007-06-16 21:29     ` Stephen Berman
  1 sibling, 2 replies; 10+ messages in thread
From: David Kastrup @ 2007-06-16 20:42 UTC (permalink / raw)
  To: Drew Adams; +Cc: Emacs-Devel

"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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 20:32   ` Drew Adams
  2007-06-16 20:42     ` David Kastrup
@ 2007-06-16 21:29     ` Stephen Berman
  2007-06-16 22:27       ` Drew Adams
  1 sibling, 1 reply; 10+ messages in thread
From: Stephen Berman @ 2007-06-16 21:29 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 21:29     ` Stephen Berman
@ 2007-06-16 22:27       ` Drew Adams
  2007-06-16 23:39         ` Stephen Berman
  0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2007-06-16 22:27 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 22:27       ` Drew Adams
@ 2007-06-16 23:39         ` Stephen Berman
  0 siblings, 0 replies; 10+ messages in thread
From: Stephen Berman @ 2007-06-16 23:39 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 19:45 should non-breaking space chars act as whitespace for Lisp? Drew Adams
  2007-06-16 19:51 ` David Kastrup
@ 2007-06-17  8:54 ` Richard Stallman
  1 sibling, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2007-06-17  8:54 UTC (permalink / raw)
  To: Drew Adams; +Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 20:42     ` David Kastrup
@ 2007-06-17  8:54       ` Richard Stallman
  2007-07-23 18:06       ` Richard Stallman
  1 sibling, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2007-06-17  8:54 UTC (permalink / raw)
  To: David Kastrup; +Cc: drew.adams, emacs-devel

    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?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: should non-breaking space chars act as whitespace for Lisp?
  2007-06-16 20:42     ` David Kastrup
  2007-06-17  8:54       ` Richard Stallman
@ 2007-07-23 18:06       ` Richard Stallman
  1 sibling, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2007-07-23 18:06 UTC (permalink / raw)
  To: David Kastrup; +Cc: drew.adams, emacs-devel

[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?

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2007-07-23 18:06 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-16 19:45 should non-breaking space chars act as whitespace for Lisp? Drew Adams
2007-06-16 19:51 ` David Kastrup
2007-06-16 20:32   ` Drew Adams
2007-06-16 20:42     ` David Kastrup
2007-06-17  8:54       ` Richard Stallman
2007-07-23 18:06       ` Richard Stallman
2007-06-16 21:29     ` Stephen Berman
2007-06-16 22:27       ` Drew Adams
2007-06-16 23:39         ` Stephen Berman
2007-06-17  8:54 ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.