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: prettify-symbols-mode, derived modes, and compose-region Date: Thu, 4 Mar 2021 22:33:01 +0100 Message-ID: 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="30961"; 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 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 04 22:34:00 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 1lHvbc-0007uk-5L for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 22:34:00 +0100 Original-Received: from localhost ([::1]:50646 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHvbb-000671-7l for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 16:33:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHvan-0005g7-K1 for emacs-devel@gnu.org; Thu, 04 Mar 2021 16:33:09 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:34141) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHvaj-0005A3-NH for emacs-devel@gnu.org; Thu, 04 Mar 2021 16:33:09 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 884BE2400FB for ; Thu, 4 Mar 2021 22:33:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1614893582; bh=qsB/FdtyjoT/OJ66vMaF+06Ygrx0UNGKElGt4iA5uFM=; h=To:From:Subject:Date:From; b=o4O2ftdihKUlv9770NAM4zvalPlXue3k6jttxdmJIZjdpVuvZtvbreOjXUck3Cro+ QLogZ81iIkOUsV7x48VDdVh942V4VgkmjatnOUVjt/otk0N4UfSdNCJScxsiXy8iWp AJST0jyBasFs57B8iikLDHUkqagZaGDaY+7xSHtZH6PotgfwGxbC26d3696MQzwimH 4qpdxcCBve5DxB3BvmMOKI9ZUEmsY6vKGMilYtIF0ztfWwg+z8quUCXvG9PjdnJpX2 iEPjKsifSC8dgUh/5g3ffZLG6TuAG+K6eZYwvCHEOt433rlMRmPweiS6WMMR2q8hte QW4rDNCIRDK9A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Ds3xp0RVyz6tmN for ; Thu, 4 Mar 2021 22:33:01 +0100 (CET) Content-Language: en-US Received-SPF: pass client-ip=185.67.36.66; envelope-from=d.williams@posteo.net; helo=mout02.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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:265989 Archived-At: Hello, I would like to ask what the general consensus is regarding the way prettify-symbols-mode (and similar modes) work, given my current use case. For context, I am the developer and maintainer of org-superstar-mode[1], a purely cosmetic minor mode for Org. It serves as a "spiritual successor" to the popular org-bullets[2] (of which I maintain the form used for MELPA[3]). Both of these minor modes (ab)use static character composition to achieve their visual effect, instead of utilizing the display text property. Recently, the following comment has been brought to my attention on this subject recently[4] (by a user named eli-zaretskii): > 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? 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). Kind regards, D. Footnotes: [1] https://github.com/integral-dw/org-superstar-mode [2] https://github.com/sabof/org-bullets [3] https://github.com/integral-dw/org-bullets [4] https://www.reddit.com/r/emacs/comments/brt0sk/prettifysymbolsmode_is_so_cool/eomb5av?utm_source=share&utm_medium=web2x&context=3