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

[Stefan Monnier]

>>>> - The rebinding of `display-local-help'.  I don't get why this is done.
>>>
>> Oh... help-at-pt... yes that one needs love (and maybe integration with
>> eldoc-mode).
> Yes, precisely, integration.  Maybe its just a question of adding a
> default value of eldoc-documentation-functions that has help-at-pt's
> simplistic text-property-based logic.

I haven't looked at all that help-at-pt offers, but it does sound about right.

> Then rebinding C-h . to some eldoc entry point that targets the echo
> area only.

I can't see any reason why we should stick to the echo area only.

> if full compatibility isn't absolutely essential, I'd say 'C-h .' is
> a pretty good candidate to be bound to M-x eldoc.

Sounds about right as well.

>>> 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.
>>
>> I could also imagine auto-enabling Eglot when the circumstances are
>> right (e.g. when the major modes's own support code is not very well
>> developed, and when we can see that a good LSP server is available)
>> making even `M-x eglot` unnecessary.
>
> I'm on the fence about that.  If hypothetically we did that, the problem
> would be that launching a future such Emacs to edit source code of a
> given mode in two different machine -- one has the server, the other
> hasn't -- has too much discrepant behavior.  There are already other
> places where behavior is dependent on the availability of an external
> program, but I think it would be less pronouced than Eglot vs no-Eglot.

In any case, I think it's pretty hypothetical at this point.
There's no need yet to decide how we'll cross that bridge.


        Stefan