[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.