Re: [RFC PATCH 1/3] emacs: selection-menu.el

[Tomi Ollila <tomi.ollila@iki.fi>]

On Fri, 24 Feb 2012 23:36:23 +0000, Mark Walters <markwalters1009@gmail.com> wrote:
> 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?

"This is evolution, not intelligent design" ;) I.e. this was done for
particular purpose, i.e completing To: field -- there choosing something
that is not offered can be written in the To: field directly (or the 
completion can be edited afterwards)... Also in case of selecting address
one can go back to the 'From:' field and edit that...

> 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. 

I've thought of this (among other things too). Narrowing would be simple
but expanding when deleting (especially when deleting past initial search)
is something... thought expand so fast that... I've settled using/testing the
current version and thinking more options if need/urge arises...

> 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. 

Yes, maybe... :)

> (I had something which almost worked and it seemed quite nice).
> 
> Finally, does this solution mean there is no "history" available?

I'm not familiar with this "history" feature, so currently yes. But
depending how history works it might be applicable to add in a form
or another. Also, if there is use for this outside of my current
use case then how to implement all desired features are something
to think of. I've so far thought some more args or layering or something
to make this more generic. 

> 
> Best wishes
> 
> Mark

Thanks for interest

Tomi