Re: Imports / inclusion of s.el into Emacs

[조성빈]

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?)

> And
> your proposal will make it much less useful, and that's bad.


> > > I was answering Philippe, and he mentioned earlier that he's
> > > a big fan of "Convention over Configuration" a philosophy
> > > popularized in the 2000's by the RoR community.
> > I can’t see why CoC applies here - function names aren’t
> > ‘configuration’, right?
>
> No, but using `(setq completion-styles 'flex)` is. A pretty useful
> bit of it too.  Maybe you try it for a while? It works with Company,
> completion-at-point and, theoretically, with a new version of Helm.

In fact, I already use it - I use flex for both Company & Helm, it’s
wonderful. (As I have said already) Thanks for flex-completion, it’s super
useful to me.

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.

> You can also try M-x fido-mode.
>
> Anyway, CoC is what Phillipe brought up, not me. It's a RoR thing,
> and I was answering him.

Oh, I might have missed that. Sorry.

> And Convention is pretty good, sure,
> when you're starting from scratch.  So in your next new language,
> by all means, use the Best Convention (TM).
>
> > > Quite the contrary. I'm trying to convince you that it can
> > > work with closer to that if you work towards it without
> > > futzing up other people's, equally legitimate, ways of
> > > thinking about symbol names.
> >
> > Actually, IMO that ways of thinking symbol names should be
> > codified and be recommended - could you help in making some
> > emacs lisp API guidelines with that knowledge?
>
> 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?

> Like washing-machines.el or
> little-green-men.el?  Sure, I can do that.  I have my own
> conventions on how to name things (and they've changed
> over the years, a lot, and they will probably change until
> I'm dead.  I wouldn't recommend putting  a lot of weight in
> them, though. You can check my latest packages, like
> eglot.el or jsonrpc.el to see how I name things.

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

> João