New feature in project.el: Remembering the previously used projects

New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

Hi all,

Thanks some good work by Simen, project commands (project-find-file, 
etc) now prompt you to choose among known projects, if currently outside 
of all project directories.

It's now on master.

There's also a new command, project-switch-project.

Please let us know how you like the change, and if you see any new problems.

Re: New feature in project.el: Remembering the previously used projects

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Thanks some good work by Simen, project commands (project-find-file, etc) now
> prompt you to choose among known projects, if currently outside of all project
> directories.
>
> It's now on master.
>
> There's also a new command, project-switch-project.

Thanks!

> Please let us know how you like the change, and if you see any new problems.

Only one feature request and some minor questions from me.

Can the project-list file name please be customisable?

Could the contents of the project-list file comprise easily readable,
printable, and even extensible sexps?

Could project-switch-project reuse read-multiple-choice or similar?

Isn't there a race here?

  (defun project--ensure-file-exists (filename)
    "Create an empty file FILENAME if it doesn't exist."
    (unless (file-exists-p filename)
      (with-temp-buffer
        (write-file filename))))

Why not use something like the following instead?

  (ignore-error file-already-exists
    (write-region "" nil filename nil 0 nil 'excl))

In fact, couldn't project--ensure-file-exists be eliminated altogether?
If the file doesn't exist, just don't set project--list, or set it to
nil.

Thanks,

-- 
Basil

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

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

On 29.05.2020 02:05, Basil L. Contovounesios wrote:

>> Please let us know how you like the change, and if you see any new problems.
> 
> Only one feature request and some minor questions from me.
> 
> Can the project-list file name please be customisable?

Of course. Just an omission.

> Could the contents of the project-list file comprise easily readable,
> printable, and even extensible sexps?
> 
> Could project-switch-project reuse read-multiple-choice or similar?

I'm attaching a patch that makes it use read-multiple-choice, check it 
out. But I'm not sure the result looks better than what we have now.

Suggestions on "similar" welcome.

> Isn't there a race here?
> 
>    (defun project--ensure-file-exists (filename)
>      "Create an empty file FILENAME if it doesn't exist."
>      (unless (file-exists-p filename)
>        (with-temp-buffer
>          (write-file filename))))
> 
> Why not use something like the following instead?
> 
>    (ignore-error file-already-exists
>      (write-region "" nil filename nil 0 nil 'excl))

Looks good to me. Let's see what Simen says.

> In fact, couldn't project--ensure-file-exists be eliminated altogether?
> If the file doesn't exist, just don't set project--list, or set it to
> nil.

Or that.

[-- Attachment #2: project-switch-read-multiple.diff --]
[-- Type: text/x-patch, Size: 1736 bytes --]

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 92293d0e2d..54bacc598e 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -805,15 +805,11 @@ project-switch-commands
 command to run when KEY is pressed.  LABEL is used to distinguish
 the choice in the dispatch menu.")
 
-(defun project--keymap-prompt ()
-  "Return a prompt for the project swithing dispatch menu."
-  (mapconcat
+(defun project--switch-choices ()
+  (mapcar
    (pcase-lambda (`(,key ,label))
-     (format "[%s] %s"
-             (propertize (key-description `(,key)) 'face 'bold)
-             label))
-   project-switch-commands
-   "  "))
+     (list (aref key 0) label))
+   project-switch-commands))
 
 ;;;###autoload
 (defun project-switch-project ()
@@ -822,17 +818,12 @@ project-switch-project
 and presented in a dispatch menu."
   (interactive)
   (let ((dir (project-prompt-project-dir))
-        (choice nil))
-    (while (not (and choice
-                     (or (equal choice (kbd "C-g"))
-                         (assoc choice project-switch-commands))))
-      (setq choice (read-key-sequence (project--keymap-prompt))))
-    (if (equal choice (kbd "C-g"))
-        (message "Quit")
-      (let ((default-directory dir)
-            (project-current-inhibit-prompt t))
-        (call-interactively
-         (nth 2 (assoc choice project-switch-commands)))))))
+        (choice (read-multiple-choice "Action:"
+                                      (project--switch-choices))))
+    (let ((default-directory dir)
+          (project-current-inhibit-prompt t))
+      (call-interactively
+       (nth 2 (assoc (string choice) project-switch-commands))))))
 
 (provide 'project)
 ;;; project.el ends here

Re: New feature in project.el: Remembering the previously used projects

[Philip K.]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.05.2020 02:05, Basil L. Contovounesios wrote:

>> Could project-switch-project reuse read-multiple-choice or similar?
>
> I'm attaching a patch that makes it use read-multiple-choice, check it
> out. But I'm not sure the result looks better than what we have now.
>
> Suggestions on "similar" welcome.

I tried to same thing last night, but didn't get around to submitting it
in time. It's mosty the same, I just dropped project--keymap-prompt and
changed the type of project-switch-commands, because it seemed easier
that way.

I think it can be improved by adding a "case-insenstive" option to
read-multiple-choice, because for example currently it seems to
highlight the second "f" in "Find file"
                                  ^
        this one here ____________|

I have tried something out, and will submit a patch right after this one.

-- 
	Philip K.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Reworked-project-switch-project-to-use-read-multiple.patch --]
[-- Type: text/x-diff, Size: 2959 bytes --]

From 8b320e00fbd89a3b8e9097b04cf307d3230e6ed6 Mon Sep 17 00:00:00 2001
From: Philip K <philip@warpmail.net>
Date: Fri, 29 May 2020 09:23:15 +0200
Subject: [PATCH] Reworked project-switch-project to use read-multiple-choice

