gnus-summary-save-parts enhancement

gnus-summary-save-parts enhancement

[Antoine Levitt]

First of all, can someone merge this?

=== modified file 'lisp/gnus/gnus-sum.el'
--- lisp/gnus/gnus-sum.el       2011-02-05 00:11:16 +0000                      
+++ lisp/gnus/gnus-sum.el	2011-02-10 15:27:11 +0000
@@ -12087,7 +12087,7 @@
 			  gnus-summary-save-parts-default-mime)
 		      'gnus-summary-save-parts-type-history)
 	 (setq gnus-summary-save-parts-last-directory
-	       (read-file-name "Save to directory: "
+	       (read-directory-name "Save to directory: "
 			       gnus-summary-save-parts-last-directory
 			       nil t))
 	 current-prefix-arg))

It just clarifies that the completion asks for a directory and not a
file. Ido users need this or ido fails spectacularly.

Second of all, I think there should be a setting to only save
non-displayable content (typical use case is someone sends you several
pdf/doc/jpeg files, you want to use X m with "." but not save the
plaintext and HTML part). Here's another patch to do that (basically
adds a defcustom and an if, using mm-automatic-display-p).

=== modified file 'lisp/gnus/gnus-sum.el'                                      
--- lisp/gnus/gnus-sum.el       2011-02-05 00:11:16 +0000                      
+++ lisp/gnus/gnus-sum.el	2011-02-10 15:36:37 +0000
@@ -1259,6 +1259,13 @@
   :group 'gnus-summary
   :type 'regexp)
 
+(defcustom gnus-summary-save-parts-only-non-display nil
+  "*Whether to only save parts that are not displayed in
+  `gnus-summary-save-parts' (\\<gnus-summary-mode-map>\\[gnus-summary-save-parts]). Check
+  is performed using `mm-automatic-display-p'."
+  :group 'gnus-summary
+  :type 'boolean)
+
 (defcustom gnus-read-all-available-headers nil
   "Whether Gnus should parse all headers made available to it.
 This is mostly relevant for slow back ends where the user may
@@ -12117,22 +12124,23 @@
     (when (if reverse
 	      (not (string-match type (mm-handle-media-type handle)))
 	    (string-match type (mm-handle-media-type handle)))
-      (let ((file (expand-file-name
-		   (gnus-map-function
-		    mm-file-name-rewrite-functions
-		    (file-name-nondirectory
-		     (or
-		      (mail-content-type-get
-		       (mm-handle-disposition handle) 'filename)
-		      (mail-content-type-get
-		       (mm-handle-type handle) 'name)
-		      (format "%s.%d.%d" gnus-newsgroup-name
-			      (cdr gnus-article-current)
-			      gnus-summary-save-parts-counter))))
-		   dir)))
-	(incf gnus-summary-save-parts-counter)
-	(unless (file-exists-p file)
-	  (mm-save-part-to-file handle file))))))
+      (unless (and gnus-summary-save-parts-only-non-display (mm-automatic-display-p handle))
+	(let ((file (expand-file-name
+		     (gnus-map-function
+		      mm-file-name-rewrite-functions
+		      (file-name-nondirectory
+		       (or
+			(mail-content-type-get
+			 (mm-handle-disposition handle) 'filename)
+			(mail-content-type-get
+			 (mm-handle-type handle) 'name)
+			(format "%s.%d.%d" gnus-newsgroup-name
+				(cdr gnus-article-current)
+				gnus-summary-save-parts-counter))))
+		     dir)))
+	  (incf gnus-summary-save-parts-counter)
+	  (unless (file-exists-p file)
+	    (mm-save-part-to-file handle file)))))))
 
 ;; Summary extract commands

Re: gnus-summary-save-parts enhancement

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Thu, Feb 10 2011, Antoine Levitt wrote:

> It just clarifies that the completion asks for a directory and not a
> file. Ido users need this or ido fails spectacularly.

As an ex-ido user I've been bitten by this, without thinking it might by
Gnus fault. I pushed your fix.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: gnus-summary-save-parts enhancement

[Eric Abrahamsen]

On Fri, Feb 11 2011, Julien Danjou wrote:

> On Thu, Feb 10 2011, Antoine Levitt wrote:
>
>> It just clarifies that the completion asks for a directory and not a
>> file. Ido users need this or ido fails spectacularly.
>
> As an ex-ido user I've been bitten by this, without thinking it might by
> Gnus fault. I pushed your fix.

With no-gnus updated this morning (it's got the above patch included),
this doesn't seem to be working. I've got gnus-completing-read-function
set to 'gnus-ido-completing-read, no other modifications that I can
think of. 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?

Eric

Re: gnus-summary-save-parts enhancement

[Antoine Levitt]

12/02/11 04:11, Eric Abrahamsen
>
> With no-gnus updated this morning (it's got the above patch included),
> this doesn't seem to be working. I've got gnus-completing-read-function
> set to 'gnus-ido-completing-read, no other modifications that I can
> think of.

This doesn't seem to be doing anything here, both the default value of
the variable and gnus-ido-completing-read call ido.

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

Re: gnus-summary-save-parts enhancement

[Eric Abrahamsen]

On Sat, Feb 12 2011, Antoine Levitt wrote:

> 12/02/11 04:11, Eric Abrahamsen
>>
>> With no-gnus updated this morning (it's got the above patch included),
>> this doesn't seem to be working. I've got gnus-completing-read-function
>> set to 'gnus-ido-completing-read, no other modifications that I can
>> think of.
>
> This doesn't seem to be doing anything here, both the default value of
> the variable and gnus-ido-completing-read call ido.
>

Aha, I might have gotten confused when this functionality was added.

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

Debugger entered--Lisp error: (quit)
  ad-Orig-completing-read("Save MIME part to (default bestearningbh1.rtf): ~/Downloads/Attachments/" (("dummy" . 1)) nil nil nil ido-file-history nil nil)
  completing-read("Save MIME part to (default bestearningbh1.rtf): ~/Downloads/Attachments/" (("dummy" . 1)) nil nil nil ido-file-history)
  byte-code("\304\305\b	\"\306\307\211\n\307\v&\207" [item prompt ido-text-init history completing-read ido-make-prompt (("dummy" . 1)) nil] 7)
  ido-read-internal(file "Save MIME part to (default bestearningbh1.rtf): " ido-file-history "~/Downloads/Attachments/bestearningbh1.rtf" nil nil)
  ido-read-file-name("Save MIME part to (default bestearningbh1.rtf): " "~/Downloads/Attachments/" "~/Downloads/Attachments/bestearningbh1.rtf" nil nil nil)
  read-file-name("Save MIME part to (default bestearningbh1.rtf): " "/home/eric/Downloads/Attachments/" "/home/eric/Downloads/Attachments/bestearningbh1.rtf")
  mm-save-part((#<buffer  *mm*<2>> ("text/rtf" (name . "bestearningbh1.rtf") (x-mac-creator . "4D535744") (x-unix-mode . "0644") (x-mac-type . "52544620")) quoted-printable nil ("attachment" (filename . "bestearningbh1.rtf")) nil nil nil))
  gnus-mime-save-part()
  call-interactively(gnus-mime-save-part nil nil)

Re: gnus-summary-save-parts enhancement

[Antoine Levitt]

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?

Re: gnus-summary-save-parts enhancement

[Eric Abrahamsen]

On Sat, Feb 12 2011, Antoine Levitt wrote:

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

I see the problem… I can't be bothered to hack anything (and deal with
the results), so I guess I'll live with the current behavior!

Thanks,
Eric