On 13May2014 17:06, Alex Andreotti <alex.andreo...@gmail.com> wrote:
> I'm using mutt in a desktop environment, would like to know if there's
> a way (any) to make mutt go to a specific email from an external
> program/script, mutt could be in a different mailbox, ideally this
> should change too.
Patrice Levesque <mutt.wa...@ptaff.ca> wrote:
I believe you mean “Is there a way to control an already-running mutt
instance so that it goes to a specific mail message”?
Yes
[... mechanism, and description of hazards...]
Unless somebody comes up with something really clever, I'd strongly
suggest you consider spawning a different instance of mutt instead;
much, *much* simpler and foolproof.
For some reason I didn't think about this... eventually will be a nice
fall back.
Let me say I second Patrice's recommendation, and that this is what I do: spawn
a new terminal with a new mutt inside.
The approach I use requires the external program to know the mail folder and
message-id. Since my core use case is actionable MacOSX notifications that are
emitted by my mail filer, I have those two things to hand already.
The core step of interest to you is my mutt-open-message script:
https://bitbucket.org/cameron_simpson/css/src/tip/bin/mutt-open-message
Most of that is argument processing and construction of $pattern: the critical
mutt incantation is the last line:
mutt -f "$folder" -e "push '<search>$pattern<enter><display-message>'"
Feel free to take the script as a whole, and indeed any of the other related
scripts, which I'm going to sketch now.
The mail filer, for particular messages, runs the command:
alert -e term -e mutt-open-message -f foldername message-id -- "alert message
here..."
"term" is a script to open a terminal and run and command in it; it is my
platform agnostic "open a terminal" wrapper. On a Mac it opens "Terminal".
The remaining complexity is specific to MacOSX users; if you're not one you can
probably adapt part of all of this to your desktop simply enough.
Links to some scripts:
alert: https://bitbucket.org/cameron_simpson/css/src/tip/bin/alert
as-script: https://bitbucket.org/cameron_simpson/css/src/tip/bin/as-script
term: https://bitbucket.org/cameron_simpson/css/src/tip/bin/term
All the others are easily inferrable from these, or you could grab a tarball or
just clone the repository.
For MacOSX users, a few remarks on the hoop jumping I've needed to make this
work:
Notifications: the "alert" script uses "terminal-notifier" if it is on MacOSX.
I get this from MacPorts. Like "Terminal" and a heap of other Mac executables,
it accepts a shell string, possibly passes badly though AppleScript, as the
command to execute instead of a nice clean sequence of arguments (such as
"xterm -e" accepts).
Because of this, I have the script "as-script" whose whole purpose is to take a
nice clean list of arguments and transcribe them to a shell script correctly
quotes, and preserving the current directory and environment. The latter are to
spawn a terminal with the right environment from the notification dialogue
arbitrarily later.
So both "alert" and "term" use "as-script" to get a pathname to an executable
script which we can pass to terminal-notifier or AppleScript without worrying
about hideous quoting.
So the sequence is:
mailfiler runs "alert" as the command to emit a notification, passing:
term -e mutt-open-message -f foldername message-id
as the notification action.
When a notification is clicked, it runs term (above) to pop up mutt open to
that message.
Any questions about the intervening mechanisms, feel free to ask.
Cheers,
Cameron Simpson <c...@zip.com.au>
Maintainer's Motto: If we can't fix it, it ain't broke.
