bug#23377: 25.0.93; Completion is extremely slow for insert-char

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

emacs -Q
C-x 8 RET TAB

This takes over a minute on my Emacs before the completions buffer is
displayed listing the characters. (On subsequent invocations, it's more
like eight seconds.) On Emacs 24 it is effectively instantaneous.

There seems to have been a change whereby the character is shown besides
it's name. This might be a very nice feature, except that it's too slow,
and it seems a bit of a waste because a large proportion of the
characters are unavailable and are shown as little boxes with tiny
numbers inside.

Perhaps there should be a way to turn this feature off? (I don't see
anything about insert-char in NEWS.)

By the way, yes, this is the way I usually use this command. I hit TAB
immediately to get a full list of characters and then `C-x o C-x 1'
because I don't use special characters often enough to remember their
names and I need to get thoroughly immersed in the whole list to see the
naming patterns again and jog my memory.


In GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-23 built on moondust
Repository revision: 5c587fdff164e8b90beb47f6da64b4884290e40a
Windowing system distributor 'Fedora Project', version 11.0.11803000
System Description:	Fedora release 23 (Twenty Three)

Configured using:
 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3 -gdwarf-4''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_MONETARY: en_DK.utf8
  value of $LC_NUMERIC: en_DK.utf8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  TeX-PDF-mode: t
  shell-dirtrack-mode: t
  gnus-undo-mode: t
  recentf-mode: t
  display-battery-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  save-place-mode: t
  electric-pair-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent messages:
Reading incoming mail from file...
nnfolder: Reading incoming mail (no new mail)...done
Reading active file via nnfolder...done
Checking new news...done
Auto-saving...
Updating buffer list...
Formats have changed, recompiling...done
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Making completion list...
Quit

Load-path shadows:
/home/nlj/.emacs.d/elpa/org-20160425/ob-gnuplot hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-gnuplot
/home/nlj/.emacs.d/elpa/org-20160425/org-eshell hides /data/projects/vc/emacs/git/emacs/lisp/org/org-eshell
/home/nlj/.emacs.d/elpa/org-20160425/ox-md hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-md
/home/nlj/.emacs.d/elpa/org-20160425/ob-shen hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-shen
/home/nlj/.emacs.d/elpa/org-20160425/org-timer hides /data/projects/vc/emacs/git/emacs/lisp/org/org-timer
/home/nlj/.emacs.d/elpa/org-20160425/ob-ruby hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ruby
/home/nlj/.emacs.d/elpa/org-20160425/ox hides /data/projects/vc/emacs/git/emacs/lisp/org/ox
/home/nlj/.emacs.d/elpa/org-20160425/ox-html hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-html
/home/nlj/.emacs.d/elpa/org-20160425/ob-latex hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-latex
/home/nlj/.emacs.d/elpa/org-20160425/org-archive hides /data/projects/vc/emacs/git/emacs/lisp/org/org-archive
/home/nlj/.emacs.d/elpa/org-20160425/ob-org hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-org
/home/nlj/.emacs.d/elpa/org-20160425/org-install hides /data/projects/vc/emacs/git/emacs/lisp/org/org-install
/home/nlj/.emacs.d/elpa/org-20160425/ox-latex hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-latex
/home/nlj/.emacs.d/elpa/org-20160425/ob-sass hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sass
/home/nlj/.emacs.d/elpa/org-20160425/ox-icalendar hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-icalendar
/home/nlj/.emacs.d/elpa/org-20160425/ob-screen hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-screen
/home/nlj/.emacs.d/elpa/org-20160425/org-bibtex hides /data/projects/vc/emacs/git/emacs/lisp/org/org-bibtex
/home/nlj/.emacs.d/elpa/org-20160425/org-footnote hides /data/projects/vc/emacs/git/emacs/lisp/org/org-footnote
/home/nlj/.emacs.d/elpa/org-20160425/org-datetree hides /data/projects/vc/emacs/git/emacs/lisp/org/org-datetree
/home/nlj/.emacs.d/elpa/org-20160425/org-colview hides /data/projects/vc/emacs/git/emacs/lisp/org/org-colview
/home/nlj/.emacs.d/elpa/org-20160425/org-attach hides /data/projects/vc/emacs/git/emacs/lisp/org/org-attach
/home/nlj/.emacs.d/elpa/org-20160425/org-mouse hides /data/projects/vc/emacs/git/emacs/lisp/org/org-mouse
/home/nlj/.emacs.d/elpa/org-20160425/ob-dot hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-dot
/home/nlj/.emacs.d/elpa/org-20160425/ob-scala hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-scala
/home/nlj/.emacs.d/elpa/org-20160425/org-compat hides /data/projects/vc/emacs/git/emacs/lisp/org/org-compat
/home/nlj/.emacs.d/elpa/org-20160425/ob-core hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-core
/home/nlj/.emacs.d/elpa/org-20160425/ob-awk hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-awk
/home/nlj/.emacs.d/elpa/org-20160425/ob-makefile hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-makefile
/home/nlj/.emacs.d/elpa/org-20160425/org-macro hides /data/projects/vc/emacs/git/emacs/lisp/org/org-macro
/home/nlj/.emacs.d/elpa/org-20160425/org-ctags hides /data/projects/vc/emacs/git/emacs/lisp/org/org-ctags
/home/nlj/.emacs.d/elpa/org-20160425/org-capture hides /data/projects/vc/emacs/git/emacs/lisp/org/org-capture
/home/nlj/.emacs.d/elpa/org-20160425/ox-beamer hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-beamer
/home/nlj/.emacs.d/elpa/org-20160425/org-mobile hides /data/projects/vc/emacs/git/emacs/lisp/org/org-mobile
/home/nlj/.emacs.d/elpa/org-20160425/org-indent hides /data/projects/vc/emacs/git/emacs/lisp/org/org-indent
/home/nlj/.emacs.d/elpa/org-20160425/ob-lilypond hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lilypond
/home/nlj/.emacs.d/elpa/org-20160425/ob-asymptote hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-asymptote
/home/nlj/.emacs.d/elpa/org-20160425/ox-odt hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-odt
/home/nlj/.emacs.d/elpa/org-20160425/org-w3m hides /data/projects/vc/emacs/git/emacs/lisp/org/org-w3m
/home/nlj/.emacs.d/elpa/org-20160425/ob-plantuml hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-plantuml
/home/nlj/.emacs.d/elpa/org-20160425/ob-table hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-table
/home/nlj/.emacs.d/elpa/org-20160425/ob-ocaml hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ocaml
/home/nlj/.emacs.d/elpa/org-20160425/org-crypt hides /data/projects/vc/emacs/git/emacs/lisp/org/org-crypt
/home/nlj/.emacs.d/elpa/org-20160425/ob-js hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-js
/home/nlj/.emacs.d/elpa/org-20160425/ob-clojure hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-clojure
/home/nlj/.emacs.d/elpa/org-20160425/ob-haskell hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-haskell
/home/nlj/.emacs.d/elpa/org-20160425/org-version hides /data/projects/vc/emacs/git/emacs/lisp/org/org-version
/home/nlj/.emacs.d/elpa/org-20160425/ob-scheme hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-scheme
/home/nlj/.emacs.d/elpa/org-20160425/org-table hides /data/projects/vc/emacs/git/emacs/lisp/org/org-table
/home/nlj/.emacs.d/elpa/org-20160425/ob-C hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-C
/home/nlj/.emacs.d/elpa/org-20160425/ob-ledger hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ledger
/home/nlj/.emacs.d/elpa/org-20160425/ob-fortran hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-fortran
/home/nlj/.emacs.d/elpa/org-20160425/ob-sql hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sql
/home/nlj/.emacs.d/elpa/org-20160425/org hides /data/projects/vc/emacs/git/emacs/lisp/org/org
/home/nlj/.emacs.d/elpa/org-20160425/org-loaddefs hides /data/projects/vc/emacs/git/emacs/lisp/org/org-loaddefs
/home/nlj/.emacs.d/elpa/org-20160425/org-list hides /data/projects/vc/emacs/git/emacs/lisp/org/org-list
/home/nlj/.emacs.d/elpa/org-20160425/ob-lisp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lisp
/home/nlj/.emacs.d/elpa/org-20160425/org-docview hides /data/projects/vc/emacs/git/emacs/lisp/org/org-docview
/home/nlj/.emacs.d/elpa/org-20160425/ob-eval hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-eval
/home/nlj/.emacs.d/elpa/org-20160425/org-element hides /data/projects/vc/emacs/git/emacs/lisp/org/org-element
/home/nlj/.emacs.d/elpa/org-20160425/ob hides /data/projects/vc/emacs/git/emacs/lisp/org/ob
/home/nlj/.emacs.d/elpa/org-20160425/ox-ascii hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-ascii
/home/nlj/.emacs.d/elpa/org-20160425/org-info hides /data/projects/vc/emacs/git/emacs/lisp/org/org-info
/home/nlj/.emacs.d/elpa/org-20160425/ob-css hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-css
/home/nlj/.emacs.d/elpa/org-20160425/org-rmail hides /data/projects/vc/emacs/git/emacs/lisp/org/org-rmail
/home/nlj/.emacs.d/elpa/org-20160425/org-irc hides /data/projects/vc/emacs/git/emacs/lisp/org/org-irc
/home/nlj/.emacs.d/elpa/org-20160425/ob-tangle hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-tangle
/home/nlj/.emacs.d/elpa/org-20160425/ob-ditaa hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ditaa
/home/nlj/.emacs.d/elpa/org-20160425/org-feed hides /data/projects/vc/emacs/git/emacs/lisp/org/org-feed
/home/nlj/.emacs.d/elpa/org-20160425/org-clock hides /data/projects/vc/emacs/git/emacs/lisp/org/org-clock
/home/nlj/.emacs.d/elpa/org-20160425/org-habit hides /data/projects/vc/emacs/git/emacs/lisp/org/org-habit
/home/nlj/.emacs.d/elpa/org-20160425/org-pcomplete hides /data/projects/vc/emacs/git/emacs/lisp/org/org-pcomplete
/home/nlj/.emacs.d/elpa/org-20160425/org-entities hides /data/projects/vc/emacs/git/emacs/lisp/org/org-entities
/home/nlj/.emacs.d/elpa/org-20160425/ob-io hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-io
/home/nlj/.emacs.d/elpa/org-20160425/ob-octave hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-octave
/home/nlj/.emacs.d/elpa/org-20160425/org-faces hides /data/projects/vc/emacs/git/emacs/lisp/org/org-faces
/home/nlj/.emacs.d/elpa/org-20160425/ob-perl hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-perl
/home/nlj/.emacs.d/elpa/org-20160425/org-src hides /data/projects/vc/emacs/git/emacs/lisp/org/org-src
/home/nlj/.emacs.d/elpa/org-20160425/org-protocol hides /data/projects/vc/emacs/git/emacs/lisp/org/org-protocol
/home/nlj/.emacs.d/elpa/org-20160425/ox-man hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-man
/home/nlj/.emacs.d/elpa/org-20160425/ob-python hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-python
/home/nlj/.emacs.d/elpa/org-20160425/ob-mscgen hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-mscgen
/home/nlj/.emacs.d/elpa/org-20160425/ox-texinfo hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-texinfo
/home/nlj/.emacs.d/elpa/org-20160425/ob-exp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-exp
/home/nlj/.emacs.d/elpa/org-20160425/org-inlinetask hides /data/projects/vc/emacs/git/emacs/lisp/org/org-inlinetask
/home/nlj/.emacs.d/elpa/org-20160425/ox-publish hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-publish
/home/nlj/.emacs.d/elpa/org-20160425/ob-java hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-java
/home/nlj/.emacs.d/elpa/org-20160425/ob-sqlite hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sqlite
/home/nlj/.emacs.d/elpa/org-20160425/org-mhe hides /data/projects/vc/emacs/git/emacs/lisp/org/org-mhe
/home/nlj/.emacs.d/elpa/org-20160425/ox-org hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-org
/home/nlj/.emacs.d/elpa/org-20160425/ob-R hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-R
/home/nlj/.emacs.d/elpa/org-20160425/ob-lob hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lob
/home/nlj/.emacs.d/elpa/org-20160425/ob-picolisp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-picolisp
/home/nlj/.emacs.d/elpa/org-20160425/org-agenda hides /data/projects/vc/emacs/git/emacs/lisp/org/org-agenda
/home/nlj/.emacs.d/elpa/org-20160425/ob-matlab hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-matlab
/home/nlj/.emacs.d/elpa/org-20160425/org-gnus hides /data/projects/vc/emacs/git/emacs/lisp/org/org-gnus
/home/nlj/.emacs.d/elpa/org-20160425/org-macs hides /data/projects/vc/emacs/git/emacs/lisp/org/org-macs
/home/nlj/.emacs.d/elpa/org-20160425/org-id hides /data/projects/vc/emacs/git/emacs/lisp/org/org-id
/home/nlj/.emacs.d/elpa/org-20160425/ob-keys hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-keys
/home/nlj/.emacs.d/elpa/org-20160425/ob-comint hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-comint
/home/nlj/.emacs.d/elpa/org-20160425/ob-ref hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ref
/home/nlj/.emacs.d/elpa/org-20160425/org-bbdb hides /data/projects/vc/emacs/git/emacs/lisp/org/org-bbdb
/home/nlj/.emacs.d/elpa/org-20160425/ob-calc hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-calc
/home/nlj/.emacs.d/elpa/org-20160425/ob-emacs-lisp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-emacs-lisp
/home/nlj/.emacs.d/elpa/org-20160425/ob-maxima hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-maxima
/home/nlj/.emacs.d/elpa/org-20160425/org-plot hides /data/projects/vc/emacs/git/emacs/lisp/org/org-plot
/home/nlj/.emacs.d/elpa/soap-client-3.1.1/soap-inspect hides /data/projects/vc/emacs/git/emacs/lisp/net/soap-inspect
/home/nlj/.emacs.d/elpa/soap-client-3.1.1/soap-client hides /data/projects/vc/emacs/git/emacs/lisp/net/soap-client
~/.emacs.d/modules/emms/lisp/tq hides /data/projects/vc/emacs/git/emacs/lisp/emacs-lisp/tq

Features:
(shadow bbdb-message mail-extr emacsbug sendmail iso-transl ibuf-ext
ibuffer nndraft nnmh utf-7 server pinentry epa-file epa derived
network-stream nsm starttls nnfolder bbdb-gnus bbdb-mua nnnil gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp gnus-cache
latexenc preview prv-emacs font-latex latex tex-style sage-latex tex-buf
tex dbus xml tex-mode shell flyspell ispell sage sage-load rx
emms-bookmarks emms-cue emms-mode-line-icon emms-browser sort
emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd
emms-playing-time emms-lyrics emms-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source eieio eieio-core url-vars emms-streams
emms-tag-editor emms-mark emms-mode-line emms-cache emms-info-ogginfo
emms-info-mp3info emms-info later-do emms-playlist-mode emms-player-vlc
emms-player-mplayer emms-player-simple emms-source-playlist
emms-source-file locate emms-setup emms emms-compat org-contacts cl-seq
org-capture gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source tls gnutls utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message cl-macs rfc822 mml mml-sec password-cache epg
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums gmm-utils mailheader gnus-win gnus gnus-ems nnheader
mail-utils mm-util help-fns mail-prsvr cl org-rmail org-mhe org-irc
org-info org-gnus gnus-util org-docview doc-view subr-x dired org-bibtex
bibtex org-bbdb org-w3m org-agenda org-pdfview org-element avl-tree
pdf-tools compile cus-edit pdf-view bookmark pp jka-compr pdf-cache
pdf-info tq pdf-util image-mode org advice org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func bbdb-anniv
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs bbdb-com crm
mailabbrev bbdb bbdb-site timezone bbdb-loaddefs finder-inf tex-site
info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode cconv edmacro kmacro recentf tree-widget wid-edit easymenu
battery time wheatgrass-theme paren savehist saveplace elec-pair desktop
frameset cl-loaddefs pcase cl-lib delsel cus-start cus-load time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 1285020 206650)
 (symbols 48 108661 0)
 (miscs 40 8794 7040)
 (strings 32 198434 9049)
 (string-bytes 1 6064752)
 (vectors 16 49290)
 (vector-slots 8 1235993 34663)
 (floats 8 646 569)
 (intervals 56 212801 107)
 (buffers 976 48)
 (heap 1024 154470 18395))

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Paul Eggert]

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

Thanks, I reproduced the problem and yes, it is wayyy too slow. Also, 
the code in question has some FIXMEs that have not been fixed. Since 
we're trying to push out a new release, at this point we should probably 
revert the relevant change and think about how to do this sort of thing 
in a better way in a later release. Proposed patch attached.


[-- Attachment #2: 0001-Do-not-show-chars-in-C-x-8-RET-completions.patch --]
[-- Type: application/x-patch, Size: 1775 bytes --]

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Stefan Monnier]

> Thanks, I reproduced the problem and yes, it is wayyy too slow. Also, the
> code in question has some FIXMEs that have not been fixed. Since we're
> trying to push out a new release, at this point we should probably revert
> the relevant change and think about how to do this sort of thing in a better
> way in a later release. Proposed patch attached.

Seems like a better way forward is to add a config var, which defaults
to disabled.


        Stefan

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Drew Adams]

> Seems like a better way forward is to add a config var, which defaults
> to disabled.

+1 for the option.

But I think it should be enabled, not disabled, by default.

The typical, and generally better (IMO) reflex is to use a
good pattern to match, not just shoot blindly: C-x 8 RET TAB.
Exceptional users can easily disable it.  Most will take
advantage of it.  In practice, it shouldn't take much typing
to radically improve the performance.

IOW, if the main reason to disable it is for performance in
an extreme use case (C-x 8 RET TAB), then that should not
guide the default behavior.

(Of course, the choice of default behavior is much less
important than is the choice of letting users decide, by
giving them an option.)

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Paul Eggert]

Drew Adams wrote:
> if the main reason to disable it is for performance in
> an extreme use case (C-x 8 RET TAB)

It's not that extreme. It's natural for a user to get the whole list and then
use C-s to find the desired character.

Also, there's a problem even in less-"extreme" cases. I just now tried 'C-x 8
RET B TAB', which lists every character whose name starts with "B", and this
took about 18 s on my platform, whereas with Emacs 24.5 it is almost
instantaneous.  18 s is waayyy to slow for this sort of user interaction.

Stefan's suggestion of a config var sounds good. It's a bit late to be adding
features to the emacs-25 branch, though, so I'm inclined to revert in emacs-25
(with a "do not merge to master") and add a customizable var in master.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Drew Adams]

> > if the main reason to disable it is for performance in
> > an extreme use case (C-x 8 RET TAB)
> 
> It's not that extreme. It's natural for a user to get the
> whole list and then use C-s to find the desired character.

"Natural" or not is primarily opinion-based.

I sometimes do something similar, so yes, there are times
when you might want to do that.  I submit that someone who
does it regularly is exceptional however, hardly typical.

That is, asking Emacs, each time (or even most of the time
or much of the time), to show you all of the Unicode chars
along with their names, is exceptional.

There is nothing wrong with a user choosing _not_ to show
the chars by default - absolutely nothing.  The question is
what the _default_ Emacs behavior should be for users in
general.  (But the more important question is, again whether
to provide a user option.)

> Also, there's a problem even in less-"extreme" cases. I just
> now tried 'C-x 8 RET B TAB', which lists every character whose
> name starts with "B",

which filters out the _vast_ majority of candidates -
lots of them.  And that's just from typing ONE char.

> and this took about 18 s on my platform,

How long did `C-x 8 RET TAB' take? ;-)

