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 to yank text at point into minibuffer? Date: Sun, 19 Feb 2006 11:53:16 -0800 Message-ID: References: <87slqfb5w1.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1140391507 15923 80.91.229.2 (19 Feb 2006 23:25:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Feb 2006 23:25:07 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 20 00:25:05 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FAxvF-0004pi-Dd for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2006 00:24:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FAxvE-0008BK-V3 for ged-emacs-devel@m.gmane.org; Sun, 19 Feb 2006 18:24:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FAugT-0008Hl-NP for emacs-devel@gnu.org; Sun, 19 Feb 2006 14:57:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FAuf1-0007hI-L0 for emacs-devel@gnu.org; Sun, 19 Feb 2006 14:56:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FAucc-0006y5-VY for emacs-devel@gnu.org; Sun, 19 Feb 2006 14:53:31 -0500 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FAuiU-00007e-Rd for emacs-devel@gnu.org; Sun, 19 Feb 2006 14:59:35 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k1JJrQAw009216 for ; Sun, 19 Feb 2006 12:53:26 -0700 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1JJrQXq007928 for ; Sun, 19 Feb 2006 12:53:26 -0700 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-80-102.vpn.oracle.com [141.144.80.102]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k1JJrOt8007912 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 19 Feb 2006 12:53:25 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87slqfb5w1.fsf@jurta.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:50770 Archived-At: > Not sure what you mean by "accumulate...replacing". I > suggested to _replace_ the minibuffer input successively by > different alternative things at point. There was no accumulation. I mean accumulating only on the first `M-.', and replacing the thing inserted to the minibuffer by the first `M-.' with other things on all successive `M-.'. It would be useful to keep the initial minibuffer input intact, and to insert/replace things within the existing minibuffer input. I think `M-.' should not replace the existing minibuffer input, because I imagine such a situation when the user types e.g. `M-!', types a command and wants to *add* the thing at point to the end of the command in the minibuffer. The version I currently use replaces all minibuffer input, even the first time. But I can see your point. It probably makes sense not to replace minibuffer input on the first use of `M-.' It should only replace stuff that it has previously inserted itself (immediately before). > Sorry, I must not be following you at all. How is `M-.' more > keystrokes than `M-n'? `M-.' requires more keystrokes than `M-n' only for the cases where a complex input string is constructed from things at point (like the grep case). Thus `M-.' requires from the user typing the input string, navigating to the correct place in it and typing `M-.'. I don't see this. Whether the new behavior being discussed is bound to `M-n' or `M-.', it has the same behavior, so the same number of keystrokes would be required in each case. The only issue wrt the key binding is the double-duty that you want `M-n' to perform: minibuffer history traversal and text-grabbing at point. I want to put those two different behaviors on different bindings. > and still is restricted in what the user might expect from this > feature: to grab successive characters, words, > maybe even lines to the minibuffer the same way as e.g. isearch > does with C-w and C-y. > > Sorry, I'm lost. I don't see the restriction you're > suggesting. Perhaps a concrete example would clear this up. > I think I have not understood you. Still no concrete example, BTW. Maybe you're right, but how can I tell without a reason or an example of what you mean? I think a single key is not enough to unleash the full potential of `M-.'. I expect that users might want additional keybindings to yank successive characters/words/lines to the minibuffer. I think you're now making my argument - not the part about needing more key bindings, but the part about the utility of having alternative text-grabbing functions. To be clear, here are my points, after adopting your proposal to not replace initial input, and after thinking some more about the utility of successively grabbing more of the same kind of thing (e.g. words) at point: 1. Use a separate key, not `M-n' (which is history traversal), for text-grabbing. E.g. `M-.'. 2. Bind `M-.' to a list of two things: a) a list of alternative text-grabbing functions - my approach and b) a single function that grabs successive things (e.g. words) - your approach. Either component could be nil, in which case that behavior would not be available. The default value could be this: ((symbol-grabber word-grabber line-grabber URL-grabber) word-grabber). If you never wanted my approach, you would use (nil word-grabber). If I never wanted your approach, I would use ((symbol-grabber word-grabber line-grabber URL-grabber) nil) 3. If both components are present, one of them is the default, to be determined by a new user option. Alternatively, the order of the components could determine which is the default, but in that case you could not use a lambda list for the single-function component (or else we we need to recognize lambda, quoted lambda, function, #', etc). 4. When you use `M-.', you always get the default behavior, as determined by the new option, unless you first use `C-u', in which case you get the alternate behavior. Example: I like the default behavior to cause successive `M-.' to grab alternative things, so I set the option to choose this (i.e. to use the first component). You like the default behavior to cause successive `M-.' to grab successive things of the same kind (e.g. words), so you set the option to choose that (i.e. to use the second component). Each of us is happy. If at some point while inputting I want your preferred behavior, I use `C-u M-.' in the minibuffer. From then on, as long as I keep doing `M-.', I get your behavior of grabbing successive words. If at some point while inputting you want my preferred behavior, you use `C-u M-.'. From then on, as long as you keep using `M-.', you get my behavior of grabbing different kinds of thing at point. Each of us is happy to be able to get the alternate behavior for a one-off use. 5. `C-u' could be more sophisticated yet. If you use a numeric arg, not just plain `C-u', then the numeric arg could specify the number of things to grab, in the case of alternative types of things (first component of the `M-.' list). The second component does let you grab multiple things, but they are always of the same type (e.g. words). Using this, I could use `C-u 6 M-. M-.' to grab 6 of whatever kind of thing the second grabbing function grabs. For example, if I wanted to insert 6 lines, then I could use `C-u 6 M-. M-. M-.'. Granted, for the default grabbing functions this might have limited utility, but users might have special grabbers for which this could be useful.