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

["Basil L. Contovounesios" <contovob@tcd.ie>]

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