Support for shorthand emoji input

Support for shorthand emoji input

[Tor Kringeland]

Currently, inputting some common emoji using `C-x 8 e e' is quite
cumbersome.  /E.g./ to input `👍' one has to write

  C-x 8 e e b h n a a

How about having a subcommand (/e.g./ `C-x 8 e c') and allow users to
specify a custom list of emoji?  It would work similar to `C-x 8 e r'
except that the options would be constant.  Personally I don't look at
the transient menus when inserting my common emoji, as it's part of
muscle memory, so this would serve a distinct purpose from `C-x 8 e r'.

Re: Support for shorthand emoji input

[Juri Linkov]

> Currently, inputting some common emoji using `C-x 8 e e' is quite
> cumbersome.  /E.g./ to input `👍' one has to write
>
>   C-x 8 e e b h n a a

BTW, another missing feature is an input method that would turn
a key sequence like ‘: - )’ into ‘😀’.  Many apps provide such
feature that surprisingly works like input methods in Emacs,
e.g. an incomplete sequence is left untranslated, etc.

More complex sequences work this way: type the first few chars,
e.g. ‘: t h’, then a completion list pops up with the first
completion selected ‘:thumbsup:’.  Then typing RET inserts ‘👍’.

Re: Support for shorthand emoji input

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 30 Nov 2021 19:59:20 +0200
> Cc: emacs-devel@gnu.org
> 
> BTW, another missing feature is an input method that would turn
> a key sequence like ‘: - )’ into ‘😀’.  Many apps provide such
> feature that surprisingly works like input methods in Emacs,
> e.g. an incomplete sequence is left untranslated, etc.

It isn't an input method, it's a general-purpose text-replacing
facility.  We need to add it.  Currently, abbrevs can be used as
poor-man's alternative, but abbrevs cannot replace arbitrary text.

The feature should offer several popular replacements and allow users
to select and add to them.

Re: Support for shorthand emoji input

[Tor Kringeland]

Juri Linkov <juri@linkov.net> writes:

> More complex sequences work this way: type the first few chars,
> e.g. ‘: t h’, then a completion list pops up with the first
> completion selected ‘:thumbsup:’.  Then typing RET inserts ‘👍’.

`telega.el' (a Telegram client) supports this [1].  Though they use
`company-mode', which isn't part of core.

- [1] https://zevlg.github.io/telega.el/#completing-input-in-chatbuf

Re: Support for shorthand emoji input

[Lars Ingebrigtsen]

Tor Kringeland <tor.a.s.kringeland@ntnu.no> writes:

> Currently, inputting some common emoji using `C-x 8 e e' is quite
> cumbersome.  /E.g./ to input `👍' one has to write
>
>   C-x 8 e e b h n a a
>
> How about having a subcommand (/e.g./ `C-x 8 e c') and allow users to
> specify a custom list of emoji?  It would work similar to `C-x 8 e r'
> except that the options would be constant.  Personally I don't look at
> the transient menus when inserting my common emoji, as it's part of
> muscle memory, so this would serve a distinct purpose from `C-x 8 e r'.

You can pre-populate `C-x 8 e r' with the emojis you use (by putting
them in the emoji--recent list), but they'll move around as they're
being used.

So adding a new command (and user option to hold your favourite emojis)
would be fine.  Er...  `C-x 8 e f' for "favourite"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Support for shorthand emoji input

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> BTW, another missing feature is an input method that would turn
> a key sequence like ‘: - )’ into ‘😀’.  Many apps provide such
> feature that surprisingly works like input methods in Emacs,
> e.g. an incomplete sequence is left untranslated, etc.