Even just typing one char makes a huge difference.  Type
two and the difference is hugely huge.  Type three ...
four ...

> whereas with Emacs 24.5 it is almost instantaneous.

Isn't it almost instantaneous if the char display is
turned off (in Emacs 25)?  IOW, disabling the new
feature should provide the same performance as before.
If it does not then yes, there is likely a bug here to
be fixed.

But if it is the same, and the slowdown comes only from
displaying the named characters, then it is not clear
that there is a bug.  By displaying the chars you are
asking Emacs to do more work.

> 18 s is waayyy to slow for this sort of user interaction.

What sort of user interaction?  What do you expect, from
typing only `B'?  As you can see when you hit TAB after
`B', there are still lots of candidate chars, and you
are asking Emacs to display all of them.

> Stefan's suggestion of a config var sounds good.

Yes, it's obvious.  It should be a user config var,
IOW an option.

FWIW, I have some experience with this, as Icicles
has had a similar option for many years.  IMO, being
able to see the matching chars is extremely helpful
(and in the case of Icicles, it is enabled by default).

But of course if it is enabled then you might not want to
be doing things like `C-x 8 RET TAB' or `C-x 8 RET B TAB'.

And you might need to be told that, in the doc string.
And you certainly should be told about the option to
turn off such costly-but-useful behavior.

