From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Display question Date: Wed, 08 Jun 2011 10:51:32 +0300 Message-ID: <8339jkdam3.fsf@gnu.org> References: <87hb80hno5.fsf@maru.md5i.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1307519520 3299 80.91.229.12 (8 Jun 2011 07:52:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Jun 2011 07:52:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 08 09:51:54 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QUDYQ-0000ZK-0H for ged-emacs-devel@m.gmane.org; Wed, 08 Jun 2011 09:51:54 +0200 Original-Received: from localhost ([::1]:38856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUDYO-0002mq-T6 for ged-emacs-devel@m.gmane.org; Wed, 08 Jun 2011 03:51:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUDY5-0002mP-Jf for emacs-devel@gnu.org; Wed, 08 Jun 2011 03:51:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUDY4-0001bY-IN for emacs-devel@gnu.org; Wed, 08 Jun 2011 03:51:33 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:34907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUDY4-0001bF-BH for emacs-devel@gnu.org; Wed, 08 Jun 2011 03:51:32 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LMG00L00O5S3T00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Wed, 08 Jun 2011 10:51:30 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.223.140]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LMG00KLYOHTLRA0@a-mtaout21.012.net.il>; Wed, 08 Jun 2011 10:51:30 +0300 (IDT) In-reply-to: <87hb80hno5.fsf@maru.md5i.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140292 Archived-At: > From: Michael Welsh Duggan > Date: Wed, 08 Jun 2011 01:55:54 -0400 > > Afterward, I get a character that looks like a double-boxed RLO. Image > included: > > Is this expected? If I just do (insert RLO RLO RLO) a few times in a > non-font-locked buffer, I get a box around RLO, with a tiny space > between the boxes, and not the double box seen here. The difference between these two use cases is that characters delivered from display tables are not subject to the treatment we give to "glyphless characters", which is what u+200b ZERO WIDTH SPACE is. You expect this character to be displayed as a thin space (probably to get the boxed "RLO" look prettier), but this thin space will only show when u+200b is treated as a glyphless character, which can happen when it comes from the buffer, but not from a display table. The problem here is that display tables and glyphless character display are 2 similar, but different features, and we didn't yet figure out how to mix them, or whether to fuse them into a single feature. So now they "fight" each other, and the display table wins in this case. We could perhaps find some ad-hoc solution for this particular case, but I really think we should solve the general issue -- how to combine display tables and glyphless character display together -- before we discuss the solutions. Btw, you cannot expect that u+200b is displayed as a thin space, because the user could change that via glyphless-char-display-control, which see. So this particular use of u+200b is questionable to begin with, IMO.