Re: Imports / inclusion of s.el into Emacs

[Philippe Vaucher]

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