GNU bug report logs - #66317
Project mode-line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66317 in the body.
You can then email your comments to 66317 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Project mode-line
Date: Tue, 03 Oct 2023 09:29:23 +0300

[Message part 1 (text/plain, inline)]

Here is the implementation of the mode-line project indicator prepended
before the vc indicator with the project menu discussed in bug#63469:

[project-mode-line.patch (text/x-diff, inline)]

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 2e6ae89a443..8798feb2c56 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -2010,5 +2102,20 @@ project-uniquify-dirname-transform
           (file-relative-name dirname root))))
     dirname))
 
+;;; Project mode-line
+
+(let ((form '(:eval (when-let (project (project-current))
+                      (concat " "
+                              (propertize
+                               (project-name project)
+                               'mouse-face 'mode-line-highlight
+                               'local-map
+                               (make-mode-line-mouse-map
+                                'down-mouse-1
+			        `(menu-item "Project"
+                                            ,menu-bar-project-menu))))))))
+  (when-let (pos (seq-position mode-line-format '(vc-mode vc-mode)))
+    (cl-pushnew form (nthcdr pos mode-line-format))))
+
 (provide 'project)
 ;;; project.el ends here

Message #8 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 03 Oct 2023 10:07:00 +0200

Hi,

Juri Linkov <juri <at> linkov.net> writes:

> Here is the implementation of the mode-line project indicator prepended
> before the vc indicator with the project menu discussed in bug#63469:
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 2e6ae89a443..8798feb2c56 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -2010,5 +2102,20 @@ project-uniquify-dirname-transform
>            (file-relative-name dirname root))))
>      dirname))
>
> +;;; Project mode-line
> +
> +(let ((form '(:eval (when-let (project (project-current))
> +                      (concat " "
> +                              (propertize
> +                               (project-name project)
> +                               'mouse-face 'mode-line-highlight
> +                               'local-map
> +                               (make-mode-line-mouse-map
> +                                'down-mouse-1
> +                             `(menu-item "Project"
> +                                            ,menu-bar-project-menu))))))))
> +  (when-let (pos (seq-position mode-line-format '(vc-mode vc-mode)))
> +    (cl-pushnew form (nthcdr pos mode-line-format))))
> +
>  (provide 'project)
>  ;;; project.el ends here

This looks nice (I actually have something similar in my
`mode-line-format` already), but I think that modifying
`mode-line-format` when project.el is loaded is a bit problematic.
Perhaps a better alternative would be to define a variable that holds
this mode-line construct, along with an autoloaded function that people
can call from their init files to actually add this construct to
`mode-line-format`.  WDYT?


Best,

Eshel

Message #11 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 3 Oct 2023 05:06:20 -0700

Juri Linkov <juri <at> linkov.net> writes:

> Here is the implementation of the mode-line project indicator prepended
> before the vc indicator with the project menu discussed in bug#63469:

LGTM.

Message #14 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eshel Yaron <me <at> eshelyaron.com>, Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 3 Oct 2023 19:24:52 +0300

On 03/10/2023 11:07, Eshel Yaron via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Hi,
> 
> Juri Linkov<juri <at> linkov.net>  writes:
> 
>> Here is the implementation of the mode-line project indicator prepended
>> before the vc indicator with the project menu discussed in bug#63469:
>>
>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>> index 2e6ae89a443..8798feb2c56 100644
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -2010,5 +2102,20 @@ project-uniquify-dirname-transform
>>             (file-relative-name dirname root))))
>>       dirname))
>>
>> +;;; Project mode-line
>> +
>> +(let ((form '(:eval (when-let (project (project-current))
>> +                      (concat " "
>> +                              (propertize
>> +                               (project-name project)
>> +                               'mouse-face 'mode-line-highlight
>> +                               'local-map
>> +                               (make-mode-line-mouse-map
>> +                                'down-mouse-1
>> +                             `(menu-item "Project"
>> +                                            ,menu-bar-project-menu))))))))
>> +  (when-let (pos (seq-position mode-line-format '(vc-mode vc-mode)))
>> +    (cl-pushnew form (nthcdr pos mode-line-format))))
>> +
>>   (provide 'project)
>>   ;;; project.el ends here
> This looks nice (I actually have something similar in my
> `mode-line-format` already), but I think that modifying
> `mode-line-format` when project.el is loaded is a bit problematic.
> Perhaps a better alternative would be to define a variable that holds
> this mode-line construct, along with an autoloaded function that people
> can call from their init files to actually add this construct to
> `mode-line-format`.  WDYT?

I also think this would be a more conservative choice (keeping the 
runtime cost of using project.el to zero by default).

- A public defvar with the mode-line spec for the project element (which 
could be used by alternative mode-lines as well).
- Either a public function, or a defcustom (nil by default) where the 
setter does the same thing. The latter seems a bit user-friendlier.

Message #17 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 03 Oct 2023 20:11:55 +0300

> This looks nice (I actually have something similar in my
> `mode-line-format` already), but I think that modifying
> `mode-line-format` when project.el is loaded is a bit problematic.
> Perhaps a better alternative would be to define a variable that holds
> this mode-line construct, along with an autoloaded function that people
> can call from their init files to actually add this construct to
> `mode-line-format`.  WDYT?

In bug#63469 I implemented 'project-mode' with the buffer-local
variable 'project-name'.  But due to objections I rewrote this
to simpler and direct implementation.  I could revive the previous
patch now.

Message #20 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Eshel Yaron <me <at> eshelyaron.com>
Cc: 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 3 Oct 2023 20:51:50 +0300

On 03/10/2023 20:11, Juri Linkov wrote:
>> This looks nice (I actually have something similar in my
>> `mode-line-format` already), but I think that modifying
>> `mode-line-format` when project.el is loaded is a bit problematic.
>> Perhaps a better alternative would be to define a variable that holds
>> this mode-line construct, along with an autoloaded function that people
>> can call from their init files to actually add this construct to
>> `mode-line-format`.  WDYT?
> In bug#63469 I implemented 'project-mode' with the buffer-local
> variable 'project-name'.  But due to objections I rewrote this
> to simpler and direct implementation.  I could revive the previous
> patch now.

Could you make it a user option 'project-show-in-mode-line' or similar?

Minor mode 'project-mode-line-mode' would also be okay.

Message #23 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 66317 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66317: Project mode-line
Date: Tue, 03 Oct 2023 20:58:49 +0300

> On 03/10/2023 20:11, Juri Linkov wrote:
>>> This looks nice (I actually have something similar in my
>>> `mode-line-format` already), but I think that modifying
>>> `mode-line-format` when project.el is loaded is a bit problematic.
>>> Perhaps a better alternative would be to define a variable that holds
>>> this mode-line construct, along with an autoloaded function that people
>>> can call from their init files to actually add this construct to
>>> `mode-line-format`.  WDYT?
>> In bug#63469 I implemented 'project-mode' with the buffer-local
>> variable 'project-name'.  But due to objections I rewrote this
>> to simpler and direct implementation.  I could revive the previous
>> patch now.
>
> Could you make it a user option 'project-show-in-mode-line' or similar?
>
> Minor mode 'project-mode-line-mode' would also be okay.

But there is no such mode for vc-mode (vc-mode is not a proper mode).

Message #26 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66317: Project mode-line
Date: Tue, 3 Oct 2023 21:04:03 +0300

On 03/10/2023 20:58, Juri Linkov wrote:
>> On 03/10/2023 20:11, Juri Linkov wrote:
>>>> This looks nice (I actually have something similar in my
>>>> `mode-line-format` already), but I think that modifying
>>>> `mode-line-format` when project.el is loaded is a bit problematic.
>>>> Perhaps a better alternative would be to define a variable that holds
>>>> this mode-line construct, along with an autoloaded function that people
>>>> can call from their init files to actually add this construct to
>>>> `mode-line-format`.  WDYT?
>>> In bug#63469 I implemented 'project-mode' with the buffer-local
>>> variable 'project-name'.  But due to objections I rewrote this
>>> to simpler and direct implementation.  I could revive the previous
>>> patch now.
>> Could you make it a user option 'project-show-in-mode-line' or similar?
>>
>> Minor mode 'project-mode-line-mode' would also be okay.
> But there is no such mode for vc-mode (vc-mode is not a proper mode).

VC Mode is just always on globally (though there is a variable 
vc-handled-backends which can be disabled). And as such, it always adds 
runtime overhead.

Message #29 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 03 Oct 2023 21:17:09 +0300

> Cc: 66317 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>
> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 03 Oct 2023 20:58:49 +0300
> 
> > On 03/10/2023 20:11, Juri Linkov wrote:
> >>> This looks nice (I actually have something similar in my
> >>> `mode-line-format` already), but I think that modifying
> >>> `mode-line-format` when project.el is loaded is a bit problematic.
> >>> Perhaps a better alternative would be to define a variable that holds
> >>> this mode-line construct, along with an autoloaded function that people
> >>> can call from their init files to actually add this construct to
> >>> `mode-line-format`.  WDYT?
> >> In bug#63469 I implemented 'project-mode' with the buffer-local
> >> variable 'project-name'.  But due to objections I rewrote this
> >> to simpler and direct implementation.  I could revive the previous
> >> patch now.
> >
> > Could you make it a user option 'project-show-in-mode-line' or similar?
> >
> > Minor mode 'project-mode-line-mode' would also be okay.
> 
> But there is no such mode for vc-mode (vc-mode is not a proper mode).

I indeed think that an optional variable to control the mode-line
additions would be better than a minor mode: this is too little
functionality to justify a minor mode.

Message #32 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 04 Oct 2023 09:18:28 +0300

[Message part 1 (text/plain, inline)]

>> >>> This looks nice (I actually have something similar in my
>> >>> `mode-line-format` already), but I think that modifying
>> >>> `mode-line-format` when project.el is loaded is a bit problematic.
>> >>> Perhaps a better alternative would be to define a variable that holds
>> >>> this mode-line construct, along with an autoloaded function that people
>> >>> can call from their init files to actually add this construct to
>> >>> `mode-line-format`.  WDYT?
>> >> In bug#63469 I implemented 'project-mode' with the buffer-local
>> >> variable 'project-name'.  But due to objections I rewrote this
>> >> to simpler and direct implementation.  I could revive the previous
>> >> patch now.
>> >
>> > Could you make it a user option 'project-show-in-mode-line' or similar?
>> >
>> > Minor mode 'project-mode-line-mode' would also be okay.
>>
>> But there is no such mode for vc-mode (vc-mode is not a proper mode).
>
> I indeed think that an optional variable to control the mode-line
> additions would be better than a minor mode: this is too little
> functionality to justify a minor mode.

Ok, here is the implementation with an optional variable:

[project-mode-line.patch (text/x-diff, inline)]

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 2e6ae89a443..74b2347b715 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -2010,5 +2103,36 @@ project-uniquify-dirname-transform
           (file-relative-name dirname root))))
     dirname))
 
+;;; Project mode-line
+
+;;;###autoload
+(defcustom project-mode-line nil
+  "Show the current project name with the menu on the mode line."
+  :type 'boolean
+  :group 'project
+  :version "30.1")
+
+(defvar project-menu-entry
+  `(menu-item "Project" ,menu-bar-project-menu))
+
+(defvar project-mode-line-map
+  (let ((map (make-sparse-keymap)))
+    (define-key map [mode-line down-mouse-1] project-menu-entry)
+    map))
+
+(defvar project-mode-line-format '(:eval (project-mode-line-format)))
+(put 'project-mode-line-format 'risky-local-variable t)
+
+(defun project-mode-line-format ()
+  "Compose the project mode-line."
+  (when-let ((project (project-current)))
+    (concat
+     " "
+     (propertize
+      (project-name project)
+      'mouse-face 'mode-line-highlight
+      'help-echo "mouse-1: Project menu"
+      'local-map project-mode-line-map))))
+
 (provide 'project)
 ;;; project.el ends here
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 207adb3a2a4..70e4087e131 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -682,6 +682,7 @@ mode-line-end-spaces
 	     'mode-line-buffer-identification
 	     "   "
 	     'mode-line-position
+	     '(project-mode-line project-mode-line-format)
 	     '(vc-mode vc-mode)
 	     "  "
 	     'mode-line-modes

Message #35 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 04 Oct 2023 09:15:37 +0200

Juri Linkov <juri <at> linkov.net> writes:

> Ok, here is the implementation with an optional variable:

Thanks, I've tried this patch on top of Emacs master and it seems to
work well.  One small suggestion is to consider giving the project name
in the mode line a dedicated face, so people/themes could customize its
appearance.  (By default, it could just inherit from `default`.)

> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 2e6ae89a443..74b2347b715 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -2010,5 +2103,36 @@ project-uniquify-dirname-transform
>            (file-relative-name dirname root))))
>      dirname))
>  
> +;;; Project mode-line
> +
> +;;;###autoload
> +(defcustom project-mode-line nil
> +  "Show the current project name with the menu on the mode line."
> +  :type 'boolean
> +  :group 'project
> +  :version "30.1")
> +
> +(defvar project-menu-entry
> +  `(menu-item "Project" ,menu-bar-project-menu))
> +
> +(defvar project-mode-line-map
> +  (let ((map (make-sparse-keymap)))
> +    (define-key map [mode-line down-mouse-1] project-menu-entry)
> +    map))
> +
> +(defvar project-mode-line-format '(:eval (project-mode-line-format)))
> +(put 'project-mode-line-format 'risky-local-variable t)
> +
> +(defun project-mode-line-format ()
> +  "Compose the project mode-line."
> +  (when-let ((project (project-current)))
> +    (concat
> +     " "
> +     (propertize
> +      (project-name project)
> +      'mouse-face 'mode-line-highlight
> +      'help-echo "mouse-1: Project menu"
> +      'local-map project-mode-line-map))))
> +
>  (provide 'project)
>  ;;; project.el ends here
> diff --git a/lisp/bindings.el b/lisp/bindings.el
> index 207adb3a2a4..70e4087e131 100644
> --- a/lisp/bindings.el
> +++ b/lisp/bindings.el
> @@ -682,6 +682,7 @@ mode-line-end-spaces
>  	     'mode-line-buffer-identification
>  	     "   "
>  	     'mode-line-position
> +	     '(project-mode-line project-mode-line-format)
>  	     '(vc-mode vc-mode)
>  	     "  "
>  	     'mode-line-modes

Message #38 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 04 Oct 2023 10:43:01 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: dmitry <at> gutov.dev,  66317 <at> debbugs.gnu.org,  me <at> eshelyaron.com
> Date: Wed, 04 Oct 2023 09:18:28 +0300
> 
> Ok, here is the implementation with an optional variable:

Thanks.

> +;;;###autoload
> +(defcustom project-mode-line nil
> +  "Show the current project name with the menu on the mode line."
> +  :type 'boolean
> +  :group 'project
> +  :version "30.1")

Assuming Dmitry is OK with this implementation, this option should be
in NEWS, I think.

> --- a/lisp/bindings.el
> +++ b/lisp/bindings.el
> @@ -682,6 +682,7 @@ mode-line-end-spaces
>  	     'mode-line-buffer-identification
>  	     "   "
>  	     'mode-line-position
> +	     '(project-mode-line project-mode-line-format)
>  	     '(vc-mode vc-mode)
>  	     "  "
>  	     'mode-line-modes

bindings.el is preloaded, but project.el is not.  Doesn't the above
cause trouble while bootstrapping, or forces loading project.el right
after starting Emacs?  IOW, when will project.el be loaded if the user
customizes the new option to a non-nil value?

Message #41 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Cc: me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 4 Oct 2023 17:34:09 +0300

On 04/10/2023 10:43, Eli Zaretskii wrote:
> Assuming Dmitry is OK with this implementation, this option should be
> in NEWS, I think.

LGTM, thanks. Aside from the other potential issue that you brought up.

Message #44 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 04 Oct 2023 20:04:52 +0300

>> +;;;###autoload
>> +(defcustom project-mode-line nil
>> +  "Show the current project name with the menu on the mode line."
>> +  :type 'boolean
>> +  :group 'project
>> +  :version "30.1")
>>
>> --- a/lisp/bindings.el
>> +++ b/lisp/bindings.el
>> @@ -682,6 +682,7 @@ mode-line-end-spaces
>>  	     'mode-line-buffer-identification
>>  	     "   "
>>  	     'mode-line-position
>> +	     '(project-mode-line project-mode-line-format)
>>  	     '(vc-mode vc-mode)
>>  	     "  "
>>  	     'mode-line-modes
>
> bindings.el is preloaded, but project.el is not.  Doesn't the above
> cause trouble while bootstrapping, or forces loading project.el right
> after starting Emacs?  IOW, when will project.el be loaded if the user
> customizes the new option to a non-nil value?

project-mode-line is autoloaded and nil by default.  This means no trouble
while bootstrapping, and project.el is not loaded after starting Emacs.
project.el is loaded only after customizing project-mode-line to non-nil.

Message #47 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 04 Oct 2023 20:06:17 +0300

>> Ok, here is the implementation with an optional variable:
>
> Thanks, I've tried this patch on top of Emacs master and it seems to
> work well.  One small suggestion is to consider giving the project name
> in the mode line a dedicated face, so people/themes could customize its
> appearance.  (By default, it could just inherit from `default`.)

Thanks for suggestion, will do on the second round after pushing the
initial version.

Message #50 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Thu, 05 Oct 2023 16:03:52 -0400

One interesting bug: project-switch-project causes the modeline project
name to change for all buffers.

For example if I do:

C-x p p emacs-29 RET f

then while I'm at the find-file prompt, all modelines for all buffers
show emacs-29 as the current project, no matter what they showed before
(even if they didn't show anything before)

Haven't thought at all about how to fix this, but we might want to think
about it in the context of bug#63648 where we've been rethinking the
implementation of project-switch-project.

Message #53 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66317: Project mode-line
Date: Thu, 5 Oct 2023 23:16:04 +0300

On 05/10/2023 23:03, Spencer Baugh wrote:
> then while I'm at the find-file prompt, all modelines for all buffers
> show emacs-29 as the current project, no matter what they showed before
> (even if they didn't show anything before)
> 
> Haven't thought at all about how to fix this, but we might want to think
> about it in the context of bug#63648 where we've been rethinking the
> implementation of project-switch-project.

This can be fixed with e.g. patch below.

Thank for the reminder about that report, BTW.

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 2e6ae89a443..867e4754622 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1990,8 +1990,11 @@ project-switch-project
   (let ((command (if (symbolp project-switch-commands)
                      project-switch-commands
                    (project--switch-project-command))))
-    (let ((project-current-directory-override dir))
-      (call-interactively command))))
+    (unwind-protect
+        (progn
+          (setq-local project-current-directory-override dir)
+          (call-interactively command))
+      (kill-local-variable 'project-current-directory-override))))

 ;;;###autoload
 (defun project-uniquify-dirname-transform (dirname)

Message #56 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Thu, 5 Oct 2023 23:23:17 +0300

On 04/10/2023 09:18, Juri Linkov wrote:
> diff --git a/lisp/bindings.el b/lisp/bindings.el
> index 207adb3a2a4..70e4087e131 100644
> --- a/lisp/bindings.el
> +++ b/lisp/bindings.el
> @@ -682,6 +682,7 @@ mode-line-end-spaces
>   	     'mode-line-buffer-identification
>   	     "   "
>   	     'mode-line-position
> +	     '(project-mode-line project-mode-line-format)
>   	     '(vc-mode vc-mode)
>   	     "  "
>   	     'mode-line-modes

Speaking of this change from the first patch, do we want to have 
project-mode-line automatically supported in Emacs <= 29, when they 
install the new version from ELPA? Can we safely do that?

Simply altering mode-line-format, as in the original patch, might mess 
up the custom mode-line the user had set up (or installed). How to only 
change the default mode-line is less obvious, but perhaps checking that 
the current value is equal to (get 'mode-line-format 'standard-value) 
would mean altering is okay.

Or otherwise we should say something in the docstring of 
project-mode-line: that it's only directly supported in Emacs 30, and in 
older versions the user need to add the corresponding entry to the 
mode-line-format by hand.

Message #61 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#66317: Project mode-line
Date: Fri, 06 Oct 2023 07:50:02 +0300

> Date: Thu, 5 Oct 2023 23:23:17 +0300
> Cc: 66317 <at> debbugs.gnu.org, me <at> eshelyaron.com
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 04/10/2023 09:18, Juri Linkov wrote:
> > diff --git a/lisp/bindings.el b/lisp/bindings.el
> > index 207adb3a2a4..70e4087e131 100644
> > --- a/lisp/bindings.el
> > +++ b/lisp/bindings.el
> > @@ -682,6 +682,7 @@ mode-line-end-spaces
> >   	     'mode-line-buffer-identification
> >   	     "   "
> >   	     'mode-line-position
> > +	     '(project-mode-line project-mode-line-format)
> >   	     '(vc-mode vc-mode)
> >   	     "  "
> >   	     'mode-line-modes
> 
> Speaking of this change from the first patch, do we want to have 
> project-mode-line automatically supported in Emacs <= 29, when they 
> install the new version from ELPA? Can we safely do that?
> 
> Simply altering mode-line-format, as in the original patch, might mess 
> up the custom mode-line the user had set up (or installed). How to only 
> change the default mode-line is less obvious, but perhaps checking that 
> the current value is equal to (get 'mode-line-format 'standard-value) 
> would mean altering is okay.
> 
> Or otherwise we should say something in the docstring of 
> project-mode-line: that it's only directly supported in Emacs 30, and in 
> older versions the user need to add the corresponding entry to the 
> mode-line-format by hand.

I think supporting it in Emacs 30 is fine.  It's a very minor feature,
after all, so let's not invest too much effort in it.

Message #64 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Fri, 06 Oct 2023 09:44:51 +0300

>> Speaking of this change from the first patch, do we want to have 
>> project-mode-line automatically supported in Emacs <= 29, when they 
>> install the new version from ELPA? Can we safely do that?
>> 
>> Simply altering mode-line-format, as in the original patch, might mess 
>> up the custom mode-line the user had set up (or installed). How to only 
>> change the default mode-line is less obvious, but perhaps checking that 
>> the current value is equal to (get 'mode-line-format 'standard-value) 
>> would mean altering is okay.
>> 
>> Or otherwise we should say something in the docstring of 
>> project-mode-line: that it's only directly supported in Emacs 30, and in 
>> older versions the user need to add the corresponding entry to the 
>> mode-line-format by hand.
>
> I think supporting it in Emacs 30 is fine.  It's a very minor feature,
> after all, so let's not invest too much effort in it.

Agreed.  No need to support it in older versions.  Moreover,
I'm trying to add another option to join project and vc indicators
on the mode-line that won't be possible to support in older versions.

Message #67 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Fri, 06 Oct 2023 09:46:06 +0300

> One interesting bug: project-switch-project causes the modeline project
> name to change for all buffers.
>
> For example if I do:
>
> C-x p p emacs-29 RET f
>
> then while I'm at the find-file prompt, all modelines for all buffers
> show emacs-29 as the current project, no matter what they showed before
> (even if they didn't show anything before)
>
> Haven't thought at all about how to fix this, but we might want to think
> about it in the context of bug#63648 where we've been rethinking the
> implementation of project-switch-project.

I don't see this bug because I'm using other-project-prefix from bug#63648 ;-)

Message #70 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: me <at> eshelyaron.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Fri, 6 Oct 2023 13:20:29 +0300

On 06/10/2023 09:44, Juri Linkov wrote:
> Agreed.  No need to support it in older versions.  Moreover,
> I'm trying to add another option to join project and vc indicators
> on the mode-line that won't be possible to support in older versions.

Then that needs to be explained in the docstring. project.el is 
installable in older versions.

Message #73 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 09 Oct 2023 21:10:31 +0300

>> Agreed.  No need to support it in older versions.  Moreover,
>> I'm trying to add another option to join project and vc indicators
>> on the mode-line that won't be possible to support in older versions.
>
> Then that needs to be explained in the docstring. project.el is installable
> in older versions.

Hopefully I explained this sufficiently well in the docstring
both for users of older versions and users who customized the
default mode line.

Message #76 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 9 Oct 2023 21:22:47 +0300

On 09/10/2023 21:10, Juri Linkov wrote:
>>> Agreed.  No need to support it in older versions.  Moreover,
>>> I'm trying to add another option to join project and vc indicators
>>> on the mode-line that won't be possible to support in older versions.
>> Then that needs to be explained in the docstring. project.el is installable
>> in older versions.
> Hopefully I explained this sufficiently well in the docstring
> both for users of older versions and users who customized the
> default mode line.

Not sure: I imagine that most users don't customize mode-line-format 
themselves, and thus don't know which contents it has.

I would append some clarification that in Emacs 30 the mode-line has 
that element by default.

Message #79 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 09 Oct 2023 21:45:37 +0300

>> Thanks, I've tried this patch on top of Emacs master and it seems to
>> work well.  One small suggestion is to consider giving the project name
>> in the mode line a dedicated face, so people/themes could customize its
>> appearance.  (By default, it could just inherit from `default`.)
>
> Thanks for suggestion, will do on the second round after pushing the
> initial version.

I'm not yet sure whether better to add a new face or a new variable like
grep-hit-face and xref-num-matches-face that refers to the existing face.
Then it would be possible to set such variable e.g. to the face `vc-state-base`
that inherits from `default`.

Message #82 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 09 Oct 2023 21:48:22 +0300

>>>> Agreed.  No need to support it in older versions.  Moreover,
>>>> I'm trying to add another option to join project and vc indicators
>>>> on the mode-line that won't be possible to support in older versions.
>>> Then that needs to be explained in the docstring. project.el is installable
>>> in older versions.
>> Hopefully I explained this sufficiently well in the docstring
>> both for users of older versions and users who customized the
>> default mode line.
>
> Not sure: I imagine that most users don't customize mode-line-format
> themselves, and thus don't know which contents it has.
>
> I would append some clarification that in Emacs 30 the mode-line has that
> element by default.

I'm not sure if this helps because a user might run Emacs 30
and still using some package that heavily modifies the mode line.
This will puzzle the user: why it doesn't work in Emacs 30
as documented.

Message #85 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 9 Oct 2023 21:52:39 +0300

On 09/10/2023 21:48, Juri Linkov wrote:
>>>>> Agreed.  No need to support it in older versions.  Moreover,
>>>>> I'm trying to add another option to join project and vc indicators
>>>>> on the mode-line that won't be possible to support in older versions.
>>>> Then that needs to be explained in the docstring. project.el is installable
>>>> in older versions.
>>> Hopefully I explained this sufficiently well in the docstring
>>> both for users of older versions and users who customized the
>>> default mode line.
>> Not sure: I imagine that most users don't customize mode-line-format
>> themselves, and thus don't know which contents it has.
>>
>> I would append some clarification that in Emacs 30 the mode-line has that
>> element by default.
> I'm not sure if this helps because a user might run Emacs 30
> and still using some package that heavily modifies the mode line.
> This will puzzle the user: why it doesn't work in Emacs 30
> as documented.

Hence "by default".

Mode-line package authors might be helped out by this explanation as well.

Message #88 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 09 Oct 2023 20:57:12 +0200

Juri Linkov <juri <at> linkov.net> writes:

>>> Thanks, I've tried this patch on top of Emacs master and it seems to
>>> work well.  One small suggestion is to consider giving the project name
>>> in the mode line a dedicated face, so people/themes could customize its
>>> appearance.  (By default, it could just inherit from `default`.)
>>
>> Thanks for suggestion, will do on the second round after pushing the
>> initial version.
>
> I'm not yet sure whether better to add a new face or a new variable like
> grep-hit-face and xref-num-matches-face that refers to the existing face.
> Then it would be possible to set such variable e.g. to the face `vc-state-base`
> that inherits from `default`.

Personally I think a variable pointing to a face name is a somewhat
redundant indirection, since customizing the face to inherit from some
other face is just as easy as customizing the variable to point to a
different face.  But either way works, of course.


Best,

Eshel

Message #91 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 09:50:52 +0300

>>>>>> Agreed.  No need to support it in older versions.  Moreover,
>>>>>> I'm trying to add another option to join project and vc indicators
>>>>>> on the mode-line that won't be possible to support in older versions.
>>>>> Then that needs to be explained in the docstring. project.el is installable
>>>>> in older versions.
>>>> Hopefully I explained this sufficiently well in the docstring
>>>> both for users of older versions and users who customized the
>>>> default mode line.
>>> Not sure: I imagine that most users don't customize mode-line-format
>>> themselves, and thus don't know which contents it has.
>>>
>>> I would append some clarification that in Emacs 30 the mode-line has that
>>> element by default.
>> I'm not sure if this helps because a user might run Emacs 30
>> and still using some package that heavily modifies the mode line.
>> This will puzzle the user: why it doesn't work in Emacs 30
>> as documented.
>
> Hence "by default".
>
> Mode-line package authors might be helped out by this explanation as well.

Maybe this would be sufficient:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 2475d7c403e..1d6c9c1cf1b 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -2109,7 +2109,8 @@ project-uniquify-dirname-transform
 (defcustom project-mode-line nil
   "Show the current project name with the menu on the mode line.
 This feature requires the presence of the following item in
-`mode-line-format': `(project-mode-line project-mode-line-format)'."
+`mode-line-format': `(project-mode-line project-mode-line-format)'
+that already exists by default in Emacs 30."
   :type 'boolean
   :group 'project
   :version "30.1")

Message #94 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 09:56:51 +0300

>>>> Thanks, I've tried this patch on top of Emacs master and it seems to
>>>> work well.  One small suggestion is to consider giving the project name
>>>> in the mode line a dedicated face, so people/themes could customize its
>>>> appearance.  (By default, it could just inherit from `default`.)
>>>
>>> Thanks for suggestion, will do on the second round after pushing the
>>> initial version.
>>
>> I'm not yet sure whether better to add a new face or a new variable like
>> grep-hit-face and xref-num-matches-face that refers to the existing face.
>> Then it would be possible to set such variable e.g. to the face `vc-state-base`
>> that inherits from `default`.
>
> Personally I think a variable pointing to a face name is a somewhat
> redundant indirection, since customizing the face to inherit from some
> other face is just as easy as customizing the variable to point to a
> different face.  But either way works, of course.

Probably adding a variable would be more suitable since currently
there are no faces defined in project.el at all.

Message #97 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 09:10:36 +0200

Juri Linkov <juri <at> linkov.net> writes:

>>>>>>> Agreed.  No need to support it in older versions.  Moreover,
>>>>>>> I'm trying to add another option to join project and vc indicators
>>>>>>> on the mode-line that won't be possible to support in older versions.
>>>>>> Then that needs to be explained in the docstring. project.el is installable
>>>>>> in older versions.
>>>>> Hopefully I explained this sufficiently well in the docstring
>>>>> both for users of older versions and users who customized the
>>>>> default mode line.
>>>> Not sure: I imagine that most users don't customize mode-line-format
>>>> themselves, and thus don't know which contents it has.
>>>>
>>>> I would append some clarification that in Emacs 30 the mode-line has that
>>>> element by default.
>>> I'm not sure if this helps because a user might run Emacs 30
>>> and still using some package that heavily modifies the mode line.
>>> This will puzzle the user: why it doesn't work in Emacs 30
>>> as documented.
>>
>> Hence "by default".
>>
>> Mode-line package authors might be helped out by this explanation as well.
>
> Maybe this would be sufficient:
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 2475d7c403e..1d6c9c1cf1b 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -2109,7 +2109,8 @@ project-uniquify-dirname-transform
>  (defcustom project-mode-line nil
>    "Show the current project name with the menu on the mode line.
>  This feature requires the presence of the following item in
> -`mode-line-format': `(project-mode-line project-mode-line-format)'."
> +`mode-line-format': `(project-mode-line project-mode-line-format)'
> +that already exists by default in Emacs 30."

To me, this description looks a bit too implementation-focused.  How
about the following?

    Show the name of the current project on the mode line.

    This option only works in Emacs 30 or later, for a similar effect in
    Emacs 29 or earlier add `project-mode-line-format' to your
    `mode-line-format' instead of using this option.

Message #100 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 09:18:41 +0200

Eshel Yaron <me <at> eshelyaron.com> writes:

> Juri Linkov <juri <at> linkov.net> writes:
>
>>
>> Maybe this would be sufficient:
>>
>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>> index 2475d7c403e..1d6c9c1cf1b 100644
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -2109,7 +2109,8 @@ project-uniquify-dirname-transform
>>  (defcustom project-mode-line nil
>>    "Show the current project name with the menu on the mode line.
>>  This feature requires the presence of the following item in
>> -`mode-line-format': `(project-mode-line project-mode-line-format)'."
>> +`mode-line-format': `(project-mode-line project-mode-line-format)'
>> +that already exists by default in Emacs 30."
>
> To me, this description looks a bit too implementation-focused.  How
> about the following?
>
>     Show the name of the current project on the mode line.
>
>     This option only works in Emacs 30 or later, for a similar effect in
>     Emacs 29 or earlier add `project-mode-line-format' to your
>     `mode-line-format' instead of using this option.

Correction, in the first line I meant to write:

    Whether to show the name of the current project on the mode line.


Best,

Eshel

Message #103 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eshel Yaron <me <at> eshelyaron.com>, Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 13:45:00 +0300

On 10/10/2023 10:10, Eshel Yaron wrote:
> Juri Linkov <juri <at> linkov.net> writes:
> 
>>>>>>>> Agreed.  No need to support it in older versions.  Moreover,
>>>>>>>> I'm trying to add another option to join project and vc indicators
>>>>>>>> on the mode-line that won't be possible to support in older versions.
>>>>>>> Then that needs to be explained in the docstring. project.el is installable
>>>>>>> in older versions.
>>>>>> Hopefully I explained this sufficiently well in the docstring
>>>>>> both for users of older versions and users who customized the
>>>>>> default mode line.
>>>>> Not sure: I imagine that most users don't customize mode-line-format
>>>>> themselves, and thus don't know which contents it has.
>>>>>
>>>>> I would append some clarification that in Emacs 30 the mode-line has that
>>>>> element by default.
>>>> I'm not sure if this helps because a user might run Emacs 30
>>>> and still using some package that heavily modifies the mode line.
>>>> This will puzzle the user: why it doesn't work in Emacs 30
>>>> as documented.
>>>
>>> Hence "by default".
>>>
>>> Mode-line package authors might be helped out by this explanation as well.
>>
>> Maybe this would be sufficient:
>>
>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>> index 2475d7c403e..1d6c9c1cf1b 100644
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -2109,7 +2109,8 @@ project-uniquify-dirname-transform
>>   (defcustom project-mode-line nil
>>     "Show the current project name with the menu on the mode line.
>>   This feature requires the presence of the following item in
>> -`mode-line-format': `(project-mode-line project-mode-line-format)'."
>> +`mode-line-format': `(project-mode-line project-mode-line-format)'
>> +that already exists by default in Emacs 30."
> 
> To me, this description looks a bit too implementation-focused.  How
> about the following?

I'm fine with either, but...

>      Show the name of the current project on the mode line.
> 
>      This option only works in Emacs 30 or later, for a similar effect in
>      Emacs 29 or earlier add `project-mode-line-format' to your
>      `mode-line-format' instead of using this option.

There might be a problem in the fact that it still won't work in Emacs 
30 if the user had customized the mode-line (or installed one of the 
packages that do).

Also: "in addition", not "instead".

Message #106 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 13:34:23 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

>> To me, this description looks a bit too implementation-focused.  How
>> about the following?
>
> I'm fine with either, but...
>
>>      Show the name of the current project on the mode line.
>>      This option only works in Emacs 30 or later, for a similar
>> effect in
>>      Emacs 29 or earlier add `project-mode-line-format' to your
>>      `mode-line-format' instead of using this option.
>
> There might be a problem in the fact that it still won't work in Emacs
> 30 if the user had customized the mode-line (or installed one of the
> packages that do).

I agree, perhaps we could say:

   Note that this feature relies on the default value of
   `mode-line-format' in Emacs 30 and later.  With a custom mode line,
   as well as on Emacs 29 or earlier, add `project-mode-line-format' to
   your `mode-line-format' instead of setting this option.

> Also: "in addition", not "instead".

There's no harm in adding `project-mode-line-format` to
`mode-line-format` in addition to setting `project-mode-line`, but I did
mean "instead" and not "in addition", since the value of
`project-mode-line` is irrelevant if you follow the suggestion to add
`project-mode-line-format` directly to `mode-line-format`.


Best,

Eshel

Message #109 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 14:42:11 +0300

On 10/10/2023 14:34, Eshel Yaron wrote:
> There's no harm in adding `project-mode-line-format` to
> `mode-line-format` in addition to setting `project-mode-line`, but I did
> mean "instead" and not "in addition", since the value of
> `project-mode-line` is irrelevant if you follow the suggestion to add
> `project-mode-line-format` directly to `mode-line-format`.

Understood. That creates two different documented ways to enable the 
feature, though. Maybe that's okay.

Message #112 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Eshel Yaron <me <at> eshelyaron.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Tue, 10 Oct 2023 14:46:49 +0300

On 10/10/2023 09:56, Juri Linkov wrote:
>>>>> Thanks, I've tried this patch on top of Emacs master and it seems to
>>>>> work well.  One small suggestion is to consider giving the project name
>>>>> in the mode line a dedicated face, so people/themes could customize its
>>>>> appearance.  (By default, it could just inherit from `default`.)
>>>> Thanks for suggestion, will do on the second round after pushing the
>>>> initial version.
>>> I'm not yet sure whether better to add a new face or a new variable like
>>> grep-hit-face and xref-num-matches-face that refers to the existing face.
>>> Then it would be possible to set such variable e.g. to the face `vc-state-base`
>>> that inherits from `default`.
>> Personally I think a variable pointing to a face name is a somewhat
>> redundant indirection, since customizing the face to inherit from some
>> other face is just as easy as customizing the variable to point to a
>> different face.  But either way works, of course.
> Probably adding a variable would be more suitable since currently
> there are no faces defined in project.el at all.

FWIW, I don't have a strong opinion.

Message #115 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 66317 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66317: Project mode-line
Date: Wed, 11 Oct 2023 09:27:50 +0300

>>>>>> Thanks, I've tried this patch on top of Emacs master and it seems to
>>>>>> work well.  One small suggestion is to consider giving the project name
>>>>>> in the mode line a dedicated face, so people/themes could customize its
>>>>>> appearance.  (By default, it could just inherit from `default`.)
>>>>> Thanks for suggestion, will do on the second round after pushing the
>>>>> initial version.
>>>> I'm not yet sure whether better to add a new face or a new variable like
>>>> grep-hit-face and xref-num-matches-face that refers to the existing face.
>>>> Then it would be possible to set such variable e.g. to the face `vc-state-base`
>>>> that inherits from `default`.
>>> Personally I think a variable pointing to a face name is a somewhat
>>> redundant indirection, since customizing the face to inherit from some
>>> other face is just as easy as customizing the variable to point to a
>>> different face.  But either way works, of course.
>> Probably adding a variable would be more suitable since currently
>> there are no faces defined in project.el at all.
>
> FWIW, I don't have a strong opinion.

Ok, added a face variable.

Message #118 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Juri Linkov <juri <at> linkov.net>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Sun, 15 Oct 2023 22:42:52 +0000 (UTC)

An issue with this as installed in master:  If I navigate to a file and
one of its ancestors is not readable by emacs, I'll get an error.

For example, when I visit /home/other/foo.txt, which is readable by me
even though /home/other is not, I get:

Error during redisplay: (eval (project-mode-line-format)) signaled
(permission-denied "Opening directory" "Permission denied"
"/home/other")

Here's one idea for a patch... but maybe we should be just flat-out
wrapping it in ignore-errors?

(BTW, I actually discovered this class of bug through
project-uniquify-dirname-transform, which is also affected by it, since
like project-mode-line, it runs project-current for basically every
buffer.  So if we ignore-errors in project-mode-line-format, we also
need that in project-uniquify-dirname-transform.  Maybe they should
share the lookup?)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index fd9c146a1fd..8bf1f4d0738 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -245,7 +245,8 @@ project-current
     pr))
 
 (defun project--find-in-directory (dir)
-  (run-hook-with-args-until-success 'project-find-functions dir))
+  (ignore-error (permission-denied)
+    (run-hook-with-args-until-success 'project-find-functions dir)))
 
 (defvar project--within-roots-fallback nil)
 

Message #121 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: sbaugh <at> catern.com, Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 16 Oct 2023 03:57:05 +0300

On 16/10/2023 01:42, sbaugh <at> catern.com wrote:
> -  (run-hook-with-args-until-success 'project-find-functions dir))
> +  (ignore-error (permission-denied)
> +    (run-hook-with-args-until-success 'project-find-functions dir)))

One minor problem: 'ignore-error' was added in Emacs 27, while 
project.el maintains compatibility with Emacs 26.1+.

Message #124 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> catern.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 16 Oct 2023 20:01:36 +0300

There is another problem: calling 'project-name' while evaluating
'mode-line-format' often changes the coding system mode-line indicator
from U (utf-8) to raw-text during saving the current buffer.

Here is a backtrace:

- project-name
- project--value-in-dir (that uses with-temp-buffer)
- hack-dir-local-variables-non-file-buffer
- hack-local-variables-apply

Then in the last function the coding system is broken
in two different ways:

1. by 'hack-one-local-variable' in `emacs -Q`
2. by (run-hooks 'hack-local-variables-hook)
   in buffers where flyspell-mode is enabled
   'flyspell-hack-local-variables-hook' breaks
   the coding system too.

Message #127 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, 66317 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#66317: Project mode-line
Date: Mon, 16 Oct 2023 22:12:19 +0300

> Cc: sbaugh <at> catern.com, 66317 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 16 Oct 2023 20:01:36 +0300
> 
> There is another problem: calling 'project-name' while evaluating
> 'mode-line-format' often changes the coding system mode-line indicator
> from U (utf-8) to raw-text during saving the current buffer.
> 
> Here is a backtrace:
> 
> - project-name
> - project--value-in-dir (that uses with-temp-buffer)
> - hack-dir-local-variables-non-file-buffer
> - hack-local-variables-apply
> 
> Then in the last function the coding system is broken
> in two different ways:
> 
> 1. by 'hack-one-local-variable' in `emacs -Q`

How and where?

> 2. by (run-hooks 'hack-local-variables-hook)
>    in buffers where flyspell-mode is enabled
>    'flyspell-hack-local-variables-hook' breaks
>    the coding system too.

Why?

Message #130 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, 66317 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#66317: Project mode-line
Date: Wed, 18 Oct 2023 20:20:31 +0300

>> There is another problem: calling 'project-name' while evaluating
>> 'mode-line-format' often changes the coding system mode-line indicator
>> from U (utf-8) to raw-text during saving the current buffer.
>>
>> Here is a backtrace:
>>
>> - project-name
>> - project--value-in-dir (that uses with-temp-buffer)
>> - hack-dir-local-variables-non-file-buffer
>> - hack-local-variables-apply
>>
>> Then in the last function the coding system is broken
>> in two different ways:
>>
>> 1. by 'hack-one-local-variable' in `emacs -Q`
>
> How and where?
>
>> 2. by (run-hooks 'hack-local-variables-hook)
>>    in buffers where flyspell-mode is enabled
>>    'flyspell-hack-local-variables-hook' breaks
>>    the coding system too.
>
> Why?

The bug occurs when multiple lines are displayed in the echo area.
Then '(:eval (project-mode-line-format)) is called twice.
At the end of the first call 'buffer-file-coding-system'
is still correct: utf-8.  But at the beginning of the
second call it's already wrong: raw-text.

I guess it was a mistake to allow specifying the project name
in .dir-locals.el.  A better place would be in ~/.emacs.d/projects.

Message #133 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> catern.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 18 Oct 2023 21:41:53 +0300

On 18/10/2023 20:20, Juri Linkov wrote:
> I guess it was a mistake to allow specifying the project name
> in .dir-locals.el.  A better place would be in ~/.emacs.d/projects.

But project-name uses project--value-in-dir which uses a temporary 
buffer to apply all variables in.

Does that affect the original buffer somehow?

Message #136 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: sbaugh <at> catern.com, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 18 Oct 2023 21:55:40 +0300

On 16/10/2023 20:01, Juri Linkov wrote:
> There is another problem: calling 'project-name' while evaluating
> 'mode-line-format' often changes the coding system mode-line indicator
> from U (utf-8) to raw-text during saving the current buffer.
> 
> Here is a backtrace:
> 
> - project-name
> - project--value-in-dir (that uses with-temp-buffer)
> - hack-dir-local-variables-non-file-buffer
> - hack-local-variables-apply

FWIW, I haven't been able to reproduce this so far.

Message #139 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> catern.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Thu, 19 Oct 2023 09:40:23 +0300

> FWIW, I haven't been able to reproduce this so far.

Unfortunately it's not easily reproducible.

>> The bug occurs when multiple lines are displayed in the echo area.
>> Then '(:eval (project-mode-line-format)) is called twice.
>> At the end of the first call 'buffer-file-coding-system'
>> is still correct: utf-8.  But at the beginning of the
>> second call it's already wrong: raw-text.
>>
>> I guess it was a mistake to allow specifying the project name
>> in .dir-locals.el.  A better place would be in ~/.emacs.d/projects.
>
> But project-name uses project--value-in-dir which uses a temporary buffer
> to apply all variables in.

So it does this extensive work several times per second every time
when the mode-line is updated?

Then maybe better to cache the project name somewhere? 

> Does that affect the original buffer somehow?

Actually it doesn't affect the original buffer directly.
When saving a buffer and the message is multi-line
during saving, then '(project-mode-line-format)' is called twice,
and the buffer coding is changed between these calls.

I don't know where is this code that decides to evaluate
mode-line-format twice in a row, and how this code is affected
by temporary buffers used by project--value-in-dir.

Message #142 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: sbaugh <at> catern.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Thu, 19 Oct 2023 14:23:28 +0300

On 19/10/2023 09:40, Juri Linkov wrote:
>> FWIW, I haven't been able to reproduce this so far.
> 
> Unfortunately it's not easily reproducible.
> 
>>> The bug occurs when multiple lines are displayed in the echo area.
>>> Then '(:eval (project-mode-line-format)) is called twice.
>>> At the end of the first call 'buffer-file-coding-system'
>>> is still correct: utf-8.  But at the beginning of the
>>> second call it's already wrong: raw-text.
>>>
>>> I guess it was a mistake to allow specifying the project name
>>> in .dir-locals.el.  A better place would be in ~/.emacs.d/projects.
>>
>> But project-name uses project--value-in-dir which uses a temporary buffer
>> to apply all variables in.
> 
> So it does this extensive work several times per second every time
> when the mode-line is updated?
> 
> Then maybe better to cache the project name somewhere?

There is an existing caching mechanism IIUC based on the dir-locals' 
file mtime (see the description in dir-locals-find-file), which is 
better than nothing.

We could add something on top of it, but it would have to be a cache 
keyed on the directory (because project-name should return the right 
value inside C-x p p <choose other project> k, for example), and it 
would be invalidated once every 5 seconds or so (or use some other more 
advanced logic, but I'm not sure which).

>> Does that affect the original buffer somehow?
> 
> Actually it doesn't affect the original buffer directly.
> When saving a buffer and the message is multi-line
> during saving, then '(project-mode-line-format)' is called twice,
> and the buffer coding is changed between these calls.

I suppose some global value like last-coding-system-used might create an 
interrelation between such calls. The use of a temp buffer should 
protect us from adverse effects, though.

> I don't know where is this code that decides to evaluate
> mode-line-format twice in a row, and how this code is affected
> by temporary buffers used by project--value-in-dir.

I'm not sure what to recommend, but some print-debugging could help. 
E.g. just add a (backtrace) call inside project-mode-line-format.

But that's a lot of output to sort through, so there's definitely room 
for improvement in this recipe.

Message #145 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, me <at> eshelyaron.com,
 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Fri, 20 Oct 2023 09:01:46 +0000

Juri Linkov <juri <at> linkov.net> writes:

> +(defvar project-menu-entry
> +  `(menu-item "Project" ,menu-bar-project-menu))
> +

This does not work in Emacs <=28:

  (void-variable menu-bar-project-menu)
  (list 'menu-item "Project" menu-bar-project-menu)
  (defvar project-menu-entry (list 'menu-item "Project" menu-bar-proje
  require(project)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #148 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Ihor Radchenko <yantar92 <at> posteo.net>, Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, me <at> eshelyaron.com
Subject: Re: bug#66317: Project mode-line
Date: Fri, 20 Oct 2023 18:52:34 +0300

On 20/10/2023 12:01, Ihor Radchenko wrote:
> Juri Linkov<juri <at> linkov.net>  writes:
> 
>> +(defvar project-menu-entry
>> +  `(menu-item "Project" ,menu-bar-project-menu))
>> +
> This does not work in Emacs <=28:
> 
>    (void-variable menu-bar-project-menu)
>    (list 'menu-item "Project" menu-bar-project-menu)
>    (defvar project-menu-entry (list 'menu-item "Project" menu-bar-proje
>    require(project)

I guess we'll need a compatibility definition for it.

Message #151 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> catern.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Mon, 23 Oct 2023 20:23:06 +0300

> I'm not sure what to recommend, but some print-debugging could
> help. E.g. just add a (backtrace) call inside project-mode-line-format.
>
> But that's a lot of output to sort through, so there's definitely room for
> improvement in this recipe.

Ok, here is 100% reproducible minimal test case:

0. emacs-30 -Q
1. eval:

(progn
  (require 'project)
  (setq project-mode-line t)
  (setq set-message-functions '(set-multi-message)))

2. in a temporary directory: M-! git init RET
3. C-x C-f .dir-locals.el RET
4. insert: ((fundamental-mode . ((mode . flyspell))))
5. C-x C-s

At this point even buffer-file-coding-system of .dir-locals.el
is changed to 't' (raw-text-unix).  The same happens when saving
any file in that project.

The problem doesn't occur when flyspell-mode is enabled from
file-local variables, only from dir-locals.

Message #154 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: sbaugh <at> catern.com, Eli Zaretskii <eliz <at> gnu.org>, 66317 <at> debbugs.gnu.org
Subject: Re: bug#66317: Project mode-line
Date: Wed, 25 Oct 2023 02:48:22 +0300

On 23/10/2023 20:23, Juri Linkov wrote:
>> I'm not sure what to recommend, but some print-debugging could
>> help. E.g. just add a (backtrace) call inside project-mode-line-format.
>>
>> But that's a lot of output to sort through, so there's definitely room for
>> improvement in this recipe.
> Ok, here is 100% reproducible minimal test case:
> 
> 0. emacs-30 -Q
> 1. eval:
> 
> (progn
>    (require 'project)
>    (setq project-mode-line t)
>    (setq set-message-functions '(set-multi-message)))
> 
> 2. in a temporary directory: M-! git init RET
> 3. C-x C-f .dir-locals.el RET
> 4. insert: ((fundamental-mode . ((mode . flyspell))))
> 5. C-x C-s
> 
> At this point even buffer-file-coding-system of .dir-locals.el
> is changed to 't' (raw-text-unix).  The same happens when saving
> any file in that project.
> 
> The problem doesn't occur when flyspell-mode is enabled from
> file-local variables, only from dir-locals.

I can repro. But it's as weird a bug as they come.

I guess it's a combination of using flyspell-mode and editing 
.dir-locals.el? Or have you seen other buffers' b-f-c-s changed this way 
too?

If not, it might have something to do with flyspell-mode's use of 
sit-for?.. But I'm only saying that because it's the only feature of 
this mode that I'm regularly reminded of.

I tried using a variable watcher:

  (add-variable-watcher
   'buffer-file-coding-system
   (lambda (_sym value op where)
    (message "%s %s %s" value op where)
    (if (eq 'raw-text-unix value) (backtrace))
   ))

but it just prints

prefer-utf-8-unix set  *temp*-925453 [2 times]
raw-text-unix set .dir-locals.el
  backtrace()
  (if (eq 'raw-text-unix value) (backtrace))
  (closure (t) (_sym value op where) (message "%s %s %s" value op 
where) (if (eq 'raw-text-unix value) 
(backtrace)))(buffer-file-coding-system raw-text-unix set #<buffer 
.dir-locals.el>)
  basic-save-buffer(t)
  save-buffer(1)
  funcall-interactively(save-buffer 1)
  call-interactively(save-buffer nil nil)
  command-execute(save-buffer)

OTOH, the bug is very reliable to reproduce: add the aforementioned line 
to dir-locals and save -> the coding system changes to raw-text. Delete 
the line and save -> and it's prefer-utf-8 again.

Message #157 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 66317 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
 me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66317: Project mode-line
Date: Tue, 31 Oct 2023 09:34:41 +0200

>>> +(defvar project-menu-entry
>>> +  `(menu-item "Project" ,menu-bar-project-menu))
>>> +
>> This does not work in Emacs <=28:
>>    (void-variable menu-bar-project-menu)
>>    (list 'menu-item "Project" menu-bar-project-menu)
>>    (defvar project-menu-entry (list 'menu-item "Project" menu-bar-proje
>>    require(project)
>
> I guess we'll need a compatibility definition for it.

This is fixed now.

To be able to close bug#66317, we also need to decide
what to do with these remaining patches:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66317#53
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66317#118

Message #160 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 66317 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
 me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66317: Project mode-line
Date: Wed, 1 Nov 2023 04:03:09 +0200

On 31/10/2023 09:34, Juri Linkov wrote:
>>>> +(defvar project-menu-entry
>>>> +  `(menu-item "Project" ,menu-bar-project-menu))
>>>> +
>>> This does not work in Emacs <=28:
>>>     (void-variable menu-bar-project-menu)
>>>     (list 'menu-item "Project" menu-bar-project-menu)
>>>     (defvar project-menu-entry (list 'menu-item "Project" menu-bar-proje
>>>     require(project)
>>
>> I guess we'll need a compatibility definition for it.
> 
> This is fixed now.

Thanks!

> To be able to close bug#66317, we also need to decide
> what to do with these remaining patches:
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66317#53
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66317#118

I've pushed the fixes for these two, let's see if anything comes up to 
invalidate those solutions.

Message #163 received at 66317 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 66317 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
 me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66317: Project mode-line
Date: Wed, 01 Nov 2023 09:32:54 +0200

close 66317 30.0.50
thanks

>> To be able to close bug#66317, we also need to decide
>> what to do with these remaining patches:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66317#53
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66317#118
>
> I've pushed the fixes for these two, let's see if anything comes up to
> invalidate those solutions.

Thanks.  So now closing this feature request since it seems
everything is done here.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.