From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: find-file-read-args Date: Mon, 23 Nov 2009 15:17:57 -0500 Message-ID: References: <3b31caf90911051613w80af4cu61352a29ce5dcd77@mail.gmail.com> <87vdhoe73d.fsf@mail.jurta.org> <87y6mkb6qr.fsf@mail.jurta.org> <87bpjfiark.fsf@mail.jurta.org> <871vk8uo0q.fsf@mail.jurta.org> <87ocn8ayrw.fsf@mail.jurta.org> <4AFBE741.1040506@gmx.at> <87tyx05849.fsf@mail.jurta.org> <871vjz27lw.fsf@mail.jurta.org> <4B003A50.30601@gmx.at> <4B025430.1010204@gmx.at> <87my2ljxun.fsf@mail.jurta.org> <87bpit1ql9.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259009078 8820 80.91.229.12 (23 Nov 2009 20:44:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 20:44:38 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 21:44:30 2009 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 1NCflq-0000tp-QQ for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 21:44:27 +0100 Original-Received: from localhost ([127.0.0.1]:32917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCflq-0001gA-Dt for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 15:44:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCfMP-0003og-U7 for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:18:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCfMK-0003lg-B6 for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:18:08 -0500 Original-Received: from [199.232.76.173] (port=46610 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCfMJ-0003lO-VS for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:18:03 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50159) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCfMJ-0002XM-M4 for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:18:03 -0500 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id nANKHvHS029111; Mon, 23 Nov 2009 15:17:57 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id CCBE13A38A; Mon, 23 Nov 2009 15:17:57 -0500 (EST) In-Reply-To: <87bpit1ql9.fsf@mail.jurta.org> (Juri Linkov's message of "Mon, 23 Nov 2009 11:59:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3412=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:117616 Archived-At: >> so I'd like to understand how you reproduce it. > This can be reproduced by typing M-n in the minibuffer of commands > other than find-file-*, e.g. `insert-file', `append-to-file', > `write-file', `write-region', `load-file', `recode-file-name', > `make-directory', `delete-directory', `copy-directory'. I meant "how does your code reproduce the right behavior for C-x C-f". But I think I'm beginning to understand why it works. >>> + ((eq major-mode 'dired-mode) >>> + (let ((filename (dired-get-filename nil t))) >>> + (when filename >>> + (if (file-directory-p filename) >>> + (file-name-as-directory (abbreviate-file-name filename)) >>> + (abbreviate-file-name filename))))))) >> This is ugly. Why does it have to be here rather than somewhere in dired? > I can't find a function in dired.el and dired-aux.el that uses > `abbreviate-file-name' necessary for the minibuffer reading a file name. We must be miscommunicating: I don't want to have dired-specific code (including no test for (eq major-mode 'dired-mode)) in read-file-name, because it's ugly. Can't the same behavior be obtained by changing some code in dired rather than in minibuffer.el? >>> + (filename-at-point >>> + (cond >>> + ((fboundp 'ffap-guesser) >>> + ;; Logic from `ffap-read-file-or-url' and `dired-at-point-prompter' >>> + (let ((guess (ffap-guesser))) >>> + (setq guess >>> + (if (or (not guess) >>> + (and (fboundp 'ffap-url-p) >>> + (ffap-url-p guess)) >>> + (and (fboundp 'ffap-file-remote-p) >>> + (ffap-file-remote-p guess))) >>> + guess >>> + (abbreviate-file-name (expand-file-name guess)))) >>> + (when guess >>> + (if (file-directory-p guess) >>> + (file-name-as-directory guess) >>> + guess)))) >>> + ;; ((fboundp 'thing-at-point) >>> + ;; (thing-at-point 'filename)) >>> + ))) >> >> I think this should be moved to a separate function (e.g. so it can be >> used by a separate key-binding) in file.el. That function could/should >> obey a new hook file-name-at-point-functions hook which we'd run with >> run-hook-with-args-until-success. > OK, I'll create a new function that could later be bound to a dedicated key. Thanks. Tho it doesn't need to be a command (e.g. that function shouldn't want to insert anything into the buffer, so it'll probably be better to have a separate command, unless we want to rely on called-interactively-p). >> Is it really necessary to throw away the minibuffer-default if it's not >> a cons? I'd rather keep it and just add file-name-at-point. That would >> make the change a lot more "obviously safe". > For most file/directory reading functions the minibuffer-default > duplicates the initial input, so the first typing M-n is useless since > it doesn't change the minibuffer's contents. Right, and that's what the minibuffer-setup-hook thingy in find-file-read-args was trying to do. > I'll try to better detect this situation than checking for a cons. Yes, I think your solution is at least as good as the previous one. But please check explicitly for "default == initial input", that will make the code both safer and easier to understand. >>> Index: lisp/dired-aux.el >> Am I right that this part of the change is not strictly necessary? > dired-aux.el is from other threads with the subject > "dired-dwim-target" and "dired-dwim-target-directory" that has > separate reasonings for separate but related changes. I'll send a new > patch for dired-aux.el in another message. That was my impression as well. Thank you for separating them. Stefan