all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: sbaugh@catern.com
Cc: Spencer Baugh <sbaugh@janestreet.com>,
	Eli Zaretskii <eliz@gnu.org>, Juri Linkov <juri@linkov.net>,
	71823@debbugs.gnu.org, Dmitry Gutov <dmitry@gutov.dev>
Subject: bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line
Date: Fri, 05 Jul 2024 13:04:15 +0100	[thread overview]
Message-ID: <874j94gi4g.fsf@gmail.com> (raw)
In-Reply-To: <87h6d6flld.fsf@catern.com> (sbaugh@catern.com's message of "Wed,  03 Jul 2024 17:10:06 +0000 (UTC)")

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





  reply	other threads:[~2024-07-05 12:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2024-07-15 13:30                                           ` Spencer Baugh
2024-06-30 16:38                         ` Juri Linkov
2024-07-03 13:00                           ` Spencer Baugh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874j94gi4g.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=71823@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=sbaugh@catern.com \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.