bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Package: Emacs
Version: 29.0.91


    % src/emacs -Q
    M-x emoji-insert RET
    s s

I expect at this point to see a list of "smiling Smiley" emojis
displayed in the small bottom window, but instead that window is empty
(there's just a one-pixel-thick line about one-char wide at the very
top-left) and it sits there.  At this point I get the impression that
this bottom window is actually gone and I'm now looking at an unusually
high empty echo area.  But if I try to type characters, I'm met with
messages like:

    Unbound suffix: 'a' (Use 'C-g' to abort, '?' for help) [self-insert-command]

if I hit `?` I get:

    Error in post-command-hook (transient--post-command): (error "Invalid search bound (wrong side of point)")

There are several bugs here (probably parts in `emoji.el` and parts in
`transient.el`):

1- The list shouldn't be empty, right?
2- If really the list should be empty, then it would be better after the
   first `s` not to offer me a second `s` choice if that choice leads nowhere.
3- Once I get to this empty list, the state is quite confusing.
   It would be desirable to emit a message about the fact that there's
   no valid choice at this point and that `C-g` and `?` are the only
   options (assuming these are really the only options).
4- The search-bound error, of course.

Side note: during this `emoji-insert` interaction, I only see
black&white emojis, so maybe this is linked to some compilation option
I used which prevents the use of color emojis, tho I don't know what
that option would be.


        Stefan


In GNU Emacs 29.0.91 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2023-06-12 built on pastel
Repository revision: 36aa9bd818334bba56b0fdd6e10d7dc05ba4bbd4
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure -C --enable-checking --enable-check-lisp-object-type
 --with-modules --with-cairo --with-tiff=ifavailable 'CFLAGS=-Wall -g3
 -Og -Wno-pointer-sign' PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2
XPM LUCID ZLIB

Important settings:
  value of $LANG: fr_CH.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
emoji-labels emoji generate-lisp-file multisession sqlite transient
cl-seq format-spec edmacro kmacro eieio byte-opt bytecomp byte-compile
eieio-core cl-macs gv cl-extra help-mode cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 64058 6337)
 (symbols 48 7321 0)
 (strings 32 36137 2055)
 (string-bytes 1 857492)
 (vectors 16 16552)
 (vector-slots 8 362576 16685)
 (floats 8 33 138)
 (intervals 56 617 0)
 (buffers 984 10))

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Eli Zaretskii]

> Date: Mon, 12 Jun 2023 14:15:50 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
>     % src/emacs -Q
>     M-x emoji-insert RET
>     s s
> 
> I expect at this point to see a list of "smiling Smiley" emojis
> displayed in the small bottom window, but instead that window is empty
> (there's just a one-pixel-thick line about one-char wide at the very
> top-left) and it sits there.

I cannot reproduce this, neither in the 29.0.91 pretest nor in the
current emacs-29 branch.  I get the behavior you expected: a small
window at the bottom of the frame showing some smileys.

> Side note: during this `emoji-insert` interaction, I only see
> black&white emojis, so maybe this is linked to some compilation option
> I used which prevents the use of color emojis, tho I don't know what
> that option would be.

Do you have Noto Color Emoji font installed?

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>     % src/emacs -Q
>>     M-x emoji-insert RET
>>     s s
>> 
>> I expect at this point to see a list of "smiling Smiley" emojis
>> displayed in the small bottom window, but instead that window is empty
>> (there's just a one-pixel-thick line about one-char wide at the very
>> top-left) and it sits there.
>
> I cannot reproduce this, neither in the 29.0.91 pretest nor in the
> current emacs-29 branch.  I get the behavior you expected: a small
> window at the bottom of the frame showing some smileys.

I think the problems only appear if the list of emojis becomes empty.

>> Side note: during this `emoji-insert` interaction, I only see
>> black&white emojis, so maybe this is linked to some compilation option
>> I used which prevents the use of color emojis, tho I don't know what
>> that option would be.
> Do you have Noto Color Emoji font installed?

Here I get the normal/expected behavior and I do have
`fonts-noto-color-emoji` installed but on the machine where I see the
problem that package is indeed not installed.

So I guess to reproduce the problem you need to use a machine that
has sufficiently few fonts that the list of emojis becomes empty in the
category that you select (such as "smiling smileys").


        Stefan

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Gregory Heytings]

>> % src/emacs -Q
>> M-x emoji-insert RET
>> s s
>>
>> I expect at this point to see a list of "smiling Smiley" emojis 
>> displayed in the small bottom window, but instead that window is empty 
>> (there's just a one-pixel-thick line about one-char wide at the very 
>> top-left) and it sits there.
>
> I cannot reproduce this, neither in the 29.0.91 pretest nor in the 
> current emacs-29 branch.  I get the behavior you expected: a small 
> window at the bottom of the frame showing some smileys.
>

