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: Sun, 22 Nov 2009 23:19:44 -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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258950005 23913 80.91.229.12 (23 Nov 2009 04:20:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 04:20:05 +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 05:19:58 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 1NCQP7-0002xS-IN for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 05:19:57 +0100 Original-Received: from localhost ([127.0.0.1]:56455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCQP6-0004GD-Qj for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 23:19:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCQP0-0004Fl-Sq for emacs-devel@gnu.org; Sun, 22 Nov 2009 23:19:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCQOw-0004Dk-TR for emacs-devel@gnu.org; Sun, 22 Nov 2009 23:19:50 -0500 Original-Received: from [199.232.76.173] (port=46883 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCQOw-0004Dh-Od for emacs-devel@gnu.org; Sun, 22 Nov 2009 23:19:46 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:64493 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCQOw-0005fC-BR for emacs-devel@gnu.org; Sun, 22 Nov 2009 23:19:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANibCUvO+IIa/2dsb2JhbACBTdFphDwEigI X-IronPort-AV: E=Sophos;i="4.47,269,1257138000"; d="scan'208";a="49826537" Original-Received: from 206-248-130-26.dsl.teksavvy.com (HELO ceviche.home) ([206.248.130.26]) by ironport2-out.pppoe.ca with ESMTP; 22 Nov 2009 23:19:44 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 940BBB40C9; Sun, 22 Nov 2009 23:19:44 -0500 (EST) In-Reply-To: <87my2ljxun.fsf@mail.jurta.org> (Juri Linkov's message of "Tue, 17 Nov 2009 11:59:36 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:117555 Archived-At: > Don't worry, I think it's quite useless to get the filename at point > from the Dired buffer when copying multiple files (i.e. when it shows > the *Marked files* window). A list of directories would be enough. > The complete patch below avoids this problem by setting > `minibuffer-default-add-function' to nil in `dired-do-create-files' > and thus not using the filename guessing. 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, so I'd like to understand how you reproduce it. > *************** > *** 2020,2026 **** > In a Lisp program, if you want to be sure of accessing a file's > contents literally, you should create a temporary buffer and then read > the file contents into it using `insert-file-contents-literally'." > ! (interactive "FFind file literally: ") > (switch-to-buffer (find-file-noselect filename nil t))) > > (defvar after-find-file-from-revert-buffer nil) > --- 2012,2021 ---- > In a Lisp program, if you want to be sure of accessing a file's > contents literally, you should create a temporary buffer and then read > the file contents into it using `insert-file-contents-literally'." > ! (interactive > ! (list (read-file-name > ! "Find file literally: " nil default-directory > ! (confirm-nonexistent-file-or-buffer)))) > (switch-to-buffer (find-file-noselect filename nil t))) > > (defvar after-find-file-from-revert-buffer nil) Good change, thank you. > + ((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? > + (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. > ! ;; 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". > Index: lisp/dired-aux.el Am I right that this part of the change is not strictly necessary? Stefan