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: Mon, 18 Jun 2007 16:31:50 -0700 Message-ID: References: <87hcp5t2wr.fsf@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: sea.gmane.org 1182209556 30083 80.91.229.12 (18 Jun 2007 23:32:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2007 23:32:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Juri Linkov" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 19 01:32:35 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 1I0Qi1-0005Tj-DI for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2007 01:32:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0Qi0-0006Lg-Ea for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2007 19:32:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I0Qhv-0006Jh-Lk for emacs-devel@gnu.org; Mon, 18 Jun 2007 19:32:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I0Qhu-0006JA-Vf for emacs-devel@gnu.org; Mon, 18 Jun 2007 19:32:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0Qhu-0006J5-PH for emacs-devel@gnu.org; Mon, 18 Jun 2007 19:32:26 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I0Qhu-0002IM-CD for emacs-devel@gnu.org; Mon, 18 Jun 2007 19:32:26 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5INWMWg018050; Mon, 18 Jun 2007 17:32:22 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5INE5uT019602; Mon, 18 Jun 2007 17:32:21 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt351.oracle.com with ESMTP id 2940219261182209512; Mon, 18 Jun 2007 16:31:52 -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: <87hcp5t2wr.fsf@jurta.org> 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:73265 Archived-At: > >> Also there is another bug (I can't believe it's by design): > >> after typing the face description in the *Help* window > >> goes out of sync with the face name highlighted in the > >> *Completions* window and displayed in the minibuffer (e.g. > >> when the current selected completion is `bold-italic', > >> the *Help* window displays the description of the previous > >> face `bold'). > > > > No, this is the normal behavior of `C-next'. When you hit > > `C-next', it acts on the _current_ completion candidate and > > _then_ moves to the next one (so you can then act on it, in > > turn). `C-next' is thus a shortcut for `C-RET' > > (act on the current candidate) followed by `next' (make the > > next candidate current). > > When I type `C-next' I expect it acting on the _next_ completion candidate > (`next' + `C-RET'). When I want it acting on the _current_ > completion candidate, I can simply type `C-RET'. Well, what can I say? That's what you expect and that's not what you get. We disagree. Like I said, I first implemented it the way you think you would prefer it, I corrected that design a long time afterward, and even though I was already used to the previous behavior I preferred the new behavior - and I still do. > It is a pity that you changed your original design. Displaying the result > of action applied to the previous completion candidate with the name of > the next completion candidate highlighted in the *Completions* window is > as confusing as for instance if you typed `next-error' and see > the previous match in the source buffer with the next match highlighted > in the grep/compilation buffer. This is not `next-error'. The current candidate for action (including help display) is not only highlighted in *Completions* but also inserted in the minibuffer so that you can edit it or accept it as is. That is, you hit RET or C-RET to act on the current candidate, which is in the minibuffer. What should be in the minibuffer after you do that? My answer: the next available candidate, so that you can act on it, in turn (whether with `C-RET', `RET', or `C-next'). You should not see, in the minibuffer or highlighted in *Completions*, the candidate that you already acted on. The minibuffer input after you act on a candidate has to be a different candidate, if you are to be able to act on successive candidates. What you see in the minibuffer should again, per standard Emacs behavior, be what will be acted on if you hit RET (or C-RET). This, however, does not dictate what `C-next' should do. I say it should perform the defined action on the current candidate and then prepare the next candidate for possible action. You say that it should do nothing to the current candidate and should act directly on the next candidate. It could be designed either way. For me, the text that appears in the minibuffer as input should be the target of any user action. For you, `C-next' should perform an action on text that is not yet in the minibuffer, and it should show that text in the minibuffer after the action. With my approach, `C-next' followed by `C-RET' or `RET' acts on two successive candidates. For you, it acts twice on the same candidate. Likewise, for `C-prior'. But either approach can be supported. With the behavior you propose, a user thinks of `C-next' as not acting on the current candidate but as acting on the next candidate. OK. I prefer to think of all actions, `C-RET', `C-next', `C-prior', `C-up', `C-down', as acting on the same, current candidate. I think this simplifies the user's mental model a bit. It simplifies thinking about actions, just as it simplifies talking about them (e.g. doc). But I can't argue that the behavior you want doesn't also correspond to a coherent user model. It is logical to expect to see the result of acting on a candidate only after choosing that candidate. For me, the candidate that is ripe for choosing with the keyboard is the one that is (a) highlighted in *Completions* and (b) present in the minibuffer as your default input. Choosing it acts on it, and you then see the result. You would respond that you don't disagree with most of that (display the result after choosing what to act on), but you think it is logical to sometimes choose (act on) a candidate that is not the one in the minibuffer. I cannot convince you, but I'd suggest that you not focalize only on candidate help, where the action is displaying help on the current candidate. "Act on" can mean anything, depending on the context, and I think in most contexts the current behavior is preferable. Anyway, we can go 'round the barn multiple times about this, without really getting anywhere. I think it's time to agree to disagree. If you as an Icicles user want to define your own command and bind it in place of `icicle-next-apropos-candidate-action' to `C-next', it is trivial to do so. Here is the complete definition: (defun icicle-next-apropos-candidate-action (&optional nth) "`icicle-candidate-action', then `icicle-next-apropos-candidate'. Optional argument NTH is as for `icicle-next-apropos-candidate'." (interactive) (when (interactive-p) (icicle-barf-if-outside-minibuffer)) (icicle-successive-action #'icicle-next-apropos-candidate #'icicle-candidate-action nth)) So your definition would be this: (defun JURI-next-apropos-candidate-action (&optional nth) "`icicle-next-apropos-candidate', then `icicle-candidate-action'. Optional argument NTH is as for `icicle-next-apropos-candidate'." (interactive) (when (interactive-p) (icicle-barf-if-outside-minibuffer)) (icicle-successive-action #'icicle-candidate-action #'icicle-next-apropos-candidate nth)) I have nothing fundamentally against such an approach; I just don't agree that it is generally preferable. What we can do is ask people to try the current approach for a while, and then revisit the question after that trial. It is trivial to flip the behavior if we decide to change it. I think I mentioned that I in fact employ the approach you prefer for the particular case of `icicle-search', because the use case is somewhat different. The *Help* display is a bit similar to search, so I cannot say that you are 100% wrong about it: if help display were all that `C-next' is about, you might convince me. But help is available all of the time, as a secondary action, when the primary action is something else. And for that primary action, at least, I think it is clearer if the user's simple mental model of "do something to act on the current candidate" is reinforced by `C-next', so that a user can think of `C-next' as an atomic action on the current candidate, just as for `C-RET' and `RET'.