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: patch: add-log.el: changelog find file under poin Date: Mon, 21 Jan 2008 17:17:17 -0800 Message-ID: References: <87sl0qsp39.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: ger.gmane.org 1200964655 16742 80.91.229.12 (22 Jan 2008 01:17:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Jan 2008 01:17:35 +0000 (UTC) Cc: rgm@gnu.org, janneke-list@xs4all.nl, emacs-devel@gnu.org To: "Juri Linkov" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 22 02:17:53 2008 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 1JH7lw-0004FS-DR for ged-emacs-devel@m.gmane.org; Tue, 22 Jan 2008 02:17:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JH7lW-0002WM-C8 for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2008 20:17:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JH7lR-0002WH-4O for emacs-devel@gnu.org; Mon, 21 Jan 2008 20:17:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JH7lQ-0002W5-Ha for emacs-devel@gnu.org; Mon, 21 Jan 2008 20:17:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JH7lQ-0002W2-EN for emacs-devel@gnu.org; Mon, 21 Jan 2008 20:17:20 -0500 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 1JH7lI-0003Fj-Ql; Mon, 21 Jan 2008 20:17:13 -0500 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m0M1H9w2013848; Mon, 21 Jan 2008 18:17:10 -0700 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m0LLed3I030311; Mon, 21 Jan 2008 18:17:09 -0700 Original-Received: from 141.144.88.215 by acsmt350.oracle.com with ESMTP id 3526312951200964607; Mon, 21 Jan 2008 17:16:47 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87sl0qsp39.fsf@jurta.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Message-Flag: Follow up X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: 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:87270 Archived-At: > > Yes, really. ffap is a global mode which not everyone wants. > > (I don't use it.) This feature makes sense in Change Log mode. > > Actually this feature makes sense not only in Change Log mode, > but in any buffer that contains a file name. For everyone who > doesn't want using ffap, I think it would be good to implement > a feature that will always add a file name under point to the > list of minibuffer's default values for C-x C-f. So C-x C-f > will keep its current behavior, and additionally will provide > a file name under point available via M-n. We went through this discusion at least once. See the thread "key to yank text at point into minibuffer" of late Feb 2006. * This post is the last one on-topic, and it reviews the arguments and use cases: http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg01074.html * This mid-thread post is specifically about your argument to use `M-n' for this vs my proposal to use another key: http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg00664.html. There are various ways to interpret the thingie at point - it could be a file name or URL, but it could be other things also. I would reserve `M-n' for things that the particular command deems would make appropriate default values. That could include, in some cases, something from the text at point - but it is the command that decides. That is very different from always including a file name under point "in any buffer". I would prefer something like what we discussed in that 2006 thread, a minibuffer key (I use `M-.') that is specifically for yanking text from the buffer into the minibuffer. That doesn't prohibit a particular command from also putting the file or URL at point onto the future history list (`M-n'), but it separates the two: general purpose yanking vs command-specific defaults. It doesn't always make sense, for all commands in all buffers, for `M-n' to contain the file name at point as one of its default values. A general mechanism to yank buffer text to the minibuffer is useful. It would be available for all commands in all buffers, and it would be available at any time during minibuffer input. But it shouldn't be confounded with minibuffer history/defaults. You even agreed in the previous thread that we should separate the two: D> I'd prefer to keep the default-value list separate D> from this text-grabbing feature. J> Yes, they are separate features. In the mechanism we discussed earlier, `M-.' has two possible modes (choice via option): it either (1) cycles among alternative interpretations of the thingie at point or (2) accumulates successive thingies (e.g. words) at point, in either or both directions. In #1, each alternative replaces the minibuffer input; in #2, the successive thingies are added to the input. This approach, with option choice #1, provides the same cycling that you are proposing via `M-n', but it doesn't mess up the set of default values (`M-n'), which should be command-specific. A general mechanism to yank buffer text should be on a different key. I've been using this approach for a couple of years. It complements the `M-n' history/defaults.