Using `C-x 8 RET TAB' and the like can be reasonable
(though still not very useful) when the option is
disabled.  But doing that makes ~zero sense when it
is enabled.  Users need to know this, yes.

And yes, there are other design possibilities, including,
say, treating the char display when it is enabled as if
it were disabled, until you've typed at least N chars.
In such a design, the non-nil option value could be a
number (min # of chars).

> It's a bit late to be adding features to the emacs-25
> branch, though, so I'm inclined to revert in emacs-25
> (with a "do not merge to master") and add a customizable
> var in master.

Add the user option.  And add some guidance to the doc.
I see no reason to revert the feature or to disable it
by default.

(But to be clear, I really don't care, personally - I use
Icicles.)

-- (FWIW #1) --

With Icicles, `C-x 8 RET B TAB' takes only about 1 sec,
not 18 sec.

Dunno why the difference from what you report.  Maybe it
has to do with the font used - mine shows a lot of the
hex rectangles for BALINESE*, BAMUM*, BRAHMI* etc. chars,
because my default font doesn't support them.  It shows
2093 candidates altogether.  Most of them do display the
char, not a hex rectangle, however.

`C-x 8 RET TAB' takes about 15 sec, for 38830 candidates.

And Icicles spends some extra time composing mouseover
text and mode-line text help.

(However, that's with Emacs 24.5.  I cannot use Emacs 25
for this because 25 crashes on me all the time.  But
unless the Emacs 25 code does something different for
`ucs-names' itself, it should not affect the Icicles code.
So I will expect the same kind of time, once I find an
Emacs 25 build that doesn't crash.)

