Re: Renaming eglot -- or at least add an alias?

[João Távora]

Philip Kaludercic <philipk@posteo.net> writes:

>
> That being said, there are at least two points that should be considered
> before 29.1 is released:
>
> - The rebinding of `display-local-help'.  I don't get why this is
> done.

display-local-help is a generic at-point documentation facility.  It
comes with a default binding in the Emacs global map.  M-x eldoc does
not have a default binding (yet).  d-l-help is also a much poorer
version of what ElDoc is nowadays.  Contrary to ElDoc, there is no easy
way for Eglot to link d-l-help it up to LSP-provided documentation.

It's not fully accurate to say that Eglot rebinds `display-local-help`,
at least not permanently.  Rather, for the duration of Eglot's tenure
over the buffer(s), some settings known to work are applied including
binding the 'C-h .' key to an ElDoc command.

A demanding user can override any of these settings.  Read
https://github.com/joaotavora/eglot/blob/master/MANUAL.md#overriding-eglots-choices

> - The custom mode-line modification instead of eglot being just another
>   minor mode item.

The information that Eglot displays in the mode-line is important to
signal if/how it is managing the buffer.  It could be grouped with the
other minor modes, but I felt that it would take up too much space and
look akward in that position, so I moved it to the side.

> > user should never completely forget that there is a language server
> > connection currently tied to some major modes of a project, and managing
> > those buffers.
> I am curious to hear why you think this should be.  Is it not preferable
> to make use of the tools the environment is providing instead of falling
> back on approximate heuristics like grepping for where a variable
> occurred or using TAGS-files for definitions and completion?

Of course, but I said nothing to the contrary.  I merely meant that it
is good for Eglot's user to remember that this enriched capability and
consistency is supported _transiently_ for a well-defined subset of the
buffers being worked on, and that potentially a third-party helper (the
language server program) must be installed to support more buffers.

There is a very broad applicability of Emacs to many types of uses and
very many language servers that may or not be available (probably won't
be by default).

The user should not assume that just by launching the Emacs editor, the
superior capability will be available all the time, because that
requires a piece that is not (and cannot easily be) bundled with Emacs.

You may, if you want, make an Emacs distribution with a narrower focus
on a specific application where the former is true.  See
https://portacle.github.io/, which brands itself as a "Common Lisp IDE".
There Emacs is bundled with SLIME and SLY turned on by default.

> We enthusiasts often overestimate the readiness of more casual users
> when it comes to remembering commands, bindings, packages, etc.

I think you underestimate users' ability (and maybe also your own?) to
remember a single 5 letter name.  Eglot has few commands, few
customization variables, no bindings.  It's as minimalist as I and those
who helped could make it.  For a beginner, M-x eglot is all there is to
it.

João