From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.bugs,gmane.emacs.devel Subject: Re: Problem with glyphs with face-id over 128 in unicode-2 emacs Date: Wed, 27 Feb 2008 23:58:20 +0100 Message-ID: <87d4qif1mb.fsf@kfs-lx.rd.rdm> References: <87tzjytzww.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204153941 10459 80.91.229.12 (27 Feb 2008 23:12:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Feb 2008 23:12:21 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, emacs-devel@gnu.org To: Eduardo Ochs Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 28 00:12:46 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JUVRw-0002qe-V0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Feb 2008 00:12:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUVRQ-0005Wk-H2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Feb 2008 18:12:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JUVRM-0005WC-9o for bug-gnu-emacs@gnu.org; Wed, 27 Feb 2008 18:11:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JUVRL-0005Vj-Gd for bug-gnu-emacs@gnu.org; Wed, 27 Feb 2008 18:11:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUVRL-0005Ve-Dr for bug-gnu-emacs@gnu.org; Wed, 27 Feb 2008 18:11:55 -0500 Original-Received: from mail-relay.sonofon.dk ([212.88.64.25]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JUVEF-0002iN-52 for bug-gnu-emacs@gnu.org; Wed, 27 Feb 2008 17:58:23 -0500 Original-Received: (qmail 4739 invoked from network); 27 Feb 2008 22:58:21 -0000 Original-Received: from unknown (HELO kfs-lx.rd.rdm.cua.dk) (213.83.150.21) by 0 with SMTP; 27 Feb 2008 22:58:21 -0000 In-Reply-To: <87tzjytzww.fsf@gmail.com> (Eduardo Ochs's message of "Sun\, 24 Feb 2008 07\:24\:47 -0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:17607 gmane.emacs.devel:90665 Archived-At: As promised a long time ago, I have installed changes (and cleaned up related code) to fix the problem with encoding face ids in integer glyph codes. Eduardo Ochs writes: > Suppose that we have more than 128 faces defined, and that we want to > make, say, all "\^O"s be displayed as "*"s with the face > `face-with-id-138'; we would try to do this: > > (aset standard-display-table ?\^O > (vector (make-glyph-code ?* 'face-with-id-138))) > > where, of course, face-with-id-138 is a face for which: > > (face-id 'face-with-id-138) > ==> 138. > > Then we will notice that the "\^O"s get displayed using the face with > face-id=10 instead (by the way: here (face-id 'highlight) is 10)... > > Here's what is happening: `make-glyph-code' has this definition (in > "disp-table.el" in emacs-unicode-2, i.e., in CVS Emacs after the merge > or the unicode-2 branch): > > (defun make-glyph-code (char &optional face) > "Return a glyph code representing char CHAR with face FACE." > ;; Due to limitations on Emacs integer values, faces with > ;; face id greater that 512 are silently ignored. > (if (and face (<= (face-id face) #x1ff)) > (logior char (lsh (face-id face) 22)) > char)) > > That magic number, 22, used to be 19 in pre-unicode-2 Emacs. > > The problem is that (lsh 128 22) is 0, and so (lsh 138 22) drops the > bit corresponding to the 128 in the shift, and its result is the same > as of (lsh 10 22). -- Kim F. Storm http://www.cua.dk