From: sbaugh@catern.com
To: "João Távora" <joaotavora@gmail.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: Wed, 03 Jul 2024 17:10:06 +0000 (UTC) [thread overview]
Message-ID: <87h6d6flld.fsf@catern.com> (raw)
In-Reply-To: <CALDnm51ZjSmN+epTM=vdAH7d8=kTPkouf+g5=CNczAdaHQyCxQ@mail.gmail.com> ("João Távora"'s message of "Wed, 3 Jul 2024 17:03:09 +0100")
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.
next prev parent reply other threads:[~2024-07-03 17:10 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6d6flld.fsf@catern.com \
--to=sbaugh@catern.com \
--cc=71823@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
--cc=juri@linkov.net \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).