Interesting mutt patches for mutt-kz
by Suvayu Ali
Hi everyone,
Since mutt-kz aims toward more features than typical mutt, I was
wondering if it would be possible to include the following patches.
https://bitbucket.org/dgc/mutt-dgc/raw/42d6f8d629ad3f0ceb7f4790013d3cec66...
This patch lets you create mulitpart/alternative message parts in the
compose screen.
Here is a usage description by the author:
> The <group-alternatives> binding for the componse menu (where you press
> 's' to send) combines selected attachments into a multipart/alternative
> group. The <move-up> and <move-down> bindings then allow you to change
> their order.
https://bitbucket.org/dgc/mutt-dgc/raw/42d6f8d629ad3f0ceb7f4790013d3cec66...
This patch allows regular expression based transformation of email
subjects when displayed in the index. It can be useful to get rid of
mailing list tags (e.g. [list-name]), or trim long subject lines.
Caveat: I failed to apply the subjectrx patch some time back, but I did
not attempt to fix it. Maybe it is possible with small changes.
WDYT?
--
Suvayu
Open source is the future. It sets us free.
9 years, 9 months
bug: [s]ave function adds bogus pathnames into the notmuch DB
by Selene Scriven
After updating to the latest mutt-kz in git, I noticed some
strange behavior. I was getting weird results for folder-based
queries. After some investigation, I narrowed it down to the
[s]ave and purge functions in mutt-kz.
I'm running git rev be196028c755d3ffff184e9781ac933fbacbd562 (Thu
Jan 2 15:15:55 2014 +0100).
Steps to reproduce the issue:
- Open a virtual folder in mutt-kz.
- [s]ave a message to a different Maildir. (original gets
marked as [D]eleted)
- Purge deleted messages.
Mutt-kz then prints an error. It's a bit hard to catch before
the screen redraws, but it looks like... "Writing
notmuch://?query=(folder:INBOX or (... (...older:in...ror: A
Xapian exception occurred flushing database: Can't commit during
a transaction"
At this point, I can query notmuch directly to see the broken
pathname. 'notmuch search folder:$HOME' works, but I prefer this
for more detail:
> nm-files id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local
=== id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local ===
thread:000000000003ff58 Today 10:31 [1/1] H&R Block; Appointments available now – give us a call (unread)
/home/selene/mail//home/selene/mail/receipts//new/1392149990.21796_1.mutt
Messages: 1
After running 'notmuch new', the database updates by adding the correct pathname:
> nm-files id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local
=== id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local ===
thread:000000000003ff58 Today 10:31 [1/1] H&R Block; Appointments available now – give us a call (unread)
/home/selene/mail//home/selene/mail/receipts//new/1392149990.21796_1.mutt
/home/selene/mail/receipts/new/1392149990.21796_1.mutt
Messages: 1
This gets weird if the message is ever moved again, because the
broken pathname shows up forever unless the DB gets dumped,
rebuilt from scratch, and restored (which takes ~3 hours for me).
Notmuch never detects the error or removes the bogus path.
For reference, here is the script I used above:
> cat bin/local/nm-files
#!/bin/sh
# show the files associated with each message for a given search
for ID in $( notmuch search --output=messages $* ); do
echo "=== $ID ==="
notmuch search --output=summary $ID
notmuch search --output=files $ID
echo
done
echo -n "Messages: " ; notmuch search $* | wc -l
-- Selene
9 years, 9 months
