Re: [ELPA] New package: transient

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> >> 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.

>> I shouldn't have to do anything more than `str-mul TAB`.
> If you remembered the function's name, yes.  But that's not the use
> case we are discussing here.

I remember it's a string manipulating function and it has "multibyte"
in its name, so `str-mul` *should* find it (along with a few other
candidates, probably), even if I can't remember the whole name.

>> >> Yes, we can try and improve completion, but we have a real underlying
>> >> problem of irregular naming and completion would just help us paper
>> >> over it.
>> > The command "C-u C-h d regexp RET" brings up 111 matching functions.
>> > Who will have patience looking through that list, unless the likely
>> > candidates are near the beginning?
>> IIUC that means you agree with my argument?
> Of course not!  I'm saying that "regular naming" will increase the
> length of the candidate list.

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

Having a bit more or a bit less than 111 matches makes no difference: as
you say "who will have patience looking through that list"?  You need to
narrow down that list and the only way to do it (short of removing
existing functions) is to use a less permissive matching.

> 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.

>> It's not a new opinion, BTW: I started doing that back in Emacs-21 with
>> the newcomment.el package which tried to stick to the "comment-" prefix
>> even for things which previously used a different name.
> Beginner's luck.  Occasionally, this could just happen to work, when
> the package's name happens to say something about its purpose.  But
> mostly it doesn't, as packages like the one whose name is in the
> Subject clearly demonstrate.

No, the actual name is irrelevant to my argument.  What is relevant is
that the *same* name is used, so the functions are grouped together in
the namespace.


        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)."