-- (FWIW #2) --

Option doc.  (Note the bit of advice at the end, about _not_
doing things like `C-x 8 RET TAB'.)

--

 icicle-read-char-by-name-multi-completion-flag is a variable
 defined in `icicles-opt.el'.  Its value is t

 Documentation:
 Non-nil means `icicle-read-char-by-name' uses multi-completion.
 If nil then a candidate is just as in vanilla Emacs.
 If non-nil then it is a 3-part multi-completion: NAME CODE CHAR,
 showing three ways to represent the character as text:

 * NAME is the Unicode name
 * CODE is the Unicode code point, as a hexidecimal numeral
 * CHAR is the char itself (as it appears in text, not as an integer)

 In addition, if non-nil then properties `help-echo' and
 `icicle-mode-line-help' are put on NAME, showing both NAME and the
 code point (in hex, octal, and decimal).

 Setting this option to nil can speed up reading a character
 considerably, but it does not give you the advantages of seeing the
 character (WYSIWYG) or matching its code point.

 Instead of using a nil value, you can also speed things up by:
 * turning off incremental completion
 * choosing a strong input pattern, before asking for candidate
   matching.

 You can customize this variable.

--

(The behavior is not quite the same as for vanilla Emacs.
You can complete against the code point or even the displayed
char, not just against its name - or complete against any
combinations of the three.  You can, e.g., complete against
a char such as `;' to see its name and code point.)

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 25 Apr 2016 21:10:50 -0700
> Cc: "N. Jackson" <nljlistbox2@gmail.com>, 23377@debbugs.gnu.org
> 
> Drew Adams wrote:
> > if the main reason to disable it is for performance in
> > an extreme use case (C-x 8 RET TAB)
> 
> It's not that extreme. It's natural for a user to get the whole list and then
> use C-s to find the desired character.
> 
> Also, there's a problem even in less-"extreme" cases. I just now tried 'C-x 8
> RET B TAB', which lists every character whose name starts with "B", and this
> took about 18 s on my platform, whereas with Emacs 24.5 it is almost
> instantaneous.  18 s is waayyy to slow for this sort of user interaction.

It takes less than 2 sec here.  The original recipe takes 11 sec.
This is a 32-bit optimized build with wide ints, so a build without
that option should be even faster.  IOW, on a reasonably modern
platform and the default build options, the feature performs with
reasonable speed.  E.g., this:

  C-x C-f /foo/bar/ TAB TAB

takes 2.5 sec here for a /foo/bar/ with more than 3600 files.  So it's
not like we don't see slow completion sometimes.

> Stefan's suggestion of a config var sounds good. It's a bit late to be adding
> features to the emacs-25 branch, though, so I'm inclined to revert in emacs-25
> (with a "do not merge to master") and add a customizable var in master.

No, please don't revert; it's too late for that.  Adding an option is
okay, and it should be ON by default, to keep the behavior we had in
Emacs 25, including all the pretests, until now.  A NEWS entry about
this would also be nice.

Btw, one way to make this much faster is install the fonts for the
characters that display as boxes with hex codepoints.  Emacs only
looks up fonts for characters it needs to display, and the latest
addition of Unicode added quite a few characters shown in the first
screen of *Completion*, which I suppose have no fonts on your systems
(I, too, don't have them).  In addition, Emacs 25 shows a larger
window for the *Completions* buffer by default, which also contributes
to the time it takes.

Thanks.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 25 Apr 2016 21:10:50 -0700
> Cc: "N. Jackson" <nljlistbox2@gmail.com>, 23377@debbugs.gnu.org
> 
> Drew Adams wrote:
> > if the main reason to disable it is for performance in
> > an extreme use case (C-x 8 RET TAB)
> 
> It's not that extreme. It's natural for a user to get the whole list and then
> use C-s to find the desired character.

It surprises me that this is perceived as "natural", for an Emacs
user.  Do they also use this when completing on file names or buffer
names?  I don't think so.  So why would we assume they do so in this
case?  There are more than 30K names in the list popped up by the
above; how is it "reasonable", let alone economical, to search that
huge list, instead of typing some string to narrow down the list of
completions?

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

The ability to see the characters as well as their names is very nice,
and I think it would be a shame to remove it from Emacs 25.1. Would it
really be so risky to add functionality to allow the user to toggle it
on and off?

Also, if the feature (of displaying the character glyphs in the list) is
enabled by default, would it be possible to print a message such as
"Preparing completions ..." (or something), when the list is long or
when the operation has already taken more than five seconds (or so)?
This would prevent user from feeling that Emacs has hung.

At 09:34 +0300 on Tuesday 2016-04-26, Eli Zaretskii wrote:
>
> It surprises me that this is perceived as "natural", for an Emacs
> user.

I don't think anyone would argue that this is the only natural way to
interact with completion. If one knows exactly what they are looking
for, the shorter the completion list is, the better. But "show me
everything!" is also a valid choice that's useful sometimes, and it too
is natural for greedy humans.

> Do they also use this when completing on file names or buffer names? I
> don't think so.

Actually yes. Sort of. When I'm completing for a file name and I really
have no recollection of what I named the file but I know what directory
(or even subtree) it's in, I'll complete to the directory and then
browse through the list in dired. And with buffers, I as often do `C-x
C-b' to see the whole list, as I do `C-x b'.

> So why would we assume they do so in this case?

No need to assume. I told you that I do so in my original posting of the
bug report.

I totally admit that this is not efficient, and as I start to use it
more often I'll start to remember the names of the characters I'm
looking for and will be able to use insert-char without browsing through
the list.

However, I think it's a bit unreasonable of you Eli, to expect other
Emacs users to be as efficient as you are!

So far I've used insert-char maybe six times since I learned of it
perhaps two years ago. And typically I find I have no idea of the name
of the character I'm looking for. (Is it ring, or loop, or circle, or
something else?) But, because I've found it before, I know where it is
in the complete completion list -- I know approximately how far to
scroll the buffer and I recognise the block of characters that are its
neighbours.

N.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Paul Eggert]

On 04/26/2016 06:27 AM, N. Jackson wrote:
> would it be possible to print a message such as
> "Preparing completions ..." (or something), when the list is long

That should already happen. At least, it happens for me; the message is 
"Making completion list...".

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

At 13:41 -0700 on Tuesday 2016-04-26, Paul Eggert wrote:
>
> On 04/26/2016 06:27 AM, N. Jackson wrote:
>> would it be possible to print a message such as
>> "Preparing completions ..." (or something), when the list is long
>
> That should already happen. At least, it happens for me; the message
> is "Making completion list...".

Right. I do get that here. Sorry about that -- I don't know what I was
thinking!

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Stefan Monnier]

