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: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
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: Sun, 4 Nov 2012 15:34:20 -0800
> > That is, the literal string in my code is read as a string 
> > that contains only a single raw byte of octal 240 in place
> > of the 4 chars \240 (and instead of as a string with the
> > multibyte char no-break space).  Is that right?
> 
> Yes.
> 
> > And putting that together with Eli's statement about 
> > insertion ("'insert' treats strings such as "\nnn" as
> > unibyte strings"), I understand that the buffer text
> > after I type `C-q 240' contains a unibyte raw byte, and
> > not the multibyte char no-break space.
> 
> No.  It contains the NBSP.  Try it.

Well, I was saying since the beginning tha that appeared to be the case.  But
you replied that insertion inserted a raw \240 byte.  That red herring threw me
off.

> C-q inserts a multibyte character, unlike '(insert "\240")', for example.

Thanks, I finally got that from what Stefan said.  It would have been clearer if
you had said that from the beginning, since I mentioned `C-q' and you replied
instead about "insert".  Anyway, I understand now.

> Try '(insert "\240")' and then "C-x =" will show a unibyte byte.

Yes, I got it (from Stefan's reply).  But no one mentioned using `insert' or
insertion, except you.  I know you were trying to help, but that just confused
things, for me.

> > I can see how that can be useful.  But I can also see how 
> > it would be useful to have some way of using octal syntax to
> > match multibyte chars.  Isn't there some reasonable way to
> > allow for both?
> 
> Maybe, but we didn't find one, at least not one that would be
> backward-compatible.

OK, that was my question.  Thx.

> > (decode-coding-string "\302\240" 'utf-8)
> > 
> > That allows use of only octal syntax - good.  But it still 
> > doesn't solve the problem for older Emacs versions - they
> > raise the error (coding-system-error utf-8).
> 
> You don't want this, because even if you succeed in producing a NBSP
> in Emacs 22 and older, the result will not match NBSP in other
> charsets.  It's simply impossible with those versions of Emacs.

Got it.  That is the bottom line - the answer to my question.

Thx to all who took the time to help me understand better.





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.