GNU bug report logs - #12048
24.1; handling of non-breaking of hyphen with `escape-glyph'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12048 in the body.
You can then email your comments to 12048 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.1; handling of non-breaking of hyphen with `escape-glyph'
Date: Wed, 25 Jul 2012 16:20:20 -0700

This is misguided, IMO:
 
,----
| nobreak-char-display is a variable defined in `C source code'.
| Its value is t
| 
| Documentation:
| Control highlighting of non-ASCII space and hyphen chars.
| If the value is t, Emacs highlights non-ASCII chars which have the
| same appearance as an ASCII space or hyphen, using the `nobreak-space'
| or `escape-glyph' face respectively.
     ^^^^^^^^^^^^^^^^^^^
| 
| U+00A0 (no-break space), U+00AD (soft hyphen), U+2010 (hyphen), and
| U+2011 (non-breaking hyphen) are affected.
| 
| Any other non-nil value means to display these characters
| as a escape glyph followed by an ordinary space or hyphen.
  ^^^^^^^^^^^^^^^^^
| 
| A value of nil means no special handling of these characters.
| 
| For more information check the manuals.
| 
`----
 
What is misguided?  Reusing face `escape-glyph' for highlighting
non-breaking hyphen.  Define a new face for this, just as you did with
face `nobreak-space'.
 
This has NOTHING to do with the stated purpose of face `escape-glyph'.
It conflicts with the doc of that face.  And no, this is not a doc
problem; it is a design (behavior) problem.
 
It is short-sighted to reuse existing faces this way willy nilly.  Just
define a new face, specific to THIS purpose.  If you want to have its
default properties inherit from `escape-glyph', go right ahead (even
though that is not a very good idea).  But do not simply reUSE face
`escape-glyph' for non-breaking hyphens.
 
Here is the doc for face `escape-glyph':
 
 "Face for characters displayed as sequences using `^' or `\'."
 
It actually took me a while to find out what was going on.  Did Emacs
somehow consider that a non-breaking hyphen is displayed using `^' or
`\'?  What did it mean?
 
This face's doc string also means that the last part of the
`nobreak-char-display' behavior is also misguided:
 
  Any other non-nil value means to display these characters as a escape
  glyph followed by an ordinary space or hyphen.
 
No.  Do not display them "as an escape glyph" followed....
 
And what does that phrase even mean?  Where is display "as an escape
glyph" documented?  The concept of "an escape glyph" is not documented
anywhere in Emacs manuals, that I can find.  There is only the _face_
`escape-glyph'.  Does "display as an escape glyph" mean use that face?
 
If so, that behavior is misguided - see above.
 
Well... so you plugged this paragraph into the Emacs manual:
 
   Some non-ASCII characters have the same appearance as an ASCII space
 or hyphen (minus) character.  Such characters can cause problems if
 they are entered into a buffer without your realization, e.g. by
 yanking; for instance, source code compilers typically do not treat
 non-ASCII spaces as whitespace characters.  To deal with this problem,
 Emacs displays such characters specially: it displays `U+00A0'
 (no-break space) with the `nobreak-space' face, and it displays
 `U+00AD' (soft hyphen), `U+2010' (hyphen), and `U+2011' (non-breaking
 hyphen) with the `escape-glyph' face.  To disable this, change the
 variable `nobreak-char-display' to `nil'.  If you give this variable a
 non-`nil' and non-`t' value, Emacs instead displays such characters as
 a highlighted backslash followed by a space or hyphen.
 
But here (last line) it does not mention display "as an escape glyph".
It says that a "highlighted backslash" is followed...  Highlighted how -
what face?
 
That paragraph added to the manual just describes the ugly hack that
this bug report is about.  This hack has nothing whatsoever to do with
escape sequences (octal or carat).  It is a kludge.
 
Fortunately, it is easily reparable: define and use a new face, and fix
the doc accordingly.  IOW, do for hyphens just what you did for spaces.
There is no reason to be lazy here - in the long run it just produces
more work and confusion for everyone, Emacs developers included.
 
 
 
In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

Message #10 received at 12048 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 12048 <at> debbugs.gnu.org
Subject: Re: bug#12048: 24.1;
 handling of non-breaking of hyphen with `escape-glyph'
Date: Thu, 28 Apr 2016 18:09:38 +0200

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

> What is misguided?  Reusing face `escape-glyph' for highlighting
> non-breaking hyphen.  Define a new face for this, just as you did with
> face `nobreak-space'.

Now fixed on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.