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: propose adding Icicles to Emacs Date: Fri, 15 Jun 2007 14:04:55 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1181942531 16149 80.91.229.12 (15 Jun 2007 21:22:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2007 21:22:11 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 15 23:22:10 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 1HzJFB-00083H-Hv for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 23:22:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzJFB-00015I-0T for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 17:22:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzJEc-0000t4-63 for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:21:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzJEZ-0000sD-Ry for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:21:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzJEZ-0000sA-P9 for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:21:31 -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 1HzJEX-0003rb-Uq; Fri, 15 Jun 2007 17:21:30 -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 l5FLLQlR024603; Fri, 15 Jun 2007 16:21:27 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5FKl6KG003722; Fri, 15 Jun 2007 15:21:26 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-138.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2920744771181941503; Fri, 15 Jun 2007 14:05:03 -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: 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:73012 Archived-At: > If code is specific to one function only, and you put it on > the setup hook, then it will also be executed for other functions > for which it might not be appropriate. Even in cases where that > doesn't cause immediate harm, it > doesn't seem like a clean way to proceed, IMO. > > I understand this general point. But I can only solve problems in > specific. I'm asking about what you specifically need to do to make > completing-read do what you want. Between an earlier email from me and the one you are quoting, I think I answered that. I don't think I left anything out. I went through the code bit by bit, explaining what was involved and what would need to be done, if this redefinition were to dispensed with. > 2. The treatment of `icicle-init-value-flag' can be > eliminated, along with > that option. It does not jibe with the Emacs policy of deprecating the > INIT-VALUE argument. I like it, but Emacs developers will no > doubt rule it > out. Alternatively, perhaps you could consider adding such an > option, to > allow those users who, like me, would like the default value > to always be > inserted as an init value. In any case, Icicles is not > dependent on this. > > Can't you use `minibuffer-setup-hook' to do that? No. That hook runs whether completion is used or not. It even runs for `M-:', for instance. Anyway, I said that you can eliminate this feature. Let's not belabor this stuff; there's already enough to discuss. > 3. The call to `icicle-fix-default-directory' (in my > `read-file-name') can be eliminated, along with that function, > if this fix is moved into the Emacs C code somewhere. This is a > hack to convert any backslashes in `default-directory' to slashes. > Icicles needs it because Icicles lets you > use backslashes for regexp syntax during completion. > > I semi-understand that, but how do the backslashes get into > `default-directory'? If they serve to control completion, they should > always be eliminated by the time `read-file-name' returns, right? They can get into `default-directory' on Windows, at least. IMO, they should never get into it, but they can. > 4. My `completing-read' also removes the *Completions* > window, at the end. This was added because the window was not > being removed when REQUIRE-MATCH is non-nil. > > That is a bug. If it still exists, we should fix it in `completing-read'. Right. I don't know if it is still a bug, but I think so. I believe I've seen other users (of Emacs, not Icicles) complain recently about the *Completions* window not going away. In fact I'm almost positive it's still a bug, because when I turn off Icicle mode I notice it. This happens when you have non-nil `pop-up-frames'. There are several ways in which Emacs is not very friendly to non-nil `pop-up-frames', as I've mentioned before. FWIW, in my own (non-Icicles) code, I also redirect the focus of *Completions* to the minibuffer. That is, I give the standalone *Completions* frame its own display function, and I do this inside that function: (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame) IMO, that should also be built into Emacs for such a context. The input focus for *Completions* should always be the minibuffer. Anyway, this is off-topic... > 1. The treatment of `icicle-require-match-flag' can be > discussed. I already spoke about this. This variable lets code > that calls completion functions such as `completing-read' > override the REQUIRE-MATCH argument. Code can bind > this so that any contained calls for completion will respect > the binding. I think this is a good addition and such a > variable should be available, but others might disagree. > > I don't know enough to have an opinion. Can you present a use case > for this feature? General: you might want to define a command that uses an existing that calls `completing-read'. You don't therefore have direct access to the call, so you cannot change the value of the REQUIRE-MATCH argument that was passed. Specific example: Some users like buffer-name completion to always be strict, a la Ibuffer, rather than lax, a la `switch-to-buffer'. Icicles has a user option that you can set to make REQUIRE-MATCH effectively strict for Icicles commands that use buffer names. Those buffer commands bind variable `icicle-require-match-flag' to the user's choice (which is the value of `icicle-buffer-require-match-flag'. My `completing-read' checks `icicle-require-match-flag' and overrides the REQUIRE-MATCH arg if appropriate. I mention buffer-name completion because it is a common example, but the same principle applies to any completion. > I already mentioned the need for a global variable that > records (holds) the value of the passed REQUIRE-MATCH argument. > Perhaps these two variables can be combined. The need for the > latter variable, for Icicles, is, as I said, > to be able to call for another completion with the same argument. > > I don't understand those words. Please see my reply to one of Stefan's emails on this topic. I am repeating myself. Anyway... 1. `M-*' (`icicle-narrow-candidates') calls `completing-read' or `read-file-name' again, recursively, to match an additional pattern you provide. I call this "progressive completion", and it is akin to piping greps. In this recursive call, the same value of REQUIRE-MATCH should be used. Since this is in a different command, I need a global variable for this value. 2. Also, `icicle-candidate-action', which is `C-RET' (likewise, the alternative-action command, bound to `C-S-RET'), uses the recorded value of REQUIRE-MATCH to handle the action. When a match is required, the candidate must be one of those in `minibuffer-completion-table'. For lax completion, `C-RET' lets you act on any input you type. Note: having a global variable for REQUIRE-MATCH just makes sense, to me. We already have the same thing for PREDICATE and TABLE (`minibuffer-completion-predicate', `minibuffer-completion-table'). Icicles uses these variables also for minibuffer commands. There is also a variable `minibuffer-completion-confirm'. But there is no `minibuffer-completion-require-match' - that's what my `icicle-require-match-p' is. > Multi-completions let you provide several strings for each completion > candidate when you call a completion function. That is, a > candidate can be a list of strings. The strings are joined using > a user-defined join string and > terminated with a user-defined end string. > > If this is useful, the right place to add it is inside > `try-completion' and other functions at the same level. Maybe. I don't know. You can get an idea by checking where it is used.