Re: gnus-summary-save-parts enhancement

[Antoine Levitt <antoine.levitt@gmail.com>]

12/02/11 12:48, Eric Abrahamsen
>>> When I try to save or delete-and-save an attachment the same
>>> thing happens that used to happen: it finds a file instead of a
>>> directory, and I need to cancel out of ido mode altogether with C-f in
>>> order to save to a directory. Anything else that needs to be done to
>>> make this work?
>>
>> I can't think of a reason why this would not work. Can you find out
>> where the prompt is coming from? M-x toggle-debug-on-quit and C-g inside
>> the prompt should do the trick.
>
> This is after going into a summary buffer and hitting "K o" on a message
> with an attachment. That's bound to gnus-article-save-part, so I guess
> the reason it's not working is because it's not calling
> gnus-summary-save-parts at all! What should be getting called here?

Ah, then it's normal. You've got X m, which is gnus-summary-save-parts,
and saves multiple files (therefore expects a directory), and K o which
is gnus-article-save-part, and saves just one part (therefore expects a
file). Using read-directory-name for gnus-article-save-part would break
autocompletion in case you want to save to an existing file.

The problem here is that ido has no ways of knowing whether the caller
wants a file to write or a file to read, and prety much defaults to an
agressive completion suitable for files to read, but quite bothersome
for files to write (because in many cases you want to just give a
directory name).

Also, ido has a few variables to control this kind of things. See for
instance ido-read-file-name-as-directory-commands (which is a hack, and
is probably useless with my patch on emacs-devel) and
ido-read-file-name-non-ido. So, as a hack, you could set
ido-read-file-name-as-directory-commands, but that'd break
autocompletion of file names. Possibly the best solution would be to
hack into ido to offer the possibility of presenting "." in the
completion list even for read-file-name?