summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEli Zaretskii <eliz@gnu.org>2020-02-29 15:10:09 +0200
committerEli Zaretskii <eliz@gnu.org>2020-02-29 15:10:09 +0200
commit5af9e5baad3dc68f75d93eeb4b2f2bb89ad62058 (patch)
treeae26f69c8a80afa382a1d80b2524f8f70bb3e707
parentd42419590563964fd61b35dea7738e77c0f90cba (diff)
downloademacs-5af9e5baad3dc68f75d93eeb4b2f2bb89ad62058.tar.gz
; Add an entry to TODO
* etc/TODO: Expand the ligature support entry. Add a new entry about better support of Emoji.
-rw-r--r--etc/TODO70
1 files changed, 70 insertions, 0 deletions
diff --git a/etc/TODO b/etc/TODO
index 0a06484c165..f2594f005c7 100644
--- a/etc/TODO
+++ b/etc/TODO
@@ -244,6 +244,23 @@ 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
+composition rules, is a global variable, whereas use of ligatures is
+inherently specific to buffer-local stuff like the major mode and the
+script or language in use. So there should be a buffer-local variable
+to augment/customize/override the global composition rules.
+
+Another problem is that ligatures are frequently composed of ASCII
+characters, and some of those ASCII characters are present in the mode
+line, for example "--". Since displaying a ligature instead of 2
+separate '-' characters on a mode line is not right, there should be a
+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.
+
The prettify-symbols-mode should be deprecated once ligature support
is in place.
@@ -267,6 +284,59 @@ should invoke the 'shape' method. 'hbfont_shape' should be extended
to pass to 'hb_shape_full' the required array of features, as
mentioned in the above HarfBuzz discussion.
+** Better support for displaying Emoji
+
+Emacs is capable of displaying Emoji and some of the Emoji sequences,
+provided that its fontsets are configured with a suitable font. To
+make this easier out of the box, the following should be done:
+
+*** Populate composition-function-table with Emoji rules
+
+The Unicode Character Database (UCD) includes several data files that
+define the valid Emoji sequences. These files should be imported into
+the Emacs tree, and should be converted by some script at Emacs build
+time to Lisp code that populates composition-function-table with the
+corresponding composition rules.
+
+*** Augment the default fontsets with Emoji-capable fonts
+
+The default fontsets set up by fontest.el should include known free
+fonts that provide good support for displaying Emoji sequences. In
+addition, the rule that the default face's font is used for symbol and
+punctuation characters, disregarding the fontsets, should be modified
+to exempt Emoji from this rule (since Emoji characters belong to the
+'symbol' script in Emacs), so that use-default-font-for-symbols would
+not have to be tweaked to have Emoji display by default with a capable
+font.
+
+*** Consider changing the default display of Variation Selectors
+
+Emacs by default displays the Variation Selector (VS) codepoints not
+composed with base characters as thin 1-pixel space glyphs. The
+Unicode FAQ says that if variation sequences cannot be supported, the
+VS characters should not be shown, leaving just the base character of
+the sequence visible. This could be handled via
+glyphless-char-display, by changing the entries for VS codepoints to
+'zero-width'.
+
+*** Special face for displaying text presentation of Emoji
+
+Emoji-capable fonts support Emoji sequences with the U+FE0F VARIATION
+SELECTOR-16 (VS16) for emoji-style display, but usually don't support
+the U+FE0F VARIATION SELECTOR-15 (VS15) for text-style display. There
+are other fonts which support the text-style sequences, but not
+emoji-style. Since Emacs selects a font based on a single character,
+it cannot choose 2 different fonts for displaying both styles of the
+same base character. To display both styles in the same buffer, one
+could use a special face, placing a 'face' text property on portions
+of the text. This special face could specify a specific font known to
+support text-style Emoji sequences. Emacs could have such a face
+built-in.
+
+See the discussion of bug#39799 for more details about this task.
+Another relevant resource is the Unicode Technical Standard #51
+"Unicode Emoji" (http://www.unicode.org/reports/tr51/).
+
** Extend text-properties and overlays
*** Several text-property planes
This would get us rid of font-lock-face property (and I'd be happy to