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: Key bindings proposal Date: Tue, 24 Aug 2010 09:38:46 -0700 Message-ID: <5BDE59A3371641649BE147451A98DFF0@us.oracle.com> References: <19534.1494.627000.357123@gargle.gargle.HOWL><19537.40472.267000.563053@gargle.gargle.HOWL><87tymlv41y.fsf@mail.jurta.org> <87aaodo1qt.fsf@tux.homenetwork><87tymlvyif.fsf@mail.jurta.org> <87occtc9pa.fsf@tux.homenetwork><8C662051648B4596802BF3DD72FC64FD@us.oracle.com> <87lj7wcdzf.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282668042 29761 80.91.229.12 (24 Aug 2010 16:40:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 16:40:42 +0000 (UTC) Cc: emacs-devel@gnu.org, 'Thierry Volpiatto' To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 18:40:40 2010 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.69) (envelope-from ) id 1OnwYB-0002Nw-Dm for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 18:40:39 +0200 Original-Received: from localhost ([127.0.0.1]:60337 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnwYA-0004T9-Ui for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 12:40:38 -0400 Original-Received: from [140.186.70.92] (port=35682 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnwY4-0004RR-IF for emacs-devel@gnu.org; Tue, 24 Aug 2010 12:40:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnwY2-0004O9-Uv for emacs-devel@gnu.org; Tue, 24 Aug 2010 12:40:32 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:24834) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnwY2-0004No-P2 for emacs-devel@gnu.org; Tue, 24 Aug 2010 12:40:30 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7OGeQbV031429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Aug 2010 16:40:28 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7OBQd1Q031396; Tue, 24 Aug 2010 16:40:25 GMT Original-Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 544831011282667930; Tue, 24 Aug 2010 09:38:50 -0700 Original-Received: from dradamslap1 (/10.159.216.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Aug 2010 09:38:49 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87lj7wcdzf.fsf@mail.jurta.org> Thread-Index: ActDnA4O09LzY/HWS2yLEdDek7ygdwAA2ojQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:129156 Archived-At: > > And normal access to the history (as well as access using > > completion). > > Any reason why this is still not available in vanilla Emacs? Why _what_ is not in vanilla Emacs - (a) Icicles or (b) the addition of previous command inputs to the command history or (c) the ability to complete against history items? You know the answer for (a). (b) _is_ of course available in vanilla Emacs. Icicles just extends vanilla minibuffer input, so it maintains this vanilla property. `Anything' might be a different story - dunno. For (c), the answer is that no one has bothered to add the feature to vanilla Emacs. Note: Completion against the history list has this advantage over cycling and searching it (`M-p', `M-r'): the age of the input retrieved is irrelevant. [FWIW - (c) is provided by Icicles in 3 different ways: c1. During minibuffer input anytime (not necessarily input with completion), you can use `M-o' to insert a previous input from the input history using completion (recursive minibuffer). This is on-demand history completion. I've suggested in the past that vanilla Emacs do likewise. IIRC, at one point you or someone else proposed simply adding previous inputs to the completion-candidate set. That is misguided, IMO - the two sets should be kept separate. But completion can be allowed independently against both sets - even during the same input interaction. c2. During completion, you can use `M-h' to filter the current set of completion candidates, limiting it to past inputs. c3. During completion, you can use `M-pause' to filter the (raw/initial) domain of completion candidates, limiting it to past inputs. (c2) and (c3) differ in that Icicles lets you progressively filter the set of candidates or even replace it by a saved set. (b2) acts on the current set of candidates; (c3) acts on the domain of candidates defined by the command.] [FWIW2 - Icicles has additional history-list features, any of which could serve as food for thought for vanilla Emacs. Two simple examples: (1) highlight the previous inputs in *Completions* (optionally: `C-pause' toggles it during completion); (2) sort the candidates on demand (e.g. putting previous inputs first). http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements] > > I made the point that the solution to the problem Juri described is > > not to rename the commands but to use better completion > > (e.g. substring, regexp, pcomplete, fuzzy,...). That's the point. > > It does not matter how you get better completion. > > Yes, better completion is what we need. This includes pushing > more likely completions to the top of the list. Be careful, please. What the program considers "more likely" might not correspond to what some user considers more likely in a given context. This kind of thing should be under user control. DWIM should always be considered at best only a stupid guess. It should be subjected to user control - preferably runtime, on-the-fly control. Only in that context can DWIM be useful and not just an annoyance. Programs can sometimes help by being smart, but users still know best. It would be a mistake, IMO, to systematically place previous inputs at the beginning of the *Completions* list. Of course, vanilla Emacs does not let you cycle among candidates, so their order is irrelevant except in terms of what user sees (in *Completions*). Even so, it is a bad idea to impose an order such as chronological (previous use). Alphabetical order has the advantage of making it easy to find a name (think of an index in a book). [In Icicles, users can sort completion candidates on the fly in many ways, the possible sort orders being dependent on the context (and under user control).] > But it seems in anything-M-x the sorting order of completions is > randome (at least, I can't deduce any logic behind the order of its > completions).