From: Mark Walters <markwalters1009@gmail.com>
To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org
Subject: Re: [RFC PATCH 1/3] emacs: selection-menu.el
In-Reply-To: <1330009817-24148-1-git-send-email-tomi.ollila@iki.fi>
References: <1330009817-24148-1-git-send-email-tomi.ollila@iki.fi>
User-Agent: Notmuch/0.11.1+229~g7cd7c51 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Fri, 24 Feb 2012 23:36:23 +0000
Message-ID: <874nufx0qw.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Tomi Ollila <tomi.ollila@iki.fi>
Precedence: list

On Thu, 23 Feb 2012 17:10:15 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> RFC/Idea for "improving" some selections made (in notmuch or elsewhere)
> In the hope that this will be useful, and to get some improvement advice.
> 
> I've found it somewhat difficult to use completing-read (i also tried ido-)
> to complete email addresses for mail recipients (not only due to the
> large selection of choises provided by nottoomuch-addresses.sh ;)
> and have tried to find alternatives.
> 
> The buffer selection systems (electric-buffer-list, bs-show, etc) have been
> pretty useful but I haven't found anything general.
> 
> After some 3 iterations I've come up with something like those but for
> arbitraty strings and so-far named that tool 'selection-menu'
> 
> This works by popping up buffer with all the choices shown in separate
> lines. arrow keys (and c-p/c-n) can be used to choose string and
> RET/SPC to select that. Any other key will abort the selection (ESC
> mentioned spesifically as it never "unreads" any events).
> 
> If requested user not choosing anything but pressing some key that
> key is "unread" so that the parent buffer will get it. I did that
> as in first tests I wanted to continue writing If I did not choose
> anything... More tests will show If really didn't want to loose that
> event).

Hi 

I have played with this and I like the feel of it: it is much more
informative than completing-read and much less cluttered than
ido-completing-read. 

I have some queries though:

In some uses the user might want to choose something that is not offered
(not relevant for this particular use, but maybe relevant for other
notmuch uses like selecting a from address). Is this a design choice?

I think I would like to be able to type in the buffer it shows,
e.g. page down to page through lots of addresses, maybe ctrl-s for
searching. Another possibility would be for the selection to narrow as
extra characters are typed. Though in fact maybe your choice of leaving
the character is exactly right: then the caller can take the extra
character and call selection-menu again. (I had something which almost
worked and it seemed quite nice).

Finally, does this solution mean there is no "history" available?

Best wishes

Mark