Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Dmitry Gutov]

On 19.05.2020 23:56, João Távora wrote:

> > > "**company-clang is enabled by default**, and will interfere with clangd.
> > > Disable it in `M-x customize-variable RET company-backends RET`."
> > This is a different point than you originally made.
>
> Maybe you misunderstood me. But that warning is exactly, ipsis verbis,
> the reason I did what I had to do (override company-backends).

I'm saying that simply moving company to the core won't solve that 
problem (it will still need to support existing features).

I'm not sure how splitting out a "core" package would help if the "full" 
version depends on it, actually. Surely you are going to support the 
users of the "full" version as well? And they will have a longer list in 
`company-backends' by default.

> > > Really, even if just on github, why don't you create a `company-nocruft`
> > > package that only has capf support?
> > Because I have other things on my list, and because supporting different
> > versions of the same package is not as fun as someone might expect.
>
> But you're the one arguing for all-out modular and mini-package stuff for
> the others!  Your Company has become a mini-Emacs :-)

Nice reductio at absurdum. I never said every single file should be a 
separate package.

A decent guideline, in the commercial world at least, is to split 
project into services along organizational lines (e.g. one team = one 
service, very roughly speaking). There's nobody else who's going to 
maintain company-clang but me. In other cases, I do recommend people 
create and maintain their own packages. You might want to count the 
number of dependents on MELPA.

> > If you have free time for some documentation writing, help welcome.
>
> No thank you, but I _will_ help you split it into packages.

If it behaves sufficiently differently from company (as I recall you 
were planning), you might want to pick a different name.

For example, "solitude".

> > > > Yasnippet has been wildly successful without all that. It's the #1
> > > > standard snippet solution and format for Emacs. It's in GNU ELPA,
> > > > everybody can use and depend on it.
> > > What are you saying: major modes in the core _can't_.
> > What would they use in it?
>
> Hm? They would define snippets for the programming they support.
> Snippets that are active by default once you activate the major mode.

Or maybe they simply won't.

You might want to create a separate thread here with a vote and count 
the major mode maintainers who are in. :-)

> > > And just because it was successful in GNU ELPA doesn't me it can't
> > > be _more_ successful if developed in the core.  Below you say major
> > > modes in the core aren't maintained: well, maybe _because_ they
> > > can't tap into resources like Yasnippet.
> > Um, that's unlikely to play a big role.
>
> Well, we wouldn't know, would we?  A bit of history: I got seriously
> interested in Yasnippet because of TextMate. At the time, I did some
> Ruby and watched lots of screecasts, all had Textmate. Textmate had
> all the things: syntax, snippets, commands, menus out of the box.  I
> even tried to do that stuff with Yasnippet only, there's still some heroic
> (but working!) code that will take a Textmate "bundle" and put everything
> it has in the Yasnippet menu.

Good stuff.

> Many years after that, I'm still trying to achieve the same, but by
> integrating with existing code, instead of trying to cram
> Textmate stuff into Emacs. I know  you're going to say: "then
> put the major mode in ELPA and you can have your bundle", and
> I'll say  "OK, but let's develop it in the core".

I don't really mind the idea of putting snippet.el into the core. It 
sounds like a small, self-contained library, with limited scope. Perhaps 
some other core developers take interest, too.

But I don't see moving snippet definitions to major modes as inherently 
"right" or beneficial, because putting a lot of functionality in one 
place is not particularly flexible thing to do, it's like a huge 
function that does everything: when you need another function (e.g. 
major mode) to reuse some part of it, the design breaks.

I see your desire to offload some responsibility to major mode authors, 
and I can sympathize with that. But if the people on the other side 
don't pick it up (or pick it up but then forget), this won't work. 
Especially with eglot-server-programs.

> > Okay then, we'll go ahead and make everything into GNU ELPA packages.
> >
> > And /my plan/ will be two steps closer to fruition.
> >
> > *evil laugh*
>
> An evil laugh straight from dependency hell, evil indeed :-)
>
> Now seriously: not everything, but the things that we think will be updated
> often enough to benefit users between two major releases, sure, why not?

Indeed, why not. Were I supposed to argue against this? :-) The more 
developers think about ELPA, and take care to bump version numbers in 
their files, etc, the more acceptable the idea of "let's jump move to 
packages will become".

Not everybody might agree, though. You might notice that there's still 
no cc-mode package in there.

> > Could you please avoid referring to general statements by Eli until you
> > actually discuss some particulars?
> > "Let's provide features we can provide" as as sensible as it is
> > noncommittal.
>
> That's not what I wrote.
>
> Eli said that he wants CC mode to support syntax-highlighting
> and indentation from other sources, such as TreeSitter or LSP.
> LSP will soon support these things, along with many other things.

I'll have to see this first. And how reliable it is, and how much of it 
depends on VS Code's internals, etc. And actual language server support. 
But I'm repeating myself, from another thread.

> > > If Alan doesn't want to, then we'll make another C mode,
> > *insert another kind of laugh here*
>
> Don't be silly.  I'm not proposing we evict Alan.  But Emacs is about
> alternatives.

It was more of a weak, exasperated laugh. We couldn't evict Alan even if 
we wanted: CC Mode is a beast, and C++ is difficult enough to support 
that there haven't been any real alternatives, I think, ever.

sm-c-mode in GNU ELPA is a cute experiment that supports only a fraction 
of its features. Even for C, IIRC.

> > > Anyway, see eglot.el.  It has some, though I've been quite conservative,
> > > again, precisely _because_ that code doesn't belong in eglot.el.
> > Could you mention some symbol to search for, at least?
>
> OK. Rust and java stuff down the end of the file.  But the bug tracker
> is rife  with hacks that people use to get it working in other languages:
> I've been telling people to put them in their .emacs. But they belong in
> the major mode really.
>
> See also https://github.com/joaotavora/eglot/issues/363, for example.

From what I see it there, someone could/should make an RLS-specific 
plugin for Eglot. Not sure how major modes would help. There are several 
language servers for Rust, after all.

> See also the `;;; API (WORK-IN-PROGRESS!)` section in eglot.el. Every
> generic function that takes a server as an argument is a candidate
> for major mode tweaking.

Like generic functions. Suspicious on the idea of major mode specification.

> > > So you're describing the chicken and the egg.  Or look at the very large
> > > amount of mode-specific code that lsp-mode.el.  It also doesn't belong
> > > there.
> > That could be true. But if the Eglot team are best-positioned to write
> > that code, and to maintain it, you'll be the ones to do it anyway. Then
> > why split it across files, move it to major modes, etc?
>
> Why not? We do have your beautiful xref.el right?  Again Lisp is not
> Java hehe.
>
> Seriously, because that's where it belongs, at least the way that
> major-modes have been though of throughout the aeons.  If you want
> to change that fundamental property, you are fighting Emacs, in my
> opinion.  I want to find a Python file and start working in the best
> environment.

The only major mode that integrates with xref is emacs-lisp-mode, AFAIK 
(ok, and a couple of derivatives of it). All other integrations are in 
minor modes. That could probably tell you something.

> By the way this reminds me of a Medium thing I read this week
> where one users was fed up with VsCode asking to install packages
> for typing an Hello World in C++.

One user indeed.

> > > And do I really have to download clangd and xcode-specific code
> > > to my machine.
> > This pertaining to..?
>
> Company.  Did I put it out of context? Sorry.

I still don't understand what this is about. I don't have clangd or any 
xcode stuff on my machine, and I develop Company.

> > > GNU ELPA, as I keep saying.  The two things are completely
> > > unrelated, thankfully.
> > I'm just saying it's not an argument in favor of either of the options.
>
> It is if you want to rewrite or enhance flyspell, for example.
> Exactly  how I did flymake, a package that was injustly ridiculed
> to the point that someone made a "Flymake done right", tsk tsk

But you wouldn't rewrite Flyspell on rely on LSP only. It would still 
have to be extensible/flexible/open. So how would Eglot's presence help?

> > Do you like that Org is just its own microcosm, and basically never
> > extracts features?
>
> I think you know my answer to that.  But again, irrelevant.  Stuff
> doesn't happen by the truckload.

So you wouldn't even agree that it would make a lot of sense to move Org 
to ELPA? It's not even developed here.

> PS: this discussion is getting looong.

Yup.