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: Thu, 04 Mar 2021 23:54:10 +0200 Message-ID: <83k0qmzit9.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12457"; 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 Thu Mar 04 22:55:30 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 1lHvwP-00037b-DW for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 22:55:29 +0100 Original-Received: from localhost ([::1]:59876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHvwO-0003An-GG for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 16:55:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHvvS-0002aT-Ry for emacs-devel@gnu.org; Thu, 04 Mar 2021 16:54:30 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43389) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHvvS-0006R0-Ha; Thu, 04 Mar 2021 16:54:30 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4911 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHvvP-0005A2-L5; Thu, 04 Mar 2021 16:54:29 -0500 In-Reply-To: (message from D on Thu, 4 Mar 2021 22:33:01 +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:265991 Archived-At: > From: D > Date: Thu, 4 Mar 2021 22:33:01 +0100 > > > I'm sorry, but I don't share your enthusiasm about > > prettify-symbols-mode. It piggy-backs a feature, called "static > > character composition", which was never designed for this job, and > > which is nowadays rarely if ever used for the job it was designed > > for. So it has bit-rotted, and in some not-too-far future we will > > probably want to obsolete and remove the static character composition > > from Emacs, at which point prettify-symbols-mode will be a huge drag. > > I empathize with the sentiment, which consequently brings me here to > ask: Should I consider relying on composition "future-proof" or is > this use discouraged? Yes, I'd very much like to discourage the use of static compositions. Especially in text-related modes such as Org, where human-readable text is the main content (as opposed to programming-language modes). That's because static compositions don't support bidirectional editing and display, and so some of the scripts and languages we support elsewhere in Emacs are off-limits when static compositions are involved. So prettify-symbols-mode is semi-okay, as it is usually turned on in PL modes, where everything is left-to-right. But using the same techniques in Org is from my POV much worse, and I'd be happier if that could be avoided. > Because if it is, I may run into an issue. In > the case of org-bullets, I have no qualms to just rid the code of the > composition hack, as it (to my knowledge) serves no purpose there that > can't trivially be fulfilled by the display property. Meanwhile, > Superstar has a more "justified" reason to favor composition over > display: The decorations it adds to a buffer are not necessarily > monospaced in a given user's font set. This can lead to alignment > problems for entries that should be the same level of indentation. > Superstar solves this problem by letting the user superimpose the > decoration character with whitespace. This way, a user can have an > asterisk display as a while keeping alignment by using > the string "\s", which is passed to compose-region and > produces the desired result. Conversely, too wide chars can be > "normalized" by using U2003 (EM SPACE) and similar characters to widen > all affected "bullets" equally. If static composition were to be > deprecated, I would not be able to provide this feature anymore, and > it's the primary reason I don't think I could avoid the composition > hack in Superstar (given it directly benefits from actual > composition). I'm not sure I understand the problem, but can't you use :align-to in display properties to solve the alignment issues? Thanks.