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

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

[Tomi Ollila]

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).
---
 emacs/selection-menu.el |   68 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)
 create mode 100644 emacs/selection-menu.el

diff --git a/emacs/selection-menu.el b/emacs/selection-menu.el
new file mode 100644
index 0000000..b65cef3
--- /dev/null
+++ b/emacs/selection-menu.el
@@ -0,0 +1,68 @@
+;;; selection-menu.el --- "generic" menu to choose one string.
+;;;
+;;; Author: Tomi Ollila -- too ät iki piste fi
+
+;;; License: GPLv2+
+
+(defun selection-menu (ident items &optional unread)
+  "Pops up a buffer listing lines given ITEMS one per line.
+Use arrow keys (and C-p/C-n) to select and SPC/RET to select.
+Return to parent buffer when any other key is pressed.
+In this case if optional UNREAD is non-nil return the
+read key back to input queue for parent to consume."
+  (if (eq (length items) 0) nil
+    (let ((helpmsg "Type ESC to abort, Space or Enter to select.")
+	  (saved-point (point))
+	  select buffer first last overlay pevent)
+      (save-window-excursion
+	(setq buffer (get-buffer-create " *Selection Menu*"))
+	(set-buffer buffer)
+	(setq buffer-read-only nil)
+	(kill-all-local-variables)
+	(erase-buffer)
+	(dolist (item items) (insert " " item "\n"))
+	(forward-line -1)
+	(setq last (point))
+	(goto-char (point-min))
+	(setq first (1+ (point)))
+	(pop-to-buffer buffer)
+	(setq mode-name "Selection Menu"
+	      mode-line-buffer-identification (concat "*" ident "*")
+	      buffer-read-only t
+	      overlay (make-overlay (point) (line-end-position)))
+	(overlay-put overlay 'face 'highlight)
+	(while
+	    (let ((event (read-key helpmsg)))
+	      (cond ((or (eq event 'up) (eq event 16))
+		     (when (> (point) first)
+		       (forward-line -1)
+		       (move-overlay overlay (point) (line-end-position)))
+		     t)
+		    ((or (eq event 'down) (eq event 14))
+		     (when (< (point) last)
+		       (forward-line)
+		       (move-overlay overlay (point) (line-end-position)))
+		     t)
+		    ((or (eq event 32) (eq event 13) (eq event 'return))
+		     (setq select
+			   (buffer-substring (1+ (point))
+					     (line-end-position)))
+		     nil)
+		    ((eq event 'escape)
+		     nil)
+		    (t (setq pevent event)
+		       nil)
+		    ))))
+      (goto-char saved-point)
+      (kill-buffer buffer)
+      (if (and unread pevent)
+	  (push pevent unread-command-events))
+      (message "")
+      select)))
+
+;;(selection-menu "foo" (list))
+;;(selection-menu "foo" (list "a"))
+;;(selection-menu "Send mail to:" (list "a" "b" "c" "d" "faaarao") t)
+;; test by entering c-x c-e at the end of previous lines
+
+(provide 'selection-menu)
-- 
1.7.8.2

[RFC PATCH 2/3] emacs: add selection-menu.el to Makefile.local

[Tomi Ollila]

In order for next patch to be easily useable, add
selection-menu.el to the build.
---
 emacs/Makefile.local |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 4fee0e8..ff1e0f9 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -14,7 +14,8 @@ emacs_sources := \
 	$(dir)/notmuch-message.el \
 	$(dir)/notmuch-crypto.el \
 	$(dir)/coolj.el \
-	$(dir)/notmuch-print.el
+	$(dir)/notmuch-print.el \
+	$(dir)/selection-menu.el
 
 emacs_images := \
 	$(srcdir)/$(dir)/notmuch-logo.png
-- 
1.7.8.2

[RFC PATCH 3/3] emacs: use selection-menu for recipient address completion

[Tomi Ollila]

Replace use of completing-read with selection-menu when
completing for recipient addresses.
---
 emacs/notmuch-address.el |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 2bf762b..1d63fe4 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -45,6 +45,8 @@ line."
 (defun notmuch-address-options (original)
   (process-lines notmuch-address-command original))
 
+(require 'selection-menu)
+
 (defun notmuch-address-expand-name ()
   (let* ((end (point))
 	 (beg (save-excursion
@@ -61,9 +63,7 @@ line."
 		  ((eq num-options 1)
 		   (car options))
 		  (t
-		   (completing-read (format "Address (%s matches): " num-options)
-				    (cdr options) nil nil (car options)
-				    'notmuch-address-history)))))
+		   (selection-menu "Send To:" options t)))))
     (if chosen
 	(progn
 	  (push chosen notmuch-address-history)
-- 
1.7.8.2

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

[Mark Walters]

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

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

[Tomi Ollila]

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

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

[Tom Prince]

On Fri, 24 Feb 2012 23:36:23 +0000, Mark Walters <markwalters1009@gmail.com> wrote:
> 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 wonder if the completion method should be customizable, rather than
forcing a particular one? There is at least, ido-mode, anything,
icicles, as various completion methods availble for emacs, suggesting
that it is a personal thing which method one prefers.

  Tom