Re: Imports / inclusion of s.el into Emacs

[João Távora]

On Tue, May 5, 2020 at 5:47 PM 조성빈 <address@hidden> wrote:
>
> João Távora <address@hidden> 작성:
>
> > On Tue, May 5, 2020 at 2:55 PM 조성빈 <address@hidden> wrote:
> >
> >> I’m not saying only about completion - I was thinking about things
> >> like how C-h f isn’t really useful for function finding and we
> >> should use C-h a and C-h d.
> >
> > But I'm saying it _is_ useful. It IS useful to me. With flex.
>
> Yes, that’s true, but flex, while is super useful (and I’m grateful to you
> developing it), is still a hack that exists because the function names don’t
> have good rules. (Why should everybody use flex, just to find functions?)

Good question. Because one can use flex for every idiosyncratically
named out there, which is the majority, not just functions, or at least
not just the very small subset of functions we use in the core.

Again, it's languages with built-in namespaces or implicit
OO namespaces like Ruby, C++ , Java, etc that give you the
illusion that things can be like that in Lisp. But they can't.
_Especially_ in Elisp, which has a big shared namespace.

(BTW I very much appreciate that you like flex. You're welcome.)

> However, IMO the fact that you can now search functions in C-h f a bit easily
> doesn't mean that the functions can be less consistent.

I'm not proposing we make new name inconsistent. I'm proposing
we don't touch the names we've already done.  Or that we touch
them very cautiously.

> > For new domains, surely?
> ------------------------------------------------------------------------------
> Well, Elisp will gain some more core APIs in the future, so I was thinking
> about that, but except from package prefixes, wouldn’t it be similar?

OK, a new core API (say thread-support, or emoji-support)  is a new
"domain" (again, it is kinda hard to draw the line because one big
namespace).

> How do you think about this:
>
> > I think some preliminary conventions that Elisp already follows is that the
> > <action>-<object> scheme is for actions on the object like rename-file or
> > clear-string, and <object>-<property> scheme is for getting properties of
> > the
> > object like string-width and file-name-extension. (I’m not considering
> > polymorphic ones.)
> >
> > But then there are exceptions, like string-trim (which should then be
> > trim-string) or string-join (which should then be join-string).

It's not bad. You could program Common Lisp with that, but in Elisp
goes against Stefan's rule which is: always prefix by the name
of the file. But even if we ignore it, it's hard. Say I'm writing a library
for music files,  a music.el.  I want a function to play a piece of music.
Should I name it play-music or music-play or music-play-music?
Whoever wrote package-list-packages, package-menu-hide-package,
package-install, describe-package, list-packages must have had
nightmares  with this. I shiver every time I see those names popup
in my minibufer.

A true story: some people in CL like to suffix all slot accessors with
"-OF". NAME-OF, TYPE-OF, etc. I did that for a while, but now I don't
do it. It's just silly. Once you start doing  it, it's disappointing not to
see it consistently applied everywhere.

You can't "tame" names in Lisp, is my feeling.

João