From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: D Newsgroups: gmane.emacs.devel Subject: Re: prettify-symbols-mode, derived modes, and compose-region Date: Fri, 5 Mar 2021 22:24:44 +0100 Message-ID: <18caf24f-fb5d-616d-fb24-393f7d2149f7@posteo.net> References: <83k0qmzit9.fsf@gnu.org> <587ee071-985b-450a-2df7-0b4bb0f97b48@posteo.net> <83eeguyt58.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5156"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Stefan Monnier , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 05 22:25:26 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 1lIHws-0001Eh-Js for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 22:25:26 +0100 Original-Received: from localhost ([::1]:37680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIHwr-00027k-N3 for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 16:25:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIHwJ-0001i1-0E for emacs-devel@gnu.org; Fri, 05 Mar 2021 16:24:51 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:40263) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIHwH-0008VG-69 for emacs-devel@gnu.org; Fri, 05 Mar 2021 16:24:50 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id EC839160060 for ; Fri, 5 Mar 2021 22:24:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1614979486; bh=Gwax2EY9+l+eeNyBVAL7K7ZJpn3HzUf/FNQGTsadXv0=; h=Subject:To:From:Cc:Date:From; b=WefwU15ehhM2JeaStWzumT7FpDZXiIkFfIDSVzxJNy9v6wEbDVi3i1AB9o87m2K7W btVgUGDXIVKTdkN1zyJdStxbM50UPk7DcgX60gmX66QulzVxjKVCAz9zD4tSXvaeq2 yn9nnoowVpr+td1mu5NHobSxOoCi0bSYW/Z6mqJs0cahrJd+hMnK5QRgL8cUdYROnA O8tSZdKVso0sR1ch8hIIMk7hXISb+Q6aalFhGT49QMUld5Ju3+ywMuoQAkLkPPd1p9 9oRw4yxOyV7yuGR0M8xUYwt9tcU/I//L2iAImhu3VzV+Ca9gWuL9SM0CWkt2QXoToX 2eFqLACTFptyQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Dsgjm66l2z9rxV; Fri, 5 Mar 2021 22:24:44 +0100 (CET) In-Reply-To: <83eeguyt58.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=185.67.36.65; envelope-from=d.williams@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:266047 Archived-At: > 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. > IOW, I think this solution is fragile. In theory, yes. In practice this has (to my knowledge) not cropped up. My approach is, however, a hack at the end of the day. I mean, the reason I acknowledge is that why I'm here :) > And that's even before you consider > complex text shaping which could combine several codepoints into a > single wide grapheme cluster. I don't think that using a character capable of that would be of any use as a decorative element. I'd say decorating a title or representing an item bullet is largely the domain of dingbats, geometric shapes, and to a lesser extent pictograms ("Emoji"). > 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. That would of course be the perfect solution. But, doesn't this have to exist in one way or another already? For example, the checkbox widget in custom interfaces to my knowledge visually replaces a simple "[X]" with a bitmap. When I examine a checkbox with C-u C-x = it seems to be the case that display does the legwork and somehow obtains the image size from the xpm file (I suppose). (On an unrelated side note, I adore the custom interface. Especially the way you can specify complex composite types and tweak the interface to be more expressive, and how you can safety check values using :set) > I suggest to try that and bring up any issues you > have, then we could talk specifically about those issues. Fair. >> IIRC you can query Emacs about the size the character would have if it >> were to be displayed right now in the currently selected window. >> But you don't know that it's the same size as the character will have >> when it will actually be displayed (and that char could have >> simultaneously two different sizes in two different windows, of course). > > That's true, but for shr it doesn't (in general) make much difference. > That is, if you display a rendered HTML document on two different > displays, it'll look awful anyway, until you re-render tables and the > like with the new width of the glyphs. That is, a layout with > > | foo bar | more foo | > | zot | | > > rarely looks on two different displays -- even if the :width/:align-to > elements were to magically adjust themselves. Same with superstar, essentially. For example, every decorative bullet can have a "fallback character" for terminal displays, and this behaves correctly from the perspective of the frame you opened the buffer with. I include a simple redisplay command for emacsclient users for this reason. So I suppose I operate under the same limitations as shr? In that case, I probably should look into that character size function. Could you point me in the right general direction? I'm not quite sure how to find it.