GNU bug report logs - #12054
24.1; regression? font-lock no-break-space with nil nobreak-char-display

Previous Next

Full log

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 12054 <at> debbugs.gnu.org
Subject: Re: bug#12054: 24.1;
	regression? font-lock no-break-space with nil nobreak-char-display
Date: Sun, 04 Nov 2012 01:06:28 +0800

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

> Just why is it that the regexp "[\240]+" does not match this char?
> Why should a character-alternative expression care whether the
> representation is unibyte or multibyte?  Isn't that a bug?

When \240 occurs in a unibyte string, Emacs recognizes it as an
eight-bit raw byte.  When converting unibyte strings to multibyte, Emacs
does not "unify" eight-bit raw bytes with Unicode characters #x80-#xff;
they get their own code points, in this case #x3fffa0.  (One reason for
doing this is to allow unibyte strings to be specified using string
constants in Emacs Lisp source code.)

> How to use octal syntax to match that char?  The Elisp manual says
> clearly that "The most general read syntax for a character represents
> the character code in either octal or hex."  MOST GENERAL, not most
> limited and partial.

I've already edited the documentation to take out this sentence.  It is
incorrect anyway, for the reason that octal escapes are limited to three
digits.

Previous Next

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