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

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 12054 <at> debbugs.gnu.org
Subject: bug#12054: 24.1; regression? font-lock no-break-space with nil nobreak-char-display
Date: Sat, 3 Nov 2012 10:32:36 -0700

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

Hm.  I admit that I do not have a grasp of this yet.  I will read the updated
doc when I get hold of it.  You didn't answer the question "How to use..."  I
guess that silence indicates that it is impossible (?).

Anyway, trying to put together your statement that the old text was incorrect
with Eli's claim that it is still correct has me perplexed.

So just what is the "most general read syntax for a char" now?

And what is a general read syntax that will work also for older Emacs versions
when reading Unicode chars present in a file?

Previous Next

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