This is basically what packages like emojify do, I think?  (Which uses
the popular emoji key sequences defined by Github, if I remember
correctly.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Support for shorthand emoji input

[Tor Kringeland]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> You can pre-populate `C-x 8 e r' with the emojis you use (by putting
> them in the emoji--recent list), but they'll move around as they're
> being used.
>
> So adding a new command (and user option to hold your favourite emojis)
> would be fine.  Er...  `C-x 8 e f' for "favourite"?

Nice 👍

Also, it would be nice to have the user option be an alist so that you
could specify /e.g./

  ("t" . "👍")

instead of the emoji being lexicographically ordered.

Re: Support for shorthand emoji input

[Lars Ingebrigtsen]

Tor Kringeland <tor.a.s.kringeland@ntnu.no> writes:

> Also, it would be nice to have the user option be an alist so that you
> could specify /e.g./
>
>   ("t" . "👍")
>
> instead of the emoji being lexicographically ordered.

Makes sense to me.  Could you report this as a wishlist item with
report-emacs-bug so that we don't forget to add this command?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Support for shorthand emoji input

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It isn't an input method, it's a general-purpose text-replacing
  > facility.  We need to add it.

What exactly is the proposed general-purpose text-replacing facility
that people propose to add?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Support for shorthand emoji input

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: juri@linkov.net, tor.a.s.kringeland@ntnu.no, emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 23:30:18 -0500
> 
>   > It isn't an input method, it's a general-purpose text-replacing
>   > facility.  We need to add it.
> 
> What exactly is the proposed general-purpose text-replacing facility
> that people propose to add?

A facility to let users specify text replacements to be done
on-the-fly as you type.  It should be similar to what the abbrevs do,
just extended to handle non word-constituent characters, including
punctuation and symbols.  For example, replacing -- with the em-dash
character — or 1/2 with ½ or (C) with © or <== with ←.

Re: Support for shorthand emoji input

[Juri Linkov]

>>   > It isn't an input method, it's a general-purpose text-replacing
>>   > facility.  We need to add it.
>>
>> What exactly is the proposed general-purpose text-replacing facility
>> that people propose to add?
>
> A facility to let users specify text replacements to be done
> on-the-fly as you type.  It should be similar to what the abbrevs do,
> just extended to handle non word-constituent characters, including
> punctuation and symbols.  For example, replacing -- with the em-dash
> character — or 1/2 with ½ or (C) with © or <== with ←.

I really don't see how this is different from an input method:
after 'C-\ compose RET', --- is replaced with the em-dash,
12 with ½, (C) with ©, <- with ←.

Re: Support for shorthand emoji input

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rms@gnu.org,  tor.a.s.kringeland@ntnu.no,  emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 11:18:55 +0200
> 
> >>   > It isn't an input method, it's a general-purpose text-replacing
> >>   > facility.  We need to add it.
> >>
> >> What exactly is the proposed general-purpose text-replacing facility
> >> that people propose to add?
> >
> > A facility to let users specify text replacements to be done
> > on-the-fly as you type.  It should be similar to what the abbrevs do,
> > just extended to handle non word-constituent characters, including
> > punctuation and symbols.  For example, replacing -- with the em-dash
> > character — or 1/2 with ½ or (C) with © or <== with ←.
> 
> I really don't see how this is different from an input method:
> after 'C-\ compose RET', --- is replaced with the em-dash,
> 12 with ½, (C) with ©, <- with ←.

It is different because the implementation doesn't need to use quail
(which is problematic and supports many features that are not needed
for the above).  The need to type C-\ before you have this is also
problematic: it means I cannot easily have a "real" input method
active while I use this facility.

Basically, it's unrelated to producing characters, so using an input
method for it is not clean, IMO.

Re: Support for shorthand emoji input

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A facility to let users specify text replacements to be done
  > on-the-fly as you type.  It should be similar to what the abbrevs do,
  > just extended to handle non word-constituent characters, including
  > punctuation and symbols.  For example, replacing -- with the em-dash
  > character — or 1/2 with ½ or (C) with © or <== with ←.

It sounds useful, but may be hard to implement efficiently.
Abbrevs are efficient because it does lookup of a word at the end
of that word.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Support for shorthand emoji input

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: juri@linkov.net, tor.a.s.kringeland@ntnu.no, emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 23:29:29 -0500
> 
>   > A facility to let users specify text replacements to be done
>   > on-the-fly as you type.  It should be similar to what the abbrevs do,
>   > just extended to handle non word-constituent characters, including
>   > punctuation and symbols.  For example, replacing -- with the em-dash
>   > character — or 1/2 with ½ or (C) with © or <== with ←.
> 
> It sounds useful, but may be hard to implement efficiently.
> Abbrevs are efficient because it does lookup of a word at the end
> of that word.

I very much doubt that comparing a bunch of characters before point
with a list of strings could be so inefficient as to make this feature
unusable.

But it's all highly academic unless someone produces a working code.

Re: Support for shorthand emoji input

[Stefan Monnier]

Eli Zaretskii [2021-12-02 09:55:23] wrote:
> A facility to let users specify text replacements to be done
> on-the-fly as you type.  It should be similar to what the abbrevs do,
> just extended to handle non word-constituent characters, including
> punctuation and symbols.  For example, replacing -- with the em-dash
> character — or 1/2 with ½ or (C) with © or <== with ←.

FWIW, `abbrev.el` already supports abbrevs with non-word-constituents.
This support comes with 2 caveats, admittedly:

- You need to specify a `:regexp` to `define-abbrev-table` which
  describes the form of abbrevs this table should support (and this
  regexp is matched with `looking-back` so it can be a bit tricky to
  get it quite right).
- `self-insert-command` only calls `expand-abbrev` for you when you
  insert a non-word char right after a word-char, so if your abbrev ends
  with a non-word char you can't rely on `self-insert-command` to
  trigger the expansion (unless you add a `post-self-insert-hook` or
  `post-command-hook` or some such).


        Stefan

Re: Support for shorthand emoji input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  tor.a.s.kringeland@ntnu.no,  emacs-devel@gnu.org,
>   juri@linkov.net
> Date: Fri, 03 Dec 2021 08:14:53 -0500
> 
> Eli Zaretskii [2021-12-02 09:55:23] wrote:
> > A facility to let users specify text replacements to be done
> > on-the-fly as you type.  It should be similar to what the abbrevs do,
> > just extended to handle non word-constituent characters, including
> > punctuation and symbols.  For example, replacing -- with the em-dash
> > character — or 1/2 with ½ or (C) with © or <== with ←.
> 
> FWIW, `abbrev.el` already supports abbrevs with non-word-constituents.
> This support comes with 2 caveats, admittedly:

Yes, I know.  If these caveats could be resolved, we'd have the
feature ready for use.