all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Simen Heggestøyl" <simenheg@runbox.com>
To: "Philip K." <philip@warpmail.net>
Cc: contovob@tcd.ie, emacs-devel@gnu.org, dgutov@yandex.ru
Subject: Re: New feature in project.el: Remembering the previously used projects
Date: Tue, 02 Jun 2020 19:04:52 +0200	[thread overview]
Message-ID: <47369.1526263551$1591117726@news.gmane.org> (raw)
In-Reply-To: 87wo4tn2ap.fsf@warpmail.net

"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	other threads:[~2020-06-02 17:04 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 20:06 New feature in project.el: Remembering the previously used projects Dmitry Gutov
2020-05-28 23:05 ` Basil L. Contovounesios
2020-05-28 23:29   ` Dmitry Gutov
2020-05-29  7:31     ` Philip K.
2020-05-29 13:51       ` Dmitry Gutov
2020-05-29 15:54         ` Simen Heggestøyl
     [not found]         ` <871rn2ivne.fsf@simenheg@gmail.com>
2020-05-30 10:29           ` Philip K.
2020-06-02 17:04             ` Simen Heggestøyl [this message]
     [not found]             ` <5ed68784.1c69fb81.61518.35eeSMTPIN_ADDED_BROKEN@mx.google.com>
2020-06-03 11:28               ` Basil L. Contovounesios
2020-05-30 12:38           ` Dmitry Gutov
2020-06-02 17:14             ` Simen Heggestøyl
2020-05-30 21:57           ` Juri Linkov
2020-05-30 23:39             ` Dmitry Gutov
2020-06-01 23:01               ` Juri Linkov
2020-06-02 21:34                 ` Dmitry Gutov
2020-06-03 20:13                   ` Dmitry Gutov
2020-06-03 22:40                     ` Juri Linkov
2020-06-03 23:13                       ` Dmitry Gutov
2020-06-04 21:55                         ` Juri Linkov
2020-06-04 22:37                           ` Dmitry Gutov
2020-06-05  8:33                           ` Philip K.
2020-06-05  8:42                             ` Simen Heggestøyl
2020-06-05 11:44                             ` Dmitry Gutov
2020-06-05 11:59                               ` Philip K.
2020-06-05 13:59                                 ` Philip K.
2020-06-05 17:20                                   ` Dmitry Gutov
2020-06-06  1:24                                   ` Jamie Beardslee
2020-12-19 22:18                                     ` Dmitry Gutov
2020-06-06 23:46                             ` Juri Linkov
2020-06-07  0:40                               ` Dmitry Gutov
2020-06-07 22:38                                 ` Juri Linkov
2020-06-02 17:43             ` Simen Heggestøyl
     [not found]             ` <87a71l2wjf.fsf@simenheg@gmail.com>
2020-06-02 17:57               ` Dmitry Gutov
2020-06-03 22:34               ` Juri Linkov
2020-06-03 23:17                 ` Dmitry Gutov
2020-06-04 18:33                   ` Simen Heggestøyl
2020-06-04 21:58                   ` Juri Linkov
     [not found]             ` <5ed68fe1.1c69fb81.45e50.0c7cSMTPIN_ADDED_BROKEN@mx.google.com>
2020-06-03 11:28               ` Basil L. Contovounesios
2020-05-31 13:00           ` Dmitry Gutov
2020-06-02 17:51             ` Simen Heggestøyl
     [not found]             ` <87k10picej.fsf@simenheg@gmail.com>
2020-06-02 21:33               ` Dmitry Gutov
     [not found]         ` <5ed13064.1c69fb81.4bf5e.dc8eSMTPIN_ADDED_BROKEN@mx.google.com>
2020-06-03 11:28           ` Basil L. Contovounesios
2020-06-03 11:27     ` Basil L. Contovounesios
2020-06-03 11:47       ` Dmitry Gutov
2020-06-03 13:38         ` Basil L. Contovounesios
2020-06-03 19:15           ` Simen Heggestøyl
     [not found]           ` <87lfl4x8p0.fsf@simenheg@gmail.com>
2020-06-03 20:11             ` Dmitry Gutov
2020-06-04 18:19               ` Simen Heggestøyl
2020-05-29 22:55 ` Kévin Le Gouguec
2020-05-29 23:22   ` Dmitry Gutov
2020-05-29 23:31     ` Dmitry Gutov
2020-05-30  0:42     ` Dmitry Gutov
2020-05-30  6:05       ` Simen Heggestøyl
     [not found]       ` <5ed1f7ae.1c69fb81.9b99b.4ce7SMTPIN_ADDED_BROKEN@mx.google.com>
2020-05-30 12:42         ` Kévin Le Gouguec
2020-05-30 13:17           ` Dmitry Gutov
2020-05-30 17:05             ` Dmitry Gutov
2020-05-30 18:29               ` Kévin Le Gouguec
2020-06-02 17:29           ` Simen Heggestøyl
     [not found]       ` <877dwuc5zu.fsf@simenheg@gmail.com>
2020-05-30 13:21         ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='47369.1526263551$1591117726@news.gmane.org' \
    --to=simenheg@runbox.com \
    --cc=contovob@tcd.ie \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=philip@warpmail.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.