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

[Dmitry Gutov]

On 22.05.2020 22:44, João Távora wrote:
> Dmitry Gutov <address@hidden> writes:
>
> > On 22.05.2020 17:32, João Távora wrote:
> > We're talking about this issue you mentioned:
> > https://github.com/joaotavora/eglot/issues/363
>
> I was talking about user reports about server bugs, but no matter we can
> talk bout what you want to talk.

This is the bug report you showed, and I made some extra observations.

> > The resolution there, it seems, is that the user must discover which
> > data, and in which format, to add to eglot-workspace-configuration for
> > stuff to work as expected.
> >
> > In the meantime (as I have just found out by doing a search), lsp-rust
> > both contains this setting at a reasonable default:
> >
> > https://github.com/emacs-lsp/lsp-mode/blob/057e8789638a0bf493930637185694b6b09ea58e/lsp-rust.el#L267
> >
> > ...and exposes the possible values of this setting in a
> > well-documented user option:
> >
> > https://github.com/emacs-lsp/lsp-mode/blob/057e8789638a0bf493930637185694b6b09ea58e/lsp-rust.el#L185
> >
> > So, which of these two approaches to development does look more
> > "integrated" to you?
>
> You know the answer: the one where one does the latter in rust-mode

I don't think that's what "integrated" means.

> This x-y.el way of working where x is the extension and y is the
> language is an explicit anti-goal.  I know you prefer it, you have in
> company, but I don't, I don't prefer it.

It's not like I prefer it. And I'm happy when delegating this stuff to 
major modes (via c-a-p-f) works. These particular responsibilities, 
however, the ones you want to delegate, are more technical, and require 
the knowledge of ecosystem more alien to Emacs, and the settings 
themselves will likely become outdated, or incomplete, on the regular basis.

OTOH, when a major mode provides a completion function that's outdated, 
users will install an extension that provides "better" completions (via 
company-backends or, again, c-a-p-f), and will consider it as a 
self-contained, distinct piece of improved functionality.

If the LSP settings are broken or outdated, however, the user are more 
likely to see that as Eglot being broken or obsolete.

> Of course, as you know, the whole point of LSP to start with is to make
> these obsolete.
Some basic idea was like that, maybe. But then the reality intervened. 
And people value features more than stability.

And I'm fairly sure language servers will continue to provide their 
ad-hoc extensions because different languages have different needs.