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

[João Távora]

On Tue, May 19, 2020 at 8:38 PM Dmitry Gutov <address@hidden> 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).

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

> To do that, and to avoid confusing some of the users, I'd have to create
> some instructions on what C/C++ developers should use and in what cases.

Or just create those things as packages that depend on `company-nocruft`
(Yes I know "nocruft" is a cheeky name, just to make a point.  Call it
what you with, `company-base`.  Eglot would depend on that)

> If you have free time for some documentation writing, help welcome.

No thank you, but I _will_ help you split it into packages.

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

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

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

> > The lack of maintainers is not an argument for changing the place
> > where these things are maintained.  That's not magically going to
> > bring more maintainers.
>
> As far as Yasnippet is concerned, I'm not arguing to change things. You are.

I thought you were talking about major-modes, which Yasnippet is not.

Yasnippet would presumably maintain its one-man maintainership, Noam,
for which  I am very grateful.  It's Noam's call if Yasnippet stays in GitHub,
mind you.  But it's my call to propose snippet.el to the core, and I can't
imagine Noam saying no to offloading a big part of the snippet expansion
and navigation engine to another much cleaner package.

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

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

> > 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.  There's already another C mode in ELPA, I think.  No
C++ mode though, that's much harder to parse (and _that's_ why we
should offload this work).

> > Again, this fictional tragedy ignore the advent of :core GNU ELPA
> > packages.
> If we add every [important or fast-moving] core package to GNU ELPA,
> that could solve some problems indeed.

Yes.  Important or fast-moving sounds good.

> Mainly leaving organizational issues, like increasing the diffs mailing
> list traffic, the bug tracker load, and so on, the more packages we take
> in. And increasing the core's risks and commitments in unfortunate cases
> where the original authors leave.

I told you I was not going to discuss these things ;-)  And you agreed,
so don't mix up the discussions.

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

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.

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

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

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

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

> In theory, your statement makes sense. But I don't see any solid
> examples so far, as pertaining to packages under discussion. And only by
> considering examples in detail we can derive good rules.
>
> > Both approaches are defensible, of course.
> > But a mixed approach will tend to limp.
>
> This, however, is something good-sounding, but just as likely wrong as
> it is right. We could use some principles, however.
>
> Yes, I want Emacs to be modular, and I'm not the only one. But the
> degree of modularity, and the division lines, all should be driven by
> practical considerations.
>
> Do you like the current monolith?

And this is precisely where the problem is.  My answer to this
question is irrelevant, because I'm a very small part in the
development of Emacs, due to multiple reasons. Skills, time available,
etc.  So I try to work in a way that doesn't actively preempt future
migrations  to other architectures, but I don't refrain from working
inside the current architecture because I'm not conceptually
satisfied with what it could be if I could magically convince everyone
to think like me and spend an almost unlimited about of collective brain
power.

These is my rule-of-thumb: scratch my itch. If possible scratch
other's, and do it in a way that doesn't induce new itches to
others still.

> 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.  Look in your backyard :-) extract
that company-clang to a separate package :-)

> Eli asked why we never followed up on our "promises" to consider some
> packages for the core which we put into GNU ELPA. I explained that those
> packages likely didn't need that anyway. This is where this line of
> discussion came from.

Sorry, I might have missed some posts in this particular line

João

PS: this discussion is getting looong.