bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#65519: 30.0.50; [FR Eglot] keymaps for useful functions


From: João Távora
Subject: bug#65519: 30.0.50; [FR Eglot] keymaps for useful functions
Date: Fri, 25 Aug 2023 10:37:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> There are some useful eglot functions that can currently only invoked
> with M-x, by default.  I'm currently defining a keymap
>
> (define-keymap :prefix 'my-eglot-bindings
>   "a" 'eglot-code-actions
>   "f" 'eglot-format
>   "h" 'eglot-inlay-hints-mode
>   "r" 'eglot-rename)
>
> that I bind to a a prefix key in c-mode-common-hook.

I think this is a fine way to go about it.

> Feature request: Could eglot-mode do something like that?

This request comes up often.  The reason Eglot does this is partly
answered in the top bullet of eglot.el's description:

;; * Eglot's main job is to hook up the information that language
;;   servers offer via LSP to Emacs's UI facilities: Xref for
;;   definition-chasing, Flymake for diagnostics, Eldoc for at-point
;;   documentation, etc.  Eglot's job is generally *not* to provide
;;   such a UI itself, though a small number of simple
;;   counter-examples do exist, e.g. in the `eglot-rename' command or
;;   the `eglot-inlay-hints-mode' minor mode.  When a new UI is
;;   evidently needed, consider adding a new package to Emacs, or
;;   extending an existing one.

So this is how Eglot wants to sell itself: to be a low-profile
middle-man between Emacs and LSP.  It doesn't always work and people
understandibly want Eglot to be more of a front-man.

I try to resist this temptation as much as possible because that leads
to bloat and duplicated functionality with idiosyncractic interfaces.

So I always push for other "standard" packages to provide the UI.  But
as you can see in those 4 examples, I ended up being pragmatic and
putting the command in Eglot itself.

But it's not unthinkable (in fact, it's desired I think and I've looked
into it) that 'eglot-format' simply dissolves into Emacs's longstanding
'indent.el' machinery.  And there's some talk of a "refactoring
interface" for Emacs in emacs-devel (I think).  So that's where
'eglot-code-actions' and 'eglot-rename' should really live.

In short, I think it's OK to be pragmatic.  Why not make a
eglot-bindings.el package?

João





reply via email to

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