> > * https://www.gnu.org/software/emacs/manual/html_node/elisp/Association-Lists.html sometimes
> > alist-get, assq, copy-alist. How am I supposed to use `C-h f alist TAB` to discover the function I
> want? I
> > can't, I have to go to that webpage and read it all.
> I think "C-h d alist RET" is your friend.
> You miss the central point of my argument.
I'm sorry to have missed that, but all I had was what you wrote:
How am I supposed to use `C-h f alist TAB` to discover the function
I think you're not noticing that in the list above "assq" and "assoc" are not findable using "alist".
> The problem is not that the doc is hard to find, it's that I *have* to
> find it to know which are the related functions.
If "alist" is not a keyword that could be used in this case, then what
is? "associaion list"? something else? When one tries to discover
functionality, one must start with something, we cannot start with
nothing, can we?
No no, I *want* to use "alist" but cannot because it's not properly namespaced.
Focusing on exceptions is again avoiding the central argument.
Let's take a simple example: shell-command-to-string. To which
"namespace" it should belong, in your opinion? It is relevant to
"shell", "commands", "programs", and "strings".
Under the "shell-" namespace is fine, the primary goal of this api is to run a shell command.
Anyway, to steelman your argument yes, for some fonctions it might be complicated, especially generic ones. There are various solutions to this but the main factor in finding them is to focus on the main argument of my proposal: there are lots of domains where my proposal makes a lot of sense: process-*, file-*, directory-*, buffer-*, etc. You could start by acknowledging this. For the generic fonctions, we can either namespace them under generic-*, or alias them for each namespace like "list-lenght", "vector-length" etc.
We could also not touch them at all and improve the rest where everyone agrees first, and focus on theses corner cases later.
I am sure that if other langages solved it we can too, let's not be in the "perfect solution" bias ;-)