Re: [notmuch] Notmuch's search view sucks
On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth wrote: > And a step beyond that would support different languages for > different emails, but that sounds like something "hard" to identify. But probably not as hard as identifying spam. It could probably be done with a simple Bayesian filter counting word frequencies---but it'd be much better if somebody else had already solved the problem, since this smells suspiciously like something that ought to be a separate project and put in a library ... does anyone know if such a project already exists? I know Google can do it ... It'd be very cool to have notmuch automatically tag messages according to what language they're in. -- Karl Wiberg, k...@treskal.com subrabbit.wordpress.com www.treskal.com/kalle ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Trouble with notmuch-show
I know html support is still poor, but the following seems worse than
not showing anything. When I visit this message, I get prompted to save
the MIME part and the following is displayed (including all the hidden
stuff). Original message is attached.
Jed
message{ id:4B182A91.9020304 at sandia.gov depth:0 match:1
filename:/home/jed/.mail-archive/gmail-all/pop/new/1259875803.M47630P27852Q0R271bd14e8c36baf4.localhost
header{
"Raymond Tuminaro" (46 mins. ago) (inbox unread)
Subject: [SIAM-CSE] Copper Mountain Iterative Methods Announcement Posting,
April 4-9, 2010
From: "Raymond Tuminaro"
To: siam-cse at siam.org
Cc:
Bcc:
Date: Thu, 3 Dec 2009 13:16:01 -0800
header}
body{
part{ ID: 2, Content-type: text/html
Non-text part: text/html
part}
part{ ID: 3, Content-type: text/plain
___
SIAM-CSE mailing list
To post messages to the list please send them to: SIAM-CSE at siam.org
http://lists.siam.org/mailman/listinfo/siam-cse
part}
body}
message}
-- next part --
A non-text attachment was scrubbed...
Name: 1259875803.M47630P27852Q0R271bd14e8c36baf4.localhost
Type: application/octet-stream
Size: 12176 bytes
Desc: Problem html message
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091203/602423b2/attachment-0001.obj>
Re: [notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
On Thu, 03 Dec 2009 10:48:00 +0100, Marten Veldthuis wrote: > I can see one clear case where that would become a problem: mistaggings. > If I set up something so that in 99% of the cases, it'd tag new mail > correctly with say "inbox unread mytag", I could quickly pick the > mistagged ones out and remove the offending tag. > > If you do it like above however, the autotag script would come merrily > along and retag them. Right. A fully automatic, rule-based tag does not allow for manual deletion of the exact same tag, (nor even manual addition). I've given this some thought and there are things we could do here. For example, the automatic tag could be stored internally under a different prefix than the manual tag of the same name. That would be enough to support the manual addition of a tag, such that a user-level search such as: tag:foo would map internally to something like: (auto-tag:foo OR manual-tag:foo) Then manual tag removal could similarly be stored as yet anther internal prefix that would work in a negative sense. So the search for "tag:foo" would now map to: ((auto-tag:foo OR manual-tag:foo) AND NOT manual-tag-removal:foo) [*] I'm not sure yet if this idea is simply clever or insanely stupid. It does seem like we could do this and hide all of the complexity entirely from the user. But hidden complexity can raise its head in nasty ways. Such as "I wrote this rule in my configuration file, why isn't it working?" (in the face of a hidden manual-tag-removal). Another idea would be to just keep the rule-based tags strictly as configured, explicitly prevent the user from manually adding/removing tags of the same name. And then the user could play games like the above in saved searches to be able to simulate manual touchups of rule-based tags, (without the automatic vs. manual state being hidden). Yet another idea is to keep all rule-based tagging out of the configuration, and let the user come up with whatever scheme they most prefer. This could still allow for the configuration to hold saved searches, (which could stand in for rule-based tags in a lot of cases and avoid a lot of the complexity discussed here). So those are some of my current thoughts on the issue. And that's why I haven't put any auto tagging into the configuration file yet. -Carl [*] Or should that be: (manual-tag:foo OR (auto-tag:foo AND NOT manual-tag-removal:foo)) It probably wouldn't matter in practice as presumably the addition of the manual-tag would remove any manual-tag-removal and vice-versa. pgpXgxLBgKfRD.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
On Thu, 03 Dec 2009 10:48:00 +0100, Marten Veldthuis wrote: > I can see one clear case where that would become a problem: mistaggings. > If I set up something so that in 99% of the cases, it'd tag new mail > correctly with say "inbox unread mytag", I could quickly pick the > mistagged ones out and remove the offending tag. > > If you do it like above however, the autotag script would come merrily > along and retag them. Right. A fully automatic, rule-based tag does not allow for manual deletion of the exact same tag, (nor even manual addition). I've given this some thought and there are things we could do here. For example, the automatic tag could be stored internally under a different prefix than the manual tag of the same name. That would be enough to support the manual addition of a tag, such that a user-level search such as: tag:foo would map internally to something like: (auto-tag:foo OR manual-tag:foo) Then manual tag removal could similarly be stored as yet anther internal prefix that would work in a negative sense. So the search for "tag:foo" would now map to: ((auto-tag:foo OR manual-tag:foo) AND NOT manual-tag-removal:foo) [*] I'm not sure yet if this idea is simply clever or insanely stupid. It does seem like we could do this and hide all of the complexity entirely from the user. But hidden complexity can raise its head in nasty ways. Such as "I wrote this rule in my configuration file, why isn't it working?" (in the face of a hidden manual-tag-removal). Another idea would be to just keep the rule-based tags strictly as configured, explicitly prevent the user from manually adding/removing tags of the same name. And then the user could play games like the above in saved searches to be able to simulate manual touchups of rule-based tags, (without the automatic vs. manual state being hidden). Yet another idea is to keep all rule-based tagging out of the configuration, and let the user come up with whatever scheme they most prefer. This could still allow for the configuration to hold saved searches, (which could stand in for rule-based tags in a lot of cases and avoid a lot of the complexity discussed here). So those are some of my current thoughts on the issue. And that's why I haven't put any auto tagging into the configuration file yet. -Carl [*] Or should that be: (manual-tag:foo OR (auto-tag:foo AND NOT manual-tag-removal:foo)) It probably wouldn't matter in practice as presumably the addition of the manual-tag would remove any manual-tag-removal and vice-versa. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/088d51fe/attachment.pgp>
Re: [notmuch] [PATCH 2/9] Adjust autoload comments
Firstly, thanks for the full explanations! On Thu, 03 Dec 2009 17:04:52 -0800, Carl Worth wrote: > The notmuch-folder command is definitely a nice primary interface to > notmuch for some people. I'm seriously considering making it the view > that one gets with "M-x notmuch" (after the notmuch-folder view gets a > little sprucing up). Coming from sup and being a gmail user "emacs -f notmuch" seems like the natural mail interface to me. Still, even if the default view changes I can switch to just opening a tag:inbox search. I've left the elisp-make-autoload-file change in our builds, which means all the ";;;###autoload" enveloped functions are available. Nobody seems to be upset by the change. > As for notmuch-search, I find it very convenient to have the ability to > do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it) > From any random emacs buffer. If you don't live inside emacs, and just > have a single emacs frame open for notmuch sake, maybe that's not as > interesting. Carl, you've got me pegged. I use the /other/ editor, I only installed emacs for notmuch. For me, I've already managed to train myself to just fire up notmuch and hit 's' when searching. The extra search buffer that method creates makes no difference to my personal usage patterns. -- Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/9] Adjust autoload comments
On Thu, Dec 03, 2009 at 05:04:52PM -0800, Carl Worth wrote: > The notmuch-folder command is definitely a nice primary interface to > notmuch for some people. I'm seriously considering making it the view > that one gets with "M-x notmuch" (after the notmuch-folder view gets a > little sprucing up). I actually really like having notmuch open right into my "inbox". I thought part of the point of notmuch was to get rid of the whole dump idea of folders! jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/6dbd9d8f/attachment.pgp>
Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface
On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth wrote: > * Much nicer looking presentation, (no more ugly reverse-video or > underlines on the message summary line). > > * More reliable message-visibility buttons, (using RET in the first > column of a message-summary line now works). Not sure what happened, but: Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts From: cama...@picnicpark.org To: notmuch@notmuchmail.org Cc: Keith Amidon Bcc: Date: Fri, 27 Nov 2009 05:30:10 -0800 now collapses into: Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts From: Keith Amidon on my system (notice the From: header). -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH 2/9] Adjust autoload comments
On Thu, Dec 03, 2009 at 05:04:52PM -0800, Carl Worth wrote: > The notmuch-folder command is definitely a nice primary interface to > notmuch for some people. I'm seriously considering making it the view > that one gets with "M-x notmuch" (after the notmuch-folder view gets a > little sprucing up). I actually really like having notmuch open right into my "inbox". I thought part of the point of notmuch was to get rid of the whole dump idea of folders! jamie. signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] vim: preserve the 'show everything' flag when finding next/prev buffer
* Carl Worth [091203 16:31]: > Sorry I missed this with your earlier, related changes. But I've pushed > this now. Thanks. -Bart -- WebSig: http://www.jukie.net/~bart/sig/
Re: [notmuch] [PATCH] Remove unused notmuch_parse_date function prototype.
On Sat, 28 Nov 2009 14:11:16 -0600, "Jeffrey C. Ollie" wrote: > notmuch_parse_date is not implemented, so remove the unused function > prototype. Thanks for helping to clean out this cruft. Obviously, this function did exist in the past. -Carl PS. Is there any easy way to check for problems like this at compile time? (I suppose I could go look at the checks we have in the cairo project---I know Behdad wrote stuff there to ensure we weren't leaking private functions into the library interface, etc. so he may have coded up something for this case as well.) pgpolg4zAwwYw.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Remove unused notmuch_parse_date function prototype.
On Sat, 28 Nov 2009 14:11:16 -0600, "Jeffrey C. Ollie" wrote: > notmuch_parse_date is not implemented, so remove the unused function > prototype. Thanks for helping to clean out this cruft. Obviously, this function did exist in the past. -Carl PS. Is there any easy way to check for problems like this at compile time? (I suppose I could go look at the checks we have in the cairo project---I know Behdad wrote stuff there to ensure we weren't leaking private functions into the library interface, etc. so he may have coded up something for this case as well.) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/4611d9e5/attachment.pgp>
Re: [notmuch] [PATCH 2/9] Adjust autoload comments
On Mon, 30 Nov 2009 20:38:00 +, James Rowe wrote: > I had planned on posting a patch for inclusion in packaging/Gentoo per > Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the > backburner and I haven't looked again. Might still be useful to people > unless there is going to be a "real" release soon, as then it would be > easier to push for it on bugs.gentoo.org. Is the GPLv3 a problem for you and your ebuild for some reason, or is it just that you happened to start with a GPLv2 file or so? I'm definitely interested in hearing, since this is the first project I've let loose myself under the GPLv3. So far, it hasn't seemed to be a big impediment to contributions, which I think is great. -Carl pgpscK31hu3ei.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/9] Adjust autoload comments
On Mon, 30 Nov 2009 20:38:00 +, James Rowe wrote: > I had planned on posting a patch for inclusion in packaging/Gentoo per > Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the > backburner and I haven't looked again. Might still be useful to people > unless there is going to be a "real" release soon, as then it would be > easier to push for it on bugs.gentoo.org. Is the GPLv3 a problem for you and your ebuild for some reason, or is it just that you happened to start with a GPLv2 file or so? I'm definitely interested in hearing, since this is the first project I've let loose myself under the GPLv3. So far, it hasn't seemed to be a big impediment to contributions, which I think is great. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/99aa9913/attachment.pgp>
Re: [notmuch] [PATCH 2/9] Adjust autoload comments
On Mon, 30 Nov 2009 20:38:00 +, James Rowe wrote:
> I have to admit I played with elisp-make-autoload-file in my ebuild
> initially, but came to the conclusion there wasn't a great deal of
> purpose to exposing more than the main notmuch function. Mostly because
> it muddies my emacs and shell autocompletion, and my laziness prevailed.
> Am I missing some obviously useful things that can be done if
> notmuch-{folder,search} are available directly?
The notmuch-folder command is definitely a nice primary interface to
notmuch for some people. I'm seriously considering making it the view
that one gets with "M-x notmuch" (after the notmuch-folder view gets a
little sprucing up).
As for notmuch-search, I find it very convenient to have the ability to
do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it)
From any random emacs buffer. If you don't live inside emacs, and just
have a single emacs frame open for notmuch sake, maybe that's not as
interesting.
-Carl
pgpDwyxv7wvMU.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/9] Adjust autoload comments
On Mon, 30 Nov 2009 20:38:00 +, James Rowe wrote:
> I have to admit I played with elisp-make-autoload-file in my ebuild
> initially, but came to the conclusion there wasn't a great deal of
> purpose to exposing more than the main notmuch function. Mostly because
> it muddies my emacs and shell autocompletion, and my laziness prevailed.
> Am I missing some obviously useful things that can be done if
> notmuch-{folder,search} are available directly?
The notmuch-folder command is definitely a nice primary interface to
notmuch for some people. I'm seriously considering making it the view
that one gets with "M-x notmuch" (after the notmuch-folder view gets a
little sprucing up).
As for notmuch-search, I find it very convenient to have the ability to
do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it)
Re: [notmuch] [PATCH] Add some text to configure on how to install dependencies with yum.
On Sat, 28 Nov 2009 08:20:08 -0600, "Jeffrey C. Ollie" wrote: > Add some text on how to install dependencies with yum for Fedora or > other systems that use yum for package management. Since the named of > the required packages on Fedora are slightly different from Debian > this will help get new users of notmuch that use Fedora going quicker. Thanks Jeffrey, I'm sure many people will find this very convenient. This is pushed. -Carl pgpmdkpGm59lv.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Add some text to configure on how to install dependencies with yum.
On Sat, 28 Nov 2009 08:20:08 -0600, "Jeffrey C. Ollie" wrote: > Add some text on how to install dependencies with yum for Fedora or > other systems that use yum for package management. Since the named of > the required packages on Fedora are slightly different from Debian > this will help get new users of notmuch that use Fedora going quicker. Thanks Jeffrey, I'm sure many people will find this very convenient. This is pushed. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/06cae925/attachment-0001.pgp>
Re: [notmuch] [PATCH] notmuch-reply: Display reply message part using UTF-8.
On Sat, 28 Nov 2009 19:58:29 +0800, Kan-Ru Chen wrote: > Pass the message through the charset filter so that we can view > messages wrote in different charset encoding. ... > Same problem as notmuch-show before. Noticed this when I intend to > reply a Chinese mail... Thanks Kanru, This is pushed now. -Carl pgpI7Zo0wCKIX.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] notmuch-reply: Display reply message part using UTF-8.
On Sat, 28 Nov 2009 19:58:29 +0800, Kan-Ru Chen wrote: > Pass the message through the charset filter so that we can view > messages wrote in different charset encoding. ... > Same problem as notmuch-show before. Noticed this when I intend to > reply a Chinese mail... Thanks Kanru, This is pushed now. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/3dd85ea9/attachment.pgp>
Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool
On Thu, 3 Dec 2009 03:15:26 +0600, Mikhail Gusarov wrote: > In order to handle message renames the following changes were deemed > necessary: Hi Mikhail, Thanks for contributing this patch (twice!). I think if I had gotten to it sooner, I probably would have committed it. But now... > * Mtime check on individual files was disabled. As files may be moved around > without changing their mtime, it's necessary to parse them even if they appear > old in case old message was moved. mtime check on directories was kept as > moving > files changes mtime of directory. That sounds pretty harsh. I'm having to do a lot of stat() calls already when new mail arrives. Having to also parse the message ID out of (roughly, for me) 1 files every time sounds pretty rough. Fortunately... > Note that after applying this patch notmuch still does not handle copying > files > (which is harmless, database will point to the last copy of message found > during > 'notmuch new') and deleting files (which is more serious, as dangling entries > will show up in searches). Today, Keith and designed an interface that will support addition, copying, rename, and deletion of files. And it will be faster than the existing code with its mtime heuristics. The complete design is on Keith's laptop right now, and hopefully he'll appear soon with an implementation. Basically, there are only two new functions needed in the library (if we got the design right): notmuch_directory_t notmuch_database_read_directory (notmuch_database_t *database, const char *path); notmuch_status_t notmuch_message_remove_filename (notmuch_message_t *message, const char *filename); The notmuch_directory_t object will be used in place of the current notmuch_database_get_timestamp call in notmuch-new.c. In addition to the mtime that we currently read from the database, it will provide a list of all directories and files (along with message IDs) known to the database for a particular path. So notmuch-new can then quickly compare the results of scandir with this notmuch_directory_t object and then call notmuch_database_add_message and notmuch_message_remove_filename as appropriate. I'm leaving out details about how to ensure we don't delete a message too soon if it's actually a rename that will be seen as an added file later in the scan. Obviously the implementation will need to deal with that, (either with an additional library call for "I'm done adding files, go ahead and delete dangling messages", or by postponing all calls to remove_filename until later). Oh, and one idea is to do deletion by dropping all indexed terms, but saving the message ID and any tags in the database. That's small and is the only precious data, so might be worth holding onto "just in case". Anyway, I think we'll see code for that soon, so I'm not planning to commit the offered patch. But people really needing renames might want to use it for now, (and live with any performance implications it causes). -Carl pgpK07jCVYjC6.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH (rebased)] Handle message renames in mail spool
On Thu, 3 Dec 2009 03:15:26 +0600, Mikhail Gusarov wrote: > In order to handle message renames the following changes were deemed > necessary: Hi Mikhail, Thanks for contributing this patch (twice!). I think if I had gotten to it sooner, I probably would have committed it. But now... > * Mtime check on individual files was disabled. As files may be moved around > without changing their mtime, it's necessary to parse them even if they appear > old in case old message was moved. mtime check on directories was kept as > moving > files changes mtime of directory. That sounds pretty harsh. I'm having to do a lot of stat() calls already when new mail arrives. Having to also parse the message ID out of (roughly, for me) 1 files every time sounds pretty rough. Fortunately... > Note that after applying this patch notmuch still does not handle copying > files > (which is harmless, database will point to the last copy of message found > during > 'notmuch new') and deleting files (which is more serious, as dangling entries > will show up in searches). Today, Keith and designed an interface that will support addition, copying, rename, and deletion of files. And it will be faster than the existing code with its mtime heuristics. The complete design is on Keith's laptop right now, and hopefully he'll appear soon with an implementation. Basically, there are only two new functions needed in the library (if we got the design right): notmuch_directory_t notmuch_database_read_directory (notmuch_database_t *database, const char *path); notmuch_status_t notmuch_message_remove_filename (notmuch_message_t *message, const char *filename); The notmuch_directory_t object will be used in place of the current notmuch_database_get_timestamp call in notmuch-new.c. In addition to the mtime that we currently read from the database, it will provide a list of all directories and files (along with message IDs) known to the database for a particular path. So notmuch-new can then quickly compare the results of scandir with this notmuch_directory_t object and then call notmuch_database_add_message and notmuch_message_remove_filename as appropriate. I'm leaving out details about how to ensure we don't delete a message too soon if it's actually a rename that will be seen as an added file later in the scan. Obviously the implementation will need to deal with that, (either with an additional library call for "I'm done adding files, go ahead and delete dangling messages", or by postponing all calls to remove_filename until later). Oh, and one idea is to do deletion by dropping all indexed terms, but saving the message ID and any tags in the database. That's small and is the only precious data, so might be worth holding onto "just in case". Anyway, I think we'll see code for that soon, so I'm not planning to commit the offered patch. But people really needing renames might want to use it for now, (and live with any performance implications it causes). -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/6a8cc6f5/attachment.pgp>
Re: [notmuch] Hi, I'm Mark, and I'm addicted to effective mail handling
On Thu, 3 Dec 2009 14:17:44 -0700, Mark Anderson wrote: > I've been a good friend of Carl's since college, and was following his > interest in 'sup'. Hi Mark, welcome to notmuch! > I have transitioned to 'sup', and I'm ready to move on. Hopefully, tracking my interests in mailers will be a smoother ride from here on out. :-) > The main issue I've had with getting notmuch working is that I've been > using difficult distros. Hey, I got it working with macports on OS X 10.4 last week. Does that count? Good luck getting things going. I guess one consolation is that by the time you do get it running, notmuch will be a bit better than it is today. -Carl pgpfV5BbrUvxV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch's search view sucks
On Thu, 03 Dec 2009 14:33:51 +0100, Gregor Hoffleit wrote:
> first a short introduction: I was a mutt user for ages. When I read
> about Sup, I was intrigued. After a short evaluation period, I switched
> to Sup, which I'm now using since six months.
Hi Gregor, welcome to notmuch!
> But. Compared to Sup, the current notmuch clients suck :-)
Hey, we like our rough edges *really* rough, dontcha know?
> I'm experimenting with a notmuch web client (currently 'evenless'),
> trying to replicate much of the feeling of Sup, in a web client.
Hey, that sounds really interesting! I'll definitely look forward to
what you come up with.
> Also, any l10n (e.g. of time representation) would have to be hardcoded
> as well (btw, anybody knows a library for human readable time
> representations which supports l10n and i18n?).
I'd love to see one. The quick scan I did for human-readable time
formatting found stuff in languages like perl, python, and ruby, but I
didn't notice much in C. I also didn't look close enough to see if any
of these have multi-language suport.
> So perhaps it's better to move the polishing into the client (Yeah!
> Python to the rescue! ;-). But then, 'notmuch search' would need to
> return some raw representation of the date field as well.
Good point. There's actually a weird mix of raw and cooked output from
the notmuch command line right now. As you noticed, "notmuch search"
cooks the date too much, (and in a way useful only to English speakers).
Meanwhile, the "notmuch show" output is far too raw to be read without a
client prettying it up. (The message{ header{ body{ body} header}
message} stuff is almost as bad as XML.)
> Any comment? Any other thoughts about this?
I think I'd like to see notmuch output get both more cooked and more raw
at the same time. I'd like things to be more cooked by default,
("notmuch show" shouldn't print the ugly delimiters, should indent
messages, and should start up a pager). And then we just need options
that frontends can pass to get the raw output, (but quoted
safely---which the current "notmuch show" output is *not*).
-Carl
PS. If you're worried about multi-lingualization issues for notmuch,
you'll want to know that notmuch is (for now) unconditionally
instructing Xapian to use an English-language stemmer when indexing
mail. Obviously we'll want to support a configuration option for
specifying a default stemmer, (Xapian has stemmers for many languages I
believe). And a step beyond that would support different languages for
different emails, but that sounds like something "hard" to identify.
pgp51kI3oj69Z.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch's search view sucks
On Thu, 03 Dec 2009 14:33:51 +0100, Gregor Hoffleit
wrote:
> first a short introduction: I was a mutt user for ages. When I read
> about Sup, I was intrigued. After a short evaluation period, I switched
> to Sup, which I'm now using since six months.
Hi Gregor, welcome to notmuch!
> But. Compared to Sup, the current notmuch clients suck :-)
Hey, we like our rough edges *really* rough, dontcha know?
> I'm experimenting with a notmuch web client (currently 'evenless'),
> trying to replicate much of the feeling of Sup, in a web client.
Hey, that sounds really interesting! I'll definitely look forward to
what you come up with.
> Also, any l10n (e.g. of time representation) would have to be hardcoded
> as well (btw, anybody knows a library for human readable time
> representations which supports l10n and i18n?).
I'd love to see one. The quick scan I did for human-readable time
formatting found stuff in languages like perl, python, and ruby, but I
didn't notice much in C. I also didn't look close enough to see if any
of these have multi-language suport.
> So perhaps it's better to move the polishing into the client (Yeah!
> Python to the rescue! ;-). But then, 'notmuch search' would need to
> return some raw representation of the date field as well.
Good point. There's actually a weird mix of raw and cooked output from
the notmuch command line right now. As you noticed, "notmuch search"
cooks the date too much, (and in a way useful only to English speakers).
Meanwhile, the "notmuch show" output is far too raw to be read without a
client prettying it up. (The message{ header{ body{ body} header}
message} stuff is almost as bad as XML.)
> Any comment? Any other thoughts about this?
I think I'd like to see notmuch output get both more cooked and more raw
at the same time. I'd like things to be more cooked by default,
("notmuch show" shouldn't print the ugly delimiters, should indent
messages, and should start up a pager). And then we just need options
that frontends can pass to get the raw output, (but quoted
safely---which the current "notmuch show" output is *not*).
-Carl
PS. If you're worried about multi-lingualization issues for notmuch,
you'll want to know that notmuch is (for now) unconditionally
instructing Xapian to use an English-language stemmer when indexing
mail. Obviously we'll want to support a configuration option for
specifying a default stemmer, (Xapian has stemmers for many languages I
believe). And a step beyond that would support different languages for
different emails, but that sounds like something "hard" to identify.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091203/e324ef5e/attachment.pgp>
[notmuch] Hi, I'm Mark, and I'm addicted to effective mail handling
On Thu, 3 Dec 2009 14:17:44 -0700, Mark Anderson wrote: > I've been a good friend of Carl's since college, and was following his > interest in 'sup'. Hi Mark, welcome to notmuch! > I have transitioned to 'sup', and I'm ready to move on. Hopefully, tracking my interests in mailers will be a smoother ride from here on out. :-) > The main issue I've had with getting notmuch working is that I've been > using difficult distros. Hey, I got it working with macports on OS X 10.4 last week. Does that count? Good luck getting things going. I guess one consolation is that by the time you do get it running, notmuch will be a bit better than it is today. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/7cf55208/attachment.pgp>
[notmuch] hack to retag a directory
At Thu, 03 Dec 2009 09:39:32 -0400, david at tethera.net wrote: > I think this will be obsolete pretty soon when the equivalent is > built-in to notmuch, but in the mean time, here is a script that > somebody might find useful: retag a whole directory (recursively). I > don't claim it is nice in any way, but it seems usable for me, taking > about 5 seconds to retag a directory containing 1000 messages. Sigh. And of course the version I posted was broken. I put a fixed version at http://pivot.cs.unb.ca/git/?p=notmuch-scripts.git;a=blob_plain;f=tagdir;hb=HEAD You might, or might not also be interested in http://pivot.cs.unb.ca/git/?p=notmuch-scripts.git;a=blob_plain;f=gitmuch;hb=HEAD which is the beginnings of how to keep tags in git (for syncing between machines). Right now the notmuch restore step is the bottleneck, but Carl apparently knows how to speed 'notmuch restore' up. d
[notmuch] Notmuch's search view sucks
Hi there, first a short introduction: I was a mutt user for ages. When I read about Sup, I was intrigued. After a short evaluation period, I switched to Sup, which I'm now using since six months. Sup has many rough edges on its own, and it's not that easy to fix some of them from the current codebase. notmuch looks like a clean restart of the same idea, but with a different architecture. I like the concept of a command line tool with a minimal set of functionality as a common core, upon which different clients can build on. But. Compared to Sup, the current notmuch clients suck :-) Today: Sup's search-results-mode. It has a lot of polish that's plainly missing from notmuch.el (or notmuch.vim): - Sup's display is much terse than notmuch, still - Sup manages to display the first few words of the first unread message in the thread. - If a thread contains many authors, Sup shows only the firstnames. If that's still too long to fit, it cuts off at some point. - User's name is rewritten as 'me'. - The message date format needs only 8 characters (notmuch: 12). - Message count is only displayed when necessary (>=1). - Threads with unread messages are bold (resp. hilighted). - Threads with attachments are marked with an "@". - Threads with mails to user are marked with an ">". - Different colors of tags, message content. All in all, 'notmuch search' is a raw representation of field values, while Sup's search-results-mode shows a polished and terse interpretation of the same values, for human beings, even optimized for the current display width. Now notmuch.el and notmuch.vim just display the output of 'notmuch search', verbatim (perhaps enhanced with coloring based on regexes). I'm experimenting with a notmuch web client (currently 'evenless'), trying to replicate much of the feeling of Sup, in a web client. First, I took the output of 'notmuch search', parsed it and tried to reformat it like Sup. That worked well for all fields but the date field: In contrast to the other fields, notmuch's date representation is intended for direct consumption by humans (english-speaking, that is ;-). I noticed this entry in TODO: Add a "--format" option to "notmuch search", (something printf-like for selecting what gets printed). Since I'm not eager to write a format parser, I started to implement --format as an enumerating option notmuch_format_t. By now, I have NOTMUCH_FORMAT_DEFAULT and NOTMUCH_FORMAT_SUP. do_search_threads() does the real work. In notmuch-time.c, I have implemented an alternative nice and terse time representation, notmuch_time_relative8_date(). I realized, though, that at this point I would have to hardcode things like ANSI coloring into NOTMUCH_FORMAT_SUP. Also, any l10n (e.g. of time representation) would have to be hardcoded as well (btw, anybody knows a library for human readable time representations which supports l10n and i18n?). So perhaps it's better to move the polishing into the client (Yeah! Python to the rescue! ;-). But then, 'notmuch search' would need to return some raw representation of the date field as well. Any comment? Any other thoughts about this? Regards, Gregor Hoffleit
[notmuch] Quick thoughts on a notmuch daemon
Here's a little idea in case someone wants to write some code before I get around to it. Two current problems: 1. You can't read mail (updating tags, etc.) at the same time new mail is being incorporated to the database. So if you have "notmuch new" as a cron job, then you will sometimes see "failed to obtain write lock" in emacs. 2. Lots of people want to interact with a notmuch database on a remote server, for obvious reasons. A simple solution would be a notmuch daemon that can accept commands on stdin, (in basically the exact same form as the current notmuch command-line interface). If the daemon does the job of periodically incorporating new mail, then the only command necessary to solve (1) above would be the tag command. But with the other commands in place, (such as search and show), then this could operate over ssh and all that would be necessary is one additional command not in the current command line, (for "give me this file"). And then the client could just maintain a local cache of mail files as needed. So that might be a nice project for somebody, and would likely be very useful for many people. -Carl pgp2nnLCTBBMN.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Quick thoughts on a notmuch daemon
Here's a little idea in case someone wants to write some code before I get around to it. Two current problems: 1. You can't read mail (updating tags, etc.) at the same time new mail is being incorporated to the database. So if you have "notmuch new" as a cron job, then you will sometimes see "failed to obtain write lock" in emacs. 2. Lots of people want to interact with a notmuch database on a remote server, for obvious reasons. A simple solution would be a notmuch daemon that can accept commands on stdin, (in basically the exact same form as the current notmuch command-line interface). If the daemon does the job of periodically incorporating new mail, then the only command necessary to solve (1) above would be the tag command. But with the other commands in place, (such as search and show), then this could operate over ssh and all that would be necessary is one additional command not in the current command line, (for "give me this file"). And then the client could just maintain a local cache of mail files as needed. So that might be a nice project for somebody, and would likely be very useful for many people. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/ddeabf75/attachment.pgp>
[notmuch] Recent (and forthcoming) improvements to the emacs interface
I just pushed out a nice set of changes to the emacs interface. Here's a quick summary of what you can expect to get when you next update: * Much nicer looking presentation, (no more ugly reverse-video or underlines on the message summary line). * More reliable message-visibility buttons, (using RET in the first column of a message-summary line now works). * Space bar fixed to advance to next open message, (it was originally written this way, but has been broken since we changed from global to local toggling of hidden message parts). * Showing a thread where the search matches only a subset of the thread now opens only the matched messages (in addition to unread messages). This last feature is the big one---the rest all just happened to come along at the same time. One thing that I often do is read some giant thread and then tag a single message deep in that thread for dealing with later. And previously, doing a search for that tag would bring back the entire thread. Now, it opens only the message I'm actually looking for. So this is a very welcome change And thanks to Bart Trojanowski for the groundwork for this change. I think the vim interface has had this feature for a while, (or would have if I had pushed all of Bart's changes earlier). Meanwhile, Keith and Eric gave me some helpful feedback about the notmuch user-interface over lunch today, and in particular about the handling of the "unread" tag. Here are some of the things discussed, along with some things I'd like to change in response. I'm open to suggestions on all of these, and most importantly, wanted to let people know about some upcoming user-interface changes before they were in place and potentially surprising. * The magic space bar is too magic. Threads are separate conversations so one key for paging through the current conversation shouldn't also switch to the next conversation, (particularly when the complementary key DEL doesn't reverse this behavior of SPACE). Recommendation: Make SPACE only page the current message. Recommend that user use 'a' to advance to next thread, (or 'x' to exit back to search results). * The unread tag is not handled transparently enough. Both Keith and Eric complained of frequently being presented with messages as "unread" that they had read before. (And I don't want to ever have to manually think about whether to remove a thread as "unread".) Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and 'x' mark remove the "unread" tag from all messages in the current thread (as well as the "inbox" tag as currently). Also make 'n' and 'p' remove the "unread tag as well. Followup: This frees up 'N' and 'P', so I'd like to use the for "next message" and "previous message" and make 'n' and 'p' do "next open message" and "previous open message". * Opening up unread messages in notmuch-show mode is not helpful. Keith reads a lot of high-volume mailing lists by reading the subject lines in search mode and then doing "* -inbox". He likes that notmuch remembers that these messages are still unread, but if he later searches for a single message that happens to be in a giant thread of unread messages, then he wants to see just than one message, not all of them. Recommendation: Make notmuch-show-mode open *only* messages that match the search---not unread messages as well. At this point the unread tag becomes just a hint to the user and won't be explicitly handled differently by the interface, (other than that various commands will remove the unread tag if present). The unread tag is still useful for when searching for something like "I know I read this message recently". Followup: I wonder if I would miss one feature here. If I'm interrupted after reading part of a giant thread, currently I can quite and when I come back notmuch will remember right where I was while reading. One way to get this behavior back would be to make SPACE remove the inbox tag from each message its scrolled off. I'll have to think about that. * The current 'a' key in search-mode is unreliable. It seemed like a good idea to make 'a' only archive messages that match the search, but it's a flawed idea. Imagine the following scenario: Eric is reading his inbox and sees some threads related to a boring topic. He filters down to these with "f tag:boring". He's satisfied with the search results, and hits 'a' on each thread and even sees the "inbox" tag disappear from the presentation. But then when he returns to his inbox search and refreshes, the boring threads re-appear and have the inbox tag again. Ugh. The presentation is inconsistent and things just feel unreliable and broken. And a related issue: * The '*' key in search-mode doesn't provide any feedback that it has actually done anything, (none of
[notmuch] Hi, I'm Mark, and I'm addicted to effective mail handling
I've been a good friend of Carl's since college, and was following his interest in 'sup'. I have transitioned to 'sup', and I'm ready to move on. I just want a text email system that looks a lot like GMail, but isn't owned elsewhere. I want to be able to control the data. I just recenty found a card game version of the old RPG Paranoia, I suppose I may have caught something from Friend Computer. (... No, Friend Computer, that's not treason, I'm trying to understand the Traitors so that I can capture or eliminate them. ) :) The main issue I've had with getting notmuch working is that I've been using difficult distros. Cygwin is one, although there must be some way to get it working properly. I'll be playing glib hokey-pokey if I can figure it out. I also have an Ubuntu machine at home, but it is sitting on an LTS release so that I don't have to mess with my MythTV setup regularly, this makes some packages more difficult to find. Anyway, more power to the mailer!! -Mark
[notmuch] [PATCH 2/2] notmuch.el: Add support for reply-to sender
From: Aneesh Kumar K.V Add key binding to do a reply-to sender. This is mapped to 'R' Signed-off-by: Aneesh Kumar K.V --- notmuch.el | 24 ++-- 1 files changed, 22 insertions(+), 2 deletions(-) diff --git a/notmuch.el b/notmuch.el index bd8a6ce..c067e63 100644 --- a/notmuch.el +++ b/notmuch.el @@ -62,7 +62,8 @@ (define-key map "s" 'notmuch-search) (define-key map "m" 'message-mail) (define-key map "f" 'notmuch-show-forward-current) -(define-key map "r" 'notmuch-show-reply) +(define-key map "r" 'notmuch-show-reply-all) +(define-key map "R" 'notmuch-show-reply) (define-key map "|" 'notmuch-show-pipe-message) (define-key map "w" 'notmuch-show-save-attachments) (define-key map "V" 'notmuch-show-view-raw-message) @@ -367,12 +368,31 @@ buffer." (forward-line))) (message-mode)) -(defun notmuch-show-reply () +(defun notmuch-show-reply-all () "Begin composing a reply to the current message in a new buffer." (interactive) (let ((message-id (notmuch-show-get-message-id))) (notmuch-reply message-id))) + +(defun notmuch-format-reply (format-string query-string) + (switch-to-buffer (generate-new-buffer "notmuch-draft")) + (call-process notmuch-command nil t nil "reply" + (concat "--format=" format-string) query-string) + (message-insert-signature) + (goto-char (point-min)) + (if (re-search-forward "^$" nil t) + (progn + (insert "--text follows this line--") + (forward-line))) + (message-mode)) + +(defun notmuch-show-reply () + "Begin composing a reply to the current message in a new buffer." + (interactive) + (let ((message-id (notmuch-show-get-message-id))) +(notmuch-format-reply "sender-only" message-id))) + (defun notmuch-show-forward-current () "Forward the current message." (interactive) -- 1.6.5.2.74.g610f9
[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender
From: Aneesh Kumar K.V
This patch add --format=sender-only option.
Signed-off-by: Aneesh Kumar K.V
---
notmuch-reply.c | 76 +++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 9ca1236..9d96ef1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -354,6 +354,80 @@ notmuch_reply_format_headers_only(void *ctx,
notmuch_config_t *config, notmuch_q
}
return 0;
}
+static int
+notmuch_reply_format_sender_only(void *ctx, notmuch_config_t *config,
notmuch_query_t *query)
+{
+GMimeMessage *reply;
+notmuch_messages_t *messages;
+notmuch_message_t *message;
+const char *subject, *recipient, *from_addr = NULL;
+const char *in_reply_to, *orig_references, *references;
+char *reply_headers;
+
+for (messages = notmuch_query_search_messages (query);
+notmuch_messages_has_more (messages);
+notmuch_messages_advance (messages))
+{
+ message = notmuch_messages_get (messages);
+
+ /* The 1 means we want headers in a "pretty" order. */
+ reply = g_mime_message_new (1);
+ if (reply == NULL) {
+ fprintf (stderr, "Out of memory\n");
+ return 1;
+ }
+
+ subject = notmuch_message_get_header (message, "subject");
+
+ if (strncasecmp (subject, "Re:", 3))
+ subject = talloc_asprintf (ctx, "Re: %s", subject);
+ g_mime_message_set_subject (reply, subject);
+
+ recipient = notmuch_message_get_header (message, "From");
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "To", recipient);
+
+ from_addr = notmuch_config_get_user_primary_email (config);
+ from_addr = talloc_asprintf (ctx, "%s <%s>",
+notmuch_config_get_user_name (config),
+from_addr);
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "From", from_addr);
+
+ g_mime_object_set_header (GMIME_OBJECT (reply), "Bcc",
+ notmuch_config_get_user_primary_email (config));
+
+ in_reply_to = talloc_asprintf (ctx, "<%s>",
+notmuch_message_get_message_id (message));
+
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "In-Reply-To", in_reply_to);
+
+ orig_references = notmuch_message_get_header (message, "references");
+ references = talloc_asprintf (ctx, "%s%s%s",
+ orig_references ? orig_references : "",
+ orig_references ? " " : "",
+ in_reply_to);
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "References", references);
+
+ reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
+ printf ("%s", reply_headers);
+ free (reply_headers);
+
+ g_object_unref (G_OBJECT (reply));
+ reply = NULL;
+
+ printf ("On %s, %s wrote:\n",
+ notmuch_message_get_header (message, "date"),
+ notmuch_message_get_header (message, "from"));
+
+ show_message_body (notmuch_message_get_filename (message), reply_part);
+
+ notmuch_message_destroy (message);
+}
+return 0;
+}
int
notmuch_reply_command (void *ctx, int argc, char *argv[])
@@ -378,6 +452,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
reply_format_func = notmuch_reply_format_default;
} else if (strcmp (opt, "headers-only") == 0) {
reply_format_func = notmuch_reply_format_headers_only;
+ } else if (strcmp (opt, "sender-only") == 0) {
+ reply_format_func = notmuch_reply_format_sender_only;
} else {
fprintf (stderr, "Invalid value for --format: %s\n", opt);
return 1;
--
1.6.5.2.74.g610f9
[notmuch] Recent (and forthcoming) improvements to the emacs interface
ation. But then when he
returns to his inbox search and refreshes, the boring threads
re-appear and have the inbox tag again. Ugh. The presentation is
inconsistent and things just feel unreliable and broken.
And a related issue:
* The '*' key in search-mode doesn't provide any feedback that it has
actually done anything, (none of the added/removed tags are changed
in the presentation). And hitting '=' isn't necessarily ideal since
it can make things irretrievably disappear, ('a' is different since
it allows the user to confirm that things are good before making
results disappear with '='). [*]
Recommendation: Revert 'a' to act on all messages in a thread---not
only those that match the search results. Then change '*' to work by
walking the list and explicitly calling the same action as 'a' on
each line. This will provide the desired feedback and should be
plenty fast.
Note: There are still use cases where the user might want to modify
the tags only on messages matching the search, (think, "remove from
inbox all messages from:someone"). So I'm aware that there's still a
hole in functionality here, but I really want to fix the current
inconsistency in the presentation. And I'm open to further
suggestions here.
Let me know if any of the above seems crazy,
-Carl
PS. We also talked about new support for efficiently detecting file
addition, deletion, and renames. More on that when it becomes real.
[*] Yes, this is just a lame standin for a real undo feature. But until
we do have undo, it's an important standin.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091203/ae9c1bed/attachment.pgp>
Re: [notmuch] [PATCH] vim: preserve the 'show everything' flag when finding next/prev buffer
* Carl Worth [091203 16:31]: > Sorry I missed this with your earlier, related changes. But I've pushed > this now. Thanks. -Bart -- WebSig: http://www.jukie.net/~bart/sig/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Trouble with notmuch-show
I know html support is still poor, but the following seems worse than
not showing anything. When I visit this message, I get prompted to save
the MIME part and the following is displayed (including all the hidden
stuff). Original message is attached.
Jed
message{ id:4b182a91.9020...@sandia.gov depth:0 match:1
filename:/home/jed/.mail-archive/gmail-all/pop/new/1259875803.M47630P27852Q0R271bd14e8c36baf4.localhost
header{
"Raymond Tuminaro" (46 mins. ago) (inbox unread)
Subject: [SIAM-CSE] Copper Mountain Iterative Methods Announcement Posting,
April 4-9, 2010
From: "Raymond Tuminaro"
To: siam-...@siam.org
Cc:
Bcc:
Date: Thu, 3 Dec 2009 13:16:01 -0800
header}
body{
part{ ID: 2, Content-type: text/html
Non-text part: text/html
part}
part{ ID: 3, Content-type: text/plain
___
SIAM-CSE mailing list
To post messages to the list please send them to: siam-...@siam.org
http://lists.siam.org/mailman/listinfo/siam-cse
part}
body}
message}
1259875803.M47630P27852Q0R271bd14e8c36baf4.localhost
Description: Problem html message
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] vim: preserve the 'show everything' flag when finding next/prev buffer
On Fri, 27 Nov 2009 21:31:12 -0500, Bart Trojanowski wrote: > When show mode is invoked it could be displaying just the matched messages > or everything. This flag is passed to NM_search_show_thread(). It is then > stored in a buffer variable, b:nm_show_everything, and used for subsequent > calls to NM_search_show_thread() triggered by , and . Hi Bart, Sorry I missed this with your earlier, related changes. But I've pushed this now. -Carl pgpPimohI6Avh.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] vim: preserve the 'show everything' flag when finding next/prev buffer
On Fri, 27 Nov 2009 21:31:12 -0500, Bart Trojanowski wrote: > When show mode is invoked it could be displaying just the matched messages > or everything. This flag is passed to NM_search_show_thread(). It is then > stored in a buffer variable, b:nm_show_everything, and used for subsequent > calls to NM_search_show_thread() triggered by , and . Hi Bart, Sorry I missed this with your earlier, related changes. But I've pushed this now. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/116b1a71/attachment.pgp>
[notmuch] Hi, I'm Mark, and I'm addicted to effective mail handling
I've been a good friend of Carl's since college, and was following his interest in 'sup'. I have transitioned to 'sup', and I'm ready to move on. I just want a text email system that looks a lot like GMail, but isn't owned elsewhere. I want to be able to control the data. I just recenty found a card game version of the old RPG Paranoia, I suppose I may have caught something from Friend Computer. (... No, Friend Computer, that's not treason, I'm trying to understand the Traitors so that I can capture or eliminate them. ) :) The main issue I've had with getting notmuch working is that I've been using difficult distros. Cygwin is one, although there must be some way to get it working properly. I'll be playing glib hokey-pokey if I can figure it out. I also have an Ubuntu machine at home, but it is sitting on an LTS release so that I don't have to mess with my MythTV setup regularly, this makes some packages more difficult to find. Anyway, more power to the mailer!! -Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH 1/3] Use default face for the button types so that the underlines go away
On Tue, 1 Dec 2009 21:45:47 +0530, aneesh.ku...@gmail.com wrote: > From: Alexander Botero-Lowry > > Since we know what these buttons do it seems like the underlines are > unnecessary. This also backs out the attempt at fixing the button > alignment on the message row, which is broken because of some > interaction with indent-rigidly in some threads Thanks, Alexander (and Aneesh). By the time I was ready to apply this patch, I had fixed the "also" portion of the commit independently in a different way, (which actually does give reliable first-column usage of the buttons). But I've now committed the removal of the underlines from these buttons. And Aneesh, for the following patch which removes the reverse-video, I also implemented a different version of that. Take a look, emacs users, and let me know what you think of the new presentation of messages. I find it much more pleasant to look at myself. -Carl pgpJNR9SCSZpa.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 1/3] Use default face for the button types so that the underlines go away
On Tue, 1 Dec 2009 21:45:47 +0530, aneesh.kumar at gmail.com wrote: > From: Alexander Botero-Lowry > > Since we know what these buttons do it seems like the underlines are > unnecessary. This also backs out the attempt at fixing the button > alignment on the message row, which is broken because of some > interaction with indent-rigidly in some threads Thanks, Alexander (and Aneesh). By the time I was ready to apply this patch, I had fixed the "also" portion of the commit independently in a different way, (which actually does give reliable first-column usage of the buttons). But I've now committed the removal of the underlines from these buttons. And Aneesh, for the following patch which removes the reverse-video, I also implemented a different version of that. Take a look, emacs users, and let me know what you think of the new presentation of messages. I find it much more pleasant to look at myself. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/800812ac/attachment.pgp>
Re: [notmuch] hack to retag a directory
At Thu, 03 Dec 2009 09:39:32 -0400, da...@tethera.net wrote: > I think this will be obsolete pretty soon when the equivalent is > built-in to notmuch, but in the mean time, here is a script that > somebody might find useful: retag a whole directory (recursively). I > don't claim it is nice in any way, but it seems usable for me, taking > about 5 seconds to retag a directory containing 1000 messages. Sigh. And of course the version I posted was broken. I put a fixed version at http://pivot.cs.unb.ca/git/?p=notmuch-scripts.git;a=blob_plain;f=tagdir;hb=HEAD You might, or might not also be interested in http://pivot.cs.unb.ca/git/?p=notmuch-scripts.git;a=blob_plain;f=gitmuch;hb=HEAD which is the beginnings of how to keep tags in git (for syncing between machines). Right now the notmuch restore step is the bottleneck, but Carl apparently knows how to speed 'notmuch restore' up. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
Excerpts from Carl Worth's message of Wed Dec 02 22:36:13 +0100 2009: > As a side-note, I would recommend against making your auto-tagging > scripts process only new messages. You can get a much more reliable > setup by having your auto-tagging scripts apply to the global > database. And this is not inefficient at all if you simply ensure that > you only match messages which need the tag added. I can see one clear case where that would become a problem: mistaggings. If I set up something so that in 99% of the cases, it'd tag new mail correctly with say "inbox unread mytag", I could quickly pick the mistagged ones out and remove the offending tag. If you do it like above however, the autotag script would come merrily along and retag them. -- - Marten
[notmuch] hack to retag a directory
I think this will be obsolete pretty soon when the equivalent is built-in to notmuch, but in the mean time, here is a script that somebody might find useful: retag a whole directory (recursively). I don't claim it is nice in any way, but it seems usable for me, taking about 5 seconds to retag a directory containing 1000 messages. I use it like tagdir Maildir/.list.debian-devel -inbox +debian +devel -- next part -- A non-text attachment was scrubbed... Name: tagdir Type: application/octet-stream Size: 681 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091203/d06a9e3e/attachment-0001.obj> -- next part --
[notmuch] hack to retag a directory
I think this will be obsolete pretty soon when the equivalent is built-in to notmuch, but in the mean time, here is a script that somebody might find useful: retag a whole directory (recursively). I don't claim it is nice in any way, but it seems usable for me, taking about 5 seconds to retag a directory containing 1000 messages. I use it like tagdir Maildir/.list.debian-devel -inbox +debian +devel tagdir Description: Binary data ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch's search view sucks
Hi there, first a short introduction: I was a mutt user for ages. When I read about Sup, I was intrigued. After a short evaluation period, I switched to Sup, which I'm now using since six months. Sup has many rough edges on its own, and it's not that easy to fix some of them from the current codebase. notmuch looks like a clean restart of the same idea, but with a different architecture. I like the concept of a command line tool with a minimal set of functionality as a common core, upon which different clients can build on. But. Compared to Sup, the current notmuch clients suck :-) Today: Sup's search-results-mode. It has a lot of polish that's plainly missing from notmuch.el (or notmuch.vim): - Sup's display is much terse than notmuch, still - Sup manages to display the first few words of the first unread message in the thread. - If a thread contains many authors, Sup shows only the firstnames. If that's still too long to fit, it cuts off at some point. - User's name is rewritten as 'me'. - The message date format needs only 8 characters (notmuch: 12). - Message count is only displayed when necessary (>=1). - Threads with unread messages are bold (resp. hilighted). - Threads with attachments are marked with an "@". - Threads with mails to user are marked with an ">". - Different colors of tags, message content. All in all, 'notmuch search' is a raw representation of field values, while Sup's search-results-mode shows a polished and terse interpretation of the same values, for human beings, even optimized for the current display width. Now notmuch.el and notmuch.vim just display the output of 'notmuch search', verbatim (perhaps enhanced with coloring based on regexes). I'm experimenting with a notmuch web client (currently 'evenless'), trying to replicate much of the feeling of Sup, in a web client. First, I took the output of 'notmuch search', parsed it and tried to reformat it like Sup. That worked well for all fields but the date field: In contrast to the other fields, notmuch's date representation is intended for direct consumption by humans (english-speaking, that is ;-). I noticed this entry in TODO: Add a "--format" option to "notmuch search", (something printf-like for selecting what gets printed). Since I'm not eager to write a format parser, I started to implement --format as an enumerating option notmuch_format_t. By now, I have NOTMUCH_FORMAT_DEFAULT and NOTMUCH_FORMAT_SUP. do_search_threads() does the real work. In notmuch-time.c, I have implemented an alternative nice and terse time representation, notmuch_time_relative8_date(). I realized, though, that at this point I would have to hardcode things like ANSI coloring into NOTMUCH_FORMAT_SUP. Also, any l10n (e.g. of time representation) would have to be hardcoded as well (btw, anybody knows a library for human readable time representations which supports l10n and i18n?). So perhaps it's better to move the polishing into the client (Yeah! Python to the rescue! ;-). But then, 'notmuch search' would need to return some raw representation of the date field as well. Any comment? Any other thoughts about this? Regards, Gregor Hoffleit ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH (rebased)] Handle message renames in mail spool
In order to handle message renames the following changes were deemed necessary:
* Mtime check on individual files was disabled. As files may be moved around
without changing their mtime, it's necessary to parse them even if they appear
old in case old message was moved. mtime check on directories was kept as moving
files changes mtime of directory.
* If message being parsed is already found in database under different path,
then this message is considered to be moved, path is updated in database and
this file does not undergo further processing.
Note that after applying this patch notmuch still does not handle copying files
(which is harmless, database will point to the last copy of message found during
'notmuch new') and deleting files (which is more serious, as dangling entries
will show up in searches).
Signed-off-by: Mikhail Gusarov
---
lib/database.cc | 32 ++-
notmuch-new.c | 116 ++
2 files changed, 78 insertions(+), 70 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 23ddd4a..45d8fc7 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -993,19 +993,31 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
if (private_status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND) {
_notmuch_message_set_filename (message, filename);
_notmuch_message_add_term (message, "type", "mail");
- } else {
- ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
- goto DONE;
- }
- ret = _notmuch_database_link_message (notmuch, message, message_file);
- if (ret)
- goto DONE;
+ ret = _notmuch_database_link_message (notmuch, message,
message_file);
+ if (ret)
+ goto DONE;
- date = notmuch_message_file_get_header (message_file, "date");
- _notmuch_message_set_date (message, date);
+ date = notmuch_message_file_get_header (message_file, "date");
+ _notmuch_message_set_date (message, date);
- _notmuch_message_index_file (message, filename);
+ _notmuch_message_index_file (message, filename);
+ } else {
+ const char *old_filename = notmuch_message_get_filename (message);
+ if (strcmp (old_filename, filename) == 0) {
+ /* We have already seen it */
+ goto DONE;
+ } else {
+ if (access (old_filename, R_OK) == 0) {
+ /* old_filename still exists, we've got a duplicate */
+ ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
+ goto DONE;
+ } else {
+ /* Message file has been moved/renamed */
+ _notmuch_message_set_filename (message, filename);
+ }
+ }
+ }
_notmuch_message_sync (message);
} catch (const Xapian::Error &error) {
diff --git a/notmuch-new.c b/notmuch-new.c
index 9d20616..d595fc4 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -217,66 +217,62 @@ add_files_recursive (notmuch_database_t *notmuch,
}
if (S_ISREG (st->st_mode)) {
- /* If the file hasn't been modified since the last
-* add_files, then we need not look at it. */
- if (path_dbtime == 0 || st->st_mtime > path_dbtime) {
- state->processed_files++;
-
- if (state->verbose) {
- if (state->output_is_a_tty)
- printf("\r\033[K");
-
- printf ("%i/%i: %s",
- state->processed_files,
- state->total_files,
- next);
-
- putchar((state->output_is_a_tty) ? '\r' : '\n');
- fflush (stdout);
- }
-
- status = notmuch_database_add_message (notmuch, next, &message);
- switch (status) {
- /* success */
- case NOTMUCH_STATUS_SUCCESS:
- state->added_messages++;
- tag_inbox_and_unread (message);
- break;
- /* Non-fatal issues (go on to next file) */
- case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
- /* Stay silent on this one. */
- break;
- case NOTMUCH_STATUS_FILE_NOT_EMAIL:
- fprintf (stderr, "Note: Ignoring non-mail file: %s\n",
-next);
- break;
- /* Fatal issues. Don't process anymore. */
- case NOTMUCH_STATUS_READONLY_DATABASE:
- case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
- case NOTMUCH_STATUS_OUT_OF_MEMORY:
- fprintf (stderr, "Error: %s. Halting processing.\n",
-notmuch_status_to_string (status));
- ret = status;
-
Re: [notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
Excerpts from Carl Worth's message of Wed Dec 02 22:36:13 +0100 2009: > As a side-note, I would recommend against making your auto-tagging > scripts process only new messages. You can get a much more reliable > setup by having your auto-tagging scripts apply to the global > database. And this is not inefficient at all if you simply ensure that > you only match messages which need the tag added. I can see one clear case where that would become a problem: mistaggings. If I set up something so that in 99% of the cases, it'd tag new mail correctly with say "inbox unread mytag", I could quickly pick the mistagged ones out and remove the offending tag. If you do it like above however, the autotag script would come merrily along and retag them. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/2] notmuch.el: Add support for reply-to sender
From: Aneesh Kumar K.V Add key binding to do a reply-to sender. This is mapped to 'R' Signed-off-by: Aneesh Kumar K.V --- notmuch.el | 24 ++-- 1 files changed, 22 insertions(+), 2 deletions(-) diff --git a/notmuch.el b/notmuch.el index bd8a6ce..c067e63 100644 --- a/notmuch.el +++ b/notmuch.el @@ -62,7 +62,8 @@ (define-key map "s" 'notmuch-search) (define-key map "m" 'message-mail) (define-key map "f" 'notmuch-show-forward-current) -(define-key map "r" 'notmuch-show-reply) +(define-key map "r" 'notmuch-show-reply-all) +(define-key map "R" 'notmuch-show-reply) (define-key map "|" 'notmuch-show-pipe-message) (define-key map "w" 'notmuch-show-save-attachments) (define-key map "V" 'notmuch-show-view-raw-message) @@ -367,12 +368,31 @@ buffer." (forward-line))) (message-mode)) -(defun notmuch-show-reply () +(defun notmuch-show-reply-all () "Begin composing a reply to the current message in a new buffer." (interactive) (let ((message-id (notmuch-show-get-message-id))) (notmuch-reply message-id))) + +(defun notmuch-format-reply (format-string query-string) + (switch-to-buffer (generate-new-buffer "notmuch-draft")) + (call-process notmuch-command nil t nil "reply" + (concat "--format=" format-string) query-string) + (message-insert-signature) + (goto-char (point-min)) + (if (re-search-forward "^$" nil t) + (progn + (insert "--text follows this line--") + (forward-line))) + (message-mode)) + +(defun notmuch-show-reply () + "Begin composing a reply to the current message in a new buffer." + (interactive) + (let ((message-id (notmuch-show-get-message-id))) +(notmuch-format-reply "sender-only" message-id))) + (defun notmuch-show-forward-current () "Forward the current message." (interactive) -- 1.6.5.2.74.g610f9 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender
From: Aneesh Kumar K.V
This patch add --format=sender-only option.
Signed-off-by: Aneesh Kumar K.V
---
notmuch-reply.c | 76 +++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 9ca1236..9d96ef1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -354,6 +354,80 @@ notmuch_reply_format_headers_only(void *ctx,
notmuch_config_t *config, notmuch_q
}
return 0;
}
+static int
+notmuch_reply_format_sender_only(void *ctx, notmuch_config_t *config,
notmuch_query_t *query)
+{
+GMimeMessage *reply;
+notmuch_messages_t *messages;
+notmuch_message_t *message;
+const char *subject, *recipient, *from_addr = NULL;
+const char *in_reply_to, *orig_references, *references;
+char *reply_headers;
+
+for (messages = notmuch_query_search_messages (query);
+notmuch_messages_has_more (messages);
+notmuch_messages_advance (messages))
+{
+ message = notmuch_messages_get (messages);
+
+ /* The 1 means we want headers in a "pretty" order. */
+ reply = g_mime_message_new (1);
+ if (reply == NULL) {
+ fprintf (stderr, "Out of memory\n");
+ return 1;
+ }
+
+ subject = notmuch_message_get_header (message, "subject");
+
+ if (strncasecmp (subject, "Re:", 3))
+ subject = talloc_asprintf (ctx, "Re: %s", subject);
+ g_mime_message_set_subject (reply, subject);
+
+ recipient = notmuch_message_get_header (message, "From");
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "To", recipient);
+
+ from_addr = notmuch_config_get_user_primary_email (config);
+ from_addr = talloc_asprintf (ctx, "%s <%s>",
+notmuch_config_get_user_name (config),
+from_addr);
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "From", from_addr);
+
+ g_mime_object_set_header (GMIME_OBJECT (reply), "Bcc",
+ notmuch_config_get_user_primary_email (config));
+
+ in_reply_to = talloc_asprintf (ctx, "<%s>",
+notmuch_message_get_message_id (message));
+
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "In-Reply-To", in_reply_to);
+
+ orig_references = notmuch_message_get_header (message, "references");
+ references = talloc_asprintf (ctx, "%s%s%s",
+ orig_references ? orig_references : "",
+ orig_references ? " " : "",
+ in_reply_to);
+ g_mime_object_set_header (GMIME_OBJECT (reply),
+ "References", references);
+
+ reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
+ printf ("%s", reply_headers);
+ free (reply_headers);
+
+ g_object_unref (G_OBJECT (reply));
+ reply = NULL;
+
+ printf ("On %s, %s wrote:\n",
+ notmuch_message_get_header (message, "date"),
+ notmuch_message_get_header (message, "from"));
+
+ show_message_body (notmuch_message_get_filename (message), reply_part);
+
+ notmuch_message_destroy (message);
+}
+return 0;
+}
int
notmuch_reply_command (void *ctx, int argc, char *argv[])
@@ -378,6 +452,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
reply_format_func = notmuch_reply_format_default;
} else if (strcmp (opt, "headers-only") == 0) {
reply_format_func = notmuch_reply_format_headers_only;
+ } else if (strcmp (opt, "sender-only") == 0) {
+ reply_format_func = notmuch_reply_format_sender_only;
} else {
fprintf (stderr, "Invalid value for --format: %s\n", opt);
return 1;
--
1.6.5.2.74.g610f9
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
