Re: find-file-read-args

[Stefan Monnier]

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