bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12054: 24.1; regression? font-lock no-break-space with nil nobreak-c


From: Chong Yidong
Subject: bug#12054: 24.1; regression? font-lock no-break-space with nil nobreak-char-display
Date: Sun, 04 Nov 2012 01:06:28 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"Drew Adams" <drew.adams@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]