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 18:56:49 +0200
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 3 Nov 2012 09:25:35 -0700
> Cc: 12054 <at> debbugs.gnu.org
> 
> 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.

> Why should a character-alternative expression care whether the
> representation is unibyte or multibyte?  Isn't that a bug?

It's an unfortunate dark corner, due to the ambiguity of what \240
really means in a string.

> How to use octal syntax to match that char?

Why do you need the octal syntax?  Why not just use a literal  ?  Is
that only for the sake of old Emacs versions, or for some other
reason?

> 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 see no contradiction or incorrect information in this cited text.
The octal notation does work in your example, it's just that its
semantics is not what you expected.  Or am I missing something?





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.