emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simen Heggestøyl
Subject: Re: New feature in project.el: Remembering the previously used projects
Date: Tue, 02 Jun 2020 19:04:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

"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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]