From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: prettify-symbols-mode, derived modes, and compose-region Date: Fri, 05 Mar 2021 09:08:35 +0200 Message-ID: <83eeguyt58.fsf@gnu.org> References: <83k0qmzit9.fsf@gnu.org> <587ee071-985b-450a-2df7-0b4bb0f97b48@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12901"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: D Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 05 08:09:31 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lI4aX-0003FD-Qy for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 08:09:29 +0100 Original-Received: from localhost ([::1]:54170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lI4aW-0007Ae-Si for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 02:09:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lI4Zz-0006jX-KI for emacs-devel@gnu.org; Fri, 05 Mar 2021 02:08:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52875) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lI4Zw-0005mS-V5; Fri, 05 Mar 2021 02:08:54 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3108 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lI4Zw-0007Aa-Cs; Fri, 05 Mar 2021 02:08:52 -0500 In-Reply-To: <587ee071-985b-450a-2df7-0b4bb0f97b48@posteo.net> (message from D on Fri, 5 Mar 2021 01:22:30 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266011 Archived-At: > Cc: emacs-devel@gnu.org > From: D > Date: Fri, 5 Mar 2021 01:22:30 +0100 > > The data structure org-superstar-todo-bullet-alist associates a todo > keyword with a character to be displayed. The image shows the alignment > problem. The compose-region solution to this is simply to compose each > character with a wide enough space, so the user simply has to use > "\N{EM SPACE}" instead of ? in the alist. > compose-region will then just superimpose the two and you get a "padded" > character. But how do you know that no character associated with a todo keyword could ever be wider than the EM SPACE in the same font? That's entirely up to the font designer. And that's even before you consider complex text shaping which could combine several codepoints into a single wide grapheme cluster. IOW, I think this solution is fragile. Anyway, I think it should be very easy to add a new display property type that would override the pixel width of a font glyph with a fixed value calculated in some way by a Lisp program. > On a side note: Are there any quirks I should be aware of when > transitioning to the display property? I doubt there will be any > difference in terms of performance (contrast overlays, which my mode > can't afford use), but is there anything else I should be aware of? I'm > asking in case there have been efforts like mine in the past which I am > not aware of. This question is too general, and the only answer I can give to such a question is YES. I suggest to try that and bring up any issues you have, then we could talk specifically about those issues.