---
 lisp/progmodes/project.el | 44 ++++++++++++++-------------------------
 1 file changed, 16 insertions(+), 28 deletions(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 92293d0e2d..cdc27d11f5 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -792,28 +792,21 @@ project-prompt-project-dir
 ;;; Project switching
 
 ;;;###autoload
-(defvar project-switch-commands
-  '(("f" "Find file" project-find-file)
-    ("s" "Find regexp" project-find-regexp)
-    ("d" "Dired" project-dired)
-    ("e" "Eshell" project-eshell))
+(defcustom project-switch-commands
+  '((?f "Find file" project-find-file)
+    (?s "Find regexp" project-find-regexp)
+    (?d "Dired" project-dired)
+    (?e "Eshell" project-eshell))
   "Alist mapping keys to project switching menu entries.
 Used by `project-switch-project' to construct a dispatch menu of
 commands available upon \"switching\" to another project.
 
 Each element looks like (KEY LABEL COMMAND), where COMMAND is the
 command to run when KEY is pressed.  LABEL is used to distinguish
-the choice in the dispatch menu.")
-
-(defun project--keymap-prompt ()
-  "Return a prompt for the project swithing dispatch menu."
-  (mapconcat
-   (pcase-lambda (`(,key ,label))
-     (format "[%s] %s"
-             (propertize (key-description `(,key)) 'face 'bold)
-             label))
-   project-switch-commands
-   "  "))
+the choice in the dispatch menu."
+  :type '(repeat (list (character :tag "Invocation Key")
+                       (string :tag "Label")
+                       (function :tag "Command"))))
 
 ;;;###autoload
 (defun project-switch-project ()
@@ -821,18 +814,13 @@ project-switch-project
 The available commands are picked from `project-switch-commands'
 and presented in a dispatch menu."
   (interactive)
-  (let ((dir (project-prompt-project-dir))
-        (choice nil))
-    (while (not (and choice
-                     (or (equal choice (kbd "C-g"))
-                         (assoc choice project-switch-commands))))
-      (setq choice (read-key-sequence (project--keymap-prompt))))
-    (if (equal choice (kbd "C-g"))
-        (message "Quit")
-      (let ((default-directory dir)
-            (project-current-inhibit-prompt t))
-        (call-interactively
-         (nth 2 (assoc choice project-switch-commands)))))))
+  (let* ((default-directory (project-prompt-project-dir))
+         (choice (read-multiple-choice
+                  "Open project via"
+                  (mapcar #'butlast project-switch-commands)))
+         (project-current-inhibit-prompt t))
+    (call-interactively
+     (nth 2 (assq (car choice) project-switch-commands)))))
 
 (provide 'project)
 ;;; project.el ends here
-- 
2.20.1

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 29.05.2020 10:31, Philip K. wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 29.05.2020 02:05, Basil L. Contovounesios wrote:
> 
>>> Could project-switch-project reuse read-multiple-choice or similar?
>>
>> I'm attaching a patch that makes it use read-multiple-choice, check it
>> out. But I'm not sure the result looks better than what we have now.
>>
>> Suggestions on "similar" welcome.
> 
> I tried to same thing last night, but didn't get around to submitting it
> in time. It's mosty the same, I just dropped project--keymap-prompt and
> changed the type of project-switch-commands, because it seemed easier
> that way.

Let's see what Simen thinks about this. FWIW, I somewhat prefer the 
current version.

> I think it can be improved by adding a "case-insenstive" option to
> read-multiple-choice, because for example currently it seems to
> highlight the second "f" in "Find file"
>                                    ^
>          this one here ____________|
> 
> I have tried something out, and will submit a patch right after this one.

A patch is good, but note that project.el is in ELPA now. So we might be 
unable to take advantage of the new version fully. Maybe with a version 
check, etc.

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

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

Hi Basil and Philip, thanks for checking it out!

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.05.2020 02:05, Basil L. Contovounesios wrote:
>
>> Can the project-list file name please be customisable?
>
> Of course. Just an omission.

Yup.

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Could the contents of the project-list file comprise easily readable,
> printable, and even extensible sexps?

I guess it could, but do you have any immediate use case in mind, or
were you thinking about easier forward compatibility in general?

I modeled the current approach after org-agenda-files, thinking that the
scheme with one project directory per line would be the easiest to edit
by hand.

> In fact, couldn't project--ensure-file-exists be eliminated altogether?
> If the file doesn't exist, just don't set project--list, or set it to
> nil.

Sounds good to me. How about the attached?

> Could project-switch-project reuse read-multiple-choice or similar?

There's definitely an advantage to reusing a function like that,
especially since it provides a more unified interface for the users.

I tested it with Philip's patch, but I have to agree with Dmitry in that
I prefer the current interface where the key choices are presented in
brackets next to the labels. I find it much easier to read the choices
at a glance compared to when the keys are made bold in midst of the
label texts. Also the "Find regexp" choice doesn't have an "s" in it, so
in that case read-multiple-choice puts the "s" in brackets instead,
making it non-uniform with the layout of the other choices.

The current approach where button choices are kept apart from the labels
is inspired by the Org Export Dispatcher and Magit's many menus, which I
think are excellent interfaces. If it turns out that more people, like
Dmitry and myself, like this approach better, maybe
read-multiple-choice's layout could be changed?

"Philip K." <philip@warpmail.net> writes:

> I think it can be improved by adding a "case-insenstive" option to
> read-multiple-choice, because for example currently it seems to
> highlight the second "f" in "Find file"
>                                   ^
>         this one here ____________|

Hm, won't that be a problem when the user wants to use the lower and
upper variants of the same character for different commands? That's done
extensively in Org Mode's Export Dispatcher for instance. The bracketed
layout approach has natural support for it however:

  [f] Find foo  [F] Find bar

-- Simen


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-project-ensure-file-exists.patch --]
[-- Type: text/x-diff, Size: 2154 bytes --]

From 4cb6cbb3776f142050cd70de279294cf98c63969 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Simen=20Heggest=C3=B8yl?= <simenheg@gmail.com>
Date: Fri, 29 May 2020 16:58:09 +0200
Subject: [PATCH] Remove 'project--ensure-file-exists'

* lisp/progmodes/project.el (project--ensure-file-exists): Remove.
(project--read-project-list): Set 'project--list' to nil when the
project list file doesn't exist.
---
 lisp/progmodes/project.el | 27 +++++++++++----------------
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 92293d0e2d..56087a7290 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -718,25 +718,20 @@ project-compile
 (defvar project--list 'unset
   "List of known project directories.")
 
-(defun project--ensure-file-exists (filename)
-  "Create an empty file FILENAME if it doesn't exist."
-  (unless (file-exists-p filename)
-    (with-temp-buffer
-      (write-file filename))))
-
 (defun project--read-project-list ()
   "Initialize `project--list' from the project list file."
   (let ((filename (locate-user-emacs-file "project-list")))
-    (project--ensure-file-exists filename)
-    (with-temp-buffer
-      (insert-file-contents filename)
-      (let ((dirs (split-string (buffer-string) "\n" t))
-            (project-list '()))
-        (dolist (dir dirs)
-          (cl-pushnew (file-name-as-directory dir)
-                      project-list
-                      :test #'equal))
-        (setq project--list (reverse project-list))))))
+    (setq project--list
+          (when (file-exists-p filename)
+            (with-temp-buffer
+              (insert-file-contents filename)
+              (let ((dirs (split-string (buffer-string) "\n" t))
+                    (project-list '()))
+                (dolist (dir dirs)
+                  (cl-pushnew (file-name-as-directory dir)
+                              project-list
+                              :test #'equal))
+                (reverse project-list)))))))
 
 (defun project--ensure-read-project-list ()
   "Initialize `project--list' if it hasn't already been."
-- 
2.26.2

Re: New feature in project.el: Remembering the previously used projects

[Philip K.]

Simen Heggestøyl <simenheg@runbox.com> writes:

> Hm, won't that be a problem when the user wants to use the lower and
> upper variants of the same character for different commands? That's done
> extensively in Org Mode's Export Dispatcher for instance. The bracketed
> layout approach has natural support for it however:
>
>   [f] Find foo  [F] Find bar

Is that intended? Org uses this for things like generate HTML in a file
or in a buffer, where the lowercase variant is what's more probable
(since you don't need to press the extra shift key). I can't think of
examples where something like this would be interesting when opening a
project? Or what would "foo" and "bar" be in your example? Find a file
or a directory?

I would have prefered read-multiple-choice, because the function is more
extensive than "just" a key-reading-loop, and seems to catch more
edge-cases.

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

"Philip K." <philip@warpmail.net> writes:

> Simen Heggestøyl <simenheg@runbox.com> writes:
>
>> Hm, won't that be a problem when the user wants to use the lower and
>> upper variants of the same character for different commands? That's done
>> extensively in Org Mode's Export Dispatcher for instance. The bracketed
>> layout approach has natural support for it however:
>>
>>   [f] Find foo  [F] Find bar
>
> Is that intended? Org uses this for things like generate HTML in a file
> or in a buffer, where the lowercase variant is what's more probable
> (since you don't need to press the extra shift key).

Yes, Org uses it for things that are similar to each other, like the
"Export to HTML" options:

  [h] As a HTML file  [H] As a HTML buffer

And Magit uses it for different log listing styles for instance:

  [l] Short  [L] Long

> I can't think of examples where something like this would be
> interesting when opening a project? Or what would "foo" and "bar" be
> in your example?

I didn't have anything specific in mind, just thinking why remove the
possibility if the user wishes to do so? Maybe "e" and "E" could be used
to launch different shells in the project root, for instance:

  [e] Shell  [E] Eshell

Or having string search and regexp search commands separately:

  [s] Find string  [S] Find regexp

> I would have prefered read-multiple-choice, because the function is
> more extensive than "just" a key-reading-loop, and seems to catch more
> edge-cases.

Me too. The only gripe I (and Dmitry) had with it was that we preferred
the layout of the current interface. For me it's because I find it hard
to distinguish the bold letters used by read-multiple-choice. Would it
be an option to change read-multiple-choice's prompt to use brackets to
distinguish key choices instead? If more people prefer it, making it the
default, or if not, at least adding it as an option? In that case I
wouldn't hesitate to change project-switch-project to use
read-multiple-choice.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Basil L. Contovounesios]

Simen Heggestøyl <simenheg@runbox.com> writes:

> "Philip K." <philip@warpmail.net> writes:
>
>> I would have prefered read-multiple-choice, because the function is
>> more extensive than "just" a key-reading-loop, and seems to catch more
>> edge-cases.
>
> Me too. The only gripe I (and Dmitry) had with it was that we preferred
> the layout of the current interface. For me it's because I find it hard
> to distinguish the bold letters used by read-multiple-choice. Would it
> be an option to change read-multiple-choice's prompt to use brackets to
> distinguish key choices instead? If more people prefer it, making it the
> default, or if not, at least adding it as an option? In that case I
> wouldn't hesitate to change project-switch-project to use
> read-multiple-choice.

+1 for making read-multiple-choice more flexible (and robust ;).

-- 
Basil

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 29.05.2020 18:54, Simen Heggestøyl wrote:
>> In fact, couldn't project--ensure-file-exists be eliminated altogether?
>> If the file doesn't exist, just don't set project--list, or set it to
>> nil.
> Sounds good to me. How about the attached?

Looks good to me.

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.05.2020 18:54, Simen Heggestøyl wrote:
>>> In fact, couldn't project--ensure-file-exists be eliminated altogether?
>>> If the file doesn't exist, just don't set project--list, or set it to
>>> nil.
>> Sounds good to me. How about the attached?
>
> Looks good to me.

Installed, thanks.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

>> Could the contents of the project-list file comprise easily readable,
>> printable, and even extensible sexps?
>
> I guess it could, but do you have any immediate use case in mind, or
> were you thinking about easier forward compatibility in general?
>
> I modeled the current approach after org-agenda-files, thinking that the
> scheme with one project directory per line would be the easiest to edit
> by hand.

Please use a more future-proof format like is used by saveplace.el,
for example, in ~/.emacs.d/places it's saved as:

  ;;; -*- coding: utf-8; mode: lisp-data -*-
  (("/tmp/"
    (dired-filename . "/tmp/file"))

that allows adding more metadata in future.  Also could you please
add a command to run shell, in addition to the already added eshell.

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 31.05.2020 00:57, Juri Linkov wrote:
> Also could you please
> add a command to run shell, in addition to the already added eshell.

Would you like to do the honors?

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

>> Also could you please
>> add a command to run shell, in addition to the already added eshell.
>
> Would you like to do the honors?

No problem, done.

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 02.06.2020 02:01, Juri Linkov wrote:
>>> Also could you please
>>> add a command to run shell, in addition to the already added eshell.
>> Would you like to do the honors?
> No problem, done.

Thanks!

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

Hi Juri,

On 03.06.2020 00:34, Dmitry Gutov wrote:
>>>> Also could you please
>>>> add a command to run shell, in addition to the already added eshell.
>>> Would you like to do the honors?
>> No problem, done.

Regarding the key binding change you have done in that patch, which of 
the following two options do you prefer?

- Move project-eshell to 'e', project-shell to 'E', project-find-regexp 
back to 's',
- Or move project-find-regexp to 'g'.

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

>>>>> Also could you please
>>>>> add a command to run shell, in addition to the already added eshell.
>>>> Would you like to do the honors?
>>> No problem, done.
>
> Regarding the key binding change you have done in that patch, which of the
> following two options do you prefer?
>
> - Move project-eshell to 'e', project-shell to 'E', project-find-regexp
>   back to 's',

The problem is that there is no mnemonic connection between
'E' and 'project-shell'.  'E' stands for 'Emacs' in 'Emacs-Shell' (eshell).

> - Or move project-find-regexp to 'g'.

If you have no plans to implement 'project-grep' then 'g' should be fine.

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 04.06.2020 01:40, Juri Linkov wrote:
>>>>>> Also could you please
>>>>>> add a command to run shell, in addition to the already added eshell.
>>>>> Would you like to do the honors?
>>>> No problem, done.
>>
>> Regarding the key binding change you have done in that patch, which of the
>> following two options do you prefer?
>>
>> - Move project-eshell to 'e', project-shell to 'E', project-find-regexp
>>    back to 's',
> 
> The problem is that there is no mnemonic connection between
> 'E' and 'project-shell'.  'E' stands for 'Emacs' in 'Emacs-Shell' (eshell).

They both have 'e' in their names. If we imagine that both 's' and 'h' 
are taken (the latter standing for 'help', maybe), then 'e' is kind of a 
natural choice.

And maybe 'search' is more important than 'shell', as far as the choice 
for 's' goes.

The main thought behind this option is that 'shell' and 'eshell' are not 
too different, so it should make sense to put them on the same letter.

>> - Or move project-find-regexp to 'g'.
> 
> If you have no plans to implement 'project-grep' then 'g' should be fine.

While I might not, it can't stop somebody else, especially if that's for 
their personal config only. But we could also use 'G' for it.

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

>>> - Move project-eshell to 'e', project-shell to 'E', project-find-regexp
>>>    back to 's',
>> The problem is that there is no mnemonic connection between
>> 'E' and 'project-shell'.  'E' stands for 'Emacs' in 'Emacs-Shell' (eshell).
>
> They both have 'e' in their names. If we imagine that both 's' and 'h' are
> taken (the latter standing for 'help', maybe), then 'e' is kind of
> a natural choice.

Maybe it's not too bad when read-multiple-choice will underline
the letter ‘e’ in ‘shell’ in the prompt with:

  (read-multiple-choice "Switch project"
                        '((?E "Eshell")
                          (?e "shell")
                          (?h "help")))

so the prompt will be: _E_shell, sh_e_ll, _h_elp

> And maybe 'search' is more important than 'shell', as far as the choice for
> 's' goes.

Is it possible to use key sequences, e.g. ‘s h’ for ‘shell’, ‘s e’ for ‘search’?

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 05.06.2020 00:55, Juri Linkov wrote:

>> They both have 'e' in their names. If we imagine that both 's' and 'h' are
>> taken (the latter standing for 'help', maybe), then 'e' is kind of
>> a natural choice.
> 
> Maybe it's not too bad when read-multiple-choice will underline
> the letter ‘e’ in ‘shell’ in the prompt with:
> 
>    (read-multiple-choice "Switch project"
>                          '((?E "Eshell")
>                            (?e "shell")
>                            (?h "help")))
> 
> so the prompt will be: _E_shell, sh_e_ll, _h_elp

Sure. But we not using read-multiple-choice, or at least not yet.

>> And maybe 'search' is more important than 'shell', as far as the choice for
>> 's' goes.
> 
> Is it possible to use key sequences, e.g. ‘s h’ for ‘shell’, ‘s e’ for ‘search’?

Provided someone implements it, sure.

But if we'd put two commands on the same letter this way, I'd rather we 
use two similar ones, again shell and eshell. And keep 'search' 
separate. I'm pretty sure the latter is going to be used more often, so 
it deserves a separate letter.

Re: New feature in project.el: Remembering the previously used projects

[Philip K.]

Juri Linkov <juri@linkov.net> writes:

> Is it possible to use key sequences, e.g. ‘s h’ for ‘shell’, ‘s e’ for ‘search’?

Don't most people tend to use either shell, eshell or some other
terminal application? If I were to use shell, over eshell, I guess that
this would be somewhat annoying, at least by default.

I was thinking that a "x" key could be added, which would invoke
execute-extended-command, but in the project root.

-- 
	Philip K.

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

philip@warpmail.net (Philip K.) writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> Is it possible to use key sequences, e.g. ‘s h’ for ‘shell’, ‘s e’ for ‘search’?
>
> Don't most people tend to use either shell, eshell or some other
> terminal application? If I were to use shell, over eshell, I guess that
> this would be somewhat annoying, at least by default.

Agreed.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 05.06.2020 11:33, Philip K. wrote:
> Juri Linkov <juri@linkov.net> writes:
> 
>> Is it possible to use key sequences, e.g. ‘s h’ for ‘shell’, ‘s e’ for ‘search’?
> 
> Don't most people tend to use either shell, eshell or some other
> terminal application? If I were to use shell, over eshell, I guess that
> this would be somewhat annoying, at least by default.

So what are you saying? Which option would you prefer?

Simply by the statement above, I'd probably choose to have only one of 
the commands in the default set, expecting the user to customize it, if 
they routinely use the other. And Eshell seems to be a tiny bit more 
popular (though I could be wrong here).

> I was thinking that a "x" key could be added, which would invoke
> execute-extended-command, but in the project root.

Why not. Would you like to send a patch?

Re: New feature in project.el: Remembering the previously used projects

[Philip K.]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05.06.2020 11:33, Philip K. wrote:
>> Juri Linkov <juri@linkov.net> writes:
>> 
>>> Is it possible to use key sequences, e.g. ‘s h’ for ‘shell’, ‘s e’ for ‘search’?
>> 
>> Don't most people tend to use either shell, eshell or some other
>> terminal application? If I were to use shell, over eshell, I guess that
>> this would be somewhat annoying, at least by default.
>
> So what are you saying? Which option would you prefer?

I was questioning how many people switch between eshell and shell, so
that both would have to be part of the menu. One way out would be to
have a user option for "prefered shell", either in Emacs or as part of
project.el.

> Simply by the statement above, I'd probably choose to have only one of 
> the commands in the default set, expecting the user to customize it, if 
> they routinely use the other. And Eshell seems to be a tiny bit more 
> popular (though I could be wrong here).
>
>> I was thinking that a "x" key could be added, which would invoke
>> execute-extended-command, but in the project root.
>
> Why not. Would you like to send a patch?

Sure, I'll try it out.

-- 
	Philip K.

Re: New feature in project.el: Remembering the previously used projects

[Philip K.]

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

philip@warpmail.net (Philip K.) writes:

> Sure, I'll try it out.

An initial attempt attached below. It seems like everything works, the
only thing I wasn't sure about was execute-extended-command's "typed"
argument, since it seems to always be nil, when invoked interactivly?

-- 
	Philip K.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-project-execute-command.patch --]
[-- Type: text/x-diff, Size: 1404 bytes --]

From 192bdfe0b775c0456fe0ec45b58134b3d2630913 Mon Sep 17 00:00:00 2001
From: Philip K <philip@warpmail.net>
Date: Fri, 5 Jun 2020 15:07:04 +0200
Subject: [PATCH] Add project-execute-command

---
 lisp/progmodes/project.el | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index a94a27dbc2..e8c35a0fb1 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -744,6 +744,15 @@ project-compile
          (default-directory (project-root pr)))
     (compile command comint)))
 
+;;;###autoload
+(defun project-execute-command (prefix command)
+  "Execute an extended COMMAND in project root."
+  (interactive (list current-prefix-arg
+                     (read-extended-command)))
+  (let* ((pr (project-current t))
+         (default-directory (project-root pr)))
+    (execute-extended-command prefix command)))
+
 \f
 ;;; Project list
 
@@ -830,7 +839,8 @@ project-switch-commands
     ("d" "Dired" project-dired)
     ("v" "VC-Dir" project-vc-dir)
     ("s" "Shell" project-shell)
-    ("e" "Eshell" project-eshell))
+    ("e" "Eshell" project-eshell)
+    ("x" "Execute command" project-execute-command))
   "Alist mapping keys to project switching menu entries.
 Used by `project-switch-project' to construct a dispatch menu of
 commands available upon \"switching\" to another project.
-- 
2.26.2

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 05.06.2020 16:59, Philip K. wrote:
> philip@warpmail.net (Philip K.) writes:
> 
>> Sure, I'll try it out.
> 
> An initial attempt attached below.

Thank you.

Should it be -execute-command or -execute-extended-command?

> It seems like everything works, the
> only thing I wasn't sure about was execute-extended-command's "typed"
> argument, since it seems to always be nil, when invoked interactivly?

It seems to be set during previous invocation?

In any case, it's only used for shorter typing suggestions, so it's 
probably not important here.

Re: New feature in project.el: Remembering the previously used projects

[Jamie Beardslee]

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

"Philip K." <philip@warpmail.net> writes:

> An initial attempt attached below. It seems like everything works, the
> only thing I wasn't sure about was execute-extended-command's "typed"
> argument, since it seems to always be nil, when invoked interactivly?

I have no idea what's going on with that typed argument, but maybe it
would be more sensible to use `call-interactively' just in case?

(defun project-execute-extended-command ()
  "Execute an extended command in project root."
  (declare (interactive-only command-execute))
  (interactive)
  (let ((default-directory
	  (project-root (project-current t))))
    (call-interactively #'execute-extended-command)))

--
Jamie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 519 bytes --]

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

Hi all,

On 06.06.2020 04:24, Jamie Beardslee wrote:
> "Philip K."<philip@warpmail.net>  writes:
> 
>> An initial attempt attached below. It seems like everything works, the
>> only thing I wasn't sure about was execute-extended-command's "typed"
>> argument, since it seems to always be nil, when invoked interactivly?
> I have no idea what's going on with that typed argument, but maybe it
> would be more sensible to use `call-interactively' just in case?
> 
> (defun project-execute-extended-command ()
>    "Execute an extended command in project root."
>    (declare (interactive-only command-execute))
>    (interactive)
>    (let ((default-directory
> 	  (project-root (project-current t))))
>      (call-interactively #'execute-extended-command)))

Sorry for the, uh, delay.

I've pushed this now in 32e781b2. Thanks!

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

> Don't most people tend to use either shell, eshell or some other
> terminal application? If I were to use shell, over eshell, I guess that
> this would be somewhat annoying, at least by default.

I wonder why people who prefer eshell, don't enable it with

  (fset 'shell 'eshell)

Then the project menu could have just one entry 'shell'.

> I was thinking that a "x" key could be added, which would invoke
> execute-extended-command, but in the project root.

Or as a more general solution a prefix key sequence could be added
like recently was added a prefix key sequence 'C-x t t' to run the
next command in a new tab, a similar key like 'C-x p p' could be used
to run the next command in the project root.

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 07.06.2020 02:46, Juri Linkov wrote:
>> Don't most people tend to use either shell, eshell or some other
>> terminal application? If I were to use shell, over eshell, I guess that
>> this would be somewhat annoying, at least by default.
> 
> I wonder why people who prefer eshell, don't enable it with
> 
>    (fset 'shell 'eshell)

I thought the point of 'shell' was that 'eshell' doesn't handle all 
possible programs you could run in it? For those cases, people would run 
'shell'.

The above line would make that harder.

> Then the project menu could have just one entry 'shell'.

A slightly longer line can change the entry in project-switch-commands.

>> I was thinking that a "x" key could be added, which would invoke
>> execute-extended-command, but in the project root.
> 
> Or as a more general solution a prefix key sequence could be added
> like recently was added a prefix key sequence 'C-x t t' to run the
> next command in a new tab, a similar key like 'C-x p p' could be used
> to run the next command in the project root.

It's a good idea, and we really should have a command like that.

But, for commands that are present in the switch menu, it would still be 
more economical to use project-switch-project, right? I mean, as far as 
the total number of keypresses goes.

BTW, I thought 'C-x p p' would be for 'project-switch-project'. But 
maybe people have a different idea, it's not a strong preference.

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

>>> I was thinking that a "x" key could be added, which would invoke
>>> execute-extended-command, but in the project root.
>> Or as a more general solution a prefix key sequence could be added
>> like recently was added a prefix key sequence 'C-x t t' to run the
>> next command in a new tab, a similar key like 'C-x p p' could be used
>> to run the next command in the project root.
>
> It's a good idea, and we really should have a command like that.
>
> But, for commands that are present in the switch menu, it would still be
> more economical to use project-switch-project, right? I mean, as far as 
> the total number of keypresses goes.

Indeed, these shortcuts make key sequences much shorter.
Perhaps 'project-switch-project' even could use 'set-transient-map'
with a normal keymap?

> BTW, I thought 'C-x p p' would be for 'project-switch-project'. But maybe
> people have a different idea, it's not a strong preference.

Maybe, it seems the prefix 'C-x p' is free to use for project commands.

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Juri Linkov <juri@linkov.net> writes:

> Please use a more future-proof format like is used by saveplace.el,
> for example, in ~/.emacs.d/places it's saved as:
>
>   ;;; -*- coding: utf-8; mode: lisp-data -*-
>   (("/tmp/"
>     (dired-filename . "/tmp/file"))
>
> that allows adding more metadata in future.

Looks good to me. If Dmitry agrees I can start working on changing the
format.

Maybe it should be renamed from "project-list" to simply "projects" too
while we're at it, to match similar files, like "places", "bookmarks",
and so on?

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 02.06.2020 20:43, Simen Heggestøyl wrote:
> Looks good to me. If Dmitry agrees I can start working on changing the
> format.

I'm fine with it. Up to you, really.

> Maybe it should be renamed from "project-list" to simply "projects" too
> while we're at it, to match similar files, like "places", "bookmarks",
> and so on?

OK, sure.

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

>> Please use a more future-proof format like is used by saveplace.el,
>> for example, in ~/.emacs.d/places it's saved as:
>>
>>   ;;; -*- coding: utf-8; mode: lisp-data -*-
>>   (("/tmp/"
>>     (dired-filename . "/tmp/file"))
>>
>> that allows adding more metadata in future.
>
> Looks good to me. If Dmitry agrees I can start working on changing the
> format.

While using this new feature, I discovered that switching projects
by directory is not quite handy, directory strings are too long
and begin with the same prefix.

I think there is a need for an additional command to switch projects by name.

A clear advantage of Lisp data is that in this case project names
could be saved in the same file ~/.emacs.d/projects, e.g.:

  (("/project/path/"
    (name . "Project name"))

or after implementing the proposal from bug#41572 to use .dir-locals.el,
then maybe to save the project name in .dir-locals.el like

  ((nil . ((project-name . "Project name")

A separate question is how to assign a name to a project.

> Maybe it should be renamed from "project-list" to simply "projects" too
> while we're at it, to match similar files, like "places", "bookmarks",
> and so on?

Indeed, "projects" is much better.  "project-list" looks like that ugly
directory name "\Program Files" that caused much trouble to people on
MS-Windows whereas it should have been named just "\Programs".

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 04.06.2020 01:34, Juri Linkov wrote:

> While using this new feature, I discovered that switching projects
> by directory is not quite handy, directory strings are too long
> and begin with the same prefix.

Interesting. It's not really the case here, but I imagine how it is 
possible to be true for many people.

> I think there is a need for an additional command to switch projects by name.
> 
> A clear advantage of Lisp data is that in this case project names
> could be saved in the same file ~/.emacs.d/projects, e.g.:
> 
>    (("/project/path/"
>      (name . "Project name"))
> 
> or after implementing the proposal from bug#41572 to use .dir-locals.el,
> then maybe to save the project name in .dir-locals.el like
> 
>    ((nil . ((project-name . "Project name")

That's an option, but I wonder if we could do without it:

> A separate question is how to assign a name to a project.

One way to avoid that, is to generate project names on the fly, in a 
uniquify fashion. If base directory names are unique, use those. 
Otherwise, prepend their parent names, and so on.

And we won't need a separate command. The exact strategy could be a user 
option, though.

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04.06.2020 01:34, Juri Linkov wrote:
>
>> While using this new feature, I discovered that switching projects
>> by directory is not quite handy, directory strings are too long
>> and begin with the same prefix.
>
> Interesting. It's not really the case here, but I imagine how it is
> possible to be true for many people.

Same. I'm using Ivy for completion though, maybe that plays a role.

>> I think there is a need for an additional command to switch projects by name.
>> A clear advantage of Lisp data is that in this case project names
>> could be saved in the same file ~/.emacs.d/projects, e.g.:
>>    (("/project/path/"
>>      (name . "Project name"))
>> or after implementing the proposal from bug#41572 to use
>> .dir-locals.el,
>> then maybe to save the project name in .dir-locals.el like
>>    ((nil . ((project-name . "Project name")
>
> That's an option, but I wonder if we could do without it:
>
>> A separate question is how to assign a name to a project.
>
> One way to avoid that, is to generate project names on the fly, in a
> uniquify fashion. If base directory names are unique, use those. 
> Otherwise, prepend their parent names, and so on.
>
> And we won't need a separate command.

Generating the names on the fly in a uniquify fashion sounds like good
idea to me (in the beginning this feature feature actually did just
that, but I later changed it to what we have now for simplicity).

> The exact strategy could be a user option, though.

Yep. I imagine different ways the name could be derived from the path
automatically (also supporting name = path like we have now), and maybe
even an option to let users specify the name manually whenever a new
project is encountered.

Juri Linkov <juri@linkov.net> writes:

>> Maybe it should be renamed from "project-list" to simply "projects" too
>> while we're at it, to match similar files, like "places", "bookmarks",
>> and so on?
>
> Indeed, "projects" is much better.  "project-list" looks like that ugly
> directory name "\Program Files" that caused much trouble to people on
> MS-Windows whereas it should have been named just "\Programs".

Done.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Juri Linkov]

> One way to avoid that, is to generate project names on the fly, in
> a uniquify fashion. If base directory names are unique, use those.
> Otherwise, prepend their parent names, and so on.

Maybe like reading filenames in project-find-file
that truncates long directory names.  Or like uniquify indeed.

Re: New feature in project.el: Remembering the previously used projects

[Basil L. Contovounesios]

Simen Heggestøyl <simenheg@runbox.com> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> Please use a more future-proof format like is used by saveplace.el,
>> for example, in ~/.emacs.d/places it's saved as:
>>
>>   ;;; -*- coding: utf-8; mode: lisp-data -*-
>>   (("/tmp/"
>>     (dired-filename . "/tmp/file"))
>>
>> that allows adding more metadata in future.
>
> Looks good to me. If Dmitry agrees I can start working on changing the
> format.
>
> Maybe it should be renamed from "project-list" to simply "projects" too
> while we're at it, to match similar files, like "places", "bookmarks",
> and so on?

SGTM.  Thanks,

-- 
Basil

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 29.05.2020 18:54, Simen Heggestøyl wrote:
>> On 29.05.2020 02:05, Basil L. Contovounesios wrote:
>>
>>> Can the project-list file name please be customisable?
>> Of course. Just an omission.
> Yup.

Simen what do you say?

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 2d0b6c4a21..70ee8d11ed 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -93,6 +93,10 @@
  (require 'cl-generic)
  (eval-when-compile (require 'subr-x))

+(defgroup project nil
+  "Operations on the current project."
+  :group 'tools)
+
  (defvar project-find-functions (list #'project-try-vc)
    "Special hook to find the project containing a given directory.
  Each functions on this hook is called in turn with one
@@ -249,6 +253,7 @@ project-vc-merge-submodules
  After changing this variable (using Customize or .dir-locals.el)
  you might have to restart Emacs to see the effect."
    :type 'boolean
+  :version "28.1"
    :package-version '(project . "0.2.0")
    :safe 'booleanp)

@@ -601,6 +606,7 @@ project-read-file-name-function
                   (const :tag "Read with completion from absolute names"
                          project--read-file-absolute)
                   (function :tag "Custom function" nil))
+  :group 'project
    :version "27.1")

  (defun project--read-file-cpd-relative (prompt
@@ -716,6 +722,11 @@ project-compile
  \f
  ;;; Project list

+(defcustom project-list-file (locate-user-emacs-file "project-list")
+  "File to save the list of known projects list."
+  :type 'string
+  :group 'project)
+
  (defvar project--list 'unset
    "List of known project directories.")

@@ -727,7 +738,7 @@ project--ensure-file-exists

  (defun project--read-project-list ()
    "Initialize `project--list' from the project list file."
-  (let ((filename (locate-user-emacs-file "project-list")))
+  (let ((filename project-list-file))
      (project--ensure-file-exists filename)
      (with-temp-buffer
        (insert-file-contents filename)
@@ -746,7 +757,7 @@ project--ensure-read-project-list

  (defun project--write-project-list ()
    "Persist `project--list' to the project list file."
-  (let ((filename (locate-user-emacs-file "project-list")))
+  (let ((filename project-list-file))
      (with-temp-buffer
        (insert (string-join project--list "\n"))
        (write-region nil nil filename nil 'silent))))

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.05.2020 18:54, Simen Heggestøyl wrote:
>>> On 29.05.2020 02:05, Basil L. Contovounesios wrote:
>>>
>>>> Can the project-list file name please be customisable?
>>> Of course. Just an omission.
>> Yup.
>
> Simen what do you say?

I think there's a "list" too much in project-list-file's docstring,
otherwise it looks good to me.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 02.06.2020 20:51, Simen Heggestøyl wrote:
> I think there's a "list" too much in project-list-file's docstring,
> otherwise it looks good to me.

Ah, yes. Already fixed locally, but thanks for the reminder!

Pushed to master.

Re: New feature in project.el: Remembering the previously used projects

[Basil L. Contovounesios]

Simen Heggestøyl <simenheg@runbox.com> writes:

>> On 29.05.2020 02:05, Basil L. Contovounesios wrote:
>>
>> Could the contents of the project-list file comprise easily readable,
>> printable, and even extensible sexps?
>
> I guess it could, but do you have any immediate use case in mind, or
> were you thinking about easier forward compatibility in general?

I was thinking in terms of both Emacs' natural lingua franca, the sexp
(i.e. what's easiest to read from and write to disc), as well as forward
compatibility.  (What happens if project.el decides it needs to store
more information - is it going to start littering
user-emacs-directory with more files?)

> I modeled the current approach after org-agenda-files, thinking that the
> scheme with one project directory per line would be the easiest to edit
> by hand.

Ideally users would edit the list via interactive commands that keep
disc and memory contents in sync, rather than by editing the file
directly.  But either way, Emacs is good at editing sexps too.  There's
no need to follow Org's example here.

>> Could project-switch-project reuse read-multiple-choice or similar?
>
> There's definitely an advantage to reusing a function like that,
> especially since it provides a more unified interface for the users.
>
> I tested it with Philip's patch, but I have to agree with Dmitry in that
> I prefer the current interface where the key choices are presented in
> brackets next to the labels. I find it much easier to read the choices
> at a glance compared to when the keys are made bold in midst of the
> label texts. Also the "Find regexp" choice doesn't have an "s" in it, so
> in that case read-multiple-choice puts the "s" in brackets instead,
> making it non-uniform with the layout of the other choices.
>
> The current approach where button choices are kept apart from the labels
> is inspired by the Org Export Dispatcher and Magit's many menus, which I
> think are excellent interfaces. If it turns out that more people, like
> Dmitry and myself, like this approach better, maybe
> read-multiple-choice's layout could be changed?

Indeed, I think it would be nice to eventually be able to use
read-multiple-choice, but it's not quite up to scratch yet.

Thanks,

-- 
Basil

Re: New feature in project.el: Remembering the previously used projects

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.05.2020 02:05, Basil L. Contovounesios wrote:
>
>> Could the contents of the project-list file comprise easily readable,
>> printable, and even extensible sexps?
>> Could project-switch-project reuse read-multiple-choice or similar?
>
> I'm attaching a patch that makes it use read-multiple-choice, check it
> out.

Thanks.

> But I'm not sure the result looks better than what we have now.

You're right, it doesn't look as good, and what we have now is fine.

But as far as I'm concerned that's a bug with read-multiple-choice that
should eventually be fixed so that it can be used in more places.

With that in mind, I wonder whether project-switch-commands should use
character rather than string keys.  Or would that be too limiting?

-- 
Basil

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 03.06.2020 14:27, Basil L. Contovounesios wrote:
> With that in mind, I wonder whether project-switch-commands should use
> character rather than string keys.  Or would that be too limiting?

That would probably make it more compatible to use with 
read-multiple-choice.

The downsides: a bit less readable for the casual reader, I guess? And 
if keys a strings, the feature could be extended to handle full key 
sequences, maybe. But I'm not sure this is really needed.

Let's hear from Simen thinks.

Re: New feature in project.el: Remembering the previously used projects

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03.06.2020 14:27, Basil L. Contovounesios wrote:
>> With that in mind, I wonder whether project-switch-commands should use
>> character rather than string keys.  Or would that be too limiting?
>
> That would probably make it more compatible to use with read-multiple-choice.
>
> The downsides: a bit less readable for the casual reader, I guess? And if keys a
> strings, the feature could be extended to handle full key sequences, maybe. But
> I'm not sure this is really needed.

Perhaps read-multiple-choice will be extended to support both one day...

> Let's hear from Simen thinks.

Of course.

-- 
Basil

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 03.06.2020 14:27, Basil L. Contovounesios wrote:
>>> With that in mind, I wonder whether project-switch-commands should use
>>> character rather than string keys.  Or would that be too limiting?
>>
>> That would probably make it more compatible to use with read-multiple-choice.
>>
>> The downsides: a bit less readable for the casual reader, I guess? And if keys a
>> strings, the feature could be extended to handle full key sequences, maybe. But
>> I'm not sure this is really needed.
>
> Perhaps read-multiple-choice will be extended to support both one day...

I think compatibility with read-multiple-choice outweighs those
downsides. Then if read-multiple-choice is extended to support both one
day, project-switch-commands can grow with it (after we've changed
project-switch-project to use read-multiple-choice).

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 03.06.2020 22:15, Simen Heggestøyl wrote:
> I think compatibility with read-multiple-choice outweighs those
> downsides. Then if read-multiple-choice is extended to support both one
> day, project-switch-commands can grow with it (after we've changed
> project-switch-project to use read-multiple-choice).

Makes sense. Do you want to push that change, or should I?

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03.06.2020 22:15, Simen Heggestøyl wrote:
>> I think compatibility with read-multiple-choice outweighs those
>> downsides. Then if read-multiple-choice is extended to support both one
>> day, project-switch-commands can grow with it (after we've changed
>> project-switch-project to use read-multiple-choice).
>
> Makes sense. Do you want to push that change, or should I?

I did now, hope it looks okay.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Kévin Le Gouguec]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Please let us know how you like the change, and if you see any new problems.

This is a nice addition!

I have one gripe with it though: I've rigged frame-title-format to show
the basename of the project root directory[1], which means I have a call
to project-current on every redisplay.

IIUC, when default-directory is inside a project, project-current now
calls project--add-to-project-list-front, which in turn calls
project--write-project-list.

This slows down redisplay quite noticeably on my end[2].  I don't know
what the best solution would be; does it sound acceptable to add an
optional SKIP-LIST-UPDATE argument for project-current, or is it too
much trouble for this peculiar use-case?


At any rate, thanks for enhancing project.el.


[1] https://gitlab.com/peniblec/dotfiles/-/blob/0812042b76691c704d902acd7710350648bd9344/.emacs#L377

[2] Just typing is enough for me to notice it; it's even more noticeable
    if you e.g. bind C-x o to this function:

    (defun my/other-window (count &optional all-frames)
      (interactive "p")
      (let ((repeat-map (make-sparse-keymap)))
        (define-key repeat-map [?o] #'other-window)
        (set-transient-map repeat-map t)
        (other-window count all-frames)))

    … then split a window, hit C-x o and keep "o" pressed.  Sticking a
    counter in other-window suggests that there's no actual slowdown;
    visually though, before this feature, the focused window changed
    very rapidly, while with this feature the focus change is only
    visible every second or so.

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 30.05.2020 01:55, Kévin Le Gouguec wrote:

> I have one gripe with it though: I've rigged frame-title-format to show
> the basename of the project root directory[1], which means I have a call
> to project-current on every redisplay.

First thought: you can cache it based it the value of default-directory. 
Which should cut down on these calls (which trigger directory 
traversals, etc) dramatically, and should be an improvement either way.

> IIUC, when default-directory is inside a project, project-current now
> calls project--add-to-project-list-front, which in turn calls
> project--write-project-list.
> 
> This slows down redisplay quite noticeably on my end[2].  I don't know
> what the best solution would be; does it sound acceptable to add an
> optional SKIP-LIST-UPDATE argument for project-current, or is it too
> much trouble for this peculiar use-case?

And another thought: maybe we should only add a project to the project 
list if user interaction happened (i.e. going through 
project-prompt-project-dir). Simen, what do you think?

The patch below mostly does that, except it misses the case when a 
directory was selected from project-switch-project. To fix that, we 
could either duplicate the bit of logic there, or undo, in part, the 
commit 9f88356b6770fb710c47e277dbdb4ba31b463d08 (turn 
project-prompt-project-dir back into project-prompt-project, to return a 
project instance, and handle the addition to history in there).

Anyway, the quick patch:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 1f2a4e8471..2611b04680 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -114,10 +114,11 @@ project-current
       ((unless project-current-inhibit-prompt
          maybe-prompt)
        (setq dir (project-prompt-project-dir)
-            pr (project--find-in-directory dir))))
-    (if pr
-        (project--add-to-project-list-front pr)
-      (project--remove-from-project-list dir)
+            pr (project--find-in-directory dir))
+      (if pr
+          (project--add-to-project-list-front pr)
+        (project--remove-from-project-list dir))))
+    (unless pr
        (setq pr (cons 'transient dir)))
      pr))

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 30.05.2020 02:22, Dmitry Gutov wrote:
> First thought: you can cache it based it the value of default-directory. 
> Which should cut down on these calls (which trigger directory 
> traversals, etc) dramatically, and should be an improvement either way.

Although... project-try-vc already performs caching based on the current 
directory. Which might be enough for a lot of scenarios.

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 30.05.2020 02:22, Dmitry Gutov wrote:
> And another thought: maybe we should only add a project to the project 
> list if user interaction happened (i.e. going through 
> project-prompt-project-dir). Simen, what do you think?

Alternatively, we could defer writing the file until Emacs is being 
closed (and do that in kill-emacs-hook).

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Dmitry Gutov <dgutov@yandex.ru> writes:

> And another thought: maybe we should only add a project to the project
> list if user interaction happened (i.e. going through
> project-prompt-project-dir). Simen, what do you think?
>
> The patch below mostly does that, except it misses the case when a
> directory was selected from project-switch-project. [...]

Hm, I think it misses all cases when project-switch-project is used,
since project-current will find the project using
project--find-in-directory (project-switch-project already did the
prompting part).

Maybe a simple solution could be to only write to the file when the
addition caused the project list to change? I think it's a good change
regardless, but is it enough to fix your issue, Kévin?

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 1f2a4e8471..a2ef84e444 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -751,14 +751,15 @@ project--write-project-list
       (write-region nil nil filename nil 'silent))))

 (defun project--add-to-project-list-front (pr)
-  "Add project PR to the front of the project list and save it.
-Return PR."
+  "Add project PR to the front of the project list.
+Save the result to disk if the project list was changed."
   (project--ensure-read-project-list)
-  (let ((dir (project-root pr)))
+  (let* ((dir (project-root pr))
+         (do-write (not (equal (car project--list) dir))))
     (setq project--list (delete dir project--list))
-    (push dir project--list))
-  (project--write-project-list)
-  pr)
+    (push dir project--list)
+    (when do-write
+      (project--write-project-list))))

 (defun project--remove-from-project-list (pr-dir)
   "Remove directory PR-DIR from the project list.

Dmitry Gutov <dgutov@yandex.ru> writes:

> Alternatively, we could defer writing the file until Emacs is being
> closed (and do that in kill-emacs-hook).

Maybe. I think doing it more eagerly has some advantages though if we
can make it work:

- Launching a new Emacs session while another one is running will use
  the latest project list.

- If there's any problem writing to the file I imagine it's better to be
  notified about it up front rather than at the time Emacs is killed.

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Kévin Le Gouguec]

Simen Heggestøyl <simenheg@runbox.com> writes:

> Maybe a simple solution could be to only write to the file when the
> addition caused the project list to change? I think it's a good change
> regardless, but is it enough to fix your issue, Kévin?

It is, thank you!

(Though I've just noticed that project-current now returns transient
projects unconditionally when project--find-in-directory returns nil;
since I'm not interested in showing transient projects in the frame
title, I might just go with project-try-vc like Dmitry suggested…)

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 30.05.2020 15:42, Kévin Le Gouguec wrote:
> (Though I've just noticed that project-current now returns transient
> projects unconditionally when project--find-in-directory returns nil;

BTW, that's a bug. :-(

> since I'm not interested in showing transient projects in the frame
> title, I might just go with project-try-vc like Dmitry suggested…)

Not really what I was suggesting.

Here's another patch you can try, it should cover both problems:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 1f2a4e8471..2d0b6c4a21 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -115,10 +115,11 @@ project-current
          maybe-prompt)
        (setq dir (project-prompt-project-dir)
              pr (project--find-in-directory dir))))
-    (if pr
-        (project--add-to-project-list-front pr)
-      (project--remove-from-project-list dir)
-      (setq pr (cons 'transient dir)))
+    (when maybe-prompt
+      (if pr
+          (project--add-to-project-list-front pr)
+        (project--remove-from-project-list dir)
+        (setq pr (cons 'transient dir))))
      pr))

  (defun project--find-in-directory (dir)

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 30.05.2020 16:17, Dmitry Gutov wrote:
> Here's another patch you can try, it should cover both problems:
> 
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 1f2a4e8471..2d0b6c4a21 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -115,10 +115,11 @@ project-current
>           maybe-prompt)
>         (setq dir (project-prompt-project-dir)
>               pr (project--find-in-directory dir))))
> -    (if pr
> -        (project--add-to-project-list-front pr)
> -      (project--remove-from-project-list dir)
> -      (setq pr (cons 'transient dir)))
> +    (when maybe-prompt
> +      (if pr
> +          (project--add-to-project-list-front pr)
> +        (project--remove-from-project-list dir)
> +        (setq pr (cons 'transient dir))))
>       pr))
> 
>   (defun project--find-in-directory (dir)

Pushed to master, since it was a definite bug. Thanks for reporting.

Re: New feature in project.el: Remembering the previously used projects

[Kévin Le Gouguec]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 30.05.2020 16:17, Dmitry Gutov wrote:
>> Here's another patch you can try, it should cover both problems:
>>  <snip>
>
> Pushed to master, since it was a definite bug. Thanks for reporting.

Thanks!  That pretty much solves my only issue with these changes
AFAICT.

(And sorry for misreading your earlier messages.)

Re: New feature in project.el: Remembering the previously used projects

[Simen Heggestøyl]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Simen Heggestøyl <simenheg@runbox.com> writes:
>
>> Maybe a simple solution could be to only write to the file when the
>> addition caused the project list to change? I think it's a good change
>> regardless, but is it enough to fix your issue, Kévin?
>
> It is, thank you!

Good, I've pushed the fix to master. Thanks!

-- Simen

Re: New feature in project.el: Remembering the previously used projects

[Dmitry Gutov]

On 30.05.2020 09:05, Simen Heggestøyl wrote:

>> The patch below mostly does that, except it misses the case when a
>> directory was selected from project-switch-project. [...]
> 
> Hm, I think it misses all cases when project-switch-project is used,
> since project-current will find the project using
> project--find-in-directory (project-switch-project already did the
> prompting part).

Yes, I mentioned that downside. See another patch I just posted.

> Maybe a simple solution could be to only write to the file when the
> addition caused the project list to change? I think it's a good change
> regardless, but is it enough to fix your issue, Kévin?

Seems like a good idea either way.

> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Alternatively, we could defer writing the file until Emacs is being
>> closed (and do that in kill-emacs-hook).
> 
> Maybe. I think doing it more eagerly has some advantages though if we
> can make it work:
> 
> - Launching a new Emacs session while another one is running will use
>    the latest project list.
> 
> - If there's any problem writing to the file I imagine it's better to be
>    notified about it up front rather than at the time Emacs is killed.

If that's your preference, let's go with it.

Note that the above downsides are common for other features that use 
kill-emacs-hook, so we're probably used to them. And I wouldn't say that 
the project list is really critical to avoid losing. So I'm fine with 
either.