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: find-file-read-args Date: Mon, 23 Nov 2009 11:59:54 +0200 Organization: JURTA Message-ID: <87bpit1ql9.fsf@mail.jurta.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258973126 12060 80.91.229.12 (23 Nov 2009 10:45:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 10:45:26 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 11:45:19 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 1NCWPz-0005OL-FG for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 11:45:15 +0100 Original-Received: from localhost ([127.0.0.1]:46126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCWPy-0000hc-V5 for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 05:45:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCWLw-0007U6-MH for emacs-devel@gnu.org; Mon, 23 Nov 2009 05:41:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCWLq-0007SK-Py for emacs-devel@gnu.org; Mon, 23 Nov 2009 05:41:03 -0500 Original-Received: from [199.232.76.173] (port=56826 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCWLq-0007SE-GT for emacs-devel@gnu.org; Mon, 23 Nov 2009 05:40:58 -0500 Original-Received: from smtp-out3.starman.ee ([85.253.0.5]:60580 helo=mx1.starman.ee) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCWLp-0003Cg-Ll for emacs-devel@gnu.org; Mon, 23 Nov 2009 05:40:58 -0500 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Original-Received: from mail.starman.ee (82.131.34.24.cable.starman.ee [82.131.34.24]) by mx1.starman.ee (Postfix) with ESMTP id 935E03F4222; Mon, 23 Nov 2009 12:40:47 +0200 (EET) In-Reply-To: (Stefan Monnier's message of "Sun, 22 Nov 2009 23:19:44 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:117574 Archived-At: > I think this is a useful feature. I'm not yet 100% sure this is the > best way to provide it (I think a dedicated key would be at least as > good), but it saves us from figuring out which key to use: it's > very unintrusive. > > So, I like it. But I have some more questions: > >> --- 1275,1280 ---- >> *************** >> *** 1298,1309 **** >> (remove-hook 'minibuffer-setup-hook ,hook))))) > >> (defun find-file-read-args (prompt mustmatch) >> ! (list (let ((find-file-default >> ! (and buffer-file-name >> ! (abbreviate-file-name buffer-file-name)))) >> ! (minibuffer-with-setup-hook >> ! (lambda () (setq minibuffer-default find-file-default)) >> ! (read-file-name prompt nil default-directory mustmatch))) >> t)) > >> (defun find-file (filename &optional wildcards) >> --- 1295,1301 ---- >> (remove-hook 'minibuffer-setup-hook ,hook))))) > >> (defun find-file-read-args (prompt mustmatch) >> ! (list (read-file-name prompt nil default-directory mustmatch) >> t)) > >> (defun find-file (filename &optional wildcards) > > Can you explain this hunk? This is a fairly delicate part of the > behavior of C-x C-f, The patch just moves the `minibuffer-with-setup-hook' from `find-file-read-args' to `read-file-name', thus providing the logic of setting of `minibuffer-default' to a wider set of file-reading functions than only find-file-*. > 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'. >> + ((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. >> + (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. >> ! ;; Unless a list of defaults in `minibuffer-default' >> ! ;; is provided, reset it to nil and on the >> ! ;; first request on `M-n' fill it with a list >> ! ;; of defaults relevant for file-name reading. >> ! (unless (consp minibuffer-default) >> ! (setq minibuffer-default nil) >> ! (set (make-local-variable 'minibuffer-default-add-function) >> ! (lambda () >> ! (with-current-buffer >> ! (window-buffer (minibuffer-selected-window)) >> ! (read-file-name-defaults dir initial)))))) > > 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. I'll try to better detect this situation than checking for a cons. >> 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. -- Juri Linkov http://www.jurta.org/emacs/