Re: Stopping expansion of periods in mbox name?
Ben wrote: [Sun Feb 08 2009, 08:41:54AM EST] I recently switched mutt versions on one of my computers to 1.5.19 from the 1.4 series. A problem I'm having is that mutt is expanding periods in mbox names to forward slashes, as if talking to a Maildir imap server. I think this has less to do with maildir/mbox than it has to do with some imap servers using / and some using . to nest folders. Mutt tries to be smart about it and usually succeeds, but... For example, I request a change-folder to imap://server/firstname.lastname and I get error Can't open mailbox mail/firstname/lastname. You might look at http://www.mutt.org/doc/devel/manual.html#imap-delim-chars Possibly setting that to / instead of the default /. will help? I've set mbox_type=mbox Believe that's unrelated. Using mutt 1.4.2.3i with the same configs doesn't do this. If you can't get it working, file it as a regression at http://dev.mutt.org/trac/ Hth, Aron
Re: local sendmail
emailj...@gmx.de wrote: [Wed Feb 04 2009, 09:38:07AM EST] Is there some other way around this other than having to run postfix? I haven't used rss2email but it seems trivial to edit rss2email.py to call procmail instead of sendmail. Something like: --- rss2email.py.orig 2009-02-04 09:51:18.0 -0500 +++ rss2email.py2009-02-04 09:52:14.0 -0500 @@ -188 +188 @@ - i, o = os.popen2([/usr/sbin/sendmail, recipient]) + i, o = os.popen2([/usr/bin/procmail])
Re: detect from mailcap whether called for view or reply
I guess the answer is, Nobody on the mutt-users list can think
of a way to do this. Right? ;-)
-Original Message-
From: Aron Griffis [mailto:agrif...@n01se.net]
Sent: Thursday, December 11, 2008 06:37 PM
Subject: detect from mailcap whether called for view or reply
Presently my mailcap calls a script to dumptext using a variety
of viewers. The extra level of abstraction makes it easier to do
things like detect the terminal width, so it looks something like
this:
text/html; dumptext w3m %s ; nametemplate=%s.html ; copiousoutput ; test=which
w3m /dev/null 21
and dumptext handles stuff like:
w=$({ stty size /dev/tty || echo '24 80'; } | cut -d' ' -f2)
w=$((w - 5))
w3m -cols $w -o frame=1 -o graphic_char=1 -o \
ignore_null_img_alt=1 -o color=0 -o follow_locale=1 -dump $@
There's a little more to it than that because dumptext supports
multiple viewers, not just w3m, but you get the idea.
The only problem with this is that I'd like my quoted replies to
be constrained to 80 columns, even if I'm viewing messages in
a larger terminal.
Can anybody here dream up a way to let dumptext know that it's
being called as a result of reply instead of inline viewing?
Thanks,
Aron
Re: detect from mailcap whether called for view or reply
Kyle Wheeler wrote: [Fri Jan 30 2009, 04:19:57PM EST] The closest you may be able to get is to find a way to make mutt export some environment variables so that you can make your dumptext program detect what's going on. But that'll require some hand-coding on your part, there's nothing I know of that's built in. Okay, thanks, that's what I was thinking too. Regards, Aron
Re: detect from mailcap whether called for view or reply
Cameron Simpson wrote: [Fri Jan 30 2009, 07:35:27PM EST] You could get your reply keystroke macro to set some state before commencing the reply, for example. Untested (and this hould be one line): macro index,pager r 'shell-escapetouch $HOME/var/flag/80-colsenterreplyshell-escaperm -f $HOME/var/flag/80-colsenter' Heh, I'd briefly thought about this, just couldn't stomach implementing it. Thanks for the suggestion. :-) This woud be a lot slicker if mutt had a setenv/unsetenv command. That's what I'll look into next, thanks.
Re: Starting shell command with name of current mailbox as
Noah Sheppard wrote: [Tue Jan 20 2009, 11:41:11AM EST] As yet I don't know how to pass a mutt variable as the argument to a shell command. You can't with simple shell-escape but you can by a sequence such as... enter-command set my_shell=$shellenterenter-command set shell=blah blah $somevar blahentershell-escapeenterenter-command set shell=$my_shellenter
detect from mailcap whether called for view or reply
Presently my mailcap calls a script to dumptext using a variety
of viewers. The extra level of abstraction makes it easier to do
things like detect the terminal width, so it looks something like
this:
text/html; dumptext w3m %s ; nametemplate=%s.html ; copiousoutput ; test=which
w3m /dev/null 21
and dumptext handles stuff like:
w=$({ stty size /dev/tty || echo '24 80'; } | cut -d' ' -f2)
w=$((w - 5))
w3m -cols $w -o frame=1 -o graphic_char=1 -o \
ignore_null_img_alt=1 -o color=0 -o follow_locale=1 -dump $@
There's a little more to it than that because dumptext supports
multiple viewers, not just w3m, but you get the idea.
The only problem with this is that I'd like my quoted replies to
be constrained to 80 columns, even if I'm viewing messages in
a larger terminal.
Can anybody here dream up a way to let dumptext know that it's
being called as a result of reply instead of inline viewing?
Thanks,
Aron
Re: fork process on reply
Eric Smith wrote: [Fri Nov 21 2008, 04:46:01AM EST] I would do this into another screen window ideally but others might want to launch an xterm for this purpose. I do this for new messages, replies, group-replies and list-replies. http://agriffis.n01se.net/skel.hg/index.cgi/file/tip/bin/xmutt The macros I use are at the top of the script. That's after my muttrc has been processed by m4. See lines 410-447 in: http://agriffis.n01se.net/skel.hg/index.cgi/file/tip/muttrc.in lines 410-447 Aron
Re: Bcc'ing myself on personal mail - not when posting to the list.
Chris Jones wrote: [Fri Nov 21 2008, 08:28:45PM EST] I was wondering if there was a fairly simple way to have mutt help me with this. send-hook . unmy_hdr Bcc: send-hook '!~u' my_hdr Bcc: [EMAIL PROTECTED] Does that do the trick?
Re: fork process on reply
Gary Johnson wrote: [Fri Nov 21 2008, 05:28:54PM EST] Interesting. What do you about setting the 'r' flag for messages to which you've replied? I don't presently. I played with a scheme similar to yours for a while, but I didn't like that there was no way to automatically and reliably set the 'r' flag according to whether or not I actually replied to a message. Yeah, I think the best you can do is set-flagr in the reply macros, and assume you always finish what you start. ;-) Aron
Re: send-hook and different email accounts
Marco Giusti wrote: [Thu Sep 25 2008, 06:52:45AM EDT] why i got this? it's my fault or a mutt's bug? how can i achieve the behaviour needed? I have a configuration that's similar and it works properly for me. Is that your entire config? Aron
Re: send-hook and different email accounts
Marianne Promberger wrote: [Thu Sep 25 2008, 07:21:29AM EDT] I had problems trying to achieve the same thing with set from and I'm now using send-hook . 'my_hdr From: My Name [EMAIL PROTECTED]' Setting $from should work as of 1.5.18 http://dev.mutt.org/hg/mutt/rev/4e8e3db418ea But I didn't know about unmy_hdr, so my_hdr may not be necessary, and there may be a better way to do it with set from (better because for all I remember with my_hdr From, set reverse_name doesn't work). Right, my_hdr From overrides $reverse_name, which usually isn't desired. That's why it's nice to set $from instead. IMHO there is still a tiny problem because it's impossible to determine in a hook (send-hook or send2-hook) what the final From value is, based on the combination of $reverse_name and $from. That's a bit frustrating to me because I'd like to make some other settings based on that value. Aron
tag-prefix in macros
Hi all, To simplify a complex (and let's pretend it's theoretical ;-) scenario, I'd like to do something like: macro index,pager,attach b 'enter-command fooenterbounce-message' Now anybody familiar with tag-prefix will see the problem here... The default binding falls flat: bind generic ';' tag-prefix In particular, the tag-prefix applies to enter-command, not to bounce-message as one would like. Attempting to insert tag-prefix or tag-prefix-cond in the macro doesn't work either, since that might not be the intention. So far, this is what I've done to deal with this scenario: bind generic';' noop macro index,pager,attach 'b' 'enter-command fooenterbounce-message' macro index,pager,attach ';b' \ 'tag-prefix-condenter-command fooentertag-prefixbounce-message' Of course this means rebuilding the full set of bindings. Any other ideas? (apart from changing the approach, remember this is supposedly theoretical...) Thanks, Aron
Re: tag-prefix in macros
Nicolas Rachinsky wrote: [Wed Jul 30 2008, 02:00:13PM EDT] Ok. See mutt-bug #2969 for a link to these patches an at least one more patch. Thanks!
Re: Crappy mailer and Message-ID:
Michelle Konzack wrote: [Fri Jul 13 2007, 10:56:42AM EDT] * * Do not Cc: me, because I am on THIS list, if I write here.* * Keine Cc: an mich, bin auf DIESER Liste wenn ich hier schreibe. * * Ne me mettez pas en Cc:, je suis sur CETTE liste, si j'ecris ici. * * This will be automatic for anybody using mutt if you have in your muttrc: set followup_to=yes # default subscribe mutt-users@mutt.org See http://dev.mutt.org/doc/manual.html#using-lists Unfortunately most MUAs don't respect these headers, but at least on this list it should work :-) Aron
Re: match replies in a send-hook
Aron Griffis wrote: [Thu Jul 12 2007, 07:54:57PM EDT] 1. reply-hooks should run inline with send-hooks instead of before them. The only difference between reply-hooks and send-hooks should be which message they're matching against. 2. send-hooks should be able to recognize when they're running on a message that is a reply. Something better than the subject hack. Bob Bell pointed out to me ~Q, which according to the doc matches messages which have been replied to. This seems to be intended for us in limit or tag-pattern. Whether intentional or inadvertent, it also seems to work for #2 above... send-hook '~Q' 'my_hdr X-Q-Status: this is a reply' send-hook '!~Q' 'my_hdr X-Q-Status: this is not a reply' Thanks Bob! 3. send-hooks should be able to tell if reverse_name succeeded or failed. Right now there is no way to do this short of extremely ugly hacks (think of reply-hook . set from=bogus) 4. There should be a way to run send-hooks on ALL sent messages including bounced messages. Presently no hooks run when a message is bounced, so you just have to get lucky with the folder-hook settings when you hit 'b'.
Re: Crappy mailer and Message-ID:
Michelle Konzack wrote: [Fri Jul 13 2007, 12:02:41PM EDT] Hello Aron, Am 2007-07-13 11:46:14, schrieb Aron Griffis: This will be automatic for anybody using mutt if you have in your muttrc: set followup_to=yes # default subscribe mutt-users@mutt.org See http://dev.mutt.org/doc/manual.html#using-lists Who tell you this? I use mutt since ages... nearly 8 years. I don't understand the question. The manual tells me this. :-) See also http://cr.yp.to/proto/replyto.html Unfortunately most MUAs don't respect these headers, but at least on this list it should work :-) Right, unfortunatly to muck MUAs. Or even the Webmailer do not respect it. I get every day those crappy CCs. Also it is realy annoying, if you want to respond fast and keep not attention for the To/Cc/BCc headers if people hit Group-Reply which will mostly end in PMs which I do not realy like to send. IMHO it's probably better to get used to it, or fight it by technical means, than to bother with large banners in your mail. Ultimately asking everybody who sends you mail to respect this-or-that-request is going to fail... *shrug* Aron
Re: match replies in a send-hook
Aron Griffis wrote: [Mon Jul 09 2007, 05:12:41PM EDT] As far as I can tell, there's no way to determine in a send-hook if the message is a reply. Is that right? I'll explain a bit more what I'm trying to accomplish. I want to send mails with my From address determined by the following algorithm: 1. reverse_name if possible 2. otherwise, depending on the recipients Here is a solution to this problem. Note that mutt's priority order for setting From is: 1. set by my_hdr 2. set by reverse_name 3. $from -- # Current mutt alternates '(^|[-, ])(aron|agriffis|aron.griffis)@' set from=Aron Griffis [EMAIL PROTECTED] # default needed for (b)ounce set reverse_name=yes # Recipient-based hooks; setting $from isn't effective here send-hook '~C @foo.org' 'my_hdr From: Aron Griffis [EMAIL PROTECTED]' send-hook '~C @work1.com''my_hdr From: Aron Griffis [EMAIL PROTECTED]' send-hook '~C @partner1.com' 'my_hdr From: Aron Griffis [EMAIL PROTECTED]' send-hook '~C @work2.com''my_hdr From: Aron Griffis [EMAIL PROTECTED]' # After recipient-based hooks, try to determine if the message is # a reply for which reverse_name succeeded. The best we can do is # look at the subject and hope this is definitive. In that case, kill # the custom header in favor of reverse_name. send-hook '~s ^Re:' unmy_hdr From -- # Mutt with patch http://article.gmane.org/gmane.mail.mutt.devel/14042 alternates '(^|[-, ])(aron|agriffis|aron.griffis)@' set from=Aron Griffis [EMAIL PROTECTED] # default needed for (b)ounce set reverse_name=yes # Recipient-based hooks send-hook '~C @foo.org' 'set from=Aron Griffis [EMAIL PROTECTED]' send-hook '~C @work1.com''set from=Aron Griffis [EMAIL PROTECTED]' send-hook '~C @partner1.com' 'set from=Aron Griffis [EMAIL PROTECTED]' send-hook '~C @work2.com''set from=Aron Griffis [EMAIL PROTECTED]' -- Frankly, I'm of two minds regarding the patch-based solution. PRO: The ~s ^Re: send-hook is hackish and best avoided. It could also be avoided with the q-pattern patch but that met zero feedback last time I posted it. http://n01se.net/paste/850 PRO: Modifying $from is advantageous because it affects the envelope sender as well as the From: header. This is important when sending mail from multiple accounts using a single mutt instance. CON: Modifying $from will affect messages sent after the current one, including *bounced* messages. To counter this, you'll find a pretty serious hack. There are three ways to return to the index from the compose menu. Either you send the message, abort it, or postpone it. macro compose P 'postpone-messageenter-command set ...enter' macro compose q 'exitenter-command set ...enter' macro compose y 'send-messageenter-command set ...enter' ...and of course it's worse than that. If you want different settings for different folders, it gets deep quick. Full details at http://n01se.net/agriffis/skel.hg/?file/tip/muttrc.in Oh well. Now that I've written all this, I'm not certain it's anything but a rant about my frustration trying to find an elegant solution to a seemingly simple problem in mutt. Probably what's needed to alleviate this frustration is: 1. reply-hooks should run inline with send-hooks instead of before them. The only difference between reply-hooks and send-hooks should be which message they're matching against. 2. send-hooks should be able to recognize when they're running on a message that is a reply. Something better than the subject hack. 3. send-hooks should be able to tell if reverse_name succeeded or failed. Right now there is no way to do this short of extremely ugly hacks (think of reply-hook . set from=bogus) 4. There should be a way to run send-hooks on ALL sent messages including bounced messages. Presently no hooks run when a message is bounced, so you just have to get lucky with the folder-hook settings when you hit 'b'. Is anybody else frustrated by these shortcomings or is it just me? Did anybody really read this entire message? :-) Aron
match replies in a send-hook
As far as I can tell, there's no way to determine in a send-hook if the message is a reply. Is that right? This is the most obvious thing to try, but it doesn't work because ~h is invalid in the context of a send-hook: send-hook '=h In-Reply-To:' ... Here's what I'm using presently, but I'd prefer something more definitive: send-hook '~s ^Re:' ... Thanks, Aron
Re: match replies in a send-hook
Gary Johnson wrote: [Mon Jul 09 2007, 05:43:51PM EDT] On 2007-07-09, Aron Griffis [EMAIL PROTECTED] wrote: As far as I can tell, there's no way to determine in a send-hook if the message is a reply. Is that right? This is the most obvious thing to try, but it doesn't work because ~h is invalid in the context of a send-hook: send-hook '=h In-Reply-To:' ... Here's what I'm using presently, but I'd prefer something more definitive: send-hook '~s ^Re:' ... Would a reply-hook work for you? Nope, because what I'm really trying to do is match messages that are *not* replies. Additionally I want to keep my hooks in order, which reply-hook breaks. Thanks, Aron
