Re: rerunning hooks
also sprach Kyle Wheeler <[EMAIL PROTECTED]> [2008.09.23.1523 +0200]: > Not really, because it's impossible to know which hooks "apply". > Hooks are associated with actions, not with states. The send-hook > applies whenever you attempt to *send* a message, the message-hook > applies whenever you attempt to *view* a message, and so forth. If > you are currently sending a message, but are relying on a setting > that was set by viewing a message (or perhaps are relying on the > fact that the last message you sent triggered a hook), how is mutt > to know? It could pretend that it's reopening the folder, or reviewing a message, or restarting the composing of an email, etc. -- martin | http://madduck.net/ | http://two.sentenc.es/ there are lies, statistics, and benchmarks. spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: rerunning hooks
Hi, * martin f krafft wrote: It could pretend that it's reopening the folder, or reviewing a message, or restarting the composing of an email, etc. It still can't work except it completely replays every single key stroke entered. Even then it could depend on externally defined resources (e.g. you do source file foo whose contents could change over time). This is because a second hook's behaviour at the time it is executed creates a new state based the state created by the first hook and so forth. Simply firing the appropriate folder-hooks for the folder you're in doesn't guarantee mutts state is the one you expect. A stupid and totally constructed example is: set my_cnt = '' folder-hook . 'set my_cnt=".$my_cnt"' to "count" how many times you changed folders. Regards, Rocco
Re: rerunning hooks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, September 24 at 01:22 PM, quoth martin f krafft: > also sprach Kyle Wheeler <[EMAIL PROTECTED]> [2008.09.23.1523 +0200]: >> Not really, because it's impossible to know which hooks "apply". >> Hooks are associated with actions, not with states. The send-hook >> applies whenever you attempt to *send* a message, the message-hook >> applies whenever you attempt to *view* a message, and so forth. If >> you are currently sending a message, but are relying on a setting >> that was set by viewing a message (or perhaps are relying on the >> fact that the last message you sent triggered a hook), how is mutt >> to know? > > It could pretend that it's reopening the folder, or reviewing > a message, or restarting the composing of an email, etc. Since *you* know which of those hooks are important, *you* can tell it to do that. Something I do a lot in my pager macros is the combo, which (as it happens) will re-trigger any hooks involved in viewing that particular message and doesn't require an extra screen redraw (i.e. it doesn't ever actually display the index). Something else you could try (from the pager) would be this: ^ You may have to do some extra work to make sure that the message you display is the same one that you're currently on, but that would reopen the folder and review the message. But Rocco is absolutely right: many people build up a bit of a history with their hook settings *intentionally*, and figuring out the exact history would require, at minimum, re-triggering every hook that's been triggered (and maintaining all the message state) since mutt began. For example, imagine that I had the following in my muttrc: set sendmail=oldsendmail message-hook '=b foo' 'set sendmail=newsendmail' After you've been running mutt for a while, you now want to re-trigger all the hooks that "apply". So here's the question: what should the value of $sendmail be, and how can mutt ensure that it's correct? Notice that I didn't say whether you'd read a message that had foo in the body... is that important? How is mutt to know whether you've read a message that had foo in the body since mutt was first launched? Let's add another twist: set sendmail=oldsendmail send-hook . 'set sendmail=newsendmail' message-hook '=b foo' 'unhook send-hook' message-hook '=b bar' 'send-hook "=b foo" "set sendmail=oldsendmail"' NOW what is the correct value of $sendmail? How much state does mutt have to remember in order to figure out the correct value? And we're not even considering issues like Rocco brought up, such as: send-hook . 'source genconfig.sh|' ~Kyle - -- No one loves armed missionaries. -- Maximilien Robespierre -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjaTW4ACgkQBkIOoMqOI15nbACdHD/mdG6QnMhH5WX76OD/IDAQ jPkAoLoUN8ioWdzLSLIncLTYlBkqoGWx =hkeH -END PGP SIGNATURE-
Re: Set Content-Disposition: inline on Patches automatically
Am 2008-09-06 22:10:12, schrieb Antoine Kaufmann: > Hi, > > I'm new to mutt. I often send patches to mailing lists, and I would like > mutt to set Content-Disposition to inline whenever I attach a Patch to a > new mail. Because otherwise i forget half the time to do this manually. > ;-) > > Is there a way to do this? I have a macro which generate a "signature" containg the patch/diff and then attaching it to the mutt message... Note: I use dialog/Xdialog (depending on console or X) to include the patch/diff. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Automated message processing
Am 2008-09-03 22:59:39, schrieb David Champion:
> This works, but you'd need to store the valid random number someplace.
> For a zero-knowledge approach you could do something like generate
> an MD5 hash of the prospective member's e-mail address with some
> secret that's shared between the script that sends the 'who are you'
I am using simply:
echo "${MYSECRET}${EMAIL}" |md5sum
where ${MYSECRET} is only know to me and in conjunction with the senders
${EMAIL} it works perfectly...
If someone want to know ${MYSECRET} he must 0wn1ng my brain...
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
signature.pgp
Description: Digital signature
Re: URLs screwed in the mail body
Since the message is piped to urlview, why not using: macro generic,pager,index \cb "|mimedecode |urlview\n" which should do the trick, at least for me. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Automated message processing
Am 2008-09-05 07:46:09, schrieb Peter Davis:
> I understand that. I guess what I should have said was "Mutt doesn't
> give me any way to pass a pointer to the message file. All I can do is
> pipe the contents of the message."
HOW do you filter the E-Mails?
If you are using procmail, you can use TRAP (in front of the matching
procmail recipe) to add an extra header to the message using:
:0
* ^Subject:.*subscribe me
{
TRAP='cat ${LASTFOLDER} |formail -f -I "X-Folder: ${LASTFOLDER}"
>${LASTFOLDER}.tmp && mv -f ${LASTFOLDER}.tmp ${LASTFOLDER}'
:0
.Subscribe_folder/.
}
Note: I put the TRAP inside a recipe since I do not want to have it
executed on ANY other messages I receive
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
signature.pgp
Description: Digital signature
Re: Automated message processing
Am 2008-09-04 22:58:29, schrieb Peter Davis: > Yes, but both of those require searching through a potentially large > number of messages to find the matching id. I figured that since I'm Are you joking? My LKM folder has at least 26.000 messages (2 month, 200 MByte) and a simple grep take less then 4 seconds... I asume already, you have much less messages in this folder and you are not using 15000 RpM SCSI drives Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: New mail folder list
Am 2008-09-04 13:10:02, schrieb Rado S: > It is so even when you don't read _any_ (not even new) mail in that folder. > Merely opening the folder sets a flag. > I don't know whether that's a mutt or IMAP feature, but it's a > feature rather than a bug. It seems, that the programs are reading "//new/" and if you access a Maildirfolder over IMAP, the server (in my case courier) move the messages to "//cur/" which let "buffy" thinking, they are now read. This is definitively a BUG in the biff/buffy apps or they can handel only local mail and not IMAP which asume, mutt is accessing the same folder local and not using IMAP. > If it's up to mutt, a filed wish might produce an optional behaviour. > Otherwise hack your server to do as you like or make a new IMAP > standard. ;) Code new "buffy" apps using perl :-) I have had coded a tool "tdnewmsg" which had the same "BUG" but since I have recoded it in perl it is working as I expect... Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: URLs screwed in the mail body
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday, September 21 at 07:32 PM, quoth Michelle Konzack: >Since the message is piped to urlview, why not using: > >macro generic,pager,index \cb "|mimedecode |urlview\n" > >which should do the trick, at least for me. I think he was trying to stick with his terminal's ability to recognize displayed urls, so that he could just click on them. But personally, I prefer my own extract_url.pl script, which handles a few more variants than mimedecode does (specifically, format=flowed delsp=yes messages). http://www.memoryhole.net/~kyle/extract_url/ ~Kyle - -- A fanatic is one who can't change his mind and won't change the subject. -- Winston Churchill, July 5, 1954 -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjaaZcACgkQBkIOoMqOI14wKwCcCBr2ie9UIo9EtIv7/3LoHpCH At8AnjRBiCEa+8liIowz8ERjCAJMyRQU =3m9/ -END PGP SIGNATURE-
Re: New mail folder list
Hi, * Michelle Konzack wrote: Am 2008-09-04 13:10:02, schrieb Rado S: It is so even when you don't read _any_ (not even new) mail in that folder. Merely opening the folder sets a flag. I don't know whether that's a mutt or IMAP feature, but it's a feature rather than a bug. It seems, that the programs are reading "//new/" and if you access a Maildirfolder over IMAP, the server (in my case courier) move the messages to "//cur/" which let "buffy" thinking, they are now read. It's about the buffy-list function (I think) for which mutt maintains per mailbox whether the user has been notified or not that it has new mail. Not about new mail detection, IMAP or Maildir or something like that. Regards, Rocco
Re: New mail folder list
> It seems, that the programs are reading "//new/" and if you > access a Maildirfolder over IMAP, the server (in my case courier) move > the messages to "//cur/" which let "buffy" thinking, they are > now read. > > This is definitively a BUG in the biff/buffy apps or they can handel > only local mail and not IMAP which asume, mutt is accessing the same > folder local and not using IMAP. It's the buffy-list function in mutt itself, not a separate biff/buffy app that is doing the notifying, and it was mutt that was misreading the information (or using the wrong information given my settings) that the IMAP server gave it. The IMAP server was reporting the right amount of unread mails, but mutt wasn't using that value unless it detected new mails arriving since the last time it checked. Thankfully, since the patch to mutt posted by Vladimir (which appears to work correctly even with mark_old set, unlike my patch which only worked in my situation), I haven't had any issues with the buffy list, and have been able to get rid of the ghastly sidebar patch too, which was what I was using to see folders with new mail previously. Mark -- Mark Harrison Systems Administrator OmniTI Computer Consulting, Inc. pgpHLQ7BBwu3n.pgp Description: PGP signature
cleanup
Hey all, I'm using mutt with a POP email account and am subscribed to a number of mailing lists. I was wondering if anyone is using a script that will trawl through mail folders deleting messages older than n days, or one which could be tweaked to do so. Thanks in advance! -- BGCB* GCC/O$ d--(+) s+:- a- C++ L++>+++ W++ K- w O? M V? PS- PE++ t 5 X R(+) tv+ b++ DI++ D G e+ h--- r+++ z+++ EGCB*
Re: cleanup
Hi Cristopher! On Wed, 24 Sep 2008, Cristopher Thomas wrote: > mailing lists. I was wondering if anyone is using a script that will > trawl through mail folders deleting messages older than n days, or one > which could be tweaked to do so. in mutt? Something like this could work: folder-hook spam 'push ~d>2m' or even more advanced: folder-hook foobar 'push ~A!~D!~F~r>2m\ \ =INBOX.archive.foobar~A' I used to have a folder hook like this one in my config file, but it slowed down changing into that folder a lot. And the drawback is, that it will only be triggered when you enter that folder. There are probably better tools to achieve this. archivemail is one of it. regards, Christian -- SIGIRO -- too much irony (core dumped)
Mutt 1.5.18 + Sidebar - Hangs when reading certain folders
Hi there. I'm a mutt user for a few days, using Mutt 1.5.18 with the sidebar patch (patch-1.5.18.sidebar.20080611.txt). There are some mailboxes (maildir format) I can't access with the patched version - mutt hangs when I try to read them, this is what it says in the status bar all the time: Reading .maildir/gentoo/gentoo-dev... 20/57 (35%) Mutt has 100% CPU usage all the time and doesn't react on keystrokes. It doesn't matter if I use the sidebar to open the mailbox or not. Vanilla Mutt works perfectly though. I suspect there's somthing about one more of the messages in these mailboxes but couldn't track down anything specific. -Erik
Unexpected network error
Hi, If i leave mutt open for say 1 or2 hrs theres 99% chance of the "An unexpected network error occurred. " when I try to send mail using 'y' key. I end up closing mutt reopen and then retry this time it goes through. So is there any place i can check why the error occured ? Or any variable which helps me avoid this.. Thanks Ravi
Save to a file problem (wrapped with =
Hi, I have a very basic imap mutt setup to receive emails. However, when I try to save an email to a file, lines longer than 72 characters are wrapped with a "=" added at the end. I can view the long lines just fine, but the saved file is wrapped. For example, I view it as: -/* Try to allocate a new tape buffer skeleton. Caller must not hold os_scsi_tapes_lock */ But the saved file would look like: -/* Try to allocate a new tape buffer skeleton. Caller must not hold os_scs= i_tapes_lock */ I suspected it might have something to do with my editor vi. So I set wc=0 to stop vim from wrapping around. But the problem still exists. Any help is high appreciated. Thanks! Lin
Re: Unexpected network error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, September 24 at 07:25 PM, quoth Ravi Uday: > If i leave mutt open for say 1 or2 hrs theres 99% chance of the "An > unexpected network error occurred. " when I try to send mail using > 'y' key. I end up closing mutt reopen and then retry this time it > goes through. There's not usually much more information than that, but that sort of error message suggests to me that you're using mutt to access an IMAP mailbox, and your connection timed out. I'd say reduce your timeout values ($timeout and $imap_keepalive). ~Kyle - -- He who dares not offend cannot be honest. -- Thomas Paine -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjbF30ACgkQBkIOoMqOI146lwCeNW2cfAV0/oR8HY81/KY8tTvg hMwAn2ehvmbPU8Wv2cz4bmrikC578EWA =0p00 -END PGP SIGNATURE-
Re: Save to a file problem (wrapped with =
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, September 24 at 11:18 PM, quoth Lin Tan: > I have a very basic imap mutt setup to receive emails. However, when > I try to save an email to a file, lines longer than 72 characters > are wrapped with a "=" added at the end. I can view the long lines > just fine, but the saved file is wrapped. When messages are saved to a "file" (using the command), they're saved in mbox format, which is pretty close to the raw message---and the RFCs strongly encourage that messages be wrapped to 72 characters. I guess my point is: it's doing that on purpose... what exactly is it that you're trying to achieve? There's probably a better way to achieve it. ~Kyle - -- Time is an illusion. Lunchtime doubly so. -- Douglas Adams -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjbGSMACgkQBkIOoMqOI14zdQCffv+QNJfdJQ0suD+6QgmITSQN juEAnieNUkknasjsydhieBbabC4ovvXA =EWoH -END PGP SIGNATURE-
search new mails in the opposite order
Hello, I sort emails in this manner set sort=reverse-threads set sort_aux=last-date-received when I read mails inside a thread, pressing search next new mail, but that will be the previous mail in chronological order. Try pressing does not help. Is there any way to search new mail in the opposite order and bind it to ? TIA -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: search new mails in the opposite order
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, September 25 at 01:29 PM, quoth bill lam: > when I read mails inside a thread, pressing search next new > mail, but that will be the previous mail in chronological order. Try > pressing does not help. Is there any way to search new > mail in the opposite order and bind it to ? Assuming that your is bound to the function, all you'd need to do is add this to your muttrc: bind pager,index \S previous-new-then-unread ~Kyle - -- A woman has the last word in any argument. Anything a man says after that is the beginning of a new argument. -- Unknown -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjbJbgACgkQBkIOoMqOI14ZGgCfdvjNW/vEm7bvKbh3pf4B0U9P 2pQAn3ul0Vnd5AoH5bn6ehm9vJb9MRS8 =GR80 -END PGP SIGNATURE-
