GNU bug report logs - #65519
30.0.50; [FR Eglot] keymaps for useful functions

Previous Next

To reply to this bug, email your comments to 65519 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [FR Eglot] keymaps for useful functions
Date: Fri, 25 Aug 2023 08:46:42 +0200

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.

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

In GNU Emacs 30.0.50 (build 2, aarch64-apple-darwin22.6.0, NS
 appkit-2299.70 Version 13.5 (Build 22G74)) of 2023-08-24 built on
 Mini.fritz.box
Repository revision: 53c07bd04bf59f63e49af2c626714bf3fdd03ad6
Repository branch: scratch/pkg
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.5

Message #8 received at 65519 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 65519 <at> debbugs.gnu.org
Subject: Re: bug#65519: 30.0.50; [FR Eglot] keymaps for useful functions
Date: Fri, 25 Aug 2023 10:37:23 +0100

Gerd Möllmann <gerd.moellmann <at> 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

Message #11 received at 65519 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 65519 <at> debbugs.gnu.org
Subject: Re: bug#65519: 30.0.50; [FR Eglot] keymaps for useful functions
Date: Sat, 26 Aug 2023 07:20:26 +0200

João Távora <joaotavora <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> 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.

Ok.

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

You mean making an ELPA package? Sorry, that's too much effort for me.
Maybe someone else will do it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.