* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line @ 2024-06-28 14:13 Spencer Baugh 2024-06-28 14:15 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-06-28 14:13 UTC (permalink / raw To: 71823 1. emacs -Q 2. Open e.g. src/process.c in an Emacs git checkout named "emacs-30" 3. (setopt project-mode-line t) 4. Observe "emacs-30" is added to the modeline, naming the current project. 5. M-x eglot 6. Observe "[eglot:emacs-30]" is added to the modeline; the "emacs-30" part duplicates the project-mode-line. The project-name should be included only once; and since the project-mode-line entry is available in more places (e.g. it's available in dired, whereas eglot is not), that should be the one to be preserved. A patch to do this will follow. In GNU Emacs 31.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-06-28 built on igm-qws-u22796a Repository revision: d780a4d3aec82c96e12fa074d6bfc66599b95175 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.9 (Green Obsidian) Configured using: 'configure --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-cairo --with-rsvg --without-compress-install --with-native-compilation=aot --with-tree-sitter PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr compile comint ansi-osc ansi-color ring comp-run bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 110175 9082) (symbols 48 11064 0) (strings 32 30943 2909) (string-bytes 1 975127) (vectors 16 13768) (vector-slots 8 169832 8233) (floats 8 34 1) (intervals 56 453 15) (buffers 992 12)) ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-28 14:13 bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line Spencer Baugh @ 2024-06-28 14:15 ` Spencer Baugh 2024-06-28 14:40 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-06-28 14:15 UTC (permalink / raw To: 71823 [-- Attachment #1: Type: text/plain, Size: 21 bytes --] Patch fixing this: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Skip-eglot-project-name-when-project-mode-line-t.patch --] [-- Type: text/x-patch, Size: 2986 bytes --] From 928101e122725866ee95172730ebff03f4d54d5a Mon Sep 17 00:00:00 2001 From: Spencer Baugh <sbaugh@janestreet.com> Date: Fri, 28 Jun 2024 10:00:10 -0400 Subject: [PATCH] Skip eglot project-name when project-mode-line=t Both the eglot mode line entry and project-mode-line add project-name to the modeline. When both of them are enabled, this is unnecessary duplication. To fix, add the customization eglot-mode-line-project-name to allow disabling the project-name in eglot's mode-line entry. Furthermore, by default, set this customization so that eglot will check project-mode-line and omit the project-name if project-mode-line is non-nil. This allows a user to just set project-mode-line without having to separately customize eglot. * lisp/progmodes/eglot.el (eglot-mode-line-project-name): Add. (eglot--mode-line-format): Check eglot-mode-line-project-name. (bug#71823) --- lisp/progmodes/eglot.el | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index df4cbe50dc0..60e68b323f6 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -2237,10 +2237,29 @@ eglot--mode-line-props keymap ,map help-echo ,(concat prepend blurb) mouse-face mode-line-highlight)))) +(defcustom eglot-mode-line-project-name + (if (version< "30" emacs-version) + ;; The project mode-line entry was added to `mode-line-format' in + ;; Emacs 30; before that, `project-mode-line' has no effect. + 'unless-project-mode-line + nil) + "If non-nil, the eglot mode-line entry may contain `project-name'. + +If t, the eglot mode-line entry always contains `project-name'; if nil, +it never contains `project-name'. + +If the symbol `unless-project-mode-line', the eglot mode-line entry only +contains `project-name' if `project-mode-line' is nil. (This avoids +showing `project-name' in the modeline twice.)") + (defun eglot--mode-line-format () "Compose Eglot's mode-line." (let* ((server (eglot-current-server)) (nick (and server (eglot-project-nickname server))) + (use-nick (cl-case eglot-mode-line-project-name + (nil nil) + (unless-project-mode-line (not (bound-and-true-p project-mode-line))) + (t t))) (pending (and server (jsonrpc-continuation-count server))) (last-error (and server (jsonrpc-last-error server)))) (append @@ -2253,9 +2272,9 @@ eglot--mode-line-format (define-key map [mode-line down-mouse-1] eglot-menu) map))) (when nick - `(":" + `(,(if use-nick ":" "") ,(propertize - nick + (if use-nick nick ":") 'face 'eglot-mode-line 'mouse-face 'mode-line-highlight 'help-echo (format "Project '%s'\nmouse-1: LSP server control menu" nick) -- 2.39.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-28 14:15 ` Spencer Baugh @ 2024-06-28 14:40 ` Eli Zaretskii 2024-06-28 17:49 ` João Távora 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2024-06-28 14:40 UTC (permalink / raw To: Spencer Baugh, João Távora; +Cc: 71823 > From: Spencer Baugh <sbaugh@janestreet.com> > Date: Fri, 28 Jun 2024 10:15:45 -0400 > > >From 928101e122725866ee95172730ebff03f4d54d5a Mon Sep 17 00:00:00 2001 > From: Spencer Baugh <sbaugh@janestreet.com> > Date: Fri, 28 Jun 2024 10:00:10 -0400 > Subject: [PATCH] Skip eglot project-name when project-mode-line=t > > Both the eglot mode line entry and project-mode-line add > project-name to the modeline. When both of them are enabled, > this is unnecessary duplication. > > To fix, add the customization eglot-mode-line-project-name to > allow disabling the project-name in eglot's mode-line entry. > > Furthermore, by default, set this customization so that eglot > will check project-mode-line and omit the project-name if > project-mode-line is non-nil. This allows a user to just set > project-mode-line without having to separately customize eglot. > > * lisp/progmodes/eglot.el (eglot-mode-line-project-name): Add. > (eglot--mode-line-format): Check > eglot-mode-line-project-name. (bug#71823) > --- > lisp/progmodes/eglot.el | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) > > diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el > index df4cbe50dc0..60e68b323f6 100644 > --- a/lisp/progmodes/eglot.el > +++ b/lisp/progmodes/eglot.el > @@ -2237,10 +2237,29 @@ eglot--mode-line-props > keymap ,map help-echo ,(concat prepend blurb) > mouse-face mode-line-highlight)))) > > +(defcustom eglot-mode-line-project-name > + (if (version< "30" emacs-version) > + ;; The project mode-line entry was added to `mode-line-format' in > + ;; Emacs 30; before that, `project-mode-line' has no effect. > + 'unless-project-mode-line > + nil) > + "If non-nil, the eglot mode-line entry may contain `project-name'. > + > +If t, the eglot mode-line entry always contains `project-name'; if nil, > +it never contains `project-name'. > + > +If the symbol `unless-project-mode-line', the eglot mode-line entry only > +contains `project-name' if `project-mode-line' is nil. (This avoids > +showing `project-name' in the modeline twice.)") > + > (defun eglot--mode-line-format () > "Compose Eglot's mode-line." > (let* ((server (eglot-current-server)) > (nick (and server (eglot-project-nickname server))) > + (use-nick (cl-case eglot-mode-line-project-name > + (nil nil) > + (unless-project-mode-line (not (bound-and-true-p project-mode-line))) > + (t t))) > (pending (and server (jsonrpc-continuation-count server))) > (last-error (and server (jsonrpc-last-error server)))) > (append > @@ -2253,9 +2272,9 @@ eglot--mode-line-format > (define-key map [mode-line down-mouse-1] eglot-menu) > map))) > (when nick > - `(":" > + `(,(if use-nick ":" "") > ,(propertize > - nick > + (if use-nick nick ":") > 'face 'eglot-mode-line > 'mouse-face 'mode-line-highlight > 'help-echo (format "Project '%s'\nmouse-1: LSP server control menu" nick) > -- > 2.39.3 João, any comments? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-28 14:40 ` Eli Zaretskii @ 2024-06-28 17:49 ` João Távora 2024-06-28 22:08 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-06-28 17:49 UTC (permalink / raw To: Eli Zaretskii; +Cc: Spencer Baugh, 71823 On Fri, Jun 28, 2024 at 3:41 PM Eli Zaretskii <eliz@gnu.org> wrote: > João, any comments? Tiny switches for these customizations is not a good idea. It's complex, hard to find, and doesn't scale well For this and other use cases we need something more robust like in many packages, a user-customizable eglot-mode-line-format. You can e.g. use flymake-mode-like-format as an idea. Of course, the default value of eglot-mode-line-format would keep the Eglot mode-line exactly as it is. The default value would be something like ("[" eglot-mode-line-menu ":" eglot-mode-line-project-name eglot-mode-line-outstanding-requests "]") To fix this problem, users would just remove eglot-project-name from the var Many users want to get rid of the number of outstanding requests, this would help them too. Yet other users want to put the eglot mode-line menu somewhere else but without the brackets. You get the idea. Here's the Flymake default value, btw. João flymake-mode-line-format is a variable defined in `flymake.el'. Its value is (" " flymake-mode-line-exception flymake-mode-line-counters) Mode line construct for customizing Flymake information. This variable may be risky if used as a file-local variable. You can customize this variable. Probably introduced at or before Emacs version 28.1. [back] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-28 17:49 ` João Távora @ 2024-06-28 22:08 ` Spencer Baugh 2024-06-29 7:12 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-06-28 22:08 UTC (permalink / raw To: João Távora; +Cc: Eli Zaretskii, 71823 [-- Attachment #1: Type: text/plain, Size: 1289 bytes --] On Fri, Jun 28, 2024 at 1:49 PM João Távora <joaotavora@gmail.com> wrote: > On Fri, Jun 28, 2024 at 3:41 PM Eli Zaretskii <eliz@gnu.org> wrote: > > > João, any comments? > > Tiny switches for these customizations is not a good idea. It's complex, > hard to find, and doesn't scale well > > For this and other use cases we need something more robust like > in many packages, a user-customizable eglot-mode-line-format. You > can e.g. use flymake-mode-like-format as an idea. Of course, > the default value of eglot-mode-line-format would keep the > Eglot mode-line exactly as it is. > Yes, I agree. But my goal here isn't to make eglot-mode-line customizable, it's to add code to make the eglot mode line automatically avoid duplicating project-name. I figured some people might want to disable this code, so I made it customizable, but that customization is not essential. I'm happy to remove the customization, and just have the eglot modeline automatically remove the project-name when project-mode-line is set. That removes the need for any new customization variables, while still fixing the issue of duplication. Support for actual customization of the eglot mode line can be added later with an eglot-mode-line-format, as you suggest. [-- Attachment #2: Type: text/html, Size: 1734 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-28 22:08 ` Spencer Baugh @ 2024-06-29 7:12 ` Eli Zaretskii 2024-06-29 11:59 ` Dmitry Gutov 2024-06-29 12:05 ` João Távora 0 siblings, 2 replies; 30+ messages in thread From: Eli Zaretskii @ 2024-06-29 7:12 UTC (permalink / raw To: Spencer Baugh, Dmitry Gutov; +Cc: joaotavora, 71823 > From: Spencer Baugh <sbaugh@janestreet.com> > Date: Fri, 28 Jun 2024 18:08:41 -0400 > Cc: Eli Zaretskii <eliz@gnu.org>, 71823@debbugs.gnu.org > > On Fri, Jun 28, 2024 at 1:49 PM João Távora <joaotavora@gmail.com> wrote: > > On Fri, Jun 28, 2024 at 3:41 PM Eli Zaretskii <eliz@gnu.org> wrote: > > > João, any comments? > > Tiny switches for these customizations is not a good idea. It's complex, > hard to find, and doesn't scale well > > For this and other use cases we need something more robust like > in many packages, a user-customizable eglot-mode-line-format. You > can e.g. use flymake-mode-like-format as an idea. Of course, > the default value of eglot-mode-line-format would keep the > Eglot mode-line exactly as it is. > > Yes, I agree. > > But my goal here isn't to make eglot-mode-line customizable, it's to add code to make the eglot mode line > automatically avoid duplicating project-name. > > I figured some people might want to disable this code, so I made it customizable, but that customization is not > essential. I'm happy to remove the customization, and just have the eglot modeline automatically remove the > project-name when project-mode-line is set. That removes the need for any new customization variables, > while still fixing the issue of duplication. > > Support for actual customization of the eglot mode line can be added later with an eglot-mode-line-format, as > you suggest. Why not turn the table and consider this to be a problem of project.el, to be solved there? After all, the project-mode-line option belongs to project.el, so the fact that it adds the project name to the mode line too indiscriminately can legitimately be considered to be a problem with that option. Right? On top of that, project-mode-line is new in Emacs 30, whereas Eglot has been showing the project in its mode line before that. So once again, IMO the onus is on project.el to fix this somehow. For example, by not adding this to the mode line in Eglot-controlled buffers. Adding Dmitry to the discussion. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 7:12 ` Eli Zaretskii @ 2024-06-29 11:59 ` Dmitry Gutov 2024-06-29 12:43 ` Eli Zaretskii 2024-06-30 6:50 ` Juri Linkov 2024-06-29 12:05 ` João Távora 1 sibling, 2 replies; 30+ messages in thread From: Dmitry Gutov @ 2024-06-29 11:59 UTC (permalink / raw To: Eli Zaretskii, Spencer Baugh; +Cc: joaotavora, 71823, Juri Linkov On 29/06/2024 10:12, Eli Zaretskii wrote: > After all, the project-mode-line > option belongs to project.el, so the fact that it adds the project > name to the mode line too indiscriminately can legitimately be > considered to be a problem with that option. Right? It's "discriminate" and off by default. > On top of that, > project-mode-line is new in Emacs 30, whereas Eglot has been showing > the project in its mode line before that. So once again, IMO the onus > is on project.el to fix this somehow. For example, by not adding this > to the mode line in Eglot-controlled buffers. Hard-coding an "unless Eglot" condition seems like a bad idea in terms of abstraction and general code logic. But if you have some specific improvements to suggest, please go ahead. > Adding Dmitry to the discussion. Adding Juri as well. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 11:59 ` Dmitry Gutov @ 2024-06-29 12:43 ` Eli Zaretskii 2024-06-30 6:50 ` Juri Linkov 1 sibling, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2024-06-29 12:43 UTC (permalink / raw To: Dmitry Gutov; +Cc: sbaugh, joaotavora, 71823, juri > Date: Sat, 29 Jun 2024 14:59:10 +0300 > Cc: joaotavora@gmail.com, 71823@debbugs.gnu.org, Juri Linkov <juri@linkov.net> > From: Dmitry Gutov <dmitry@gutov.dev> > > On 29/06/2024 10:12, Eli Zaretskii wrote: > > After all, the project-mode-line > > option belongs to project.el, so the fact that it adds the project > > name to the mode line too indiscriminately can legitimately be > > considered to be a problem with that option. Right? > > It's "discriminate" In what way? > and off by default. Sure, I meant when the option is turned on. > > On top of that, > > project-mode-line is new in Emacs 30, whereas Eglot has been showing > > the project in its mode line before that. So once again, IMO the onus > > is on project.el to fix this somehow. For example, by not adding this > > to the mode line in Eglot-controlled buffers. > > Hard-coding an "unless Eglot" condition seems like a bad idea in terms > of abstraction and general code logic. I agree, but Spencer's patch did the same in the opposite direction. > But if you have some specific improvements to suggest, please go > ahead. I don't, but maybe someone else does. AFAIU, João suggested something like that as well. So we all agree about the way to solve it, and we "just" need a patch that implements such a solution. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 11:59 ` Dmitry Gutov 2024-06-29 12:43 ` Eli Zaretskii @ 2024-06-30 6:50 ` Juri Linkov 2024-06-30 10:25 ` João Távora 1 sibling, 1 reply; 30+ messages in thread From: Juri Linkov @ 2024-06-30 6:50 UTC (permalink / raw To: Dmitry Gutov; +Cc: Spencer Baugh, Eli Zaretskii, joaotavora, 71823 >> After all, the project-mode-line >> option belongs to project.el, so the fact that it adds the project >> name to the mode line too indiscriminately can legitimately be >> considered to be a problem with that option. Right? > > It's "discriminate" and off by default. > >> On top of that, >> project-mode-line is new in Emacs 30, whereas Eglot has been showing >> the project in its mode line before that. So once again, IMO the onus >> is on project.el to fix this somehow. For example, by not adding this >> to the mode line in Eglot-controlled buffers. > > Hard-coding an "unless Eglot" condition seems like a bad idea in terms of > abstraction and general code logic. I completely agree. When a user explicitly expressed the wish to display the project name in the middle of the mode line by customizing project-mode-line to t, this means there is no need to duplicate it at the end of the mode line with Eglot information. This will make the mode line shorter. Ideally, everything should be customizable by two new Eglot options: eglot-mode-line-format and eglot-mode-line-position (e.g. middle/end). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 6:50 ` Juri Linkov @ 2024-06-30 10:25 ` João Távora 0 siblings, 0 replies; 30+ messages in thread From: João Távora @ 2024-06-30 10:25 UTC (permalink / raw To: Juri Linkov; +Cc: Dmitry Gutov, Eli Zaretskii, 71823, Spencer Baugh [-- Attachment #1: Type: text/plain, Size: 605 bytes --] On Sun, Jun 30, 2024, 07:55 Juri Linkov <juri@linkov.net> wrote: > shorter. > > Ideally, everything should be customizable by two new Eglot options: > eglot-mode-line-format and eglot-mode-line-position (e.g. middle/end). > The second one is redundant. There is already ample machinery to juggle elements around in relation to other elements. But the first one is absolutely what's needed, and fixes other issues, so anyone should feel free to start working on it, the default value of course producing exactly what is seen now, perhaps with the "defer to protect" semantics. João > [-- Attachment #2: Type: text/html, Size: 1178 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 7:12 ` Eli Zaretskii 2024-06-29 11:59 ` Dmitry Gutov @ 2024-06-29 12:05 ` João Távora 2024-06-29 12:17 ` Dmitry Gutov 1 sibling, 1 reply; 30+ messages in thread From: João Távora @ 2024-06-29 12:05 UTC (permalink / raw To: Eli Zaretskii; +Cc: Spencer Baugh, 71823, Dmitry Gutov On Sat, Jun 29, 2024 at 8:12 AM Eli Zaretskii <eliz@gnu.org> wrote: > Why not turn the table and consider this to be a problem of > project.el, to be solved there? After all, the project-mode-line That could make sense (and this is nowhere near a serious problem IMHO), but I have to admit that saying the onus being on Eglot is also defensible. The project name is eminently project.el property after all. What Eglot is showing there is the "project nickname": it happens to coincide with the project name for now but in rigour it would be a mnemonic for a "project/language" tuple. So it's not exactly the same thing. I've just never found a good way to express that. > But my goal here isn't to make eglot-mode-line customizable, it's to add code to make the eglot mode line > automatically avoid duplicating project-name. I understand now, but I still think it's complex and makes the future eglot-mode-line-format implementation harder. In that mode-line-format the 'eglot-mlf-project' symbol could come paired with an optional 'eglot-mlf-project-maybe' that does the check you wnat. João ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 12:05 ` João Távora @ 2024-06-29 12:17 ` Dmitry Gutov 2024-06-29 12:21 ` João Távora 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2024-06-29 12:17 UTC (permalink / raw To: João Távora, Eli Zaretskii; +Cc: Spencer Baugh, 71823 On 29/06/2024 15:05, João Távora wrote: > On Sat, Jun 29, 2024 at 8:12 AM Eli Zaretskii<eliz@gnu.org> wrote: > >> Why not turn the table and consider this to be a problem of >> project.el, to be solved there? After all, the project-mode-line > That could make sense (and this is nowhere near a serious problem IMHO), > but I have to admit that saying the onus being on Eglot is also defensible. > The project name is eminently project.el property after all. What Eglot > is showing there is the "project nickname": it happens to coincide with > the project name for now but in rigour it would be a mnemonic for a > "project/language" tuple. So it's not exactly the same thing. I've > just never found a good way to express that. Either way, it might make sense for Eglot to check out that project.el's variable and choose the format accordingly. But an independent way to customize it in Eglot can work fine too (like the customizable mode-line you proposed). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 12:17 ` Dmitry Gutov @ 2024-06-29 12:21 ` João Távora 2024-06-29 12:41 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-06-29 12:21 UTC (permalink / raw To: Dmitry Gutov; +Cc: Spencer Baugh, Eli Zaretskii, 71823 On Sat, Jun 29, 2024 at 1:17 PM Dmitry Gutov <dmitry@gutov.dev> wrote: > Either way, it might make sense for Eglot to check out that project.el's > variable and choose the format accordingly. Yes, and that's what the proposed eglot-mlf-project-maybe element to the custom variable eglot-mode-line-format would do. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 12:21 ` João Távora @ 2024-06-29 12:41 ` Spencer Baugh 2024-06-29 14:24 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-06-29 12:41 UTC (permalink / raw To: João Távora; +Cc: Dmitry Gutov, Eli Zaretskii, 71823 [-- Attachment #1: Type: text/plain, Size: 694 bytes --] On Sat, Jun 29, 2024, 8:21 AM João Távora <joaotavora@gmail.com> wrote: > On Sat, Jun 29, 2024 at 1:17 PM Dmitry Gutov <dmitry@gutov.dev> wrote: > > > Either way, it might make sense for Eglot to check out that project.el's > > variable and choose the format accordingly. > > Yes, and that's what the proposed eglot-mlf-project-maybe element to > the custom variable eglot-mode-line-format would do. > In the new variable, I think eglot-mlf-project-maybe should be the default, since it's essentially always the better behavior. If you agree it should be the default in the future customizable variable, can we just make the change now when it's not customizable? > [-- Attachment #2: Type: text/html, Size: 1370 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 12:41 ` Spencer Baugh @ 2024-06-29 14:24 ` Spencer Baugh 2024-06-30 0:25 ` João Távora 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-06-29 14:24 UTC (permalink / raw To: João Távora; +Cc: Dmitry Gutov, Eli Zaretskii, 71823 [-- Attachment #1: Type: text/plain, Size: 1169 bytes --] On Sat, Jun 29, 2024, 8:41 AM Spencer Baugh <sbaugh@janestreet.com> wrote: > On Sat, Jun 29, 2024, 8:21 AM João Távora <joaotavora@gmail.com> wrote: > >> On Sat, Jun 29, 2024 at 1:17 PM Dmitry Gutov <dmitry@gutov.dev> wrote: >> >> > Either way, it might make sense for Eglot to check out that project.el's >> > variable and choose the format accordingly. >> >> Yes, and that's what the proposed eglot-mlf-project-maybe element to >> the custom variable eglot-mode-line-format would do. >> > > In the new variable, I think eglot-mlf-project-maybe should be the > default, since it's essentially always the better behavior. > > If you agree it should be the default in the future customizable variable, > can we just make the change now when it's not customizable? > Or, here's an alternative idea, more aggressive: What if Eglot just sets project-mode-line=t in eglot-managed buffers, and removes the project-name from the Eglot entry entirely? Then the language identifier would be the major mode, the project identifier would be project-mode-line, and the eglot status indicator would just be for the status of the server. > [-- Attachment #2: Type: text/html, Size: 2436 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-29 14:24 ` Spencer Baugh @ 2024-06-30 0:25 ` João Távora 2024-06-30 12:51 ` sbaugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-06-30 0:25 UTC (permalink / raw To: Spencer Baugh; +Cc: Dmitry Gutov, Eli Zaretskii, 71823 [-- Attachment #1: Type: text/plain, Size: 844 bytes --] On Sat, Jun 29, 2024, 15:24 Spencer Baugh <sbaugh@janestreet.com> wrote: > Or, here's an alternative idea, more aggressive: > > What if Eglot just sets project-mode-line=t in eglot-managed buffers, and > removes the project-name from the Eglot entry entirely? > > Then the language identifier would be the major mode, the project > identifier would be project-mode-line, and the eglot status indicator would > just be for the status of the server. > Works for me, it's in line with Eglot's policy of setting other modes when managing buffers. Show a patch. But also, my idea of eglot-mode-line-format should be alsoh considered. AFAICT there no big technical hurdle, it's just relatively boring work and some naming decisions to make. And as I mentioned, it would fix more issues than just the one at hand. João > [-- Attachment #2: Type: text/html, Size: 2416 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 0:25 ` João Távora @ 2024-06-30 12:51 ` sbaugh 2024-06-30 14:53 ` João Távora 2024-06-30 16:38 ` Juri Linkov 0 siblings, 2 replies; 30+ messages in thread From: sbaugh @ 2024-06-30 12:51 UTC (permalink / raw To: João Távora Cc: Spencer Baugh, Eli Zaretskii, Juri Linkov, 71823, Dmitry Gutov [-- Attachment #1: Type: text/plain, Size: 1857 bytes --] João Távora <joaotavora@gmail.com> writes: > On Sat, Jun 29, 2024, 15:24 Spencer Baugh <sbaugh@janestreet.com> wrote: > > Or, here's an alternative idea, more aggressive: > > What if Eglot just sets project-mode-line=t in eglot-managed buffers, and removes the project-name from the Eglot entry > entirely? > > Then the language identifier would be the major mode, the project identifier would be project-mode-line, and the eglot status > indicator would just be for the status of the server. > > Works for me, it's in line with Eglot's policy of setting other modes when managing buffers. Show a patch. Attached. I do think this is a great way to resolve this - now that project-mode-line exists, using it deletes one small bit of eglot-specific functionality, which is in line with the Eglot design philosophy. The only issue is that this was only added to mode-line-format in Emacs 30, so we can only use it in Emacs 30 or later. The attached patch detects that with: + (when (member '(project-mode-line project-mode-line-format) mode-line-format) but I'm also totally fine with: + (when (version<= "30" emacs-version) Or I guess we could sidestep the issue if project.el itself ensured, when loaded, that mode-line-format contains project-mode-line. eglot itself does this with eglot--mode-line-format, running the following at load time: (add-to-list 'mode-line-misc-info `(eglot--managed-mode (" [" eglot--mode-line-format "] "))) Juri, any opinion? > But also, my idea of eglot-mode-line-format should be alsoh considered. AFAICT there no big technical hurdle, it's just relatively > boring work and some naming decisions to make. And as I mentioned, it would fix more issues than just the one at hand. Yes, I think that would also be useful as a separate patch. [-- Attachment #2: 0001-Use-project-mode-line-for-the-project-nick-in-Eglot.patch --] [-- Type: text/x-diff, Size: 7226 bytes --] From 5b53ecc3db2356bcab3fd8b9d8583de6a6adcef2 Mon Sep 17 00:00:00 2001 From: Spencer Baugh <sbaugh@catern.com> Date: Sun, 30 Jun 2024 08:27:43 -0400 Subject: [PATCH] Use project-mode-line for the project nick in Eglot The existence of project-mode-line now means that eglot can have an indicator for the current project of the current buffer, without using the eglot mode-line entry to do it. This commit teaches eglot to (when possible) set project-mode-line true in eglot-managed buffers and remove project-name from the eglot mode line entry. * lisp/progmodes/eglot.el (eglot--managed-mode): Set project-mode-line if the project-mode-line entry is in mode-line-format. (eglot-menu): Always include eglot-server-menu as a submenu. (eglot--mode-line-format): Don't include project-name when project-mode-line is set. (bug#71823) --- lisp/progmodes/eglot.el | 74 ++++++++++++++++++++++------------------- 1 file changed, 39 insertions(+), 35 deletions(-) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index bb6b0281d9f..249dda7f3d8 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -7,7 +7,7 @@ ;; Maintainer: João Távora <joaotavora@gmail.com> ;; URL: https://github.com/joaotavora/eglot ;; Keywords: convenience, languages -;; Package-Requires: ((emacs "26.3") (compat "27.1") (eldoc "1.14.0") (external-completion "0.1") (flymake "1.2.1") (jsonrpc "1.0.24") (project "0.9.8") (seq "2.23") (track-changes "1.2") (xref "1.6.2")) +;; Package-Requires: ((emacs "26.3") (compat "27.1") (eldoc "1.14.0") (external-completion "0.1") (flymake "1.2.1") (jsonrpc "1.0.24") (project "0.11.0") (seq "2.23") (track-changes "1.2") (xref "1.6.2")) ;; This is a GNU ELPA :core package. Avoid adding functionality ;; that is not available in the version of Emacs recorded above or any @@ -2026,6 +2026,8 @@ eglot--managed-mode (eglot--setq-saving company-tooltip-align-annotations t) (eglot--setq-saving eldoc-documentation-strategy #'eldoc-documentation-compose) + (when (member '(project-mode-line project-mode-line-format) mode-line-format) + (setq-local project-mode-line t)) (unless (eglot--stay-out-of-p 'imenu) (add-function :before-until (local 'imenu-create-index-function) #'eglot-imenu)) @@ -2161,10 +2163,24 @@ eglot-upgrade-eglot (package-delete existing t)) (package-install (cadr (assoc 'eglot package-archive-contents))))) +(easy-menu-define eglot-server-menu nil "Monitor server communication" + '("Debugging the server communication" + ["Reconnect to server" eglot-reconnect] + ["Quit server" eglot-shutdown] + "--" + ["LSP events buffer" eglot-events-buffer] + ["Server stderr buffer" eglot-stderr-buffer] + ["Customize event buffer size" + (lambda () + (interactive) + (customize-variable 'eglot-events-buffer-size))])) + (easy-menu-define eglot-menu nil "Eglot" `("Eglot" ;; Commands for getting information and customization. ["Customize Eglot" (lambda () (interactive) (customize-group "eglot"))] + ["Server" eglot-server-menu + :active (eglot-current-server)] "--" ;; xref like commands. ["Find definitions" xref-find-definitions @@ -2211,18 +2227,6 @@ eglot-menu ["Quickfix" eglot-code-action-quickfix :visible (eglot-server-capable :codeActionProvider)])) -(easy-menu-define eglot-server-menu nil "Monitor server communication" - '("Debugging the server communication" - ["Reconnect to server" eglot-reconnect] - ["Quit server" eglot-shutdown] - "--" - ["LSP events buffer" eglot-events-buffer] - ["Server stderr buffer" eglot-stderr-buffer] - ["Customize event buffer size" - (lambda () - (interactive) - (customize-variable 'eglot-events-buffer-size))])) - (defun eglot--mode-line-props (thing face defs &optional prepend) "Helper for function `eglot--mode-line-format'. Uses THING, FACE, DEFS and PREPEND." @@ -2252,7 +2256,7 @@ eglot--mode-line-format 'keymap (let ((map (make-sparse-keymap))) (define-key map [mode-line down-mouse-1] eglot-menu) map))) - (when nick + (when (and nick (not project-mode-line)) `(":" ,(propertize nick @@ -2261,28 +2265,28 @@ eglot--mode-line-format 'help-echo (format "Project '%s'\nmouse-1: LSP server control menu" nick) 'keymap (let ((map (make-sparse-keymap))) (define-key map [mode-line down-mouse-1] eglot-server-menu) - map)) - ,@(when last-error - `("/" ,(eglot--mode-line-props - "error" 'compilation-mode-line-fail - '((mouse-3 eglot-clear-status "Clear this status")) - (format "An error occurred: %s\n" (plist-get last-error - :message))))) - ,@(when (cl-plusp pending) - `("/" ,(eglot--mode-line-props - (format "%d" pending) 'warning - '((mouse-3 eglot-forget-pending-continuations - "Forget pending continuations")) - "Number of outgoing, \ + map)))) + (when last-error + `("/" ,(eglot--mode-line-props + "error" 'compilation-mode-line-fail + '((mouse-3 eglot-clear-status "Clear this status")) + (format "An error occurred: %s\n" (plist-get last-error + :message))))) + (when (cl-plusp pending) + `("/" ,(eglot--mode-line-props + (format "%d" pending) 'warning + '((mouse-3 eglot-forget-pending-continuations + "Forget pending continuations")) + "Number of outgoing, \ still unanswered LSP requests to the server\n"))) - ,@(cl-loop for pr hash-values of (eglot--progress-reporters server) - when (eq (car pr) 'eglot--mode-line-reporter) - append `("/" ,(eglot--mode-line-props - (format "%s%%%%" (or (nth 4 pr) "?")) - 'eglot-mode-line - nil - (format "(%s) %s %s" (nth 1 pr) - (nth 2 pr) (nth 3 pr)))))))))) + (cl-loop for pr hash-values of (eglot--progress-reporters server) + when (eq (car pr) 'eglot--mode-line-reporter) + append `("/" ,(eglot--mode-line-props + (format "%s%%%%" (or (nth 4 pr) "?")) + 'eglot-mode-line + nil + (format "(%s) %s %s" (nth 1 pr) + (nth 2 pr) (nth 3 pr)))))))) (add-to-list 'mode-line-misc-info `(eglot--managed-mode (" [" eglot--mode-line-format "] "))) -- 2.44.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 12:51 ` sbaugh @ 2024-06-30 14:53 ` João Távora 2024-06-30 15:05 ` João Távora 2024-07-03 13:17 ` Spencer Baugh 2024-06-30 16:38 ` Juri Linkov 1 sibling, 2 replies; 30+ messages in thread From: João Távora @ 2024-06-30 14:53 UTC (permalink / raw To: Spencer Baugh Cc: Spencer Baugh, Eli Zaretskii, Juri Linkov, 71823, Dmitry Gutov [-- Attachment #1: Type: text/plain, Size: 1851 bytes --] On Sun, Jun 30, 2024, 13:51 <sbaugh@catern.com> wrote: > João Távora <joaotavora@gmail.com> writes: > > On Sat, Jun 29, 2024, 15:24 Spencer Baugh <sbaugh@janestreet.com> wrote: > > > > Or, here's an alternative idea, more aggressive: > > > > What if Eglot just sets project-mode-line=t in eglot-managed buffers, > and removes the project-name from the Eglot entry > > entirely? > > > > Then the language identifier would be the major mode, the project > identifier would be project-mode-line, and the eglot status > > indicator would just be for the status of the server. > > > > Works for me, it's in line with Eglot's policy of setting other modes > when managing buffers. Show a patch. > > Attached. > > I do think this is a great way to resolve this - now that > project-mode-line exists, using it deletes one small bit of > eglot-specific functionality, which is in line with the Eglot design > philosophy. > Yes. The only issue is that this was only added to mode-line-format in Emacs > 30, so we can only use it in Emacs 30 or later. > No, that's not an issue, or rather your solution isn't the way to solve it. In trunk Eglot use everything that is in trunk Emacs. In released Eglot versions name sure you depend on capable versions of core GNU Elpa packages, a set which already includes project.el. So basically version bumps solves it. So please show an updated patch, and don't forget the etc/EGLOT-NEWS entry. > But also, my idea of eglot-mode-line-format should be alsoh considered. > AFAICT there no big technical hurdle, it's just relatively > > boring work and some naming decisions to make. And as I mentioned, it > would fix more issues than just the one at hand. > > Yes, I think that would also be useful as a separate patch. > Looking forward to it. João > [-- Attachment #2: Type: text/html, Size: 3260 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 14:53 ` João Távora @ 2024-06-30 15:05 ` João Távora 2024-07-03 13:17 ` Spencer Baugh 1 sibling, 0 replies; 30+ messages in thread From: João Távora @ 2024-06-30 15:05 UTC (permalink / raw To: Spencer Baugh Cc: Spencer Baugh, Eli Zaretskii, Juri Linkov, 71823, Dmitry Gutov On Sun, Jun 30, 2024 at 3:53 PM João Távora <joaotavora@gmail.com> wrote: >> The only issue is that this was only added to mode-line-format in Emacs >> 30, so we can only use it in Emacs 30 or later. > > > In released Eglot versions name sure you depend on capable versions ^^^^ I meant "make sure", obviously. Sorry about that. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 14:53 ` João Távora 2024-06-30 15:05 ` João Távora @ 2024-07-03 13:17 ` Spencer Baugh 2024-07-03 13:59 ` João Távora 1 sibling, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-07-03 13:17 UTC (permalink / raw To: João Távora Cc: Dmitry Gutov, Spencer Baugh, Eli Zaretskii, 71823, Juri Linkov [-- Attachment #1: Type: text/plain, Size: 2138 bytes --] João Távora <joaotavora@gmail.com> writes: > On Sun, Jun 30, 2024, 13:51 <sbaugh@catern.com> wrote: > > João Távora <joaotavora@gmail.com> writes: > > On Sat, Jun 29, 2024, 15:24 Spencer Baugh <sbaugh@janestreet.com> wrote: > > > > Or, here's an alternative idea, more aggressive: > > > > What if Eglot just sets project-mode-line=t in eglot-managed buffers, and removes the project-name from the Eglot entry > > entirely? > > > > Then the language identifier would be the major mode, the project identifier would be project-mode-line, and the eglot > status > > indicator would just be for the status of the server. > > > > Works for me, it's in line with Eglot's policy of setting other modes when managing buffers. Show a patch. > > Attached. > > I do think this is a great way to resolve this - now that > project-mode-line exists, using it deletes one small bit of > eglot-specific functionality, which is in line with the Eglot design > philosophy. > > Yes. > > The only issue is that this was only added to mode-line-format in Emacs > 30, so we can only use it in Emacs 30 or later. > > No, that's not an issue, or rather your solution isn't the way to solve it. In trunk Eglot use everything that is in trunk Emacs. In > released Eglot versions name sure you depend on capable versions of core GNU Elpa packages, a set which already includes > project.el. So basically version bumps solves it. Yes, certainly. That's why I bumped the required version of project.el in the Package-Requires. But, loading a newer version of project.el doesn't add the project-mode-line entry to mode-line-format. That's done in bindings.el, and can't be updated. So we still need to do something else to accomodate an Emacs 29 user with an updated eglot.el and project.el. Juri says "(member '(project-mode-line project-mode-line-format) mode-line-format)" check is good, though, so I think we can just do that. > So please show an updated patch, and don't forget the etc/EGLOT-NEWS entry. Ok, here's a new version of the patch with an etc/EGLOT-NEWS entry. [-- Attachment #2: 0001-Use-project-mode-line-for-the-project-nick-in-Eglot.patch --] [-- Type: text/x-patch, Size: 7744 bytes --] From c7ab7a1f7b74effeca4cebbc5adb602bc8a57c87 Mon Sep 17 00:00:00 2001 From: Spencer Baugh <sbaugh@janestreet.com> Date: Wed, 3 Jul 2024 09:11:51 -0400 Subject: [PATCH] Use project-mode-line for the project nick in Eglot The existence of project-mode-line now means that eglot can have an indicator for the current project of the current buffer, without using the eglot mode-line entry to do it. This commit teaches eglot to (when possible) set project-mode-line true in eglot-managed buffers and remove project-name from the eglot mode line entry. * etc/EGLOT-NEWS: Announce usage of project-mode-line. * lisp/progmodes/eglot.el (eglot--managed-mode): Set project-mode-line if the project-mode-line entry is in mode-line-format. (eglot-menu): Always include eglot-server-menu as a submenu. (eglot--mode-line-format): Don't include project-name when project-mode-line is set. (bug#71823) --- etc/EGLOT-NEWS | 8 +++++ lisp/progmodes/eglot.el | 72 ++++++++++++++++++++++------------------- 2 files changed, 46 insertions(+), 34 deletions(-) diff --git a/etc/EGLOT-NEWS b/etc/EGLOT-NEWS index 0e3e4b7aff8..7462edd1cf0 100644 --- a/etc/EGLOT-NEWS +++ b/etc/EGLOT-NEWS @@ -26,6 +26,14 @@ Eglot will now try to not register $/progress messages from the server when the defcustom is set to nil. This requires a restart of the server for the change to take effect. +** Mode line entry now uses project-mode-line for project name + +In buffers managed by Eglot, the mode line has always contained the +project-name of that buffer's project (usually the basename of the VCS +root directory). Previously project-name was part of Eglot's mode line +entry; now project-name is in a separate entry provided by +project-mode-line. + \f * Changes in Eglot 1.17 (25/1/2024) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index bb6b0281d9f..fa09fb5ea51 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -7,7 +7,7 @@ ;; Maintainer: João Távora <joaotavora@gmail.com> ;; URL: https://github.com/joaotavora/eglot ;; Keywords: convenience, languages -;; Package-Requires: ((emacs "26.3") (compat "27.1") (eldoc "1.14.0") (external-completion "0.1") (flymake "1.2.1") (jsonrpc "1.0.24") (project "0.9.8") (seq "2.23") (track-changes "1.2") (xref "1.6.2")) +;; Package-Requires: ((emacs "26.3") (compat "27.1") (eldoc "1.14.0") (external-completion "0.1") (flymake "1.2.1") (jsonrpc "1.0.24") (project "0.11.0") (seq "2.23") (track-changes "1.2") (xref "1.6.2")) ;; This is a GNU ELPA :core package. Avoid adding functionality ;; that is not available in the version of Emacs recorded above or any @@ -2026,6 +2026,8 @@ eglot--managed-mode (eglot--setq-saving company-tooltip-align-annotations t) (eglot--setq-saving eldoc-documentation-strategy #'eldoc-documentation-compose) + (when (member '(project-mode-line project-mode-line-format) mode-line-format) + (setq-local project-mode-line t)) (unless (eglot--stay-out-of-p 'imenu) (add-function :before-until (local 'imenu-create-index-function) #'eglot-imenu)) @@ -2161,10 +2163,24 @@ eglot-upgrade-eglot (package-delete existing t)) (package-install (cadr (assoc 'eglot package-archive-contents))))) +(easy-menu-define eglot-server-menu nil "Monitor server communication" + '("Debugging the server communication" + ["Reconnect to server" eglot-reconnect] + ["Quit server" eglot-shutdown] + "--" + ["LSP events buffer" eglot-events-buffer] + ["Server stderr buffer" eglot-stderr-buffer] + ["Customize event buffer size" + (lambda () + (interactive) + (customize-variable 'eglot-events-buffer-size))])) + (easy-menu-define eglot-menu nil "Eglot" `("Eglot" ;; Commands for getting information and customization. ["Customize Eglot" (lambda () (interactive) (customize-group "eglot"))] + ["Server" eglot-server-menu + :active (eglot-current-server)] "--" ;; xref like commands. ["Find definitions" xref-find-definitions @@ -2211,18 +2227,6 @@ eglot-menu ["Quickfix" eglot-code-action-quickfix :visible (eglot-server-capable :codeActionProvider)])) -(easy-menu-define eglot-server-menu nil "Monitor server communication" - '("Debugging the server communication" - ["Reconnect to server" eglot-reconnect] - ["Quit server" eglot-shutdown] - "--" - ["LSP events buffer" eglot-events-buffer] - ["Server stderr buffer" eglot-stderr-buffer] - ["Customize event buffer size" - (lambda () - (interactive) - (customize-variable 'eglot-events-buffer-size))])) - (defun eglot--mode-line-props (thing face defs &optional prepend) "Helper for function `eglot--mode-line-format'. Uses THING, FACE, DEFS and PREPEND." @@ -2261,28 +2265,28 @@ eglot--mode-line-format 'help-echo (format "Project '%s'\nmouse-1: LSP server control menu" nick) 'keymap (let ((map (make-sparse-keymap))) (define-key map [mode-line down-mouse-1] eglot-server-menu) - map)) - ,@(when last-error - `("/" ,(eglot--mode-line-props - "error" 'compilation-mode-line-fail - '((mouse-3 eglot-clear-status "Clear this status")) - (format "An error occurred: %s\n" (plist-get last-error - :message))))) - ,@(when (cl-plusp pending) - `("/" ,(eglot--mode-line-props - (format "%d" pending) 'warning - '((mouse-3 eglot-forget-pending-continuations - "Forget pending continuations")) - "Number of outgoing, \ + map)))) + (when last-error + `("/" ,(eglot--mode-line-props + "error" 'compilation-mode-line-fail + '((mouse-3 eglot-clear-status "Clear this status")) + (format "An error occurred: %s\n" (plist-get last-error + :message))))) + (when (cl-plusp pending) + `("/" ,(eglot--mode-line-props + (format "%d" pending) 'warning + '((mouse-3 eglot-forget-pending-continuations + "Forget pending continuations")) + "Number of outgoing, \ still unanswered LSP requests to the server\n"))) - ,@(cl-loop for pr hash-values of (eglot--progress-reporters server) - when (eq (car pr) 'eglot--mode-line-reporter) - append `("/" ,(eglot--mode-line-props - (format "%s%%%%" (or (nth 4 pr) "?")) - 'eglot-mode-line - nil - (format "(%s) %s %s" (nth 1 pr) - (nth 2 pr) (nth 3 pr)))))))))) + (cl-loop for pr hash-values of (eglot--progress-reporters server) + when (eq (car pr) 'eglot--mode-line-reporter) + append `("/" ,(eglot--mode-line-props + (format "%s%%%%" (or (nth 4 pr) "?")) + 'eglot-mode-line + nil + (format "(%s) %s %s" (nth 1 pr) + (nth 2 pr) (nth 3 pr)))))))) (add-to-list 'mode-line-misc-info `(eglot--managed-mode (" [" eglot--mode-line-format "] "))) -- 2.39.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 13:17 ` Spencer Baugh @ 2024-07-03 13:59 ` João Távora 2024-07-03 14:47 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-07-03 13:59 UTC (permalink / raw To: Spencer Baugh Cc: Dmitry Gutov, Spencer Baugh, Eli Zaretskii, 71823, Juri Linkov On Wed, Jul 3, 2024 at 2:17 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > > João Távora <joaotavora@gmail.com> writes: > > > On Sun, Jun 30, 2024, 13:51 <sbaugh@catern.com> wrote: > > > > João Távora <joaotavora@gmail.com> writes: > > > On Sat, Jun 29, 2024, 15:24 Spencer Baugh <sbaugh@janestreet.com> wrote: > > > > > > Or, here's an alternative idea, more aggressive: > > > > > > What if Eglot just sets project-mode-line=t in eglot-managed buffers, and removes the project-name from the Eglot entry > > > entirely? > > > > > > Then the language identifier would be the major mode, the project identifier would be project-mode-line, and the eglot > > status > > > indicator would just be for the status of the server. > > > > > > Works for me, it's in line with Eglot's policy of setting other modes when managing buffers. Show a patch. > > > > Attached. > > > > I do think this is a great way to resolve this - now that > > project-mode-line exists, using it deletes one small bit of > > eglot-specific functionality, which is in line with the Eglot design > > philosophy. > > > > Yes. > > > > The only issue is that this was only added to mode-line-format in Emacs > > 30, so we can only use it in Emacs 30 or later. > > > > No, that's not an issue, or rather your solution isn't the way to solve it. In trunk Eglot use everything that is in trunk Emacs. In > > released Eglot versions name sure you depend on capable versions of core GNU Elpa packages, a set which already includes > > project.el. So basically version bumps solves it. > > Yes, certainly. That's why I bumped the required version of project.el > in the Package-Requires. > > But, loading a newer version of project.el doesn't add the > project-mode-line entry to mode-line-format. That's done in > bindings.el, and can't be updated. So we still need to do something > else to accomodate an Emacs 29 user with an updated eglot.el and > project.el. Hmm, I don't like it I must say. I thought there would be some kind of project-mode-line-mode to call that would do what it has to do to put the project in the mode-line. Like this it feels too hacky and intrusive into project.el's and binding.el's implementation. I also don't understand the other changes (i.e. to the menu) but that's OK. I'm going back to my previous recommendation of redesigning Eglot's eglot--mode-line-format into eglot-mode-line-format in the likeness of other packages (Flymake for example). If I'm going to carefully review and test changes to Eglot's mode-line machinery like the ones you are presenting here, it might as well be the most useful changes possible. That change should fix this and other problems. Until then, I don't think this is an extremely serious problem. João ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 13:59 ` João Távora @ 2024-07-03 14:47 ` Spencer Baugh 2024-07-03 14:57 ` João Távora 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-07-03 14:47 UTC (permalink / raw To: João Távora Cc: Dmitry Gutov, Eli Zaretskii, Juri Linkov, 71823, Spencer Baugh João Távora <joaotavora@gmail.com> writes: > On Wed, Jul 3, 2024 at 2:17 PM Spencer Baugh <sbaugh@janestreet.com> wrote: >> >> João Távora <joaotavora@gmail.com> writes: >> >> > On Sun, Jun 30, 2024, 13:51 <sbaugh@catern.com> wrote: >> > >> > João Távora <joaotavora@gmail.com> writes: >> > > On Sat, Jun 29, 2024, 15:24 Spencer Baugh <sbaugh@janestreet.com> wrote: >> > > >> > > Or, here's an alternative idea, more aggressive: >> > > >> > > What if Eglot just sets project-mode-line=t in eglot-managed buffers, and removes the project-name from the Eglot entry >> > > entirely? >> > > >> > > Then the language identifier would be the major mode, the project identifier would be project-mode-line, and the eglot >> > status >> > > indicator would just be for the status of the server. >> > > >> > > Works for me, it's in line with Eglot's policy of setting other modes when managing buffers. Show a patch. >> > >> > Attached. >> > >> > I do think this is a great way to resolve this - now that >> > project-mode-line exists, using it deletes one small bit of >> > eglot-specific functionality, which is in line with the Eglot design >> > philosophy. >> > >> > Yes. >> > >> > The only issue is that this was only added to mode-line-format in Emacs >> > 30, so we can only use it in Emacs 30 or later. >> > >> > No, that's not an issue, or rather your solution isn't the way to solve it. In trunk Eglot use everything that is in trunk Emacs. In >> > released Eglot versions name sure you depend on capable versions of core GNU Elpa packages, a set which already includes >> > project.el. So basically version bumps solves it. >> >> Yes, certainly. That's why I bumped the required version of project.el >> in the Package-Requires. >> >> But, loading a newer version of project.el doesn't add the >> project-mode-line entry to mode-line-format. That's done in >> bindings.el, and can't be updated. So we still need to do something >> else to accomodate an Emacs 29 user with an updated eglot.el and >> project.el. > > Hmm, I don't like it I must say. I thought there would be some kind > of project-mode-line-mode to call that would do what it has to do > to put the project in the mode-line. Like this it feels too hacky > and intrusive into project.el's and binding.el's implementation. Sure, so here are some possible solutions: A. Check (member '(project-mode-line project-mode-line-format) mode-line-format) B. Check (version<= "30" emacs-version) C. project.el itself could ensure, when loaded, that mode-line-format contains project-mode-line. eglot itself does this with eglot--mode-line-format, running the following at load time: (add-to-list 'mode-line-misc-info `(eglot--managed-mode (" [" eglot--mode-line-format "] "))) D. Add a project-minor-mode like you suggest which puts the project in the mode-line. Do any of these seem acceptable? I personally prefer C. > I also don't understand the other changes (i.e. to the menu) but > that's OK. The project-name in the eglot mode line entry had the server menu attached to it. Since the project-name is no longer present, the server menu isn't accessible. To make the server menu accessible again, it's added to the main eglot menu. > I'm going back to my previous recommendation of redesigning Eglot's > eglot--mode-line-format into eglot-mode-line-format in the likeness of > other packages (Flymake for example). If I'm going to carefully > review and test changes to Eglot's mode-line machinery like the ones > you are presenting here, it might as well be the most useful changes > possible. > > That change should fix this and other problems. Until then, I don't think > this is an extremely serious problem. Making eglot-mode-line-format customizable is an orthogonal change, which gives different benefits. To be clear, the problem I want to fix is "there's two mode-line entries (project-mode-line-format, eglot--mode-line-format) which include project-name, so project-name shows up twice". Yes, making those entries customizable allows the user to solve the problem by customizing the entries. But I don't want to delegate the responsibility of solving this problem to the user, I want the problem to just be gone: the entries should just not duplicate project-name. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 14:47 ` Spencer Baugh @ 2024-07-03 14:57 ` João Távora 2024-07-03 15:12 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-07-03 14:57 UTC (permalink / raw To: Spencer Baugh Cc: Dmitry Gutov, Eli Zaretskii, Juri Linkov, 71823, Spencer Baugh On Wed, Jul 3, 2024 at 3:47 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > Do any of these seem acceptable? No, sorry. > > > I also don't understand the other changes (i.e. to the menu) but > > that's OK. > > The project-name in the eglot mode line entry had the server menu > attached to it. Since the project-name is no longer present, the server > menu isn't accessible. To make the server menu accessible again, it's > added to the main eglot menu. Ah right. Well that unexpected side effect alone makes this approach unacceptable. It seemed like a quick out, but it really isn't. We have to go to the other approach > But I don't want to delegate the responsibility of solving this problem > to the user, I want the problem to just be gone: the entries should just > not duplicate project-name. This problem wasn't introduced by Eglot. In fact I don't know if this is even a problem. Users must know if they want to keep the Eglot mode line info working like it always did or if they want to tweak it to save space because of a new mode-line tenant that has since appeared in the very latest Emacs (a tenant which isn't even on by default). The problem in Eglot to me is that there isn't the possibility to do the latter thing, and _that's_ what I think should be addressed. João ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 14:57 ` João Távora @ 2024-07-03 15:12 ` Spencer Baugh 2024-07-03 16:03 ` João Távora 0 siblings, 1 reply; 30+ messages in thread From: Spencer Baugh @ 2024-07-03 15:12 UTC (permalink / raw To: João Távora Cc: Dmitry Gutov, Eli Zaretskii, Spencer Baugh, 71823, Juri Linkov João Távora <joaotavora@gmail.com> writes: > On Wed, Jul 3, 2024 at 3:47 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > >> Do any of these seem acceptable? > > No, sorry. When you originally said the patch was OK, how did you think the project-mode-line worked? Whatever way that is, I can just make project-mode-line work that way. >> > I also don't understand the other changes (i.e. to the menu) but >> > that's OK. >> >> The project-name in the eglot mode line entry had the server menu >> attached to it. Since the project-name is no longer present, the server >> menu isn't accessible. To make the server menu accessible again, it's >> added to the main eglot menu. > > Ah right. Well that unexpected side effect alone makes this > approach unacceptable. Why is that? What's the problem with moving the server menu to the main menu? >> But I don't want to delegate the responsibility of solving this problem >> to the user, I want the problem to just be gone: the entries should just >> not duplicate project-name. > > This problem wasn't introduced by Eglot. Definitely, but it seems like it is best to fix it in Eglot. I hope we can find a fix from the problem I want to solve, which is satisfying to you. > In fact I don't know if this is even a problem. Users must know if > they want to keep the Eglot mode line info working like it always did > or if they want to tweak it to save space because of a new mode-line > tenant that has since appeared in the very latest Emacs (a tenant > which isn't even on by default). > > The problem in Eglot to me is that there isn't the possibility to > do the latter thing, and _that's_ what I think should be addressed. Right. But even if we solved that, the problem I want to solve would still exist, and I'd still want to solve it without requiring users to do extra configuration, which is why I say there are separate problems. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 15:12 ` Spencer Baugh @ 2024-07-03 16:03 ` João Távora 2024-07-03 17:10 ` sbaugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-07-03 16:03 UTC (permalink / raw To: Spencer Baugh Cc: Dmitry Gutov, Eli Zaretskii, Spencer Baugh, 71823, Juri Linkov On Wed, Jul 3, 2024 at 4:12 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > > João Távora <joaotavora@gmail.com> writes: > > > On Wed, Jul 3, 2024 at 3:47 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > > > >> Do any of these seem acceptable? > > > > No, sorry. > > When you originally said the patch was OK, how did you think the > project-mode-line worked? I said the idea was OK :-) I forgot that Eglot's own display of the project name is not only that. It has more functionality: the project name is only a label. So what I thought would be a mere replacement and is actually not. > >> > I also don't understand the other changes (i.e. to the menu) but > >> > that's OK. > >> > >> The project-name in the eglot mode line entry had the server menu > >> attached to it. Since the project-name is no longer present, the server > >> menu isn't accessible. To make the server menu accessible again, it's > >> added to the main eglot menu. > > > > Ah right. Well that unexpected side effect alone makes this > > approach unacceptable. > > Why is that? What's the problem with moving the server menu to the main > menu? Nothing in particular, but if we're going to do that, we might as well do the other thing, which I still think is cleaner. > >> But I don't want to delegate the responsibility of solving this problem > >> to the user, I want the problem to just be gone: the entries should just > >> not duplicate project-name. > > > > This problem wasn't introduced by Eglot. > > Definitely, but it seems like it is best to fix it in Eglot. It's best to allow the user to choose, and Eglot doesn't have a way to let the user choose (while project has). So let's give them one in Eglot. João ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 16:03 ` João Távora @ 2024-07-03 17:10 ` sbaugh 2024-07-05 12:04 ` João Távora 0 siblings, 1 reply; 30+ messages in thread From: sbaugh @ 2024-07-03 17:10 UTC (permalink / raw To: João Távora Cc: Spencer Baugh, Eli Zaretskii, Juri Linkov, 71823, Dmitry Gutov João Távora <joaotavora@gmail.com> writes: > On Wed, Jul 3, 2024 at 4:12 PM Spencer Baugh <sbaugh@janestreet.com> wrote: >> >> João Távora <joaotavora@gmail.com> writes: >> >> > On Wed, Jul 3, 2024 at 3:47 PM Spencer Baugh <sbaugh@janestreet.com> wrote: >> > >> >> Do any of these seem acceptable? >> > >> > No, sorry. >> >> When you originally said the patch was OK, how did you think the >> project-mode-line worked? > > I said the idea was OK :-) I forgot that Eglot's own display of > the project name is not only that. It has more functionality: > the project name is only a label. So what I thought would be a mere > replacement and is actually not. To be clear, I want a configuration which will have project-name from project-mode-line and no project-name in the eglot mode-line entry. So that functionality will need to be moved anyway, no matter how we solve this problem. Are you fine with including the server menu in the main menu? This is something we'd want in both the "make it work by default" or "make it customizable" solutions. >> >> But I don't want to delegate the responsibility of solving this problem >> >> to the user, I want the problem to just be gone: the entries should just >> >> not duplicate project-name. >> > >> > This problem wasn't introduced by Eglot. >> >> Definitely, but it seems like it is best to fix it in Eglot. > > It's best to allow the user to choose, and Eglot doesn't have a way > to let the user choose (while project has). So let's give them one > in Eglot. It's better still to both allow the user to choose and *also* have a default which works right out of the box. Those are two separate things which we can do separately. But allowing the user to choose adds a bunch of new customization points that need to be maintained. I don't understand why we would add these new customization points when we already are low on maintainer time for Eglot. I anticipate adding these custosmization points would have lots of small bugs. I'm all for doing it eventually, but making things work by default also solves my problem, without adding new maintenance burden. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-03 17:10 ` sbaugh @ 2024-07-05 12:04 ` João Távora 2024-07-15 13:30 ` Spencer Baugh 0 siblings, 1 reply; 30+ messages in thread From: João Távora @ 2024-07-05 12:04 UTC (permalink / raw To: sbaugh; +Cc: Spencer Baugh, Eli Zaretskii, Juri Linkov, 71823, Dmitry Gutov sbaugh@catern.com writes: > To be clear, I want a configuration which will have project-name from > project-mode-line and no project-name in the eglot mode-line entry. I understand. > So that functionality will need to be moved anyway, no matter how we > solve this problem. As I see it (now, not 2 weeks ago) only if the user wants the same as you. The reason I changed my mind is that I hadn't realized that section was being used for the server-specific menu. > Are you fine with including the server menu in the main menu? This is > something we'd want in both the "make it work by default" or "make it > customizable" solutions. No, I'm not sure of that. One of the reasons is that Eglot currently supports only one server, but there are many requests for it to support more than one in the future. So I'm not sure that's such a good move, whereas if the user decides they don't need the server menu, that's a different story. > It's better still to both allow the user to choose and *also* have a > default which works right out of the box. Those are two separate things > which we can do separately. AFAIK the current default is fine. Nothing is broken. > But allowing the user to choose adds a bunch of new customization points > that need to be maintained. Not a bunch of customization points. Only one, a very idiomatic one: eglot-mode-line-format. > I don't understand why we would add these new customization points > when we already are low on maintainer time for Eglot. I anticipate > adding these custosmization points would have lots of small bugs. I'm > all for doing it eventually, but making things work by default also > solves my problem, without adding new maintenance burden. I find this very contradictory, but that's just my opinion. It's precisely because we're low on maintainer capacity for Eglot that I don't want rash changes. No offense to your idea -- it seemed good and I approved and encouraged it, but in light of this new info, I've changed my mind. Also, Eglot enabling things outside its domain when managing buffers is indeed a design principle, but it usually applies to things that are _essential_ to helping Eglot do its job corectly (Flymake, ElDoc, even certain Company configurations). Now, I'm not sure showing the user the current project in the mode-line and giving them access to all those (undoutably useful) options is one of those "essential things", whereas telling the user that there is currently at least one live server is. Furthermore , not everyone likes this idea, as you may expect. Anyway, if you want a quick hack for your predicament, I think you can put this in your .emacs: (add-hook 'eglot-managed-mode-hook (lambda () (setf (eglot--project-nickname (eglot-current-server)) ""))) untested... João ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-07-05 12:04 ` João Távora @ 2024-07-15 13:30 ` Spencer Baugh 0 siblings, 0 replies; 30+ messages in thread From: Spencer Baugh @ 2024-07-15 13:30 UTC (permalink / raw To: João Távora Cc: Dmitry Gutov, sbaugh, Eli Zaretskii, 71823, Juri Linkov João Távora <joaotavora@gmail.com> writes: > sbaugh@catern.com writes: > >> To be clear, I want a configuration which will have project-name from >> project-mode-line and no project-name in the eglot mode-line entry. > > I understand. > >> So that functionality will need to be moved anyway, no matter how we >> solve this problem. > > As I see it (now, not 2 weeks ago) only if the user wants the same as > you. The reason I changed my mind is that I hadn't realized that section > was being used for the server-specific menu. > >> Are you fine with including the server menu in the main menu? This is >> something we'd want in both the "make it work by default" or "make it >> customizable" solutions. > > No, I'm not sure of that. One of the reasons is that Eglot currently > supports only one server, but there are many requests for it to support > more than one in the future. So I'm not sure that's such a good move, > whereas if the user decides they don't need the server menu, that's a > different story. I see. What about putting an abbreviated server name in the eglot modeline, replacing the current project-name? That would fit better with supporting multiple servers anyway: there would be multiple entries for multiple servers. I'm not sure what a good source for an abbreviated server name would be... perhaps we could query something from the LSP server, or put it in eglot-server-programs? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 12:51 ` sbaugh 2024-06-30 14:53 ` João Távora @ 2024-06-30 16:38 ` Juri Linkov 2024-07-03 13:00 ` Spencer Baugh 1 sibling, 1 reply; 30+ messages in thread From: Juri Linkov @ 2024-06-30 16:38 UTC (permalink / raw To: sbaugh Cc: Spencer Baugh, Eli Zaretskii, João Távora, 71823, Dmitry Gutov > I do think this is a great way to resolve this - now that > project-mode-line exists, using it deletes one small bit of > eglot-specific functionality, which is in line with the Eglot design > philosophy. > > The only issue is that this was only added to mode-line-format in Emacs > 30, so we can only use it in Emacs 30 or later. > > The attached patch detects that with: > > + (when (member '(project-mode-line project-mode-line-format) mode-line-format) > > but I'm also totally fine with: > > + (when (version<= "30" emacs-version) > > Or I guess we could sidestep the issue if project.el itself ensured, > when loaded, that mode-line-format contains project-mode-line. eglot > itself does this with eglot--mode-line-format, running the following at > load time: > > (add-to-list 'mode-line-misc-info > `(eglot--managed-mode (" [" eglot--mode-line-format "] "))) > > Juri, any opinion? bindings.el already contains '(project-mode-line project-mode-line-format), so checking this with (member '(project-mode-line project-mode-line-format) mode-line-format) looks fine. OTOH, I'm not sure if using (setq-local project-mode-line t) would be appreciated by users. I think your initial patch was more correct with (bound-and-true-p project-mode-line). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line 2024-06-30 16:38 ` Juri Linkov @ 2024-07-03 13:00 ` Spencer Baugh 0 siblings, 0 replies; 30+ messages in thread From: Spencer Baugh @ 2024-07-03 13:00 UTC (permalink / raw To: Juri Linkov Cc: sbaugh, Eli Zaretskii, João Távora, 71823, Dmitry Gutov Juri Linkov <juri@linkov.net> writes: >> I do think this is a great way to resolve this - now that >> project-mode-line exists, using it deletes one small bit of >> eglot-specific functionality, which is in line with the Eglot design >> philosophy. >> >> The only issue is that this was only added to mode-line-format in Emacs >> 30, so we can only use it in Emacs 30 or later. >> >> The attached patch detects that with: >> >> + (when (member '(project-mode-line project-mode-line-format) mode-line-format) >> >> but I'm also totally fine with: >> >> + (when (version<= "30" emacs-version) >> >> Or I guess we could sidestep the issue if project.el itself ensured, >> when loaded, that mode-line-format contains project-mode-line. eglot >> itself does this with eglot--mode-line-format, running the following at >> load time: >> >> (add-to-list 'mode-line-misc-info >> `(eglot--managed-mode (" [" eglot--mode-line-format "] "))) >> >> Juri, any opinion? > > bindings.el already contains '(project-mode-line project-mode-line-format), > so checking this with (member '(project-mode-line project-mode-line-format) > mode-line-format) looks fine. Will do that in the next version of the patch. > OTOH, I'm not sure if using (setq-local project-mode-line t) > would be appreciated by users. I think your initial patch > was more correct with (bound-and-true-p project-mode-line). I was also unsure, but after thinking about it, I think it's actually quite reasonable, for this reason: anyone enabling eglot already had project-name in their modeline. This patch just moves the project-name from the [eglot] element to a separate mode-line element. So this doesn't actually change the contents of an eglot user's mode-line, just the order of the elements. Plus the separate element has the mouse-1 project menu, which is a nice addition. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2024-07-15 13:30 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-06-28 14:13 bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line Spencer Baugh 2024-06-28 14:15 ` Spencer Baugh 2024-06-28 14:40 ` Eli Zaretskii 2024-06-28 17:49 ` João Távora 2024-06-28 22:08 ` Spencer Baugh 2024-06-29 7:12 ` Eli Zaretskii 2024-06-29 11:59 ` Dmitry Gutov 2024-06-29 12:43 ` Eli Zaretskii 2024-06-30 6:50 ` Juri Linkov 2024-06-30 10:25 ` João Távora 2024-06-29 12:05 ` João Távora 2024-06-29 12:17 ` Dmitry Gutov 2024-06-29 12:21 ` João Távora 2024-06-29 12:41 ` Spencer Baugh 2024-06-29 14:24 ` Spencer Baugh 2024-06-30 0:25 ` João Távora 2024-06-30 12:51 ` sbaugh 2024-06-30 14:53 ` João Távora 2024-06-30 15:05 ` João Távora 2024-07-03 13:17 ` Spencer Baugh 2024-07-03 13:59 ` João Távora 2024-07-03 14:47 ` Spencer Baugh 2024-07-03 14:57 ` João Távora 2024-07-03 15:12 ` Spencer Baugh 2024-07-03 16:03 ` João Távora 2024-07-03 17:10 ` sbaugh 2024-07-05 12:04 ` João Távora 2024-07-15 13:30 ` Spencer Baugh 2024-06-30 16:38 ` Juri Linkov 2024-07-03 13:00 ` Spencer Baugh
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.