GNU bug report logs -
#36454
26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>
Previous Next
Reported by: VanL <van <at> scratch.space>
Date: Mon, 1 Jul 2019 02:40:02 UTC
Severity: wishlist
Tags: wontfix
Found in version 26.2.90
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #48 received at 36454 <at> debbugs.gnu.org (full text, mbox):
> > > I hope we agree that wading through 170 completion candidates, let
> > > alone 500, is not very convenient, yes?
> >
> > No, we don't agree that 500 completion candidates
> > is a problem.
>
> I'm surprised to hear that, but maybe I shouldn't.
It's not a problem if you can easily filter to narrow
the choices. That's the key. Seeing that there are
initially 500 matches, and seeing the kinds of matches
they are, gives you an interactive, quick, incremental
idea how you might want to further narrow the field.
But certainly, if you do NOT have a good, quick,
powerful way to narrow further then yes, 500 candidates
is unwieldy. Even UIs that offer cycling among
candidates are inefficient and nearly useless in such
a situation, IF they don't also allow for progressive
narrowing.
> > Completion is not just an aid for entering input.
> > It's a way to discover, browse, search, etc. a
> > set of information.
>
> Completion is a very poor means for discovery and browsing.
1. Even if that were true, it is not by itself an
argument against improving completion, including
for discovery and browsing.
2. I disagree that it is true. I would suggest/guess
that you just don't have sufficient experience with
a better completion UI than that offered by `emacs -Q'.
Ask users of Ivy or Helm whether they use completion
that way.
> If we want tools for discovering characters, we should have more powerful
> commands:
Nothing prevents _both_ better completion and other tools
for char (and other) discovery. It's not either-or,
logically. It may be either-or in terms of commitment of
resources to implement such choices.
No tool is the best tool for everything. And I don't
know anyone who would just reply " completion is the
answer" to every problem.
> list characters by their Unicode block, by their script, by
> their attributes, etc.
Couldn't agree more about the utility of such aids.
(Contributions are welcome, as some like to say.)
> Completion is not for all of that;
Completion is not the best tool for everything. Correct.
On the other hand, it's likely that any such additional
tools you might add could themselves also benefit from
better completion.
Ask an Ivy or Helm user whether and how completion
improves all kinds of existing Emacs commands, including
help and other information-provider commands such as
apropos and Info.
> it can be used for that, but with very low efficiency and user-friendliness.
That's too big a generalization to be helpful in this
discussion.
> So we should not judge the need for completion by considering any use
> cases other than just completion, i.e. finding a specific character or
> a small group of related characters.
Need? How about value and usefulness?
This bug report was last modified 5 years and 311 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.