emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: Re: Renaming eglot -- or at least add an alias?
Date: Mon, 03 Oct 2022 17:35:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> - 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.  Then rebinding C-h . to some
eldoc entry point that targets the echo area only.  The latter can be
done with eldoc-display-functions, but if full compatibility isn't
absolutely essential, I'd say 'C-h .' is a pretty good candidate to be
bound to M-x eldoc.

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

João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]