From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12054: 24.1; regression? font-lock no-break-space with nil nobreak-char-display Date: Sat, 3 Nov 2012 10:22:59 -0700 Message-ID: <124464DE2A8F4248A1F0C156E00E815D@us.oracle.com> References: <87mwyzyn76.fsf@gnu.org> <45DEAA69BC6E4630BA8DA0B07A0ECE92@us.oracle.com> <83vcdm4oby.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1351963451 31209 80.91.229.3 (3 Nov 2012 17:24:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Nov 2012 17:24:11 +0000 (UTC) Cc: cyd@gnu.org, 12054@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 03 18:24:20 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TUhSG-000141-4p for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Nov 2012 18:24:20 +0100 Original-Received: from localhost ([::1]:40713 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUhS7-0000qx-GT for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Nov 2012 13:24:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUhS4-0000qg-5Q for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2012 13:24:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUhS3-0005Se-7K for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2012 13:24:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUhS3-0005Sa-3x for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2012 13:24:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TUhUr-0004QM-Tv for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2012 13:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Nov 2012 17:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12054 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12054-submit@debbugs.gnu.org id=B12054.135196356916943 (code B ref 12054); Sat, 03 Nov 2012 17:27:01 +0000 Original-Received: (at 12054) by debbugs.gnu.org; 3 Nov 2012 17:26:09 +0000 Original-Received: from localhost ([127.0.0.1]:47387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TUhU0-0004PE-KZ for submit@debbugs.gnu.org; Sat, 03 Nov 2012 13:26:08 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:45541) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TUhTy-0004P5-6f for 12054@debbugs.gnu.org; Sat, 03 Nov 2012 13:26:06 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA3HN9Uc003797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Nov 2012 17:23:10 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA3HN8HP009702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Nov 2012 17:23:09 GMT Original-Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA3HN82S015114; Sat, 3 Nov 2012 12:23:08 -0500 Original-Received: from dradamslap1 (/10.159.185.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Nov 2012 10:23:08 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83vcdm4oby.fsf@gnu.org> Thread-Index: Ac255FfHQUhqjMhrTn23YTWi+0J+EQAAS6tA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:66394 Archived-At: > > Just why is it that the regexp "[\240]+" does not match this char? >=20 > 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. 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 =3D' and by Yidong's = correction of the font-lock regexp. You can insert the _same_ char using either `C-q 240' or `C-x 8 RET = no-break space', at least AFAICT (via Yidong's highlighting and via `C-u C-x = =3D'). > > Why should a character-alternative expression care whether the > > representation is unibyte or multibyte? Isn't that a bug? >=20 > 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? > > How to use octal syntax to match that char? >=20 > Why do you need the octal syntax? Why not just use a literal =A0? Is > that only for the sake of old Emacs versions, or for some other > reason? 1. Yes, for the sake of older Emacs versions. 2. The manual says that octal syntax is the most general syntax. So one would expect that one can use it more, not less. ;-) 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? > > The Elisp manual says clearly that > > "The most general read syntax for a character represents=20 > > the character code in either octal or hex." > > > > MOST GENERAL, not most limited and partial. >=20 > 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? Dunno whether you are missing something. I am missing how the octal = notation "works" in my example. It certainly does not highlight the char I want = to highlight, i.e., does not do what I intended. How to do that? I'm missing how to use octal notation in such a font-lock-add-keywords = sexp to match that char. IOW, my incorrect use of it doesn't do the job. = Please show me how to use octal notation to get that char highlighted.