> Stefan's suggestion of a config var sounds good. It's a bit late to be adding
> features to the emacs-25 branch, though,

It's not adding a feature.  It's disabling a feature with an easy to use
switch to re-enable it.
Don't make it a defcustom, just a defvar.


        Stefan

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Paul Eggert]

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

On 04/26/2016 04:51 AM, Stefan Monnier wrote:
> It's not adding a feature.  It's disabling a feature with an easy to use
> switch to re-enable it.
> Don't make it a defcustom, just a defvar.

OK, thanks, that's easy. Proposed patch (to emacs-25) attached.

On my platform the performance is pretty bad without this, even without 
listing all the characters. I particularly notice it when I run Emacs 
over X from my office to home, something that's normally quite 
tolerable. I had already noticed this performance problem, but hadn't 
gotten around to looking into it until N. Jackson's bug report made it 
clear I wasn't alone.

In the long run there are some things we can do to improve things (e.g., 
not compute menu items until displayed, not display those ugly boxed and 
useless hexadecimal numbers, use a better menu that lets users choose 
characters by shape rather than just by name, etc.) that could let us 
turn annotation on by default, but that all needs to wait until after 
Emacs 25 comes out.


[-- Attachment #2: 0001-insert-char-annotates-names-only-on-request.patch --]
[-- Type: application/x-patch, Size: 1900 bytes --]

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Drew Adams]

