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

Previous Next

Package: emacs;

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

Date: Thu, 26 Jul 2012 05:51:02 UTC

Severity: normal

Found in version 24.1

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: cyd <at> gnu.org, 12054 <at> debbugs.gnu.org
Subject: bug#12054: 24.1; regression? font-lock no-break-space with nil nobreak-char-display
Date: Sat, 03 Nov 2012 22:57:36 +0200
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <cyd <at> gnu.org>, <12054 <at> 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.




This bug report was last modified 12 years and 202 days ago.

Previous Next


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