Re: find-file-read-args

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> 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