> not display those ugly boxed and useless hexadecimal numbers, 

They are not useless (and not particularly ugly).

Based on our experience with your over-the-top sensitivity
about what you perceived as "ugly" `...' quoting, we might
do well not to listen too much to your suggestions to remove
other things in Emacs that you find "ugly". ;-)

(In any case, removal of any sets of chars as completion
candidates should be under user control, not hard-coded.)

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Paul Eggert]

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

On 04/26/2016 09:04 AM, Drew Adams wrote:
>> not display those ugly boxed and useless hexadecimal numbers,
> They are not useless (and not particularly ugly).


I don't know, they are not particularly helpful in my setup, and they're 
hard to read (see attached for a sample). I had to wait maybe 20 seconds 
to get this screen, and it wasn't worth the wait.


[-- Attachment #2: unicode-completion.png --]
[-- Type: image/png, Size: 9906 bytes --]

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> Cc: "N. Jackson" <nljlistbox2@gmail.com>, 23377@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 26 Apr 2016 09:59:46 -0700
> 
> On 04/26/2016 09:04 AM, Drew Adams wrote:
> >> not display those ugly boxed and useless hexadecimal numbers,
> > They are not useless (and not particularly ugly).
> 
> 
> I don't know, they are not particularly helpful in my setup

They tell you what character was supposed to be displayed.

> and they're hard to read (see attached for a sample).

They aren't hard to read on my system.

> I had to wait maybe 20 seconds to get this screen, and it wasn't
> worth the wait.

The wait is because Emacs looks for suitable fonts, not because it
displays these boxes.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

At 09:59 -0700 on Tuesday 2016-04-26, Paul Eggert wrote:
>
> On 04/26/2016 09:04 AM, Drew Adams wrote:
>>> not display those ugly boxed and useless hexadecimal numbers,
>> They are not useless (and not particularly ugly).
>
> I don't know, they are not particularly helpful in my setup, and
> they're hard to read (see attached for a sample).

Well there's always C-x C-+ C-+ C-+ C-+. (I need to increase the size
four times in my set up to be able to make out what the numbers are. But
that makes the glyphs for the characters for which I do have fonts much
much easier to see as well.)

And I think displaying the numeric codes for missing characters is
generally a very useful thing.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: Drew Adams <drew.adams@oracle.com>,  Stefan Monnier <monnier@iro.umontreal.ca>,  23377@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 26 Apr 2016 15:52:11 -0300
> 
> Well there's always C-x C-+ C-+ C-+ C-+. (I need to increase the size
> four times in my set up to be able to make out what the numbers are.

I don't need to increase them at all.  But if the default is too small
for you, you could customize the scale for the glyphless-char face
(e.g., to 0.8), perhaps that will make the numbers more easily
readable.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

At 22:10 +0300 on Tuesday 2016-04-26, Eli Zaretskii wrote:
>
> if the default is too small for you, you could customize the scale for
> the glyphless-char face (e.g., to 0.8)

Thank you for pointing out this option. I have set it to 0.99 and now
the numbers are quite readable.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Drew Adams]

> Well there's always C-x C-+ C-+ C-+ C-+. (I need to increase the size
> four times in my set up to be able to make out what the numbers are.

(You must first select window *Completions*, unless you
use Icicles.  You can't just use those keys from the
minibuffer to scale *Completions*.)

FWIW, a useful Icicles feature in this context is that
*Completions*, if in a separate frame (e.g., dedicated),
uses the same font as the window that was selected when
*Completions* was displayed.  E.g., if that window uses
a font tailored to a specific locale or set of Unicode
chars *Completions* shows candidates in that font.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> Cc: Drew Adams <drew.adams@oracle.com>, "N. Jackson" <nljlistbox2@gmail.com>,
>  23377@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 26 Apr 2016 08:49:39 -0700
> 
> On 04/26/2016 04:51 AM, Stefan Monnier wrote:
> > It's not adding a feature.  It's disabling a feature with an easy to use
> > switch to re-enable it.
> > Don't make it a defcustom, just a defvar.
> 
> OK, thanks, that's easy. Proposed patch (to emacs-25) attached.

The patch is okay for emacs-25, but the default value of the variable
should be non-nil.

Thanks.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> The patch is okay for emacs-25, but the default value of the variable should
> be non-nil.

Agreed.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Paul Eggert]

On 04/26/2016 04:58 PM, John Wiegley wrote:
>> >The patch is okay for emacs-25, but the default value of the variable should
>> >be non-nil.
> Agreed.

In that case I'd rather not install the patch. The user interface is 
quite bad in common use by ordinary users, and if we're not going to fix 
this then there's little advantage (and arguably even some disadvantage) 
to supplying an optional workaround that only experts would know about 
or use.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Lars Magne Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> In that case I'd rather not install the patch. The user interface is
> quite bad in common use by ordinary users, and if we're not going to
> fix this then there's little advantage (and arguably even some
> disadvantage) to supplying an optional workaround that only experts
> would know about or use.

If I type `M-x insert-char TAB' on this machines, that takes 17 seconds
to complete on this machine.  That's kinda unusable.  I think the patch
should be installed, and the default should be nil, and then somebody
can figure out how to make this feature work in a reasonable manner on
GNU/Linux systems for Emacs 26.

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

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If I type `M-x insert-char TAB' on this machines, that takes 17 seconds to
> complete on this machine. That's kinda unusable. I think the patch should be
> installed, and the default should be nil, and then somebody can figure out
> how to make this feature work in a reasonable manner on GNU/Linux systems
> for Emacs 26.

So in what contexts is this feature actually a feature? I missed that part.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  Eli Zaretskii <eliz@gnu.org>,  nljlistbox2@gmail.com,  monnier@iro.umontreal.ca,  23377@debbugs.gnu.org
> Date: Tue, 26 Apr 2016 21:19:02 -0400
> 
> >>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > If I type `M-x insert-char TAB' on this machines, that takes 17 seconds to
> > complete on this machine. That's kinda unusable. I think the patch should be
> > installed, and the default should be nil, and then somebody can figure out
> > how to make this feature work in a reasonable manner on GNU/Linux systems
> > for Emacs 26.
> 
> So in what contexts is this feature actually a feature? I missed that part.

