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: RE: read-face-name PROMPT arg should be self-contained, including ": " Date: Mon, 19 Mar 2007 10:24:59 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174325189 28136 80.91.229.12 (19 Mar 2007 17:26:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2007 17:26:29 +0000 (UTC) Cc: Tamas Patrovics To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 18:26:17 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 1HTLcd-00039d-Os for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2007 18:26:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTLe8-0006cn-EB for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2007 12:27:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HTLe4-0006cg-Ss for emacs-devel@gnu.org; Mon, 19 Mar 2007 13:27:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HTLe0-0006c6-Gv for emacs-devel@gnu.org; Mon, 19 Mar 2007 13:27:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTLe0-0006c1-2i for emacs-devel@gnu.org; Mon, 19 Mar 2007 12:27:40 -0500 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 1HTLcV-0005x8-E3 for emacs-devel@gnu.org; Mon, 19 Mar 2007 13:26:08 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2JHQ0mj010669; Mon, 19 Mar 2007 12:26:01 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2JHNtgF023411; Mon, 19 Mar 2007 11:25:59 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt351.oracle.com with ESMTP id 2542397371174325100; Mon, 19 Mar 2007 10:25:00 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal 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:68105 Archived-At: > >> I was recently thinking that rather than adding new history vars > >> everywhere all the time, we could change the history navigation > >> to automatically skip entries which are not completion > >> candidates (at least for those cases that are `must-match'). > > > among matches only. Would that be good or bad? For non-`must-match', at > > least, that might be a nuisance, requiring you to first clear the > > minibuffer. > > You misunderstood. By "completion candidates" I didn't mean completion of > the current input, but simply possible completions (i.e. filter > the history through `test-completion'). Of course. OK, the current user input would be irrelevant here - got it. But what do you mean by "filter the history"? Do you mean filter the initial set of possible completions, to keep only those candidates that are in the history? If so, then this would still be limiting for non-`must-match', IIUC. If you wanted to be able to cycle to a history entry that is not in the initial set of completions, you could not. IOW, this would still tie the history list to the set of possible completions, even if it wasn't the set of completions matching the current input. Maybe that would be a good thing, maybe not - it's worth thinking about, at least. A priori, I tend to think it's good to keep the history list and the initial set of possible completions separate, allowing access to entries in each that might not be in the other. But I'd like to hear arguments for linking the two - it's good that you brought this up. And, as I mentioned, we should at least _allow_ use of a history variable, if only for efficiency. I do agree that it would be worthwhile to provide an easy way to access any historical input by matching - beyond what M-r does. I misspoke, BTW, when I said that history matching (M-r) gives you only the first match. What I meant was that you must use M-r again to access another match. M-r M-r M-r is not very convenient for rapidly accessing different matching history items, in order, and you cannot simply type input to match against all of the history items that match the M-r regexp. One way to improve on that might be to have successive M-r's not ask for a regexp, but reuse the regexp that you input for the first M-r. We could then arrange things so that you could then use just M-r e.*r M-r M-r M-r to cycle among the history items matching e.*r. A problem with that is that you could not then use M-r with a different regexp. An alternative approach, which would not have that problem, would be to make M-p (and M-n) following M-r (and M-s) cycle among only the regexp matches. You could then do M-r e.*r M-p M-p M-p, getting the successive matches of e.*r. A problem with that is that you could not then use M-p to access historical candidates that didn't match the regexp. You could of course use M-r .* again to "clear" the regexp filtering (except for \n matches), but users might not think of that. We could, BTW, change M-r RET to clear regexp filtering, instead of repeating the previous regexp. FWIW - In Icicles, I do something different to let you match against the history: You can type `M-pause' to filter current matches for your input to those that are in the history. Or you can type `M-h' to ignore the current set of completions and match your input against the history list directly. (Unlike `M-h', after you use `M-pause' you are not locked into matching against the history list.) You can then complete against the historical candidates or cycle among them. (Icicles allows regexp matching, so you can match e.*r against stuff in the history list without using M-r.) FWIW2 - Tamas Patrovics' library timid.el takes another approach. After a short delay when you type some input, it pops up the list of matching history items, without your asking for it explicitly (e.g. via `M-h'). You can then cycle among the history matches (but you cannot complete to one of those matches). Rather than being truly timid, doing nothing until asked (e.g. `M-h'), Timid interrupts whenever there is a sufficient lull in the conversation - it could be called "suggest.el". The longer the lull, however, the greater the timidity; you can configure the lull to make Timid as timid as you like. What these various features offer are ways to filter the history list and cycle among those matches (and, for Icicles, to complete against them). Currently, it is not too convenient to cycle among matches in Emacs using just M-r. Both Icicles and Timid let you see the list of history matches, which is another advantage, I think, over M-r. Especially when trying to come up with an improved regexp for matching, it helps to see what the current matches are (and how many there are). Perhaps Emacs could show the list of regexp matches if you used TAB after you used M-r. (Again, that would require users to use M-r .* to clear the regexp filtering, so that TAB would work ~normally again.) Anyway, lots of stuff to think about...after the release. Refs: * Icicles: http://www.emacswiki.org/cgi-bin/wiki/icicles.el * Timid: http://www.emacswiki.org/cgi-bin/wiki/timid.el