bug#66317: Project mode-line

bug#66317: Project mode-line

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: project-mode-line.patch --]
[-- Type: text/x-diff, Size: 1005 bytes --]

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

bug#66317: Project mode-line

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Juri Linkov <juri@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

bug#66317: Project mode-line

[Dmitry Gutov]

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

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Eli Zaretskii]

> Cc: 66317@debbugs.gnu.org, Eshel Yaron <me@eshelyaron.com>
> From: Juri Linkov <juri@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.

bug#66317: Project mode-line

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: project-mode-line.patch --]
[-- Type: text/x-diff, Size: 1579 bytes --]

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

bug#66317: Project mode-line

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@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

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Spencer Baugh]

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.

bug#66317: Project mode-line

[Dmitry Gutov]

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)

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@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

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dmitry@gutov.dev,  66317@debbugs.gnu.org,  me@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?

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

>> +;;;###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.

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Eli Zaretskii]

> Date: Thu, 5 Oct 2023 23:23:17 +0300
> Cc: 66317@debbugs.gnu.org, me@eshelyaron.com
> From: Dmitry Gutov <dmitry@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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@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.

bug#66317: Project mode-line

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eshel Yaron <me@eshelyaron.com> writes:

> Juri Linkov <juri@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

bug#66317: Project mode-line

[Dmitry Gutov]

On 10/10/2023 10:10, Eshel Yaron wrote:
> Juri Linkov <juri@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".

bug#66317: Project mode-line

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dmitry@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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Ihor Radchenko]

Juri Linkov <juri@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>

bug#66317: Project mode-line

[Dmitry Gutov]

On 20/10/2023 12:01, Ihor Radchenko wrote:
> Juri Linkov<juri@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.

bug#66317: Project mode-line

[Juri Linkov]

>>> +(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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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.

bug#66317: Project mode-line

[Stefan Kangas]

Juri Linkov <juri@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.

bug#66317: Project mode-line

[sbaugh]

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)
 

bug#66317: Project mode-line

[Dmitry Gutov]

On 16/10/2023 01:42, sbaugh@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+.

bug#66317: Project mode-line

[Juri Linkov]

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.

bug#66317: Project mode-line

[Eli Zaretskii]

> Cc: sbaugh@catern.com, 66317@debbugs.gnu.org
> From: Juri Linkov <juri@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?

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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?

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Juri Linkov]

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

bug#66317: Project mode-line

[Dmitry Gutov]

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.

bug#66317: Project mode-line

[Dmitry Gutov]

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.