aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEli Zaretskii2020-02-29 15:10:09 +0200
committerEli Zaretskii2020-02-29 15:10:09 +0200
commit5af9e5baad3dc68f75d93eeb4b2f2bb89ad62058 (patch)
treeae26f69c8a80afa382a1d80b2524f8f70bb3e707
parentd42419590563964fd61b35dea7738e77c0f90cba (diff)
downloademacs-5af9e5baad3dc68f75d93eeb4b2f2bb89ad62058.tar.gz
emacs-5af9e5baad3dc68f75d93eeb4b2f2bb89ad62058.zip
; 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
244composite.el for examples of this, and also grep lisp/language/*.el 244composite.el for examples of this, and also grep lisp/language/*.el
245for references to composition-function-table. 245for references to composition-function-table.
246 246
247One problem with character compositions that will need to be solved is
248that composition-function-table, the char-table which holds the
249composition rules, is a global variable, whereas use of ligatures is
250inherently specific to buffer-local stuff like the major mode and the
251script or language in use. So there should be a buffer-local variable
252to augment/customize/override the global composition rules.
253
254Another problem is that ligatures are frequently composed of ASCII
255characters, and some of those ASCII characters are present in the mode
256line, for example "--". Since displaying a ligature instead of 2
257separate '-' characters on a mode line is not right, there should be a
258way of preventing the ligation from happening. One possibility is to
259have a ZWNJ character separate these ASCII characters; another
260possibility is to introduce a special text property that prevents
261character composition, and place that property on the relevant parts
262of the mode line.
263
247The prettify-symbols-mode should be deprecated once ligature support 264The prettify-symbols-mode should be deprecated once ligature support
248is in place. 265is in place.
249 266
@@ -267,6 +284,59 @@ should invoke the 'shape' method. 'hbfont_shape' should be extended
267to pass to 'hb_shape_full' the required array of features, as 284to pass to 'hb_shape_full' the required array of features, as
268mentioned in the above HarfBuzz discussion. 285mentioned in the above HarfBuzz discussion.
269 286
287** Better support for displaying Emoji
288
289Emacs is capable of displaying Emoji and some of the Emoji sequences,
290provided that its fontsets are configured with a suitable font. To
291make this easier out of the box, the following should be done:
292
293*** Populate composition-function-table with Emoji rules
294
295The Unicode Character Database (UCD) includes several data files that
296define the valid Emoji sequences. These files should be imported into
297the Emacs tree, and should be converted by some script at Emacs build
298time to Lisp code that populates composition-function-table with the
299corresponding composition rules.
300
301*** Augment the default fontsets with Emoji-capable fonts
302
303The default fontsets set up by fontest.el should include known free
304fonts that provide good support for displaying Emoji sequences. In
305addition, the rule that the default face's font is used for symbol and
306punctuation characters, disregarding the fontsets, should be modified
307to exempt Emoji from this rule (since Emoji characters belong to the
308'symbol' script in Emacs), so that use-default-font-for-symbols would
309not have to be tweaked to have Emoji display by default with a capable
310font.
311
312*** Consider changing the default display of Variation Selectors
313
314Emacs by default displays the Variation Selector (VS) codepoints not
315composed with base characters as thin 1-pixel space glyphs. The
316Unicode FAQ says that if variation sequences cannot be supported, the
317VS characters should not be shown, leaving just the base character of
318the sequence visible. This could be handled via
319glyphless-char-display, by changing the entries for VS codepoints to
320'zero-width'.
321
322*** Special face for displaying text presentation of Emoji
323
324Emoji-capable fonts support Emoji sequences with the U+FE0F VARIATION
325SELECTOR-16 (VS16) for emoji-style display, but usually don't support
326the U+FE0F VARIATION SELECTOR-15 (VS15) for text-style display. There
327are other fonts which support the text-style sequences, but not
328emoji-style. Since Emacs selects a font based on a single character,
329it cannot choose 2 different fonts for displaying both styles of the
330same base character. To display both styles in the same buffer, one
331could use a special face, placing a 'face' text property on portions
332of the text. This special face could specify a specific font known to
333support text-style Emoji sequences. Emacs could have such a face
334built-in.
335
336See the discussion of bug#39799 for more details about this task.
337Another relevant resource is the Unicode Technical Standard #51
338"Unicode Emoji" (http://www.unicode.org/reports/tr51/).
339
270** Extend text-properties and overlays 340** Extend text-properties and overlays
271*** Several text-property planes 341*** Several text-property planes
272This would get us rid of font-lock-face property (and I'd be happy to 342This would get us rid of font-lock-face property (and I'd be happy to