I hope Stefan will be able to answer that, as he introduced the
feature a year ago.

There was a long discussion at some point of how to facilitate
selection of characters to insert, if you don't know their exact name
or codepoint, so I presume this feature was supposed to help in that
area.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Stefan Monnier]

> I hope Stefan will be able to answer that, as he introduced the
> feature a year ago.

Just so you can see what the char looks like.  It's not always obvious
from its name.  I think it's a pretty obviously desirable feature.

But in my case at least it wouldn't be worth waiting a minute to see those
chars, so I'm perfectly OK with disabling it by default (on my machines
it doesn't take very long to show up, so I'll enable it in my ~/.emacs).

> There was a long discussion at some point of how to facilitate
> selection of characters to insert, if you don't know their exact name
> or codepoint, so I presume this feature was supposed to help in that
> area.

The feature predates this discussion, but indeed it goes in the same
direction (tho I think the discussion was aimed more at choosing based
on broad categories first, then the char's appearance, so the
*Completions* list of `C-x 8 RET` is pretty far from that, showing only
a single char per line, with no grouping into categories).


        Stefan

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[John Wiegley]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> But in my case at least it wouldn't be worth waiting a minute to see those
> chars, so I'm perfectly OK with disabling it by default (on my machines it
> doesn't take very long to show up, so I'll enable it in my ~/.emacs).

I think it should be a customizable option, off by default.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Stefan Monnier]

> listing all the characters. I particularly notice it when I run Emacs over
> X from my office to home, something that's normally quite tolerable. I had

Sounds like the main problem comes from the use of old
server-side fonts.

What happens if you do

    (add-to-list 'default-frame-alist '(font-backend xft))

so as to remove the `x' font backend?


        Stefan

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Mon, 25 Apr 2016 21:25:28 -0300
> 
> emacs -Q
> C-x 8 RET TAB
> 
> This takes over a minute on my Emacs before the completions buffer is
> displayed listing the characters. (On subsequent invocations, it's more
> like eight seconds.) On Emacs 24 it is effectively instantaneous.

It takes 11 sec here on the first invocation, and is instantaneous
thereafter.

> There seems to have been a change whereby the character is shown besides
> it's name. This might be a very nice feature, except that it's too slow,
> and it seems a bit of a waste because a large proportion of the
> characters are unavailable and are shown as little boxes with tiny
> numbers inside.

If you install additional fonts, the feature will not be wasted, I
suppose.

> Perhaps there should be a way to turn this feature off? (I don't see
> anything about insert-char in NEWS.)

Yes, an option to turn this off is a good idea, I think.

> By the way, yes, this is the way I usually use this command. I hit TAB
> immediately to get a full list of characters and then `C-x o C-x 1'
> because I don't use special characters often enough to remember their
> names and I need to get thoroughly immersed in the whole list to see the
> naming patterns again and jog my memory.

