From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: add `completing-read-history' Date: Sat, 23 Jun 2007 11:02:22 -0700 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182621786 3720 80.91.229.12 (23 Jun 2007 18:03:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Jun 2007 18:03:06 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 23 20:03:04 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I29wp-0006zF-4U for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2007 20:02:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I29wo-0001Mk-Eq for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2007 14:02:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I29wk-0001Mf-SM for emacs-devel@gnu.org; Sat, 23 Jun 2007 14:02:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I29wg-0001MT-Nl for emacs-devel@gnu.org; Sat, 23 Jun 2007 14:02:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I29wg-0001MQ-Hb for emacs-devel@gnu.org; Sat, 23 Jun 2007 14:02:50 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I29wf-0004FQ-U5 for emacs-devel@gnu.org; Sat, 23 Jun 2007 14:02:50 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5NI2iEU025009 for ; Sat, 23 Jun 2007 13:02:45 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5NHqcn1020140 for ; Sat, 23 Jun 2007 12:02:44 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-7.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2982315521182621750; Sat, 23 Jun 2007 11:02:30 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73714 Archived-At: IMO, it's good to encourage Emacs-Lisp programmers to use completion more for reading user input. I suspect that some of us use `read-string' and `read-from-minibuffer' in situations where we might advantageously use `completing-read' (or another read-with-completion function). Even in my Icicles code, for instance, where I emphasize completion throughout, there were places where I simply read a string value, so I used `read-from-minibuffer' or `read-string'. Now, I instead use a function that lets users complete input against an input history. This has the advantages that the user can easily see past inputs of the appropriate kind, match against them, pick one, and possibly edit it. The completion is lax (permissive), so s?he can ignore completion if s?he likes. In that case, this acts like `read-string' or `read-from-minibuffer'. Here's the definition I use: (defun completing-read-history (prompt &optional hist pred init-input def inherit-input-method) "Lax `completing-read' against entries in history HIST. Arguments are as for `completing-read'. HIST is a symbol that is a history variable. It defaults to `minibuffer-history'. Completion is lax: a match is not required." (setq hist (or hist 'minibuffer-history)) (completing-read prompt (mapcar #'list (icicle-remove-duplicates (symbol-value hist))) pred nil init-input hist def inherit-input-method)) (Any non-destructive remove-duplicates function that uses `equal' will do.) This doesn't replace `read-from-minibuffer', of course, in situations where you pass a KEYMAP, READ, or KEEP-ALL argument to the latter. And I'm not suggesting that we should replace `read-string' either. But I do think that many programmer uses of these two functions could be replaced to advantage by calling this instead. Even the KEYMAP arg to `read-from-minibuffer' is sometimes used just to pass a minibuffer completion table (to provide completion), and some of those cases too could take advantage of this function. (I suspect, BTW, that many programmers never think of passing a completion map for arg KEYMAP - I know that it took me a while to realize that I could do that. It might be good to point this out in the Elisp manual, and to add a cross reference to that text in the section on completion.) I think it would be useful for Emacs to add such a function and encourage its use (over the non-completing read functions). Too often, I think, we don't let users take advantage of completion when they could. Sometimes, perhaps, that's due to laziness in looking for a good TABLE argument to provide suitable completion candidates. There is nearly always a history set that is appropriate, however. Yes, users can already access history items when inputting to `read-string' and `read-from-minibuffer' - they can cycle and search the history. But the advantages listed above are not there: (a) seeing all past inputs that match what you've typed so far and (b) completing against them. Even if a user decides to use the history just as s?he would today with `read-string' or `read-from-minibuffer' (i.e., cycle or search it), just being able to also see the history entries is helpful. And in *Completions* the history entries are sorted alphabetically, which can also be an advantage in choosing (you still have the chronological order available for history cycling and search). These advantages weigh more when substring and regexp completion are available and when users can change the *Completions* sort order on the fly, but I think these advantages are also important for Emacs's standard (prefix) completion. WDOT?