>
> > But when I'm discovering the API, it's a gold mine.
>
> Some of us are trying to tell you is that the Elisp manual is a
> gold mine, too. If you see parts where it is not, report it.
> Lisp languages are traditionally organized differently.
>

Thanks for the perspective. The parts where it is not is a gold mine is the
amount of hops we have to do:

Say I want to quickly remember how strings work in Emacs, how you
manipulate them, etc. With a few keystrokes I end up on
https://www.gnu.org/software/emacs/manual/html_node/elisp/Strings-and-Characters.html.
From there I have to select a topics, read it partially, go back, read
another topic, all that while skipping paragraphs most of the time (but
that can be improved with my keep-lines trick).

There is no manual entry where I see all these classified string functions
at once, and "C-h d string" makes my emacs so laggy that I cannot use it,
also most of the entries are irrelevant.

Now compare that to https://ruby-doc.org/core-2.6/String.html. Do you see
how faster that is or is just my lack of habit of using the manual? Or with
https://ruby-doc.org/core-2.6/Thread.html, see how you directly have an
example of common usage?

I guess you could argue that I'm not used to having to read big chunks of
text to get the information I'm looking for, that's I think a valid
criticism.


> If you like some "overview by topic" tool, you yourself have
> shown it can be built easily (in that "keep-lines" example).
> Let's do that first and then think it it's still worth including
> many new foreign words, not the reverse.


That's probably the path of least changes, I agree.

Design-wise I still think that Elisp would be a better language if it was
properly namespaced, given the language itself does not support namespaces.
But that's arguable even tho I think there are more strong points in favor
of using namespaces than against it.