patch: signin signoff feature (1.5.18)
Hi!
Patch to add signin and signoff features is in attach. Use this way:
send-hook . 'set signoff=\n signin=Hi!\n\n'
send-hook [EMAIL PROTECTED] 'set signoff=\n\nBug - it's when computer play
with us... signin=Hello, my friend!\n\n'
P.S. Is there reasons why so useful and trivial patch wasn't added yet
(and won't be added in the future)? I use it for many years.
--
WBR, Alex.
diff -uNr mutt-1.5.18.orig/globals.h mutt-1.5.18/globals.h
--- mutt-1.5.18.orig/globals.h 2008-01-30 06:26:50.0 +0200
+++ mutt-1.5.18/globals.h 2008-10-08 15:38:08.0 +0300
@@ -116,7 +116,9 @@
WHERE char *SendCharset;
WHERE char *Sendmail;
WHERE char *Shell;
+WHERE char *Signin;
WHERE char *Signature;
+WHERE char *Signoff;
WHERE char *SimpleSearch;
#if USE_SMTP
WHERE char *SmtpAuthenticators INITVAL (NULL);
diff -uNr mutt-1.5.18.orig/init.h mutt-1.5.18/init.h
--- mutt-1.5.18.orig/init.h 2008-01-30 06:26:50.0 +0200
+++ mutt-1.5.18/init.h 2008-10-08 15:38:08.0 +0300
@@ -2591,6 +2591,19 @@
** assumed that filename is a shell command and input should be read from
** its stdout.
*/
+ { signin, DT_STR, R_NONE, UL Signin, 0},
+ /*
+ ** .pp
+ ** Create a ``signin'' setting. This will be preprended to ougoing
+ ** messages right after the header. Newlines may be included.
+ */
+ { signoff, DT_STR, R_NONE, UL Signoff, 0},
+ /*
+ ** .pp
+ ** Create a ``signoff'' setting. This will be appended to outgoing
+ ** messages, before the ``-- '' of any signatures. If there is to
+ ** be a newline before the sigdashes, it must be included here.
+ */
{ simple_search, DT_STR, R_NONE, UL SimpleSearch, UL ~f %s | ~s %s },
/*
** .pp
diff -uNr mutt-1.5.18.orig/send.c mutt-1.5.18/send.c
--- mutt-1.5.18.orig/send.c 2008-01-30 06:26:53.0 +0200
+++ mutt-1.5.18/send.c 2008-10-08 15:38:08.0 +0300
@@ -1305,6 +1305,8 @@
if (option (OPTHDRS))
process_user_header (msg-env);
+if (Signin)
+ fputs(Signin, tempfp);
if (option (OPTSIGONTOP) (! (flags (SENDMAILX | SENDKEY)) Editor mutt_strcmp (Editor, builtin) != 0))
append_signature (tempfp);
@@ -1314,6 +1316,9 @@
generate_body (tempfp, msg, flags, ctx, cur) == -1)
goto cleanup;
+if (Signoff)
+ fputs (Signoff, tempfp);
+
if (!option (OPTSIGONTOP) (! (flags (SENDMAILX | SENDKEY)) Editor mutt_strcmp (Editor, builtin) != 0))
append_signature (tempfp);
Re: patch: signin signoff feature (1.5.18)
=- Alex Efros wrote on Wed 8.Oct'08 at 16:01:44 +0300 -= Patch to add signin and signoff features is in attach. Use this way: send-hook . 'set signoff=\n signin=Hi!\n\n' send-hook [EMAIL PROTECTED] 'set signoff=\n\nBug - it's when computer play with us... signin=Hello, my friend!\n\n' P.S. Is there reasons why so useful and trivial patch wasn't added yet (and won't be added in the future)? I use it for many years. Because no patch is needed to achieve the same. rtfm attribution + signature. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: patch: signin signoff feature (1.5.18)
Hi! On Wed, Oct 08, 2008 at 03:28:45PM +0200, Rado S wrote: Patch to add signin and signoff features is in attach. Use this way: send-hook . 'set signoff=\n signin=Hi!\n\n' send-hook [EMAIL PROTECTED] 'set signoff=\n\nBug - it's when computer play with us... signin=Hello, my friend!\n\n' P.S. Is there reasons why so useful and trivial patch wasn't added yet (and won't be added in the future)? I use it for many years. Because no patch is needed to achieve the same. rtfm attribution + signature. This is not correct. The attribution is used only while replying. It isn't designed to add Hi! at top of new message, it's function is completely different. The signature doesn't allow to add some bottom line before -- \n, like: Reminder: John, I still wait until you return my book to me!!! -- WBR, Alex. This should become possible using signature with sigdashes=no, but looks like there some troubles with it - my mutt-1.5.16 (gentoo) says: sigdashes: unknown variable. Mutt has a lot of similar small features, and that's one of reasons why it suck less. There two are very simple, clean, and doesn't conflict with existing features. If somebody think it's too much to have attribution, sigdashes, signature, signin and signoff, then I can ask why there so many other variables already exists - we can replace them ALL with single variable which define full email template (which will contain all signin, attribution, dashes and other things inside)! There a lot of small variables because it increase usability - it's easier to do some small change than to setup complete email template for each possible case. And MUA is all about usability, so this is important thing! -- WBR, Alex.
Re: patch: signin signoff feature (1.5.18)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, October 8 at 05:17 PM, quoth Alex Efros: This should become possible using signature with sigdashes=no, but looks like there some troubles with it - my mutt-1.5.16 (gentoo) says: sigdashes: unknown variable. That's because, if you look in the mutt documentation, it's actually spelled sig_dashes. I use it myself to automatically insert the ~Kyle in my mails. I have no beef with your signin variable, but your signoff variable does appear to duplicate existing features. ~Kyle - -- And thou shalt smite the house of Ahab thy master, that I may avenge the blood of my servants the prophets, and the blood of all the servants of the LORD, at the hand of Jezebel. For the whole house of Ahab shall perish. -- Bible, II Kings (9:7-8) -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjszWEACgkQBkIOoMqOI14MQACguBtW7y9vee5fsAvpth3yTAG1 COIAn0fnOHz4oVe0hdqVc67qjgiZnhYG =k0rV -END PGP SIGNATURE-
Re: patch: signin signoff feature (1.5.18)
Hi Kyle! On Wed, 08 Oct 2008, Kyle Wheeler wrote: On Wednesday, October 8 at 05:17 PM, quoth Alex Efros: This should become possible using signature with sigdashes=no, but looks like there some troubles with it - my mutt-1.5.16 (gentoo) says: sigdashes: unknown variable. That's because, if you look in the mutt documentation, it's actually spelled sig_dashes. I use it myself to automatically insert the ~Kyle in my mails. I have no beef with your signin variable, but your signoff variable does appear to duplicate existing features. The same is true for sig_dashes vs. signature and still you have the flexibility to set both settings. I don't think so. Logically they are 2 distinct functions. I have been missing such a function for long and this was one of the reasons, I switched to muttng when it was available and now I have implemented a solution in vim-script. If you think about it, you might not want a Signature sometimes, but of course you would like to have a signoff string. Or you could generate the signature automatically by a script, but the signoff-String should be the same. regards, Christian -- A: Hi all, I'm playing with datetime functions. Can someone help me, please? I need a function which converts Mar to 3. B: try strlen()
Re: patch: signin signoff feature (1.5.18)
=- Alex Efros wrote on Wed 8.Oct'08 at 17:17:33 +0300 -= Because no patch is needed to achieve the same. rtfm attribution + signature. This is not correct. The attribution is used only while replying. It isn't designed to add Hi! at top of new message, it's function is completely different. You're correct, attribution doesn't cover new messages. However, if you really need automatic greetings, you could make a script to use as $editor which prepends it for your before starting your editor. There two are very simple, clean, and doesn't conflict with existing features. They don't conflict, but aren't required either, because you can achieve the same easily for a rare case. rare: I don't see it widely used, because automatic greetings (intro or farewell) aren't really much of a gain. It's like running around with a T-shirt saying something and you assume everybody should apply it individually to oneself without your individual attention. If it's up to them anyway, they can make up what they want without your automatic comment, do you like reading pre-canned text over and over again? If somebody think it's too much to have attribution, sigdashes, signature, signin and signoff, then I can ask why there so many other variables already exists - we can replace them ALL with single variable which define full email template (which will contain all signin, attribution, dashes and other things inside)! Some things are indeed redundant, I'd prefer they went away. But the majority is not redundant: if you'd take it away, you couldn't replace it with something else to achieve the same still automatically, but doing a lot manual work for each message. There a lot of small variables because it increase usability - it's easier to do some small change than to setup complete email template for each possible case. And MUA is all about usability, so this is important thing! Usability is subjective. For some functionality means even more. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: patch: signin signoff feature (1.5.18)
=- Christian Brabandt wrote on Wed 8.Oct'08 at 17:27:05 +0200 -= If you think about it, you might not want a Signature sometimes, but of course you would like to have a signoff string. Or you could generate the signature automatically by a script, but the signoff-String should be the same. Which still could be produced _automatically_ by the same script or an extra wrapper. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: patch: signin signoff feature (1.5.18)
Hi Rado! On Wed, 08 Oct 2008, Rado S wrote: =- Christian Brabandt wrote on Wed 8.Oct'08 at 17:27:05 +0200 -= If you think about it, you might not want a Signature sometimes, but of course you would like to have a signoff string. Or you could generate the signature automatically by a script, but the signoff-String should be the same. Which still could be produced _automatically_ by the same script or an extra wrapper. I know, because I am doing it this way, since there is no other way currently. Nevertheless it is clumsy and awkward. regards, Christian -- Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) Torvalds, Linus
Re: patch: signin signoff feature (1.5.18)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, October 8 at 05:27 PM, quoth Christian Brabandt: I use it myself to automatically insert the ~Kyle in my mails. I have no beef with your signin variable, but your signoff variable does appear to duplicate existing features. The same is true for sig_dashes vs. signature and still you have the flexibility to set both settings. I don't understand what you're trying to say here... If you think about it, you might not want a Signature sometimes, but of course you would like to have a signoff string. Or you could generate the signature automatically by a script, but the signoff-String should be the same. So, if I understand correctly, you're saying that there's a huge usability and functionality difference between: unset signature and set signature=~/.signoff-only ? I *do* generate my signature via a script. It looks like this: #!/bin/sh cat ~/.signoff-only echo -- getquote # my own personal fortune implementation In some situations, when I don't want to attach a quote to my emails, I use this: set signature=~/.signoff-only That file contains: ~Kyle I'm not understanding what the problem is that a separate signoff variable addresses. Do you want to be able to change your signoff independently of your signature, via hooks? send-hook . 'set my_junk=`echo ~Kyle ~/.signoff-only`' send-hook '%C work' 'set my_junk=`echo Kyle Wheeler ~/.signoff-only`' ~Kyle - -- Preach the Gospel at all times and when necessary use words. -- St. Francis of Assisi -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjs1y0ACgkQBkIOoMqOI167IgCg08nP+pztakZLIZfD8UsXwWx1 t6QAnA0GKbkneZsgmp7uI4P/QsAzqKbp =50L8 -END PGP SIGNATURE-
Re: patch: signin signoff feature (1.5.18)
Hi Kyle! On Wed, 08 Oct 2008, Kyle Wheeler wrote: On Wednesday, October 8 at 05:27 PM, quoth Christian Brabandt: I use it myself to automatically insert the ~Kyle in my mails. I have no beef with your signin variable, but your signoff variable does appear to duplicate existing features. The same is true for sig_dashes vs. signature and still you have the flexibility to set both settings. I don't understand what you're trying to say here... Why can you set sig_dashes, if you could set it via signature? I'm not understanding what the problem is that a separate signoff variable addresses. Do you want to be able to change your signoff independently of your signature, via hooks? send-hook . 'set my_junk=`echo ~Kyle ~/.signoff-only`' send-hook '%C work' 'set my_junk=`echo Kyle Wheeler ~/.signoff-only`' You might also need to unset sig_dashes. It looks too complicated. Do you think this is an /easy/ solution just for setting the greating? regards, Christian -- • Dijkstra probably hates me. Linus Torvalds
Re: patch: signin signoff feature (1.5.18)
This entire discussion should be on mutt-dev. Followups set. Why can you set sig_dashes, if you could set it via signature? signature can be a file or a program. The signature turns out to be whatever is read from the file or whatever is printed to stdout by the program. This file or program may or may not include the dashes, so there's an option to let you tell mutt whether to assist by including them. The only simplification that doesn't remove functionality is to always assume that the signature provides its own dashes, and eliminate the sig_dashes variable. I would say that the reason for not doing that is that it's an extra hurdle for new users, who most likely assume that only the signature proper should be in the signature file. (If you're using a signature program, it's reasonable to assume you're an advanced user.) Maybe conditionally redundant describes sig_dashes, but it's not absolutely redundant. It may be redundant, but it depends on what the signature actually produces. I guess the proposed signoff variable is similarly conditionally redundant, but logically we can: * express signoff in terms of sig_dashes + signature, or * express signature in terms of sig_dashes + signoff, or * express sig_dashes in terms of signoff + signature. Having all three is strictly redundant, so adding signoff adds complexity. Adding a variable should introduce simplicity, convenience, functionality, or some other value. It doesn't add simplicity or functionality. Does it really add convenience? How often do you need to change this in a way that you can't as easily change sig_dashes and signature? -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: patch: signin signoff feature (1.5.18)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, October 8 at 06:02 PM, quoth Christian Brabandt: Why can you set sig_dashes, if you could set it via signature? ... ahh, I think I get what you're saying. But I think you're looking at it backward - the better question (which is more accurate, given the default value of sig_dashes, and helps point out the answer, I think) would be to phrase it like this: Why can you DISABLE sig_dashes, if you can disable them via your signature file? It probably started as mutt always inserts hyphens before the signature, and you *couldn't* disable them via your signature file. Then the ability to skip the hyphens was added later. Mutt's developers work hard to maintain backwards compatibility, so it's rather unlikely that they would say okay, well, since you can add hyphens to your signature file, we're just going to stop inserting them completely. You might also need to unset sig_dashes. It looks too complicated. Do you think this is an /easy/ solution just for setting the greating? Yes. I admit, it is a bit roundabout, but it is *easy*. It requires no difficult leaps in logic or long study. Compare this to solutions to other problems, such as the problem of choosing whether to send pgp-inline or pgp-mime messages based on the recipients of the message, and getting mutt to choose the right one even as you change the list of recipients in the compose menu. (hint, it uses mutt's group-matching feature, 'push', several send2-hooks, a script, and a temp file to store previous state) THAT is a difficult solution. This signature business? This is easy. soapbox Mutt is powerful because it is flexible, not because getting it set up is as simplistic and direct as possible. The question to ask with mutt is can it be made to do X without digging into the source code, whereas other mailers cannot even hope to do X without touching their source code to make a special does X feature (how many email programs allow you to alter the type of pgp signature based on the recipients? I haven't found any). Mutt is not a mailer for the faint of heart looking for a quick, easy way of reading email. Mutt is a mailer for people who are very particular about their email, but who are willing to invest a little work to get it just so. /soapbox ~Kyle - -- When ideas fail, words come in very handy. -- Johann Wolfgang von Goethe -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjs4sMACgkQBkIOoMqOI17OQQCgurktlH/uMa3DRDUVshkwv+qK itcAoOZVJmE2Ka5LBrHoPqWSDxk+++Kq =C0/V -END PGP SIGNATURE-
/var/mail/$username is not a mailbox
Hi, I have been using mutt without trouble on OS X for several weeks until today, when suddenly I got /var/mail/$username is not a mailbox. What on earth happened? I haven't done a thing to my mailspool file, nor to .muttrc. The only thing I can think of that might have somehow caused this is that I set up fetchmail as a cronjob and did not specify where to send output (so it would get mailed to me). I have since taken that out of crontab. I can cat my /var/mail/$username file; there *is* mail there. Perms are 600, owner is username, group is mail. I have Googled this extensively and found no useful answer, so have been forced to revert to claws-mail for an MUA -- arrgh! TIA
Re: /var/mail/$username is not a mailbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, October 8 at 01:37 PM, quoth Indi: I have been using mutt without trouble on OS X for several weeks until today, when suddenly I got /var/mail/$username is not a mailbox. What on earth happened? Sounds like your mailspool got corrupted (or transformed into an mbox format that mutt doesn't understand). There are several different mbox formats, all of which are mutually incompatible. Mutt understands three of them. If you somehow got a new program delivering mail to your mailspool that is writing a new and probably incompatible mbox format, that could make mutt unable to understand your mailspool file. For details on some of the different formats, check here: http://homepages.tesco.net./~J.deBoynePollard/FGA/mail-mbox-formats.html Note, near the bottom, the problems of incompatibilities: - Delivering messages to mboxcl2 format mailboxes with mboxo or mboxrd tools will corrupt the mailbox, rendering all subsequently delivered messages irretrievable. Mutt attempts to convert from mboxo and mboxrd format into mboxcl format. Generally, this is one of the general problems with mbox mailboxes (i.e. mailspools): everyone has a different idea of how to store messages in that file. The *best* thing to do, as a general rule, is to use mutt to move messages OUT of the mailspool and into a mailbox in your home directory somewhere, that only mutt uses. That way you can be assured that other programs, that might have a different idea of how to store messages, won't corrupt it. Mutt tries to make this easy by allowing you to specify a $spoolfile and an $mbox to store read messages in. Personally, I prefer not using a centralized mailspool like that, but it's really up to you. I have Googled this extensively and found no useful answer, so have been forced to revert to claws-mail for an MUA -- arrgh! Claws-mail can read the mailspool file? Hmm... I doubt it's doing it correctly... Anyway, you can attempt to fix the corrupted file by hand, using a text editor. Or you could try to use Claws-mail to save the messages elsewhere, which should enable mutt to read them in their new location. ~Kyle - -- Suppose ye that I am come to give peace on earth? I tell you, Nay; but rather division: For henceforth there shall be five in one house divided, three against two, and two against three. The father shall be divided against the son, and the son against the father; the mother against the daughter, and the daughter against the mother; the mother in law against her daughter in law, and the daughter in law against her mother in law. -- Prince of Peace, Jesus Christ (Luke 12:51-53) -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjs9qkACgkQBkIOoMqOI1544gCgtOLE7pZ0mNX6baEkQpAuyqZ1 GfIAoMn4UVHUrQ6MZc1+PDq/yVStBEdu =MJ9T -END PGP SIGNATURE-
Re: /var/mail/$username is not a mailbox
On Wed, Oct 08, 2008 at 01:06:33PM -0500, Kyle Wheeler wrote: On Wednesday, October 8 at 01:37 PM, quoth Indi: I have been using mutt without trouble on OS X for several weeks until today, when suddenly I got /var/mail/$username is not a mailbox. What on earth happened? Sounds like your mailspool got corrupted (or transformed into an mbox format that mutt doesn't understand). There are several different mbox formats, all of which are mutually incompatible. Mutt understands three of them. If you somehow got a new program delivering mail to your mailspool that is writing a new and probably incompatible mbox format, that could make mutt unable to understand your mailspool file. For details on some of the different formats, check here: http://homepages.tesco.net./~J.deBoynePollard/FGA/mail-mbox-formats.html Note, near the bottom, the problems of incompatibilities: - Delivering messages to mboxcl2 format mailboxes with mboxo or mboxrd tools will corrupt the mailbox, rendering all subsequently delivered messages irretrievable. Mutt attempts to convert from mboxo and mboxrd format into mboxcl format. Generally, this is one of the general problems with mbox mailboxes (i.e. mailspools): everyone has a different idea of how to store messages in that file. The *best* thing to do, as a general rule, is to use mutt to move messages OUT of the mailspool and into a mailbox in your home directory somewhere, that only mutt uses. That way you can be assured that other programs, that might have a different idea of how to store messages, won't corrupt it. Mutt tries to make this easy by allowing you to specify a $spoolfile and an $mbox to store read messages in. Personally, I prefer not using a centralized mailspool like that, but it's really up to you. I have Googled this extensively and found no useful answer, so have been forced to revert to claws-mail for an MUA -- arrgh! Claws-mail can read the mailspool file? Hmm... I doubt it's doing it correctly... Anyway, you can attempt to fix the corrupted file by hand, using a text editor. Or you could try to use Claws-mail to save the messages elsewhere, which should enable mutt to read them in their new location. ~Kyle -- Suppose ye that I am come to give peace on earth? I tell you, Nay; but rather division: For henceforth there shall be five in one house divided, three against two, and two against three. The father shall be divided against the son, and the son against the father; the mother against the daughter, and the daughter against the mother; the mother in law against her daughter in law, and the daughter in law against her mother in law. -- Prince of Peace, Jesus Christ (Luke 12:51-53) Thank you for the helpful advice. I still don't know for sure what happened, but I fixed it like this: mv /var/mail/indi out of the way cp /var/mail/root to /var/mail/indi chown indi:mail /var/mail/indi changed .muttrc to use MH instead and redid mailbox entries accordingly Examining the original /var/mail/indi (in jed) reveals nothing unusual; there must be some hidden property of which I am ignorant. But I expect it won't happen again using MH and ~/mail for my spool. :)
Re: /var/mail/$username is not a mailbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, October 8 at 02:56 PM, quoth Indi: Thank you for the helpful advice. I still don't know for sure what happened, but I fixed it like this: mv /var/mail/indi out of the way cp /var/mail/root to /var/mail/indi chown indi:mail /var/mail/indi changed .muttrc to use MH instead and redid mailbox entries accordingly Fair enough. I'd recommend Maildir over MH, but shrug. The key thing is that you don't leave important messages in your mailspool file (i.e. your $mbox setting is different from your $spoolfile setting). Examining the original /var/mail/indi (in jed) reveals nothing unusual; there must be some hidden property of which I am ignorant. What you should look for is stuff like: - do ALL messages in the file begin with a From ... line? (if not, add a From line) - are there any other lines that begin with the letters From ? (if so, prepend them with a ) - do ALL messages in the file contain a Content-Length: header? (if not, add one... this may be tricky to do by hand) You may be able to rescue the messages in the file by splitting them into individual files and opening them with mutt (e.g. `mutt -f rescued`). Good luck! ~Kyle - -- Idealism increases in direct proportion to one's distance from the problem. -- John Galsworthy -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjtFboACgkQBkIOoMqOI17qTwCfXd6YOdJTM3nZwH+lzLeX5Ra5 qBwAoPBKYQRmo1Pdi7sSzXoqsgVKJatc =dBml -END PGP SIGNATURE-
Decode-Copy Multipart MIME HTML
Sometimes I need to save the HTML part of a multipart MIME QP-encoded message. Decode-Copy saves the text/plain part of the email only. How can I save the HTML part of the email in a decoded state? TIA, JL -- JL [EMAIL PROTECTED] This message optimized for teletypes.
Re: Decode-Copy Multipart MIME HTML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, October 8 at 04:29 PM, quoth Jorge Luis: Sometimes I need to save the HTML part of a multipart MIME QP-encoded message. Decode-Copy saves the text/plain part of the email only. How can I save the HTML part of the email in a decoded state? I believe you can do it from the 'view-attachments' menu. While viewing a message in the pager (or while it's highlighted in the index), trigger the 'view-attachments' function (it's bound to v by default). From there, you can save each MIME component to a file, and when you do that, it should be in decoded form. ~Kyle - -- If A is success in life, then A equals x plus y plus z. Work is x; y is play; and z is keeping your mouth shut. -- Albert Einstein, Observer, Jan. 15, 1950 -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjtHLwACgkQBkIOoMqOI162mQCffi7TO36SwoKithazuxQzI5oG KOYAn2FSfIBbGY3MN2h6twC/cLZ4L7Hi =Ng6a -END PGP SIGNATURE-
Re: Decode-Copy Multipart MIME HTML
On Wed, Oct 08, 2008 at 04:29:46PM -0400, Jorge Luis wrote: Sometimes I need to save the HTML part of a multipart MIME QP-encoded message. Decode-Copy saves the text/plain part of the email only. How can I save the HTML part of the email in a decoded state? You can access the html part as an attachment. press v to get to the attachment menu, select the part and press 's' to save. -Erik -- hackerkey://v4sw5hw2ln3pr5ck0ma2u7LwXm4l7Gi2e2t4b7Ken4/7a16s0r1p-5.62/-6.56g5OR
Re: patch: signin signoff feature (1.5.18)
Hi David! On Wed, 08 Oct 2008, David Champion wrote: The only simplification that doesn't remove functionality is to always assume that the signature provides its own dashes, and eliminate the sig_dashes variable. I would say that the reason for not doing that is that it's an extra hurdle for new users, who most likely assume that only the signature proper should be in the signature file. (If you're using a signature program, it's reasonable to assume you're an advanced user.) True. That's why I think the additional variable would be reasonable, especially for new users. But I can live without it, as I already have a solution that involves my editor. functionality. Does it really add convenience? How often do you need to change this in a way that you can't as easily change sig_dashes and signature? I do it regularly using folder hooks. But as mentioned, I do change the editor setting via some folder-hooks, which trigger a vim script that inserts the right value. I just thought it would be simpler to do it via a separate setting. regards, Christian -- • Do you pine for the days when men were men and wrote their own device drivers? Torvalds, Linus and David Diamond (2001). Just for Fun: The Story of an Accidental Revolutionary, Collins.
