Re: [ELPA] New package: transient

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,
>   address@hidden
> Date: Sat, 02 May 2020 16:39:57 -0400
> 
> >> >> Typical examples: is it `multibyte-string-p` or `string-multibyte-p`,
> >> >> `file-name-absolute-p` or `absolute-file-name-p`, ... ?
> >> > Then "C-u C-h a WORDS..." is your friend.
> >> Nope, way too slow.
> > Is that the only problem? then let's speed it up, and Bob's our uncle.
> 
> When I say "slow" I measure the time in number of hand movements.
> I'm in the middle of writing code, I might have already written `str`
> even and now I'd have to do `C-u C-h a str mul RET` and that will only
> display the answer, I still have to find it in the list and then arrange
> for it to make its way to my buffer.
> 
> Compared to `-mul TAB`, I can't see any way the `C-h` route could be
> even remotely competitive.

You seem to be measuring only the "speed" of your typing the input,
and disregard the time required to look over the results of the
completion or doc search and decide which is the one you want.  By
contrast, what's important for me is the total time it took me to
request the completion/search and find the answer I was looking for.
So if a few additional keystrokes will give me the answer much more
quickly and accurately, it is a net win for me.

> No, because it lets you use a more targeted (non-substring) matching, so
> you'll have much fewer matches.

I will believe this when I see it.  For now, the proposals that are
floating will bloat the list, not make it shorter, and the fuzzy
matching in completion tends to bring more matches, not less.  For me,
any list where I don't find what I'm looking for within the first 2
dozen entries is "too long", and I tend to abandon it and look for
alternative ways of finding what I want.

> > The prefix convention we impose has almost nothing to do with the
> > issue at hand, because the package's name in many (most?) cases says
> > nothing about its domain of application.  E.g., take message.el or
> > tmm.el or windmove.el or tempo.el or xdg.el, to name just a few random
> > examples.
> 
> That's only unhelpful in the case where you don't know the relevant
> prefix name.  In such a situation, you definitely need to resort to some
> kind of manual to find your way to relevant library.
> 
> A regular/structured naming system doesn't help for that, but it helps
> afterwards: once you know under which prefix things should be found,
> then you can find the relevant function more easily.

I'm talking about the packages we actually have, and your
counter-argument seems to be that "in a better world" these
difficulties wouldn't happen.  But in this world they do happen: how
can anyone remember whether some window-related function is in
window.el, winner.el, or windmove.el?  Are we supposed to learn all
that by heart?

>         Stefan "who finds this discussion enlightening, because he took
>                 it for granted that everyone knows that such structuring
>                 is *obviously* good (tho not necessarily always best)."

Maybe you should use and hack Emacs more ;-)

Years of using Emacs with its superb documentation and elaborate
facilities to find stuff in that documentation caused me to be more
demanding, to expect better documentation that is easier to access
quickly.  I might compromise if something like that is not available
when I'm working with other software, but I certainly don't want to
give that up when I work on Emacs!  And I'm astonished to hear that
people don't _want_ the documentation we provide and the help commands
to go with it, and are willing to settle for API completion!