emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emojis and other multi-character glyphs


From: Eli Zaretskii
Subject: Re: emojis and other multi-character glyphs
Date: Sun, 26 Dec 2021 12:15:25 +0200

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Sun, 26 Dec 2021 12:43:34 +0300
> 
> There is some inconsistency in naming and behaviour in Emacs master.
> We have `forward-char', `backward-char', `delete-char', 
> `backward-delete-char' commands.  All of them use
> "char" in their names, however, `forward-char' and `backward-char' treats 
> "char" differently than
> `delete-char' and `backward-delete-char'.
> 
> Let me explain.  Emacs has support for composed characters to display 
> multiple characters composed into
> a single glyph.  Almost the same is done for multi-character emojis such as 
> ๐Ÿ‡ท๐Ÿ‡บ or ๐Ÿ‘จโ€๐Ÿ‘ฉโ€๐Ÿ‘งโ€๐Ÿ‘ฆ - multiple
> unicode chars are composed into single glyph representing some emoji.  Now, 
> if you put point under
> composed character or emoji and run `forward-char' or `backward-char' it 
> moves point to the whole glyph,
> however, if you run `delete-char' (when point is under composed char) or 
> `backward-delete-char'(when
> point just after the glyph) it will delete only single character from 
> multiple character representation, so
> pressing `C-d' under ๐Ÿ‡ท๐Ÿ‡บ will magically turn Russian flag into ๐Ÿ‡บ.  This is 
> very misleading behaviour
> especially when invisible characters are used in the emojis

Emacs had in the past a feature whereby the user could move and delete
by single codepoints in composed character sequences.  This feature
was somehow lost.  I'm trying for some time to determine how and why
it was lost, and how to restore it.  So this issue is known and is in
the works, albeit slowly.

> Maybe introduce "glyph" term meaning graphical representation of chars 
> sequence, displayed in the buffer
> and operated as a whole thing?

There's no need for that, because we can provide dwim-ish operation
for existing commands without any new terminology or new commands.

> And also it will be possible to write something like `string-glyph-length' to 
> return 1 for "๐Ÿ‘จโ€๐Ÿ‘ฉโ€๐Ÿ‘งโ€๐Ÿ‘ฆ" instead of 7
> as `length' returns now.

Why would that be useful?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]