That doesn't really work for me, FWIW.  For example, try deciding
which quotation character do you need by typing

  C-x 8 RET *QUOT TAB

If you don't see each character, you will be lost (I am).

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

At 09:26 +0300 on Tuesday 2016-04-26, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Mon, 25 Apr 2016 21:25:28 -0300
>> 
>> emacs -Q
>> C-x 8 RET TAB
>> 
>> This takes over a minute on my Emacs before the completions buffer is
>> displayed listing the characters. (On subsequent invocations, it's more
>> like eight seconds.) On Emacs 24 it is effectively instantaneous.
>
> It takes 11 sec here on the first invocation, and is instantaneous
> thereafter.

I just rebuilt with -O3 and no (other) configure options. (The above was
with -O0 with checking turned on.)

With the new binary, with the recipe above, the buffer displays in six
or seven seconds. (It takes about the same amount of time on subsequent
invocations.) That isn't stellar, but it's not the huge problem I
reported before, when it was taking over a minute.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: 23377@debbugs.gnu.org
> Date: Tue, 26 Apr 2016 22:54:33 -0300
> 
> At 09:26 +0300 on Tuesday 2016-04-26, Eli Zaretskii wrote:
> 
> >> From: nljlistbox2@gmail.com (N. Jackson)
> >> Date: Mon, 25 Apr 2016 21:25:28 -0300
> >> 
> >> emacs -Q
> >> C-x 8 RET TAB
> >> 
> >> This takes over a minute on my Emacs before the completions buffer is
> >> displayed listing the characters. (On subsequent invocations, it's more
> >> like eight seconds.) On Emacs 24 it is effectively instantaneous.
> >
> > It takes 11 sec here on the first invocation, and is instantaneous
> > thereafter.
> 
> I just rebuilt with -O3 and no (other) configure options. (The above was
> with -O0 with checking turned on.)
> 
> With the new binary, with the recipe above, the buffer displays in six
> or seven seconds. (It takes about the same amount of time on subsequent
> invocations.) That isn't stellar, but it's not the huge problem I
> reported before, when it was taking over a minute.

So what's the consensus here: do we need an option for turning the
character display off, or don't we?

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

At 10:21 +0300 on Wednesday 2016-04-27, Eli Zaretskii wrote:
>
> So what's the consensus here: do we need an option for turning the
> character display off, or don't we?

In my opinion FWIW (about 1.5 cents?), being able to see the character
beside the name is too nice to give up for Emacs 25.1, but, at least
until the feature is further refined and/or performance is improved,
there needs to be a way to toggle it on and off.

N.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Noam Postavsky]

nljlistbox2@gmail.com (N. Jackson) writes:

> At 10:21 +0300 on Wednesday 2016-04-27, Eli Zaretskii wrote:
>>
>> So what's the consensus here: do we need an option for turning the
>> character display off, or don't we?
>
> In my opinion FWIW (about 1.5 cents?), being able to see the character
> beside the name is too nice to give up for Emacs 25.1, but, at least
> until the feature is further refined and/or performance is improved,
> there needs to be a way to toggle it on and off.

I think since Mark's patch from #28302 was applied the slowdown isn't as
bad, but some people were reporting much bigger waits (depending on
fonts I guess?) and I'm still seeing a noticable wait on the order of 1
or 2 seconds, so IMO having a toggle makes sense.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[N. Jackson]

At 12:40 -0400 on Saturday 2017-09-30, Noam Postavsky wrote:
>
> nljlistbox2@gmail.com (N. Jackson) writes:
>
>> At 10:21 +0300 on Wednesday 2016-04-27, Eli Zaretskii wrote:
>>>
>>> So what's the consensus here: do we need an option for turning
>>> the character display off, or don't we?
>>
>> In my opinion FWIW (about 1.5 cents?), being able to see the
>> character beside the name is too nice to give up for Emacs
>> 25.1, but, at least until the feature is further refined and/or
>> performance is improved, there needs to be a way to toggle it
>> on and off.
>
> I think since Mark's patch from #28302 was applied the slowdown
> isn't as bad, but some people were reporting much bigger waits
> (depending on fonts I guess?) and I'm still seeing a noticable
> wait on the order of 1 or 2 seconds, so IMO having a toggle
> makes sense.

I just retried my original recipe

  emacs -Q
  C-x 8 RET
  TAB

on the emacs-26 branch and indeed it is amazingly much faster --
about one second here.

It might be nice for those on older and slower hardware to have a
toggle, but it is no longer so obviously necessary.

N.

bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Lars Ingebrigtsen]

nljlistbox2@gmail.com (N. Jackson) writes:

> I just retried my original recipe
>
>   emacs -Q
>   C-x 8 RET
>   TAB
>
> on the emacs-26 branch and indeed it is amazingly much faster --
> about one second here.
>
> It might be nice for those on older and slower hardware to have a
> toggle, but it is no longer so obviously necessary.

This was a long thread, but I think the rough consensus was that we do
want the characters to be displayed by default, and now that that
display is faster, there's not much point in adding a customisation
option to switch it off.

So I'm closing this bug report.

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