unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: nljlistbox2@gmail.com (N. Jackson)
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23377@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>,
	monnier@IRO.UMontreal.CA
Subject: bug#23377: 25.0.93; Completion is extremely slow for insert-char
Date: Tue, 26 Apr 2016 10:27:18 -0300	[thread overview]
Message-ID: <87bn4wmrex.fsf@gmail.com> (raw)
In-Reply-To: <83k2jk27zq.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 26 Apr 2016 09:34:49 +0300")

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.






  reply	other threads:[~2016-04-26 13:27 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26  0:25 bug#23377: 25.0.93; Completion is extremely slow for insert-char N. Jackson
2016-04-26  1:04 ` Paul Eggert
2016-04-26  2:17   ` Stefan Monnier
2016-04-26  2:51     ` Drew Adams
2016-04-26  4:10       ` Paul Eggert
2016-04-26  5:43         ` Drew Adams
2016-04-26  6:21         ` Eli Zaretskii
2016-04-26  6:34         ` Eli Zaretskii
2016-04-26 13:27           ` N. Jackson [this message]
2016-04-26 20:41             ` Paul Eggert
2016-04-27  1:31               ` N. Jackson
2016-04-26 11:51         ` Stefan Monnier
2016-04-26 15:49           ` Paul Eggert
2016-04-26 16:04             ` Drew Adams
2016-04-26 16:59               ` Paul Eggert
2016-04-26 17:15                 ` Eli Zaretskii
2016-04-26 18:52                 ` N. Jackson
2016-04-26 19:10                   ` Eli Zaretskii
2016-04-27  2:09                     ` N. Jackson
     [not found]                   ` <<83r3dsyynq.fsf@gnu.org>
2016-04-26 20:18                     ` Drew Adams
2016-04-26 16:27             ` Eli Zaretskii
2016-04-26 23:58               ` John Wiegley
2016-04-27  0:26                 ` Paul Eggert
2016-04-27  0:53                   ` Lars Magne Ingebrigtsen
2016-04-27  1:19                     ` John Wiegley
2016-04-27  7:24                       ` Eli Zaretskii
2016-04-27 12:27                         ` Stefan Monnier
2016-04-27 19:04                           ` John Wiegley
2016-04-27  0:10             ` Stefan Monnier
2016-04-26  6:26 ` Eli Zaretskii
2016-04-27  1:54   ` N. Jackson
2016-04-27  7:21     ` Eli Zaretskii
2016-04-27 15:16       ` N. Jackson
2017-09-30 16:40         ` Noam Postavsky
2017-09-30 20:27           ` N. Jackson
2019-06-25 13:53             ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bn4wmrex.fsf@gmail.com \
    --to=nljlistbox2@gmail.com \
    --cc=23377@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).