emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

emacs-27 fb2e34c 1/2: ; * etc/TODO (Ligatures): Update the entry based o


From: Eli Zaretskii
Subject: emacs-27 fb2e34c 1/2: ; * etc/TODO (Ligatures): Update the entry based on recent discussions.
Date: Sat, 23 May 2020 04:01:18 -0400 (EDT)

branch: emacs-27
commit fb2e34cd2155cbaaf945d8cd167b600b55b9edff
Author: Eli Zaretskii <address@hidden>
Commit: Eli Zaretskii <address@hidden>

    ; * etc/TODO (Ligatures): Update the entry based on recent discussions.
---
 etc/TODO | 33 +++++++++++++++++++++++++--------
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/etc/TODO b/etc/TODO
index f983fa2..c11848e 100644
--- a/etc/TODO
+++ b/etc/TODO
@@ -220,10 +220,23 @@ https://lists.gnu.org/r/emacs-devel/2013-11/msg00515.html
     width fonts.  However, more features are still needed to achieve this.
 
 ** Support ligatures out of the box
-For the list of typographical ligatures, see
+For the list of frequently-used typographical ligatures, see
 
   
https://en.wikipedia.org/wiki/Orthographic_ligature#Ligatures_in_Unicode_(Latin_alphabets)
 
+(Note that in general, the number of possible ligatures can be much
+larger, and there's no way, in principle, to specify the superset of
+all the ligatures that could exist.  Each font can support different
+ligatures.  The reliable way of supporting any and all ligatures is to
+hand all text to be displayed to the shaping engine and get back the
+font glyphs to display that text.  However, doing this is impossible
+with the current design of the Emacs display engine, since it examines
+buffer text one character at a time, and implements character
+composition by calls to Lisp, which makes doing this for every
+character impractically slow.  therefore, the rest of this item
+describes a limited form of ligature support which is compatible with
+the current display engine design and uses automatic compositions.)
+
 For Text and derived modes, the job is to figure out which ligatures
 we want to support, how to let the user customize that, and probably
 define a minor mode for automatic ligation (as some contexts might not
@@ -237,12 +250,12 @@ prettify-symbols-mode.  We need to figure out which 
ligatures are
 needed for each programming language, and provide user options to turn
 this on and off.
 
-The implementation should use the infrastructure for character
-compositions, i.e., we should define appropriate regexp-based rules
-for character sequences that need to be composed into ligatures, and
-populate composition-function-table with those rules.  See
-composite.el for examples of this, and also grep lisp/language/*.el
-for references to composition-function-table.
+The implementation should use the infrastructure for automatic
+character compositions, i.e., we should define appropriate
+regexp-based rules for character sequences that need to be composed
+into ligatures, and populate composition-function-table with those
+rules.  See composite.el for examples of this, and also grep
+lisp/language/*.el for references to composition-function-table.
 
 One problem with character compositions that will need to be solved is
 that composition-function-table, the char-table which holds the
@@ -259,7 +272,11 @@ way of preventing the ligation from happening.  One 
possibility is to
 have a ZWNJ character separate these ASCII characters; another
 possibility is to introduce a special text property that prevents
 character composition, and place that property on the relevant parts
-of the mode line.
+of the mode line.  Yet another possibility would be to write a
+specialized composition function, which would detect that it is called
+on mode-line strings, and return nil to signal that composition is not
+possible in this case; then use that function in the rules for
+ligatures stored in composition-function-table.
 
 The prettify-symbols-mode should be deprecated once ligature support
 is in place.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]