FWIW, I can easily reproduce this by removing the fonts-noto-color-emoji 
package.

Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply error out 
when (list-fonts (font-spec :script 'emoji)) is nil?

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply error out when
> (list-fonts (font-spec :script 'emoji)) is nil?

FWIW, I do like being able to insert some emojis even if I don't have
access to all of them (and actually I'd even be happy to insert them
without being able to see them, assuming I can see their name
instead :-)

I notice also the list of "recent" emojis is not filtered according to
the available fonts, so I see tofu for some of them.  It would be good
to replace the tofu with a readable description.


        Stefan

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Gregory Heytings]

>> Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply error out 
>> when (list-fonts (font-spec :script 'emoji)) is nil?
>
> FWIW, I do like being able to insert some emojis even if I don't have 
> access to all of them (and actually I'd even be happy to insert them 
> without being able to see them, assuming I can see their name instead 
> :-)
>

Yes, but you can still do that with C-x 8 RET, right?  The C-x 8 e 
commands use transient menus, and (as you described in the bug report) 
don't quite work when a suitable emoji font is not available.

In theory, another option would be to display, in these transient menus, 
emoji names instead of emoji characters when no emoji font is available, 
but there is not enough room for list of names such as "SMILING FACE WITH 
SMILING EYES AND HAND COVERING MOUTH" (which fit better in *Completions*).

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Eli Zaretskii]

> Date: Wed, 14 Jun 2023 23:05:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 64024@debbugs.gnu.org
> 
> 
> >> Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply error out 
> >> when (list-fonts (font-spec :script 'emoji)) is nil?
> >
> > FWIW, I do like being able to insert some emojis even if I don't have 
> > access to all of them (and actually I'd even be happy to insert them 
> > without being able to see them, assuming I can see their name instead 
> > :-)
> >
> 
> Yes, but you can still do that with C-x 8 RET, right?  The C-x 8 e 
> commands use transient menus, and (as you described in the bug report) 
> don't quite work when a suitable emoji font is not available.
> 
> In theory, another option would be to display, in these transient menus, 
> emoji names instead of emoji characters when no emoji font is available, 
> but there is not enough room for list of names such as "SMILING FACE WITH 
> SMILING EYES AND HAND COVERING MOUTH" (which fit better in *Completions*).

We have the "emoji" input method, which can help here, I think.

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Gregory Heytings]

>>>> Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply error 
>>>> out when (list-fonts (font-spec :script 'emoji)) is nil?
>>>
>>> FWIW, I do like being able to insert some emojis even if I don't have 
>>> access to all of them (and actually I'd even be happy to insert them 
>>> without being able to see them, assuming I can see their name instead 
>>> :-)
>>
>> Yes, but you can still do that with C-x 8 RET, right?  The C-x 8 e 
>> commands use transient menus, and (as you described in the bug report) 
>> don't quite work when a suitable emoji font is not available.
>>
>> In theory, another option would be to display, in these transient 
>> menus, emoji names instead of emoji characters when no emoji font is 
>> available, but there is not enough room for list of names such as 
>> "SMILING FACE WITH SMILING EYES AND HAND COVERING MOUTH" (which fit 
>> better in *Completions*).
>
> We have the "emoji" input method, which can help here, I think.
>

That's yet another way to do it.  But without a suitable font it doesn't 
work well either, e.g. after :) you see a list of four possible choices 
which are displayed in the echo area with tofus.

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Robert Pluim]

>>>>> On Thu, 15 Jun 2023 08:12:45 +0000, Gregory Heytings <gregory@heytings.org> said:

    >>>>> Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply
    >>>>> error out when (list-fonts (font-spec :script 'emoji)) is nil?
    >>>>

That would stop you using them in tty frames, where they work fine.

    >>>> FWIW, I do like being able to insert some emojis even if I don't
    >>>> have access to all of them (and actually I'd even be happy to
    >>>> insert them without being able to see them, assuming I can see
    >>>> their name instead :-)
    >>> 
    >>> Yes, but you can still do that with C-x 8 RET, right?  The C-x 8 e
    >>> commands use transient menus, and (as you described in the bug
    >>> report) don't quite work when a suitable emoji font is not
    >>> available.
    >>> 
    >>> In theory, another option would be to display, in these transient
    >>> menus, emoji names instead of emoji characters when no emoji font
    >>> is available, but there is not enough room for list of names such
    >>> as "SMILING FACE WITH SMILING EYES AND HAND COVERING MOUTH" (which
    >>> fit better in *Completions*).
    >>

"C-x 8 e s" already does that, we could extend it to "C-x 8 e e". Once
youʼre down to half a dozen emoji it should fit fine.

Robert
-- 

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]


>> Perhaps the emoji-* commands (C-x 8 e [eilrs]) should simply error out 
>> when (list-fonts (font-spec :script 'emoji)) is nil?
>
> That would stop you using them in tty frames, where they work fine.
>

That "(list-fonts (font-spec :script 'emoji))" was not a patch, just an 
idea, and indeed for TTY frames, where emojis can (but do not always) work 
fine, it should be skipped.

>
> "C-x 8 e s" already does that, we could extend it to "C-x 8 e e". Once 
> youʼre down to half a dozen emoji it should fit fine.
>

Yes, C-x 8 e s uses the standard *Completions* buffer.  The point of 
Stefan's bug report is that C-x 8 e i doesn't, and when no suitable font 
is available it's not really usable.

bug#64024: 29.0.91; `emoji-insert` shows me confusing empty lists

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]


>> "C-x 8 e s" already does that, we could extend it to "C-x 8 e e". Once 
>> youʼre down to half a dozen emoji it should fit fine.
>
> Yes, C-x 8 e s uses the standard *Completions* buffer.  The point of 
> Stefan's bug report is that C-x 8 e i doesn't, and when no suitable font 
> is available it's not really usable.
>

BTW, perhaps C-x 8 e i could automatically fall back to C-x 8 e s when no 
suitable font is available?