--- /dev/null
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 86171431FBF\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Feb 2012 19:53:55 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.804\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.804 tagged_above=-999 required=5\r
+ tests=[DATE_IN_PAST_12_24=0.804] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id D2FC3bEtB2sx for <notmuch@notmuchmail.org>;\r
+ Sat, 25 Feb 2012 19:53:54 -0800 (PST)\r
+Received: from guru.guru-group.fi (guru-group.fi [87.108.86.66])\r
+ by olra.theworths.org (Postfix) with ESMTP id 1DF56431FBD\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Feb 2012 19:53:54 -0800 (PST)\r
+Received: by guru.guru-group.fi (Postfix, from userid 501)\r
+ id D1D7568055; Sat, 25 Feb 2012 15:48:22 +0200 (EET)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC PATCH 1/3] emacs: selection-menu.el\r
+In-Reply-To: <874nufx0qw.fsf@qmul.ac.uk>\r
+References: <1330009817-24148-1-git-send-email-tomi.ollila@iki.fi>\r
+ <874nufx0qw.fsf@qmul.ac.uk>\r
+User-Agent: Notmuch/0.11.1+225~g90fb4e8 (http://notmuchmail.org) Emacs/23.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Sat, 25 Feb 2012 15:48:22 +0200\r
+Message-ID: <m2pqd3ja6x.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 26 Feb 2012 03:53:55 -0000\r
+\r
+On Fri, 24 Feb 2012 23:36:23 +0000, Mark Walters <markwalters1009@gmail.com> wrote:\r
+> On Thu, 23 Feb 2012 17:10:15 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
+> > RFC/Idea for "improving" some selections made (in notmuch or elsewhere)\r
+> > In the hope that this will be useful, and to get some improvement advice.\r
+> > \r
+> > I've found it somewhat difficult to use completing-read (i also tried ido-)\r
+> > to complete email addresses for mail recipients (not only due to the\r
+> > large selection of choises provided by nottoomuch-addresses.sh ;)\r
+> > and have tried to find alternatives.\r
+> > \r
+> > The buffer selection systems (electric-buffer-list, bs-show, etc) have been\r
+> > pretty useful but I haven't found anything general.\r
+> > \r
+> > After some 3 iterations I've come up with something like those but for\r
+> > arbitraty strings and so-far named that tool 'selection-menu'\r
+> > \r
+> > This works by popping up buffer with all the choices shown in separate\r
+> > lines. arrow keys (and c-p/c-n) can be used to choose string and\r
+> > RET/SPC to select that. Any other key will abort the selection (ESC\r
+> > mentioned spesifically as it never "unreads" any events).\r
+> > \r
+> > If requested user not choosing anything but pressing some key that\r
+> > key is "unread" so that the parent buffer will get it. I did that\r
+> > as in first tests I wanted to continue writing If I did not choose\r
+> > anything... More tests will show If really didn't want to loose that\r
+> > event).\r
+> \r
+> Hi \r
+> \r
+> I have played with this and I like the feel of it: it is much more\r
+> informative than completing-read and much less cluttered than\r
+> ido-completing-read. \r
+> \r
+> I have some queries though:\r
+> \r
+> In some uses the user might want to choose something that is not offered\r
+> (not relevant for this particular use, but maybe relevant for other\r
+> notmuch uses like selecting a from address). Is this a design choice?\r
+\r
+"This is evolution, not intelligent design" ;) I.e. this was done for\r
+particular purpose, i.e completing To: field -- there choosing something\r
+that is not offered can be written in the To: field directly (or the \r
+completion can be edited afterwards)... Also in case of selecting address\r
+one can go back to the 'From:' field and edit that...\r
+\r
+> I think I would like to be able to type in the buffer it shows,\r
+> e.g. page down to page through lots of addresses, maybe ctrl-s for\r
+> searching. Another possibility would be for the selection to narrow as\r
+> extra characters are typed. \r
+\r
+I've thought of this (among other things too). Narrowing would be simple\r
+but expanding when deleting (especially when deleting past initial search)\r
+is something... thought expand so fast that... I've settled using/testing the\r
+current version and thinking more options if need/urge arises...\r
+\r
+> Though in fact maybe your choice of leaving\r
+> the character is exactly right: then the caller can take the extra\r
+> character and call selection-menu again. \r
+\r
+Yes, maybe... :)\r
+\r
+> (I had something which almost worked and it seemed quite nice).\r
+> \r
+> Finally, does this solution mean there is no "history" available?\r
+\r
+I'm not familiar with this "history" feature, so currently yes. But\r
+depending how history works it might be applicable to add in a form\r
+or another. Also, if there is use for this outside of my current\r
+use case then how to implement all desired features are something\r
+to think of. I've so far thought some more args or layering or something\r
+to make this more generic. \r
+\r
+> \r
+> Best wishes\r
+> \r
+> Mark\r
+\r
+Thanks for interest\r
+\r
+Tomi\r
projects / notmuch-archives.git / commitdiff