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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@gnu.org>, <12054@debbugs.gnu.org>
> Date: Sat, 3 Nov 2012 10:22:59 -0700
> 
> > > Just why is it that the regexp "[\240]+" does not match this char?
> > 
> > Because, for histerical reasons, 'insert' treats strings such as
> > "\nnn" as unibyte strings.
> 
> Sorry, I don't understand your point.  My question was about the regexp (not)
> matching, not about (not) being able to insert the char.

It doesn't matter.  "\nnn" in a string is still interpreted as unibyte.

> I don't see a problem with inserting the char.  As I said, the correct char 
> gets
> inserted AFAICT, as shown both by `C-u C-x =' and by Yidong's correction of 
> the
> font-lock regexp.

Insertion with C-q does something different.

> > It's an unfortunate dark corner, due to the ambiguity of what \240
> > really means in a string.
> 
> That just makes it darker for me.  Can you please elaborate?

\240 could be taken as NBPS or as a literal byte.  They have different
representations in Emacs and are treated differently, but are
identical numerically outside of Emacs.

> 3. Why not?  Why turn it around and speak of "need" to use it?
> The real question is why _not_ be able to use octal syntax here?

For the same reason you'd use ?a and not \141: it's more clear to the
human reader.

Using octal escapes for non-ASCII characters in Emacs is deprecated
and dangerous.  You just bumped into one danger; there are more.  I
suggest you avoid this notation as much as you can.