bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Eli Zaretskii]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

[-- 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 --]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Eli Zaretskii]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Dmitry Gutov]

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.

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Dmitry Gutov]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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.

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

[-- 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 --]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Eli Zaretskii]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

[-- 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 --]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

[-- 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 --]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Juri Linkov]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

[-- 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 --]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[sbaugh]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

[-- 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 --]

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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.

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Juri Linkov]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

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.

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

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.

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[sbaugh]

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.

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[João Távora]

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

bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh]

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?