From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line Date: Wed, 03 Jul 2024 10:47:43 -0400 Message-ID: References: <86wmm9jfk7.fsf@gnu.org> <86o77kjk87.fsf@gnu.org> <17183c60-1733-4938-9a85-f3351c87bcb9@gutov.dev> <87jzi6fvar.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19143"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Dmitry Gutov , Eli Zaretskii , Juri Linkov , 71823@debbugs.gnu.org, Spencer Baugh To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 03 16:48:24 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sP1HT-0004kU-Vl for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Jul 2024 16:48:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sP1H8-0004ge-Fi; Wed, 03 Jul 2024 10:48:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sP1H6-0004ft-6h for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2024 10:48:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sP1H5-00067d-Uk for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2024 10:47:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sP1H7-0003NH-N0 for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2024 10:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jul 2024 14:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71823 X-GNU-PR-Package: emacs Original-Received: via spool by 71823-submit@debbugs.gnu.org id=B71823.172001807312955 (code B ref 71823); Wed, 03 Jul 2024 14:48:01 +0000 Original-Received: (at 71823) by debbugs.gnu.org; 3 Jul 2024 14:47:53 +0000 Original-Received: from localhost ([127.0.0.1]:40028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP1Gz-0003Ms-89 for submit@debbugs.gnu.org; Wed, 03 Jul 2024 10:47:53 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:38009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP1Gx-0003Mb-Eb for 71823@debbugs.gnu.org; Wed, 03 Jul 2024 10:47:52 -0400 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 3 Jul 2024 14:59:18 +0100") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720018063; bh=PpR1SYR2HuRCucd4sS+YcpdqLucchz0s4SxJFc/7o3g=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=B8qopNqbK9PALozVb57tX3z6mthhCyZQ9ww8MTGwcGZBrTfFpyFqLrJxdMaRbUypJ 4dTh97v2Jk572LmR3lLbQcNbOKo8aP8dAM+gKrurLNHN3xulMaguvj2WfHyVftQfUH OKuXYoG6+noBRgeHPskvnUp8MYSLJZey8b4txGAOm/IIr6jIFwzvos1uTiF92XCtzy bT8RlSs0q5w4ofK0mHqRw1DmbslyEs8+VpLgemZZVga9aTAMqxCGHyPa3RfUwxrOL8 1PGP8xaHULa25d7U+0u/xUGaFXnURg6yf69D58vqdL9HJ4LXUJZzcsxJzn/opIpW2A c3oa+Fvp7UhIg== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288322 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Wed, Jul 3, 2024 at 2:17=E2=80=AFPM Spencer Baugh wrote: >> >> Jo=C3=A3o T=C3=A1vora writes: >> >> > On Sun, Jun 30, 2024, 13:51 wrote: >> > >> > Jo=C3=A3o T=C3=A1vora writes: >> > > On Sat, Jun 29, 2024, 15:24 Spencer Baugh w= rote: >> > > >> > > Or, here's an alternative idea, more aggressive: >> > > >> > > What if Eglot just sets project-mode-line=3Dt in eglot-managed buf= fers, 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 mod= es 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 Ema= cs >> > 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 solv= e it. In trunk Eglot use everything that is in trunk Emacs. In >> > released Eglot versions name sure you depend on capable versions of co= re 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-fo= rmat) B. Check (version<=3D "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: =20=20=20 (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.