Re: I need two different folder types
* Tolga [07.Nov.08 15:08 +0200]: My $HOME and e-mail folders are in different locations, so I need one set folder=my folder location and one for attaching files. Otherwise I have to wander in my filesystem. Is this possible? Yes, and IIUC it’s common practice. Just set folder to the (local or remote) directory that contains your mailboxes. This directory is what ‘=’ or ‘+’ characters will expand to when you are referring to a mailbox. You can still refer to $HOME with ‘~’. Check the “Mailbox Shortcuts” section of the manual for other similar shortcuts. If this is not enough, you may use macros. -- ~sertaç
Re: .muttrc
* Ravi Uday [22.Tem.08 11:31 -0700]: If there is a way to retrieve your ~/.muttrc from a existing mutt session, please let me know. That would help too as my .muttrc is deleted :( Attach gdb to your mutt process with: shell-escapegdb /proc/$PPID/exe $PPID And inside gdb dump the variables like so: call mutt_dump_variables() Then parse the output. -- ~sertac
Re: How to send mail with a sign gpg in attachment like
* Dongsheng Song [15.Şub.08 20:50 +0800]:
Alex, your mutt not sign in attachment like signature.asc:
Content-Type: application/pgp-signature
Content-Disposition: inline
This is the default mutt behavior.
But Joseph's mutt is right:
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Digital signature
Content-Disposition: inline
He appears to be using a debian patch. But I guess that patch is broken
in the way it adds those extra parameters for non-ascii values of the
pgp_mime_signature_description setting.
I'm expected: Content-Type: application/pgp-signature;
name=signature.asc Content-Description: GnuPG digital signature
Content-Disposition: attachment; filename=signature.asc
Joseph, How to set 'name=signature.asc' ?
Could you give me a sample ?
I don't know why you need to set the disposition to attachment instead
of inline. If you just need to lookout for correspondents with
clueless mail readers, try the attached patch I'm using. I wonder why
this feature does not exist in in vanilla mutt.
--
~sertaç
diff -Nurp mutt-1.5.16/crypt-gpgme.c mutt-1.5.16-new/crypt-gpgme.c
--- mutt-1.5.16/crypt-gpgme.c 2007-08-21 23:49:34.0 +0300
+++ mutt-1.5.16-new/crypt-gpgme.c 2007-08-21 23:57:24.0 +0300
@@ -34,6 +34,7 @@
#include copy.h
#include pager.h
#include sort.h
+#include rfc2047.h /* for content-description */
#include sys/wait.h
#include string.h
@@ -894,6 +893,8 @@ static BODY *sign_message (BODY *a, int
t-use_disp = 1;
t-disposition = DISPATTACH;
t-d_filename = safe_strdup (smime.p7s);
+ t-description = safe_strdup (_(Digital Signature));
+ rfc2047_encode_string (t-description);
}
else
{
@@ -901,6 +902,9 @@ static BODY *sign_message (BODY *a, int
t-use_disp = 0;
t-disposition = DISPINLINE;
t-encoding = ENC7BIT;
+ t-description = safe_strdup (_(Digital Signature));
+ rfc2047_encode_string (t-description);
+ mutt_set_parameter (name, signature.asc, t-parameter);
}
t-filename = sigfile;
t-unlink = 1; /* ok to remove this file after sending. */
diff -Nurp mutt-1.5.16/pgp.c mutt-1.5.16-new/pgp.c
--- mutt-1.5.16/pgp.c 2007-04-21 23:02:39.0 +0300
+++ mutt-1.5.16-new/pgp.c 2007-08-21 23:55:10.0 +0300
@@ -35,6 +35,7 @@
#include pgp.h
#include mime.h
#include copy.h
+#include rfc2047.h /* for content-description */
#include sys/wait.h
#include string.h
@@ -1107,6 +1107,9 @@ BODY *pgp_sign_message (BODY *a)
t-use_disp = 0;
t-disposition = DISPINLINE;
t-encoding = ENC7BIT;
+ t-description = safe_strdup (_(Digital Signature));
+ rfc2047_encode_string (t-description);
+ mutt_set_parameter (name, signature.asc, t-parameter);
t-unlink = 1; /* ok to remove this file after sending. */
return (a);
--- mutt-orig/PATCHES 2007-08-21 22:58:29.0 +0300
+++ mutt/PATCHES1970-01-01 02:00:00.0 +0200
@@ -0,0 +1 @@
+sy.mime_signature_parameters
Re: w3mimgdisplay use?
* Kyle Wheeler [09.Kas.07 17:59 -0600]: n - ? This is used when displaying multiple images on a terminal window, and holds the index of the images in the cache. x - x coordinate to draw the image at (top left corner) y - y coordinate to draw the image at (top left corner) Correct. w - width to draw the image h - height to draw the image These are the width/height of the original image to draw. sx - ??? xy - ??? sw - width of the original (source) image sh - height of the original (source) image These parameters are for the actual image drawn on the window. Probably 's' stands for 'seen' or 'shown'. 'sx' and 'sy' are offsets from 'x' and 'y' respectively. After playing around, I figured out that sx and sy allow you to crop off parts of the top and left of the image... like it means start drawing from sx and sy in the image, which makes some sense. Yes, w3m uses these to redraw partly drawn images from cache when scrolling. I still can't figure out what n means, though. ...perhaps it has something to do with animated gifs? Animation frames are also drawn as separate images, so yes. But if you need to tweak these n and s parameters, I'd suggest calling w3m directly and letting it handle the details. -- ~sertaç
Re: w3mimgdisplay use?
* Kyle Wheeler [09.Kas.07 15:16 -0600]: Does anyone know how to use w3mimgdisplay to display images on the terminal (or if its even possible)? I'm hoping to be able to put it in my mailcap so that when I view an attached image, it'll display it on the terminal. I've gotten as far as understanding that it has an input command language, so I can query the size of the image, like so: echo '5;./test.jpg' | w3mimgdisplay The w3mimg protocol is documented in the source files like this: 0 1 2 +--+--+--+--+ .. +--+--+ |op|; |args |\n| +--+--+--+--+ ...+--+--+ args is separeted by ';' op args 0; params draw image 1; params redraw image 2; -none- terminate drawing 3; -none- sync drawing 4; -none- nop, sync communication response '\n' 5; pathget size of image, response width height\n 6; params(6) clear image params n;x;y;w;h;sx;sy;sw;sh;path params(6) x;y;w;h And I *believe* the command to display an image looks something like this: echo '0;1;2;3;4;5;6;7;8;9;./test.jpg' | w3mimgdisplay Yes, reads from stdin, writes to stdout. You might also just execute w3mimgdisplay and type your commands there. Check the source for command line parameters it accepts. But as of yet, I haven't actually gotten it to display anything. Does anyone have any clues? Are there some magic incantations that must be performed first? Image-specific numbers that must be generated? What's the trick? Start by strace'ing w3m? -- ~sertaç
Re: Viewing HTML messages with images
[08.Eyl.07 20:32 +0200] M. Fioretti: Just for the record: did this discussion confirm for good that it is just not possible to see html messages, images included, _inside_ the mutt pager area or not? Can we still hope? If you have w3m working with inline images, calling w3m (from a script¹) to display those html messages is practically same as displaying them in the pager area. ¹ similar to this one: http://zhar.net/projects/shell/mutt-view-html -- ~sertaç
Re: Base64 problem.
* [14.Ağu.07 17:31 -0700] Ray Van Dolson: That is a multipart/mixed message with a multipart/alternative message inside of it. However, the first text portion of the multipart/alternative portion appears to be improperly labeled as base64. Not the text part, the multipart/alternative part itself is labeled as base64. And AFAIK, that's not permitted for multipart types. The only way I can get it to show up in mutt is to edit the raw message and change the first base64 to 8bit (leaving the base64 for the actual file attachment). You can also view from the attachments menu. So is this message being generated incorrectly? Yes. Should mutt handle things differently instead of just bombing out? Yes, IMHO. I'm using the attached patch for this. -- ~sertaç --- mutt-1.5.16-orig/handler.c 2007-08-15 14:10:26.0 +0300 +++ mutt-1.5.16/handler.c 2007-08-15 14:10:05.0 +0300 @@ -1575,9 +1575,10 @@ fseeko (s-fpin, b-offset, 0); /* see if we need to decode this part before processing it */ -if (b-encoding == ENCBASE64 || b-encoding == ENCQUOTEDPRINTABLE || +if (b-type != TYPEMULTIPART + (b-encoding == ENCBASE64 || b-encoding == ENCQUOTEDPRINTABLE || b-encoding == ENCUUENCODED || plaintext || - mutt_is_text_part (b)) /* text subtypes may + mutt_is_text_part (b))) /* text subtypes may * require character * set conversion even * with 8bit encoding. --- mutt/PATCHES.oldTue Nov 6 19:59:33 2001 +++ mutt/PATCHESTue Nov 6 19:59:42 2001 @@ -0,0 +1 @@ +sy.multipart_decode
Re: Base64 problem.
* [15.Ağu.07 14:16 +0200] Thomas Roessler: On 2007-08-15 14:52:45 +0300, Sertaç Ö. Yıldız wrote: Not the text part, the multipart/alternative part itself is labeled as base64. And AFAIK, that's not permitted for multipart types. That base64 has nothing at all to do on the multipart/alternative body part: (a) the content of that body part isn't actually base64 encoded, and (b) if it was, that would be breaking a MUST NOT in the relevant spec. But mutt is trying to decode base64 in contrary to (a) and (b) and failing (IMHO) unnecessarily with an unhelpful message. Indeed, it's serious garbage; anything mutt could do to deal correctly with this particular message would cause breakage elsewhere. Is it incorrect to skip decoding if body part is multipart? I guess it just tolerates the error here, and if the multipart was actually encoding transformed (in spite of being expressly forbidden by the spec), it would fail later anyway. -- ~sertaç
Re: start mutt with mailbox with unread mail opened
[15.Ağu.07 17:03 +0200] tannhauser: On Mi, 15.08, 14:42, Taleb Hakim wrote: mutt -Z ? And that worked fine before version 1.5.16. Ouch, that hurts. I've searched the man page three times, i can't believe i've overseen this. I've referenced to the new command because i thought i could be done in some way with using it. You can also add push next-unread-mailbox near the end of your muttrc. This way mutt won't quit if there are no new messages. -- ~sertaç
Re: Apple mail
[15.May.07 17:14 +1000] Brian Salter-Duke: Could anyone suggest the best way to cleanup this sort of mail? I have recently received two from different people. It is a mess. The html is not an attachment. Mail minus headers follows Assuming the appropriate headers were present in the original mail, the problem is with the text/plain part: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding should be “quoted-printable” and charset is iso-8859-1, not ascii. Also the quotation is not properly flowed (in both parts) but it does not affect readability that much. Does it look better if you change these? You can change the content-type with the edit-type function from mutt. But I don’t know how to change the transfer-encoding without editing the raw message. -- ~sertaç
Re: buffy-size disappeared?
* [15.Nis.07 21:20 +0200] Alessio 'mOLOk' Bolognino: while compiling mutt 1.5.15 I noticed that buffy-size option is disappeared, even grepping the source didn't return anything? What's new? What happened? There is a new runtime configuration variable: check_mbox_size. -- ~sertaç
