unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-devel@gnu.org>
Subject: RE: should non-breaking space chars act as whitespace for Lisp?
Date: Sat, 16 Jun 2007 15:27:59 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMIEJODCAA.drew.adams@oracle.com> (raw)
In-Reply-To: <87lkejegfp.fsf@escher.local.home>

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

  reply	other threads:[~2007-06-16 22:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2007-06-16 23:39         ` Stephen Berman
2007-06-17  8:54 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMIEJODCAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).