procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source
This commit is contained in:
Eli Zaretskii 2020-05-23 10:59:39 +03:00
parent 13b6dfd4f7
commit fb2e34cd21
1 changed files with 25 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
etc/TODO
View file

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