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: Drew Adams
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?






reply via email to

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