; * etc/TODO (Ligatures): Update the entry based on recent discussions.

diff --git a/etc/TODO b/etc/TODO
index f983fa27d33b4543b72fce38eedaa5a4f9ae343e..c11848e0c5df6aadd74516aec3dd0a06a2f0ffe3 100644 (file)
--- 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.