From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: key to yank text at point into minibuffer? Date: Fri, 17 Feb 2006 23:57:07 +0200 Organization: JURTA Message-ID: <87psloh5ss.fsf@jurta.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1140252394 1409 80.91.229.2 (18 Feb 2006 08:46:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Feb 2006 08:46:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 18 09:46:34 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 1FANjc-0006WD-3z for ged-emacs-devel@m.gmane.org; Sat, 18 Feb 2006 09:46:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FANjb-0003TR-JM for ged-emacs-devel@m.gmane.org; Sat, 18 Feb 2006 03:46:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FAFSg-0007k0-Jc for emacs-devel@gnu.org; Fri, 17 Feb 2006 18:56:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FAFLh-000315-BN for emacs-devel@gnu.org; Fri, 17 Feb 2006 18:49:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FAFJb-00014j-Ew for emacs-devel@gnu.org; Fri, 17 Feb 2006 18:47:10 -0500 Original-Received: from [194.126.101.111] (helo=mail.neti.ee) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FAFP3-0002aY-52 for emacs-devel@gnu.org; Fri, 17 Feb 2006 18:52:45 -0500 Original-Received: from mail.neti.ee (80-235-41-12-dsl.mus.estpak.ee [80.235.41.12]) by Relayhost1.neti.ee (Postfix) with ESMTP id 1A5223019; Sat, 18 Feb 2006 01:47:03 +0200 (EET) Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Tue, 14 Feb 2006 08:55:49 -0800") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee 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:50691 Archived-At: > with every successive `M-n' inserting the next symbol/URL/file > name to the minibuffer? > > Do you mean insert (so, accumulate) or replace what's in the minibuffer? I mean to replace i.e. exactly how M-p works. > Successive `M-n' have the meaning now of traversing the history list. There > is no reason to confuse people by mapping an additional meaning onto > successive `M-n'. There is no reason to limit the default value list only to one value. > This is a design choice - whether successive `M-.' (or `M-n', in your > suggestion) should accumulate text at point, as you suggest, or should > provide alternative kinds of thing at point, as I suggested. I can see > arguments for each approach. These approaches are not conflicting. You suggest `M-.' to accumulate text at point with replacing alternative kinds of thing at point. And I suggest `M-n' to replace the minibuffer contents with default values pre-constructed from alternative kinds of thing at point. So these approaches are rather complementary. > I have a simple patch that does this for the grep prompt, but > it was held due to the feature freeze. > > However, to implement a replacement for ffap, > > To be clear about my proposal, anyway: I wasn't suggesting to get rid of > ffap. I meant only that (even independently of employing it as a poor-man's > ffap) using `M-.' to retrieve something at point would be useful. We can > forget about ffap in this discussion. This is what I meant too: to leave ffap alone, and to develop a simpler way to do the same things as ffap. > it should be improved further to allow extending the list of > default values with more user-defined values. > I.e. instead of giving the list of default values as an > argument of one of the minibuffer functions, there should be > a new buffer-local variable with a user-defined function to > get some text from the buffer and add it to > the list of default values. > > I think (but please clarify) that you're saying a few things: 1) Use a > single buffer-local function, not a list of functions, to retrieve the thing > at point; 2) Make the function buffer-local; 3) Add the retrieved thing to > the standard list of default values. Yes, exactly. > I spoke to #3 above: I'd prefer to keep the default-value list separate > from this text-grabbing feature. Yes, they are separate features. > They are logically independent: one is decided by the command; the other > is decided by the text at point and the user. They are not completely independent: often the text at point is what the user wants to have in a particular place inside the command in the minibuffer. And `M-n' does this just fine. OTOH, `M-.' does the same thing the other way with more keystrokes required from the user, 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. -- Juri Linkov http://www.jurta.org/emacs/