From 5af9e5baad3dc68f75d93eeb4b2f2bb89ad62058 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Sat, 29 Feb 2020 15:10:09 +0200 Subject: ; Add an entry to TODO * etc/TODO: Expand the ligature support entry. Add a new entry about better support of Emoji. --- etc/TODO | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) 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 -- cgit v1.2.3