[notmuch] A gtk interface
Carl Worth wrote: > On Thu, 26 Nov 2009 21:17:33 +0200, Baruch Even wrote: >> I've started to work on a Gtk+ interface to notmuch which uses the >> notmuch command line. Currently it is able to search threads and retag >> them. Next on the agenda is the ability to actually read the threads. >> >> If someone is interested, the code lives in >> http://github.com/baruch/notmuch-gtk and can be checked out from >> git://github.com/baruch/notmuch-gtk.git > > Very interesting, Baruch! > > Thanks for contributing this! > > I thought at first that the tagging commands weren't working, but > quickly realized they were working but simply weren't updating the view > to show the added/removed tags. Yes. The UI has a lot of rough edges, the search needs to be cancelable, it needs to indicate that it's in progress and I also need to implement some logic to update the threads that were retagged. But I'm more interested in fleshing out the rest of the app to make it somewhat useful to me so I can start to really make use of it. > PS. I prefer a default search of "tag:inbox" rather than "tag:inbox and > tag:unread". Otherwise, there's not much reason for "notmuch new" to add > both tags. It was like that initially, I didn't even have a good reason to change it as I didn't have the ability to change tags. I'll probably change it back. Baruch
[notmuch] Search results now start appearing "instantly"
On 2009-11-25, Carl Worth wrote: > > So please update to the latest code and let me know what you think. I'll > be interested to hear if this helps people, and also to know if the CPU > usage is a problem for anybody. Brilliant, thanks! Peter
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Excerpts from Michiel Buddingh''s message of Thu Nov 26 22:12:02 +0100 2009: > Haven't tested it, but it seems you can put > > [core] > whitespace = trailing-space,space-before-tab > > into your ~/.gitconfig now. I've also set emacs to mark trailing > whitespace with big red markers. I think it should be in notmuch/.gitattributes, which doesn't relies on new contributors to set that up. It also doesn't force this on for every git repo one has. -- Exherbo KDE, X.org maintainer
[notmuch] [PATCH] Handle message renames in mail spool
Twas brillig at 07:40:15 26.11.2009 UTC-08 when cworth at cworth.org did gyre and gimble: CW> I *really* want this patch in, since I think a lot of current users CW> would really benefit from it. I only see one big problem with it: Did you test the performance hit caused by disabling mtime checks? -- http://fossarchy.blogspot.com/ -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091126/2c18e955/attachment.pgp>
[notmuch] [PATCH 2/2] notmuch-search-add/remove-tag: restrict to messages in current query
Rather than tagging the everything in the thread. This is arguably more desirable behavior and is consistent with clearly desirably behavior of notmuch-search-operate-all. Note that this change applies indirectly to notmuch-search-archive-thread (which is actually equivalent behavior since this function is primarily used when browsing an inbox). Signed-off-by: Jed Brown --- notmuch.el |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/notmuch.el b/notmuch.el index 6adac9e..e9786c0 100644 --- a/notmuch.el +++ b/notmuch.el @@ -935,15 +935,19 @@ and will also appear in a buffer named \"*Notmuch errors*\"." (split-string (buffer-substring beg end)) (defun notmuch-search-add-tag (tag) + "Add a tag to messages in the current thread matching the +active query." (interactive (list (notmuch-select-tag-with-completion "Tag to add: "))) - (notmuch-call-notmuch-process "tag" (concat "+" tag) (notmuch-search-find-thread-id)) + (notmuch-call-notmuch-process "tag" (concat "+" tag) (notmuch-search-find-thread-id) " and " notmuch-search-query-string) (notmuch-search-set-tags (delete-dups (sort (cons tag (notmuch-search-get-tags)) 'string< (defun notmuch-search-remove-tag (tag) + "Remove a tag from messages in the current thread matching the +active query." (interactive (list (notmuch-select-tag-with-completion "Tag to remove: " (notmuch-search-find-thread-id - (notmuch-call-notmuch-process "tag" (concat "-" tag) (notmuch-search-find-thread-id)) + (notmuch-call-notmuch-process "tag" (concat "-" tag) (notmuch-search-find-thread-id) " and " notmuch-search-query-string) (notmuch-search-set-tags (delete tag (notmuch-search-get-tags (defun notmuch-search-archive-thread () -- 1.6.5.3
[notmuch] [PATCH 1/2] New function notmuch-search-operate-all: operate on all messages in the current query.
It is often convenient to change tags on several messages at once. This function applies any number of tag whitespace-delimited tag modifications to all messages matching the current query. I have bound this to `*'. Signed-off-by: Jed Brown --- notmuch.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index d7c973c..6adac9e 100644 --- a/notmuch.el +++ b/notmuch.el @@ -801,6 +801,7 @@ thread from that buffer can be show when done with this one)." (define-key map [mouse-1] 'notmuch-search-show-thread) (define-key map "+" 'notmuch-search-add-tag) (define-key map "-" 'notmuch-search-remove-tag) +(define-key map "*" 'notmuch-search-operate-all) (define-key map "<" 'beginning-of-buffer) (define-key map ">" 'notmuch-search-goto-last-thread) (define-key map "=" 'notmuch-search-refresh-view) @@ -1001,6 +1002,29 @@ This function advances point to the next line when finished." (set 'more nil)) (delete-process proc +(defun notmuch-search-operate-all (action) + "Operate on all messages matching the current query. Any +number of whitespace separated actions can be given. Each action +must have one of the two forms + + +tagname Add the tag `tagname' + -tagname Remove the tag `tagname' + +Each character of the tag name may consist of alphanumeric +characters as well as `_.+-'. +" + (interactive "sOperation (+add -drop): notmuch tag ") + (let ((action-split (split-string action " +"))) +;; Perform some validation +(let ((words action-split)) + (when (null words) (error "No operation given")) + (while words + (unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words)) + (error "Action must be of the form `+thistag -that_tag'")) + (setq words (cdr words +(apply 'notmuch-call-notmuch-process "tag" + (append action-split (list notmuch-search-query-string) nil + (defun notmuch-search (query oldest-first) "Run \"notmuch search\" with the given query string and display results." (interactive "sNotmuch search: ") -- 1.6.5.3
[notmuch] Notmuch doesn't index new mails when mail location contains symlinks
On Thu, 26 Nov 2009 13:14:22 -0800, Carl Worth wrote: > Then I'm still being really dense here. The non-propagation of mtime is > the with actual directories. And the code is trying to do the right > thing for that. The stat() is correct, it's the check for the d_type field coming out of scandir(). 20:08 [ jedbrown ] cworth: I think there are two problems with symlinks. 20:08 [ jedbrown ] cworth: First, notmuch-new.c:152 checks path_mtime which is mtime for the current directory. 20:09 [ jedbrown ] cworth: Additionally, won't entry->d_type == DT_LNK for a symlink? 20:14 [ aneesh ] jedbrown, i already have a patch posted for that 20:15 [ aneesh ] 1259125104-18785-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com Jed
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Carl Worth wrote:
> > +" The other value is 'storage_type', which can currently be set to\n"
> > +" 'maildir' or 'none'.\n";
>
> This part of the patch I don't like. I've got a mail collection spanning
> over a decade, and it's seen a lot of strange things. Most of my mail is
> in maildir format, but not quite all of it. And I actually like the
> ability to just shove random new messages into the mail store manually
> without having to create a maildir name for it.
>
> So I don't think a global configuration makes sense here. Meanwhile,
> it's really easy to detect the presence of a maildir. Whenever we see
> child directories of "cur", "new", and "tmp" then we should turn on the
> processing of maildir flags for when processing mail in "cur" and "new".
I considered that approach; ideally, we could test for the presence of
all three of cur, tmp and new--but this is rather messy to do in the
current treewalk structure. Taking any one of them as proof positive of
a Maildir might lead to unpleasant surprises--it's not all that incon-
ceivable for someone to name a mail folder 'tmp'.
There's another matter; Some mail stores will place (large) index files
in folder roots, i.e. one level above cur/, tmp/ and new/. Looking
at the ones dovecot (an IMAP server) uses, I can make out a from header,
a subject header, and a message-id, as plaintext in the first 100k or
so. It's not all that inconceivable that notmuch might register it as
a 'real' email, with unpleasant consequences for the index.
I've seen some patches fly by that add support for multiple mail
stores. Turning on Maildir support on a per-directory basis might
resolve that problem while still supporting heterogenous mail archives
to some degree. I am not convinced we can do the right thing
automatically without causing some grief to a subset of users.
> > @@ -257,7 +262,7 @@ notmuch_config_open (void *ctx,
> > talloc_free (email);
> > }
> > }
> > -
> > +
> > /* When we create a new configuration file here, we add some
> > * comments to help the user understand what can be done. */
> > if (is_new) {
>
> [nit] Trailing whitespace inserted there as well.
> Hmm... I was going to say that git ships with a pre-commit hook you can
> turn on that checks for trailing whitespace and aborts the commit if
> it's present. But it looks like the currently shipping pre-commit.sample
> hook doesn't do this anymore.
Haven't tested it, but it seems you can put
[core]
whitespace = trailing-space,space-before-tab
into your ~/.gitconfig now. I've also set emacs to mark trailing
whitespace with big red markers.
> OK, now we're into the meat of things. Clearly, you're directly
> supporting the documented flags of maildir. But we need to do a few
> things differently here. Most importantly, notmuch is already using an
> "unread" tag, so maildir's S flag should map that *that* rather than
> adding new "unseen" and "seen" flags. So messages with the S flag would
> not get the "unread" tag and messages without S would get the "unread"
> tag.
When writing the patch, I assumed there might be a minor (but important)
distinction between marking a mail 'seen' (i.e. the MUA storing the fact
that the file has been visited) and 'read' (i.e. the user marking the
contents of a mail as being read and understood). As I found out later,
notmuch's interpretation of 'read' and 'unread' is the former, so there
is no distinction.
> The "flagged" and "replied" tags seem reasonable enough. But for
> "trashed" and "passed" I think I'd rather see the tag names as "deleted"
> and "forwarded". (Since I can imagine adding commands to notmuch for
> "delete" and "forward" but not for "trash" nor "pass").
Fair enough.
> Oh, and setting the "inbox" tag correctly here based on the maildir tags
> is the final and most important thing. It looks like that's missing from
> the above. So, a missing "S" flag should map to adding both the "inbox"
> and "unread" tags.
Makes sense, will do.
> > + if (state->storage_type == MAILDIR) {
> > + char * leaf = basename(next);
>
> You could save the basename call by examining the leaf name when it is
> available as a standalone string up in the caller.
Which would require testing with S_ISDIR twice, which is uglier, but
essentially free, so I'll grant it's the better thing to do.
> So this patch is close, but needs a few fixes.
I'll be happy to implement them, although I'd like for others to chime
in on the configure-as-Maildir vs. autodetect-Maildir issue. And thanks
for your patience in working through my patch.
--
Michiel Buddingh'
[notmuch] notsomuch, a dummy curses ui
On 10:30, Thu 26 Nov 09, Carl Worth wrote: > I'm glad to see work like this going on. If you do decide to keep going > with it at all, I'd be glad to add this to contrib. I'm happy to have > all kinds of different interfaces available. Ok, I'll see what I'm doing about it in the future. Right now it don't do nothing, I'm just playing with the code. But as soon as I have something working I'll ask to be on contrib. > We can decide later if it makes sense to separate various interfaces > into their own repositories/tar-files etc. For now, while the library > and command-line keeps changing rapidly, I think it makes sense to keep > things together. I do agree. Up to now is a good idea to have everything together. I guess in the future the library API will become more standard and will be possible to split the interfaces. -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Lo hago para no volverme loco cuando noto que solo me queda un demonio en un hombro por que se ha cortado las venas el ?ngel que hab?a en el otro. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091126/025df1b1/attachment.pgp>
[notmuch] notmuch_threads_back and notmuch_messages_back
Is it possible to implement notmuch_threads_back and notmuch_messages_back? And I guess will make sense to have also notmuch_tags_back. This functions will do the oposite than notmuch_threads_advance and notmuch_messages_advance. So I can use them as iterators going back and forward. I didn't check the implementation of notmuch. I don't know if will be easy or will need to redesign a lot of code. -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- La felicidad no es hacer lo que deseas es desear lo que haces. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091126/848c8aae/attachment.pgp>
[notmuch] A gtk interface
Hi, I've started to work on a Gtk+ interface to notmuch which uses the notmuch command line. Currently it is able to search threads and retag them. Next on the agenda is the ability to actually read the threads. If someone is interested, the code lives in http://github.com/baruch/notmuch-gtk and can be checked out from git://github.com/baruch/notmuch-gtk.git The recent streaming changes made things smoother. Though tagging is excessively slow if done on a thread-by-thread basis as I implemented it now. Baruch
[notmuch] Notmuch doesn't index new mails when mail location contains symlinks
On Thu, 26 Nov 2009 10:34:12 -0800, Carl Worth wrote: > I'm a little confused here. Notmuch only uses stat, so it should be > looking at the target's mtime already. It actually takes special effort > (via lstat) to get at the mtime of the link itself. > > So why aren't things just working? Because mtime doesn't change on the directory *above* the symlinks. I think. Jed
[notmuch] OpenPGP support
On Thu, 26 Nov 2009 10:41:36 -0800, Carl Worth wrote: > I'm not sure how to make sure that I also get that when doing a reply > within notmuch. Keith, I think you worked this out, right? What did you > do? ; sign messages by default (defun my-notmuch-message-mode-hook() (if (buffer-modified-p) (mml-secure-message-sign))) (add-hook 'message-mode-hook 'my-notmuch-message-mode-hook) (add-hook 'message-setup-hook 'my-notmuch-message-mode-hook) The message-setup-hook is called for new messages, the message-mode-hook is called for both; the hack is to check for the reply case by looking to see if the buffer has been modified as the message mode hook gets called on an empty buffer in the new message case. -- keith.packard at intel.com -- 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/20091126/f03e09ea/attachment.pgp>
[notmuch] Search results now start appearing "instantly"
On 11:17, Wed 25 Nov 09, Carl Worth wrote: > And for the authors of the other interfaces, let us know when you've got > similar support for streaming searches, (or if you didn't get this > automatically as soon as "notmuch search" was fixed). Yes, actually is faster now. I had to rewrite some of the code, because before I used the notmuch_query_search_threads for pagging with the parameters for number of threads and index. But I like it more now. Thank you. -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ?sta es la historia de una sociedad que se hunde y mientras cae se repite: hasta ahora todo va bien, hasta ahora todo va bien ... Pero lo importante no es la caida sino el aterrizaje. el odio -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091126/741ec374/attachment.pgp>
[notmuch] [PATCH] Return unpropertized strings for filename and message-id
On Mon, 23 Nov 2009 17:57:31 +0100, Tassilo Horn
wrote:
> Hi!
>
> Here's my first patch. It changes that notmuch-show-get-filename and
> notmuch-show-get-message-id return simple strings and not propertited
> strings.
Thanks, Tassilo!
It's great to have a contribution from you in notmuch. I've pushed this
out now.
Two things with regards to your patch:
1. It's most convenient (for me) to apply emailed patches by sending
directly to "git am". And "git am" just happens to want to see the
complete commit message as the first thing in the mail message,
(continuing the summary of the commit which comes from the
subject).
So to satisfy "git am", introductory and explanatory portions of
the email, ("Hi!" and "Here's my first patch"), have to be
relegated to past the "---" divider).
I actually don't love this about "git am", since I think those
introductory parts are essential to having cordial and friendly
exchanges on the mailing list, (rather than just dryly shooting
code back and forth). And it feels natural to have them first. One
thing that might be interesting is to teach "git am" about an
additional divider so that other text can came *before* the commit
message.
Alternately, one can put introductory text in one message, and the
dry commit-only stuff as a reply.
2. Maybe I'll undermine my point above, but the commit here really
*does* need a commit message beyond the first line.
I've described this before as the one-line summary giving the
"what" and the rest of the commit message giving the "why".
And this is a perfect case of that. I can see exactly what the
patch does, and it makes sense. But I tried to write the rest of
the commit message and found I couldn't. In what cases did the
presence of text properties cause a problem? I don't know, and
that's what the commit message should have said.
I'd said before that I would bounce patches with only a one-line
summary. I guess I'm still too soft, but do expect me to be more strict
on this in the future. :-)
-Carl
[notmuch] OpenPGP support
On Thu, Nov 26, 2009 at 12:38:01PM +0530, Aneesh Kumar K. V wrote:
> message-mode can sign the message using C-c RET C-s
> which is mml-secure-message-sign
Thanks so much, Aneesh! That's great. I was not aware of those
abilities in mml mode. I just noticed that epa-mail-{sign,encrypt}
can do this as well, but much less cleanly. So the mml commands are
exactly what I was looking for. Well, at least exactly *half* of what
I was looking for...
So the issue now is verifying/decrypting signed/encrypted received
mail. Playing around with it a bit more, I've found a couple of
interesting things. If I'm viewing an encrypted message with
notmuch-show, and if I type 'v' (notmuch-show-view-all-mime-parts), I
get the full message view, and then a prompt to:
Decrypt (PGP) part? (y or n)
Typing 'y', I see that there is some communication with my gpg agent
(I get a gpg agent password prompt), but then once the password is
entered, nothing happens, ie. I don't see the decrypted part. I'm
trying to figure out where the problem is here. Presumably something
is failing to capture the output of the gpg decryption. I'm not clear
either about what mode is trying to do this decryption. Is this epa?
Unfortunately nothing at all happens when I hit 'v' when viewing a
message that has OpenPGP signature attachment.
I also just discovered that there are some
epa-mail-{sign,verify,{de,en}crypt} commands that work similar to (but
not as cleanly as) the mml commands. Unfortunately none of this is
very coherent. And some sort of integration with notmuch-show would
be sweet.
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/20091126/f7adb576/attachment.pgp>
[notmuch] Notmuch doesn't index new mails when mail location contains symlinks
On Thu, 26 Nov 2009 19:39:01 +0100, Jed Brown wrote: > On Thu, 26 Nov 2009 10:34:12 -0800, Carl Worth wrote: > > I'm a little confused here. Notmuch only uses stat, so it should be > > looking at the target's mtime already. It actually takes special effort > > (via lstat) to get at the mtime of the link itself. > > > > So why aren't things just working? > > Because mtime doesn't change on the directory *above* the symlinks. > > I think. Then I'm still being really dense here. The non-propagation of mtime is the with actual directories. And the code is trying to do the right thing for that. So I still don't see what's being different with the symlinks. I should probably stop exposing ignorance here on the list, and just sit down with symlinks in a mail store and see what's happening. -Carl
[notmuch] [PATCH] notmuch.el: Use variable notmuch-search-oldest-first to decide the search order
On Mon, 23 Nov 2009 20:20:59 +0530, "Aneesh Kumar K.V" wrote: > Make sure we use notmuch-search-oldest-first to decide the how > the search result should be displayed. This helps to set the > value to nil and have latest mail shown first Thanks. This is pushed now. -Carl
[notmuch] [PATCH] Add private implementations of strndup and getline.
On Mon, 23 Nov 2009 07:43:30 -0600, "Jeffrey C. Ollie"
wrote:
> Add private implementations of strndup and getline for those platforms
> that don't have them (notably Mac OS X) no matter what preprocessor
> symbols you define.
Thanks. This is off to a very good start.
> +char *
> +_notmuch_strndup (const char *s, size_t n)
> +{
> +size_t len = strlen (s);
> +char *ret;
> +
> +if (len <= n)
> + return strdup (s);
> +
> +ret = malloc(n + 1);
This needs to check and return NULL if malloc returns NULL.
> +/* getline implementation is copied from glibc. */
Then, this should have added a copyright attribution to the top of the
file.
In fact, everyone that's contributing non-trivial amounts should be
adding copyright statements. I don't mind too much if people consider
their own contributions to be insignificant enough to not merit a
copyright claim, but when copying code written by others, we definitely
need to bring the copyright attribution along.
Would also be good to mention the glibc version and license in this
comment and in the commit message as well.
-Carl
[notmuch] [PATCH] New function notmuch-search-operate-all: operate on all messages in the current query.
On Mon, 23 Nov 2009 14:07:20 +0100, Jed Brown wrote: > > Second, since we're in the search view which shows threads, we should > > really be operating on threads. But this tag command won't work like the > > '+' and '-' commands in this buffer. Those commands will add/remove a > > tag to/from every message in the thread[*]. The new '*' command, however > > will only be changing tags on messages that match the query. > > I'm not convinced that we want to operate on the entire thread. > Applying the tag only to the matched messages is enough to find the > thread, and it may really be desirable to only have it applied to > certain messages in the thread. For example, I might have constructed > an elaborate query to find five messages, including a couple that are > burried in 100-message threads in which case I would definitely not want > to tag entire threads. That's a legitimate point. But my point is that whatever behavior we choose here, I want the commands that operate on a single thread (+, -, a) to operate exactly the same as the command that operates on all threads (*). Having these behave subtly different, (as in the current patch) is going to lead to confusion on the part of the user. So, tagging only matching messages could make a lot of sense. If so, let's make the operations on single threads work the same. The race-condition issues apply to both operations, so I won't make the current patch block on resolving those. -Carl
[notmuch] [PATCH -v3] notmuch.el: Add face support to search and show mode
On Mon, 23 Nov 2009 10:51:20 +0530, "Aneesh Kumar K.V" wrote: > This add two faces, notmuch-show-subject-face and > notmuch-tag-face. The first face is used to show the subject > line in the notmuch-show-mode and the second one to show tags > in the notmuch-search-mode. I mentioned in IRC that I think we can simplify things here by just using existing message-mode faces rather than inventing new faces for things like the subject header. We're already depending on message-mode for composition, so it would be nice if our presentation of messages looked the same, and very nice if both presentation and composition could be customized in a single place. Obviously, message-mode doesn't have anything specific for tags, so I'd be happy to see a patch that add just the addition of special face treatment for tags. -Carl
[notmuch] How to index /var/spool/mail with notmuch
On Mon, 23 Nov 2009 08:42:09 +0100, Tassilo Horn wrote: > Carl Worth writes: > > > But perhaps these errors should be made into warnings instead? Any > > thoughts on that anyone? > > I think so. For other dovecot internal index files it already says > something like "Ignoring non-mail file foobar.idx" and simply skips that > file. I think that's the right thing to do for files where it has no > read permissions for, too. OK. I've added that to our TODO list. -Carl
[notmuch] [PATCH] Makefile: Enable backslash escapes for echo.
On Thu, Nov 26, 2009 at 12:05 PM, Jan Janak wrote: > I sent exactly the same patch a couple of days ago and it was > rejected because it does not work everywhere, see: > > http://notmuchmail.org/pipermail/notmuch/2009/000370.html And as I said in that thread, I believe you should use printf instead. (http://www.in-ulm.de/~mascheck/various/echo+printf/ seems like a good reference in this matter.) -- Karl Wiberg, kha at treskal.com subrabbit.wordpress.com www.treskal.com/kalle
[notmuch] OpenPGP support
On Thu, 26 Nov 2009 01:01:32 -0500, Jameson Graef Rollins wrote:
> On Mon, Nov 23, 2009 at 08:00:09AM -0500, Jameson Graef Rollins wrote:
> > Hi, folks. I know it's a hairy problem, but has anyone started
> > looking into OpenPGP support for notmuch?
>
> Hey, folks. I wanted to try to follow up on this question.
>
> I would really like to start using notmuch with emacs beyond just
> testing, but I really need to be able to handle/read/send mail with
> PGP/MIME encoded attachments. Do folks have any suggestions on how to
> handle this? Is there a separate emacs mode that people use for
> signing/verifying/{de,en}crypting mail buffers, or is this something
> that is going to have to be integrated into the notmuch mode? I guess
> the notmuch-show mode at least will need to do some verifying and
> decrypting.
>
> I've noticed that some people on this list sign their mails. Are
> those of you that do using notmuch? If so, I would love to learn how
> you handle it. Thanks so much for the info.
>
message-mode can sign the message using C-c RET C-s
which is mml-secure-message-sign
-aneesh
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091126/0d51585a/attachment.pgp>
[notmuch] A gtk interface
On Thu, 26 Nov 2009 21:17:33 +0200, Baruch Even wrote: > I've started to work on a Gtk+ interface to notmuch which uses the > notmuch command line. Currently it is able to search threads and retag > them. Next on the agenda is the ability to actually read the threads. > > If someone is interested, the code lives in > http://github.com/baruch/notmuch-gtk and can be checked out from > git://github.com/baruch/notmuch-gtk.git Very interesting, Baruch! Thanks for contributing this! I thought at first that the tagging commands weren't working, but quickly realized they were working but simply weren't updating the view to show the added/removed tags. Anyway, it will be very interesting to watch this stuff. -Carl PS. I prefer a default search of "tag:inbox" rather than "tag:inbox and tag:unread". Otherwise, there's not much reason for "notmuch new" to add both tags.
[notmuch] [PATCH] Makefile: Enable backslash escapes for echo.
Hi Stefan, On 26-11 09:17, Stefan Schmidt wrote: > This fixes a visual glitch during a silent compile. > Before: > Use "make V=1" to see the verbose compile lines.\n CC debugger.o > CCgmime-filter-reply.o > > After: > Use "make V=1" to see the verbose compile lines. > CCdebugger.o > CCgmime-filter-reply.o > > Signed-off-by: Stefan Schmidt > --- > Makefile |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index 2cd1b1b..2d19a6e 100644 > --- a/Makefile > +++ b/Makefile > @@ -41,7 +41,7 @@ include Makefile.config > # user how to enable verbose compiles. > ifeq ($(V),) > quiet_DOC := "Use \"$(MAKE) V=1\" to see the verbose compile lines.\n" > -quiet = @echo $(quiet_DOC)$(eval quiet_DOC:=)" $1 $@"; $($1) > +quiet = @echo -e $(quiet_DOC)$(eval quiet_DOC:=)" $1$@"; $($1) > endif > # The user has explicitly enabled quiet compilation. > ifeq ($(V),0) I sent exactly the same patch a couple of days ago and it was rejected because it does not work everywhere, see: http://notmuchmail.org/pipermail/notmuch/2009/000370.html -- Jan
[notmuch] [PATCH] add missing comma in debugging code
---
lib/message.cc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 1e325e2..832a1b9 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -318,7 +318,7 @@ _notmuch_message_get_in_reply_to (notmuch_message_t
*message)
if (i != message->doc.termlist_end () &&
strncmp ((*i).c_str (), prefix, prefix_len))
{
- INTERNAL_ERROR ("Message %s has duplicate In-Reply-To IDs: %s and %s\n"
+ INTERNAL_ERROR ("Message %s has duplicate In-Reply-To IDs: %s and %s\n",
notmuch_message_get_message_id (message),
message->in_reply_to,
(*i).c_str () + prefix_len);
--
1.6.5.3
[notmuch] notmuch new: Memory problem
On Thu, 26 Nov 2009 10:46:54 -0800, Carl Worth wrote: > So perhaps the new configuration option we want is a limit on message > size? Rather than ignoring large files entirely, notmuch could just stop > indexing messages past the configured limit? Having just written that, I don't think it's actually an interesting option. Instead of working around the bug, we should just find out what the bug actually is. It could be that Xapian's TermGenerator is just going nuts here. Or it could be that Xapian is just trying to hold too much data in memory instead of flushing it out to disk. Currently, notmuch doesn't ever call any explicit Xapian flush. Instead, we rely on the default behavior which is that Xapian will flush to disk after every batch of 1 documents added. So it's possible that all that's actually needed here is for notmuch to notice that it just indexed a huge file, and then explicitly flush to avoid Xapian using too much memory. Or, perhaps better, Xapian could be fixed to automatically flush if its memory usages gets "too big", (if the missing flush is actually what's needed here). Clearly, some experimenting is needed. Dominik, if you can share the large file, (with either me alone or with the whole list), a pointer to where we could download it would be appreciated. -Carl
[notmuch] OpenPGP support
On Thu, 26 Nov 2009 13:31:05 -0500, Jameson Graef Rollins wrote: > So the issue now is verifying/decrypting signed/encrypted received > mail. Playing around with it a bit more, I've found a couple of > interesting things. If I'm viewing an encrypted message with > notmuch-show, and if I type 'v' (notmuch-show-view-all-mime-parts), I > get the full message view, and then a prompt to: > > Decrypt (PGP) part? (y or n) > > Typing 'y', I see that there is some communication with my gpg agent > (I get a gpg agent password prompt), but then once the password is > entered, nothing happens, ie. I don't see the decrypted part. Our integration with the MIME pieces of emacs definitely leaves something to be desired. What currently happens when you press 'v' is that notmuch creates a new buffer with the raw message content, then runs mm-dissect-buffer and mm-display-parts on the content. This works quite well for non-text parts, (either a mailcap-configured viewer will be launched, or else you will be prompted to save the file). But for text parts, the mm code appears to just write into the temporary buffer that notmuch ends up killing before you can see anything. So we just need to work out something proper here. One thing I experimented with, that seems to work quite well, is to construct a minimal buffer that the mm code will interpret as a MIME-encoded message with just a single part. So that's just a MIME-Version header, the original Content-type header, a blank line, and then the original MIME content with its boundary markers. So if we write a notmuch command to return that, then we'll be able to easily support viewing of a single MIME part, (and I think it will be easy to detect whether any text content ended up getting added to the intermediate buffer that the user wants to see). Any help experimenting more with this stuff would be very appreciated. -Carl
[notmuch] notmuch new: Memory problem
On Wed, 25 Nov 2009 10:39:57 +0100, Dominik Epple wrote: > So the problem stems indeed from too many too large files being > present. (I actually found some being as large as 40M, not just 2.4M, > as written in previous mails.) That's very good to know. And I'm glad you at least have things working smoothly now. So perhaps the new configuration option we want is a limit on message size? Rather than ignoring large files entirely, notmuch could just stop indexing messages past the configured limit? -Carl
[notmuch] OpenPGP support
On Mon, 23 Nov 2009 08:00:09 -0500, Jameson Graef Rollins wrote: > Hi, folks. I know it's a hairy problem, but has anyone started > looking into OpenPGP support for notmuch? I definitely want this. I've got message-mode setup to sign my messages automatically when I start a new compose from within notmuch with 'm'. I did this with the following in my .emacs: ; sign messages by default (add-hook 'message-setup-hook (lambda () (mml-secure-message-sign))) I'm not sure how to make sure that I also get that when doing a reply within notmuch. Keith, I think you worked this out, right? What did you do? I'm also interested in automating things like this as much as possible. I'd much rather people flip one Boolean notmuch-sign-messages variable then have to code up multiple lambda's within .emacs. Meanwhile, the other pieces still needed are automatic signature verification for multipart/signed messages, and then support for decrypting GPG-encrypted messages. I'm certain that the various mail-handling modes within emacs already have support for these things, so it's really just a matter of finding and hooking into that support. Of course, if we code some of this up at the library or command-line level, then the non-emacs interfaces could automatically benefit from it as well. And that same argument applies for viewing of MIME-encoded message parts---I definitely want support at the command-line interface of notmuch to at least extract a specific MIME part from a message. In one sense, it's unfortunate that I figured out a way to let me view these parts within emacs without that support in the notmuch command-line. That definitely took the pressure off me to finish up coding this piece, (which actually wouldn't be hard at all). -Carl
[notmuch] Notmuch doesn't index new mails when mail location contains symlinks
On Mon, 23 Nov 2009 16:03:00 +0100, Jed Brown wrote: > > But still no luck. Finally, I deleted the symlinks and created them > > anew, and then it indexed the 12 new mails that arrived in the > > meantime. OK. So that's definitely a bug we need to fix. > The real solution is for notmuch to check mtime of whatever the > symlink's target. I'm a little confused here. Notmuch only uses stat, so it should be looking at the target's mtime already. It actually takes special effort (via lstat) to get at the mtime of the link itself. So why aren't things just working? -Carl
[notmuch] notsomuch, a dummy curses ui
On Mon, 23 Nov 2009 11:12:40 +0100, Ruben Pollan wrote: > Hi notmuch community, > > As I'm not an emacs user, I started to play with the code to see what are the > power of notmuch. I create a simple ncurses ui: > http://gitorious.org/notsomuch Hi Ruben, welcome to notmuch! I'm glad to see work like this going on. If you do decide to keep going with it at all, I'd be glad to add this to contrib. I'm happy to have all kinds of different interfaces available. We can decide later if it makes sense to separate various interfaces into their own repositories/tar-files etc. For now, while the library and command-line keeps changing rapidly, I think it makes sense to keep things together. -Carl
[notmuch] [PATCH] ANSI escapes in "new" only when output is a tty
On Sun, 22 Nov 2009 23:35:24 -0800, Keith Packard wrote: > Tracking directory mtime instead of just looking at the read-only bit > would let us skip directories that haven't seen any change in content. We've had directory mtime for a long time. I added the check for the read-only bit afterwards to be able to avoid stats on a whole directory hierarchy, (since mtime doesn't propagate upward of course). > Tracking directory contents would let us easily detect name changes > (add/remove/rename). Do we want git tree objects for the directories? ... -Carl
[notmuch] [PATCH] Handle message renames in mail spool
On Thu, 26 Nov 2009 22:38:49 +0600, Mikhail Gusarov wrote: > > Twas brillig at 07:40:15 26.11.2009 UTC-08 when cworth at cworth.org did gyre > and gimble: > > CW> I *really* want this patch in, since I think a lot of current users > CW> would really benefit from it. I only see one big problem with it: > > Did you test the performance hit caused by disabling mtime checks? Not yet, no. I only had a moment earlier---just long enough to review the patch by reading it. I haven't actually tested it at all yet. -Carl
[notmuch] Search results now start appearing "instantly"
On Thu, 26 Nov 2009 14:27:37 +0100, Ruben Pollan wrote: > On 11:17, Wed 25 Nov 09, Carl Worth wrote: > > And for the authors of the other interfaces, let us know when you've got > > similar support for streaming searches, (or if you didn't get this > > automatically as soon as "notmuch search" was fixed). > > Yes, actually is faster now. > > I had to rewrite some of the code, because before I used the > notmuch_query_search_threads for pagging with the parameters for number of > threads and index. But I like it more now. Hi Ruben, I'm glad it worked out. I probably should have sent the patches to the list for review before just pushing them out. I'll have to adjust from this being just my own thing where I do whatever I want, to instead work within our community. So please feel free to call me out on that, -Carl
[notmuch] Search results now start appearing "instantly"
On Thu, 26 Nov 2009 23:34:34 +1100, Peter Wang wrote: > On 2009-11-25, Carl Worth wrote: > > > > So please update to the latest code and let me know what you think. I'll > > be interested to hear if this helps people, and also to know if the CPU > > usage is a problem for anybody. > > Brilliant, thanks! You're quite welcome. I only wish I would have done it right the first time. Anyway, enjoy. -Carl
[notmuch] [PATCH] Makefile: Enable backslash escapes for echo.
Excerpts from Stefan Schmidt's message of Thu Nov 26 09:17:15 +0100 2009: > This fixes a visual glitch during a silent compile. > Before: > Use "make V=1" to see the verbose compile lines.\n CC debugger.o > CCgmime-filter-reply.o > > After: > Use "make V=1" to see the verbose compile lines. > CCdebugger.o > CCgmime-filter-reply.o > > Signed-off-by: Stefan Schmidt Looks right, works here with bash, dash & zsh, so: Reviewed-by: Ingmar Vanhassel Thanks! > --- > Makefile |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index 2cd1b1b..2d19a6e 100644 > --- a/Makefile > +++ b/Makefile > @@ -41,7 +41,7 @@ include Makefile.config > # user how to enable verbose compiles. > ifeq ($(V),) > quiet_DOC := "Use \"$(MAKE) V=1\" to see the verbose compile lines.\n" > -quiet = @echo $(quiet_DOC)$(eval quiet_DOC:=)" $1$@"; $($1) > +quiet = @echo -e $(quiet_DOC)$(eval quiet_DOC:=)" $1$@"; $($1) > endif > # The user has explicitly enabled quiet compilation. > ifeq ($(V),0) -- Exherbo KDE, X.org maintainer
[notmuch] [PATCH] Makefile: Enable backslash escapes for echo.
This fixes a visual glitch during a silent compile. Before: Use "make V=1" to see the verbose compile lines.\n CC debugger.o CCgmime-filter-reply.o After: Use "make V=1" to see the verbose compile lines. CCdebugger.o CCgmime-filter-reply.o Signed-off-by: Stefan Schmidt --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 2cd1b1b..2d19a6e 100644 --- a/Makefile +++ b/Makefile @@ -41,7 +41,7 @@ include Makefile.config # user how to enable verbose compiles. ifeq ($(V),) quiet_DOC := "Use \"$(MAKE) V=1\" to see the verbose compile lines.\n" -quiet = @echo $(quiet_DOC)$(eval quiet_DOC:=)" $1 $@"; $($1) +quiet = @echo -e $(quiet_DOC)$(eval quiet_DOC:=)" $1 $@"; $($1) endif # The user has explicitly enabled quiet compilation. ifeq ($(V),0) -- 1.6.5.3
[notmuch] [PATCH] Handle message renames in mail spool
On Mon, 23 Nov 2009 07:13:25 +0600, Mikhail Gusarov wrote:
> In order to handle message renames the following changes were deemed
> necessary:
Hi Mikhail,
I *really* want this patch in, since I think a lot of current users
would really benefit from it. I only see one big problem with it:
> 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).
...
> + } else if (strcmp(notmuch_message_get_filename(message), filename)) {
> + /* Message file has been moved/renamed */
> + _notmuch_message_set_filename (message, filename);
With multiple copies of the same message being present in the mailstore
as different files, the code above will set the filename of the document
to each filename in turn, correct?
Now, I *think* that Xapian defect #250 doesn't hit us here
currently. But there was an old bug in Xapian that changing just the
data of a document would also rewrite all the terms. But we've also
talked recently about storing the filename as a term as well, and once
we add that, then this code would trigger defect #250 and cause a big
slowdown here.
So I think the code just needs to verify that the old filename no longer
exists before it changes anything in the database. And then if it does
still exist, we can get our NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID return
value back here.
> } else {
> ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
> goto DONE;
> }
In this case, the return value is actually wrong. This is the case for
adding a message file that already exists in the database. I don't know
that we have any users that care about distinguishing this, but if they
did, then DUPLICATE isn't right. I suggest returning
NOTMUCH_STATUS_SUCCESS here.
-Carl
[notmuch] On "search-tags" vs. "search --for tags" (was: search-tags and tag completion in notmuch.el)
On Mon, 23 Nov 2009 01:56:04 +0100, Jan Janak wrote: > I considered implementing 'notmuch search --output=tags' (as we > discussed in another email), but it turned out that: > > * Having 'notmuch search-tags' would be consistent with Carl's > 'notmuch search-messages'. Yes, but I just put that out as an RFC. I didn't actually push it out in that form, (and my big concern was overwhelming the user with a lot of different top-level commands). > * 'notmuch search' supports other command line options (--first, > --max-threads, --sort) and these would only work when the user uses > the command to search for messages. Fortunately, the --first and --max-threads options are gone now. So some of that concern is gone now. > * 'notmuch search-tags' is easier on fingers than > 'notmuch search --output=tags' :-). We can shorten the command with something like: notmuch search --for=tags Is that any better? I don't love the '=' there, and might prefer: notmuch search --for tags But that complicates the option parsing just a bit, (which I shouldn't really care about since what we're designing here is an interface that is easy for the user). In any case, I don't expect people typing at the command-line to do things like search for tags nearly as often as searching for threads. And that's really the biggest reason I *do* want to put this functionality behind a command-line option. I'd like to have a fairly short number of top-level commands that are each something a person at the command-line would be likely to use fairly regularly. Thanks that are more likely to be used by scripts, (such as --format=html), should be hidden behind options. -Carl
[notmuch] [PATCH 3/3] notmuch.el: Select tag names with completion.
On Mon, 23 Nov 2009 01:10:56 +0100, Jan Janak wrote: > Several commands ask the user for a tag name. With this feature the > user can just press tab and Emacs automatically retrieves the list of > all existing tags from notmuch database with 'notmuch search-tags' and > presents a completion buffer to the user. > > This feature is very useful for users who have a large number of tags > because it saves typing and minimizes the risk of typos. Jan, This feature is incredibly useful. Thanks so much for coding it! I've had a bunch of messages that were effectively "lost" to me since switching from sup. I had been experimenting with different tag schemes, renaming tags, etc. within sup. But in sup there was no global-search-based tag manipulation command, so no easy way to update the tag names for messages tagged under the old scheme. I'd been aware of the problem and knew I could just code something up to search for those old tags. But now I get to see the full list every time I hit TAB in emacs. So thanks! I do still want to unify search, search-messages, search-tags, count, etc. But I've gone ahead and merged this whole series as-is to get the functionality out there for now. I assume that everyone is aware that I'm reserving the right to change the library and command-line interface as much as I want right now. If you've got code or scripts that depend on these interfaces, I highly recommend that you get them contributed to the notmuch repository so that we can fix them up as we rework the library and command line. (So, Bart, I'll merge the vim stuff which is using "notmuch count" before I change that, so I can fixup the vim stuff at the same time.) Thanks again, Jan! Well done. -Carl
[notmuch] OpenPGP support
On Mon, Nov 23, 2009 at 08:00:09AM -0500, Jameson Graef Rollins wrote:
> Hi, folks. I know it's a hairy problem, but has anyone started
> looking into OpenPGP support for notmuch?
Hey, folks. I wanted to try to follow up on this question.
I would really like to start using notmuch with emacs beyond just
testing, but I really need to be able to handle/read/send mail with
PGP/MIME encoded attachments. Do folks have any suggestions on how to
handle this? Is there a separate emacs mode that people use for
signing/verifying/{de,en}crypting mail buffers, or is this something
that is going to have to be integrated into the notmuch mode? I guess
the notmuch-show mode at least will need to do some verifying and
decrypting.
I've noticed that some people on this list sign their mails. Are
those of you that do using notmuch? If so, I would love to learn how
you handle it. Thanks so much for the info.
jamie.i
-- 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/20091126/01aab46a/attachment.pgp>
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
Hello, On 24-11 23:10, Jan Janak wrote: > I would like to propose that we make the list of tags applied by 'notmuch new' > configurable. Right now notmuch applies two tags to all new messages added to > the database, 'inbox' and 'unread'. The two tags are added by the C code in > notmuch-new.c and they cannot be changed without editing the source file and > recompiling notmuch. > > The four patches that follow this email allow for configuring the tags to be > added by 'notmuch new' either in the configuration file or on the command > line. > > This change was motivated by my desire to remove both tags from newly added > messages. My rules for adding these two tags are more complex and I do it in > a script run after 'notmuch new'. Instead of 'inbox' and 'unread', I configure > 'notmuch new' to add a new tag called 'new' (and only that one). This tag > marks newly added messages that haven't been properly tagged yet by my > auto-tagging scripts. The last script I run after 'notmuch new' removes that > tag. My auto-tagging scripts process only messages with the tag 'new'. > > On a side note; It may seem logical to add/omit the tag 'unread' directly in > 'notmuch new' based on the Maildir flags extracted from the filename of the > message. I suggest that we don't do that in 'notmuch new'. A better way would > be writing a small script or command that can be run *after* 'notmuch new'. > We could then distribute it with notmuch (maybe with other small tagging > scripts for common situations). > > I think Maildir flags should be processed after 'notmuch new' is because if > there are multiple copies of a message with different flags, we may need to > see all flags from all filenames to set corresponding tags properly and we may > also need to take the directory part into consideration (i.e. the new mail is > in 'new', not 'cur'). > > The list of tags to be applied by notmuch can be configured in the > configuration file. There is a new section [new] which contains configuration > options for 'notmuch new'. There is only one option called 'tags'. The option > contains a semicolon separated list of tags: > > [new] > tags=inbox;unread # Emulate the original behavior > > One of the patches updates 'notmuch setup' to create the section and add > the tags option with tags 'inbox' and 'unread', but only if a new > configuration file is being created. If the configuration file already exists > then it just copies the contents from the old configuration file to the new > one. > > We do not ask the user for the list of tags in the interactive part, that > would > have been too much. Users can edit the configuration file manually if they > want > to change the list of tags. If they create a new configuration file then they > probably want to accept the default anyway. > > There is one catch for users who already have a configuration file and start > using the patches. They will need to add the new section and the tags option > manually if they want to preserve current behavior of applying 'inbox' and > 'unread' automatically by 'notmuch new'. > > The last patch in the set adds a new command line option to 'notmuch new'. > The name of the option is --tag and it can be used to override any tags > configured in the configuration file. For example: > > notmuch new --tag=outbox --tag=read > > adds the tags 'outbox' and 'read' and ignores any tags from the configuration > file. > > Comments and opinions are welcome! I updated this patch series, adding features and bug fixes suggested by others on the list. The command line option --tag now *adds* tags, so the tags configured in the configuration file are still applied...unless you use the new option --no-config-tag. With this option only the tags specified on the command line will be applied by 'notmuch-new'. -- Jan
[notmuch] [PATCH 5/5] notmuch-new: Option to disable tags from the configuration file.
This patch slightly changes behavior of the command line option --tag.
Any tags specified by the user on the command line will be added
*in addition* to tags configured in the configuration file.
This behavior can be changed with the new command line option
--no-config-tags. The user can use this option to ignore any tags from
the configuration file (i.e. only tags specified on the command line
will be applied).
With this new option the user can configure 'notmuch new' not to apply
any tags (and that was not possible before):
notmuch new --no-config-tags
Suggested by Karl Wiberg.
Bugfix: Fix parsing of --verbose cmdline option.
This is a revised version of the patch, incorporating suggestions made
by Bart Trojanowski. Thanks Bart!
Signed-off-by: Jan Janak
---
notmuch-new.c | 21 -
notmuch.c | 13 +++--
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index cfbc6aa..eaed701 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -28,6 +28,7 @@ static notmuch_config_t *config = NULL;
static char **cmdline_tags = NULL;
static size_t cmdline_tags_count = 0;
+static int add_config_tags = 1;
static void
handle_sigalrm (unused (int signal))
@@ -79,19 +80,19 @@ apply_tags (notmuch_message_t *message)
char** tags;
size_t count, i;
+if (add_config_tags) {
+ tags = notmuch_config_get_new_tags (config, );
+ for (i = 0; tags && (i < count); i++) {
+ if (tags[i])
+ notmuch_message_add_tag (message, tags[i]);
+ }
+}
+
if (cmdline_tags_count) {
for (i = 0; i < cmdline_tags_count; i++) {
if (cmdline_tags[i])
notmuch_message_add_tag (message, cmdline_tags[i]);
}
-} else {
- if ((tags = notmuch_config_get_new_tags (config, )) == NULL)
- return;
-
- for (i = 0; i < count; i++) {
- if (tags[i])
- notmuch_message_add_tag (message, tags[i]);
- }
}
}
@@ -432,7 +433,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
add_files_state.output_is_a_tty = isatty (fileno (stdout));
for (i = 0; i < argc && argv[i][0] == '-'; i++) {
- if (STRNCMP_LITERAL (argv[i], "--verbose") == 0) {
+ if (strcmp (argv[i], "--verbose") == 0) {
add_files_state.verbose = 1;
} else if (STRNCMP_LITERAL (argv[i], "--tag=") == 0) {
opt = argv[i] + sizeof ("--tag=") - 1;
@@ -451,6 +452,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
}
tmp[cmdline_tags_count++] = opt;
cmdline_tags = tmp;
+ } else if (strcmp (argv[i], "--no-config-tags") == 0) {
+ add_config_tags = 0;
} else {
fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
return 1;
diff --git a/notmuch.c b/notmuch.c
index 1bd3265..2bb38f3 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -123,7 +123,7 @@ command_t commands[] = {
"\t\tInvoking notmuch with no command argument will run setup if\n"
"\t\tthe setup command has not previously been completed." },
{ "new", notmuch_new_command,
- "[--verbose] [--tag=]",
+ "[--verbose] [--tag=] [--no-config-tags]",
"\t\tFind and import new messages to the notmuch database.",
"\t\tScans all sub-directories of the mail directory, performing\n"
"\t\tfull-text indexing on new messages that are found. Each new\n"
@@ -149,7 +149,16 @@ command_t commands[] = {
"\n"
"\t\t\tAdd the tag to all messages newly added to the\n"
"\t\t\tdatabase. You may repeat this option several times if\n"
- "\t\t\tyou want to add more tags.\n"
+ "\t\t\tyou want to add more tags. Any tags configured in the\n"
+ "\t\t\tconfiguration file will still be added, unless you also\n"
+ "\t\t\tuse the option --no-config-tags.\n"
+ "\n"
+ "\t\t--no-config-tags\n"
+ "\n"
+ "\t\t\tDo not add tags configured in the configuration file.\n"
+ "\t\t\tUse this option if you only want to add tags specified\n"
+ "\t\t\ton the command line with --tag or if do not want to add\n"
+ "\t\t\tany tags at all.\n"
"\n"
"\t\tNote: \"notmuch new\" runs (other than the first run) will\n"
"\t\tskip any read-only directories, so you can use that to mark\n"
--
1.6.3.3
[notmuch] [PATCH 4/5] notmuch-new: New cmdline option --tag=.
The list of tags to be applied by 'notmuch new' can be configured in
the configuration file. This command line option can be used to
override the list of tags from the coonfiguration file on the command
line. You may repeat the option several times if you want to apply
more than one tag:
notmuch new --tag=apple --tag=orange
This is useful, for example, if you have an archive of messages you
would like to add to the database with a special tag so that they can
be easily identified later. To do that, you could simply copy the files
from the archive to the database directory and then index them all with:
notmuch new --tag=prehistory
Tags to be applied every time 'notmuch new' is run can be specified in
the configuration file. One-time tags for individual runs can be
specified on the command line with this new option.
This revision of the patch includes suggestions from Bart Trojanowski.
Signed-off-by: Jan Janak
---
notmuch-new.c | 40 ++--
notmuch.c |8 +++-
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index af717b7..cfbc6aa 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -26,6 +26,9 @@ static volatile sig_atomic_t do_add_files_print_progress = 0;
static notmuch_config_t *config = NULL;
+static char **cmdline_tags = NULL;
+static size_t cmdline_tags_count = 0;
+
static void
handle_sigalrm (unused (int signal))
{
@@ -76,12 +79,19 @@ apply_tags (notmuch_message_t *message)
char** tags;
size_t count, i;
-if ((tags = notmuch_config_get_new_tags (config, )) == NULL)
- return;
+if (cmdline_tags_count) {
+ for (i = 0; i < cmdline_tags_count; i++) {
+ if (cmdline_tags[i])
+ notmuch_message_add_tag (message, cmdline_tags[i]);
+ }
+} else {
+ if ((tags = notmuch_config_get_new_tags (config, )) == NULL)
+ return;
-for (i = 0; i < count; i++) {
- if (tags[i])
- notmuch_message_add_tag (message, tags[i]);
+ for (i = 0; i < count; i++) {
+ if (tags[i])
+ notmuch_message_add_tag (message, tags[i]);
+ }
}
}
@@ -413,7 +423,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
int ret = 0;
struct stat st;
const char *db_path;
-char *dot_notmuch_path;
+char *dot_notmuch_path, *opt;
+char **tmp;
struct sigaction action;
int i;
@@ -423,6 +434,23 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
for (i = 0; i < argc && argv[i][0] == '-'; i++) {
if (STRNCMP_LITERAL (argv[i], "--verbose") == 0) {
add_files_state.verbose = 1;
+ } else if (STRNCMP_LITERAL (argv[i], "--tag=") == 0) {
+ opt = argv[i] + sizeof ("--tag=") - 1;
+ /* FIXME: We should check for leading and trailing white-space in
+* option value here and remove it.
+*/
+ if (*opt == '\0') {
+ fprintf (stderr, "Option value missing: %s\n", argv[i]);
+ return 1;
+ }
+ tmp = talloc_realloc (ctx, cmdline_tags, char*,
+ cmdline_tags_count + 1);
+ if (tmp == NULL) {
+ fprintf (stderr, "Notmuch ran out of memory.\n");
+ return 1;
+ }
+ tmp[cmdline_tags_count++] = opt;
+ cmdline_tags = tmp;
} else {
fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
return 1;
diff --git a/notmuch.c b/notmuch.c
index f45b692..1bd3265 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -123,7 +123,7 @@ command_t commands[] = {
"\t\tInvoking notmuch with no command argument will run setup if\n"
"\t\tthe setup command has not previously been completed." },
{ "new", notmuch_new_command,
- "[--verbose]",
+ "[--verbose] [--tag=]",
"\t\tFind and import new messages to the notmuch database.",
"\t\tScans all sub-directories of the mail directory, performing\n"
"\t\tfull-text indexing on new messages that are found. Each new\n"
@@ -145,6 +145,12 @@ command_t commands[] = {
"\t\t\tVerbose operation. Shows paths of message files as\n"
"\t\t\tthey are being indexed.\n"
"\n"
+ "\t\t--tag=\n"
+ "\n"
+ "\t\t\tAdd the tag to all messages newly added to the\n"
+ "\t\t\tdatabase. You may repeat this option several times if\n"
+ "\t\t\tyou want to add more tags.\n"
+ "\n"
"\t\tNote: \"notmuch new\" runs (other than the first run) will\n"
"\t\tskip any read-only directories, so you can use that to mark\n"
"\t\tdirectories that will not receive any new mail (and make\n"
--
1.6.3.3
[notmuch] [PATCH 3/5] notmuch-setup: Copy/create the new section with tags for 'notmuch-new'.
If the user runs 'notmuch setup' and there is no configuration file yet
then we also add the new section [new] to the configuration file and
set the tags option as:
tags=inbox;unread
This will be picked up by 'notmuch new' and all new mail added to the
database will be tagged with the two tags as before.
If the user already has a configuration file and runs 'notmuch setup'
then we just copy whatever tags we find in the old configuration file
to the new one. If there are no tags in the old configuration file then
we assume that the user configured notmuch that way and the new config
file would also have no tags in the section [new].
We never ask the user interactively for the list of tags to be used by
'notmuch new', it is assumed that beginners would want to stick to the
defaults and advanced users can edit the configuration manually.
This revision of the patch includes suggestions from Bart Trojanowski.
Signed-off-by: Jan Janak
---
notmuch-client.h |4
notmuch-config.c | 40
notmuch-setup.c | 18 ++
3 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 0fb9c19..bb7d3d4 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -187,6 +187,10 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
char **
notmuch_config_get_new_tags (notmuch_config_t *config, size_t *length);
+void
+notmuch_config_set_new_tags (notmuch_config_t *config, const char *tags[],
+size_t length);
+
notmuch_bool_t
debugger_is_active (void);
diff --git a/notmuch-config.c b/notmuch-config.c
index 57072ce..2bbeb20 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -54,6 +54,16 @@ static const char user_config_comment[] =
" recipient list of replies, and will set the From address based on the\n"
" address to which the original email was addressed.\n";
+static const char new_config_comment[] =
+" Configuration section for 'notmuch new'\n"
+"\n"
+" The only supported value at the moment is 'tags. This option contains
a\n"
+" list of tags (separated by ';') that should be automatically applied
to\n"
+" newly added messages.\n"
+"\n"
+" Note that 'notmuch new' also has a command line option which can be
used\n"
+" to add additional tags to the ones configured here.\n";
+
struct _notmuch_config {
char *filename;
GKeyFile *key_file;
@@ -174,6 +184,7 @@ notmuch_config_open (void *ctx,
GError *error = NULL;
int is_new = 0;
char *notmuch_config_env = NULL;
+const char* def_new_tags[2] = {"inbox", "unread"};
if (is_new_ret)
*is_new_ret = 0;
@@ -270,6 +281,20 @@ notmuch_config_open (void *ctx,
}
}
+/* If we have no configuration file then we configure "inbox" and "unread"
+ * tags by default for 'notmuch new'. This ensures that the Emacs mode
+ * would still work as expected.
+ *
+ * We do not ask the user for tags to be used by 'notmuch new'. That's too
+ * much detail for beginners and others can edit the configuration file by
+ * hand.
+ */
+if (is_new) {
+ notmuch_config_set_new_tags (config, def_new_tags,
+sizeof(def_new_tags) /
+sizeof(const char*));
+}
+
/* When we create a new configuration file here, we add some
* comments to help the user understand what can be done. */
if (is_new) {
@@ -279,6 +304,8 @@ notmuch_config_open (void *ctx,
database_config_comment, NULL);
g_key_file_set_comment (config->key_file, "user", NULL,
user_config_comment, NULL);
+ g_key_file_set_comment (config->key_file, "new", NULL,
+ new_config_comment, NULL);
}
if (is_new_ret)
@@ -493,3 +520,16 @@ notmuch_config_get_new_tags (notmuch_config_t *config,
size_t *length)
*length = config->new_tags_length;
return config->new_tags;
}
+
+void
+notmuch_config_set_new_tags (notmuch_config_t *config,
+const char *tags[],
+size_t length)
+{
+g_key_file_set_string_list (config->key_file,
+ "new", "tags",
+ tags, length);
+
+talloc_free (config->new_tags);
+config->user_other_email = NULL;
+}
diff --git a/notmuch-setup.c b/notmuch-setup.c
index d06fbf8..aeffb88 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -92,12 +92,10 @@ notmuch_setup_command (unused (void *ctx),
unused (int argc), unused (char *argv[]))
{
char *response = NULL;
-size_t response_size;
+size_t response_size, old_other_emails_len, new_tags_len, i;
notmuch_config_t *config;
-char **old_other_emails;
-size_t old_other_emails_len;
+char **old_other_emails, **new_tags;
GPtrArray
[notmuch] [PATCH 2/5] notmuch: Config option to specify tags to be applied by 'notmuch new'.
Add support for section [new] in the configuration file. This section
is supposed to contain options for 'notmuch new'. Currently there is
only one option called tags.
The tags option can be used to configure a set of tags to be applied
by 'notmuch new'. Individual tags are separated by semicolon.
'notmuch new' is modified not to apply 'inbox' and 'unread' by default,
but instead it obtains the set of tags to be applied from the new
configuration file option.
Signed-off-by: Jan Janak
This revision of the patch includes suggestions from Bart Trojanowski.
---
notmuch-client.h |3 +++
notmuch-config.c | 43 +++
notmuch-new.c| 19 ++-
3 files changed, 64 insertions(+), 1 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index c04eaeb..0fb9c19 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -184,6 +184,9 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
const char *other_email[],
size_t length);
+char **
+notmuch_config_get_new_tags (notmuch_config_t *config, size_t *length);
+
notmuch_bool_t
debugger_is_active (void);
diff --git a/notmuch-config.c b/notmuch-config.c
index fc65d6b..57072ce 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -22,6 +22,7 @@
#include
#include
+#include
static const char toplevel_config_comment[] =
" .notmuch-config - Configuration file for the notmuch mail system\n"
@@ -62,6 +63,9 @@ struct _notmuch_config {
char *user_primary_email;
char **user_other_email;
size_t user_other_email_length;
+
+char **new_tags;
+size_t new_tags_length;
};
static int
@@ -199,6 +203,8 @@ notmuch_config_open (void *ctx,
config->user_primary_email = NULL;
config->user_other_email = NULL;
config->user_other_email_length = 0;
+config->new_tags = NULL;
+config->new_tags_length = 0;
if (! g_key_file_load_from_file (config->key_file,
config->filename,
@@ -450,3 +456,40 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
talloc_free (config->user_other_email);
config->user_other_email = NULL;
}
+
+char **
+notmuch_config_get_new_tags (notmuch_config_t *config, size_t *length)
+{
+char **tags;
+size_t i, len;
+char *start, *end;
+
+if (config->new_tags == NULL) {
+ config->new_tags_length = 0;
+ tags = g_key_file_get_string_list (config->key_file, "new", "tags",
+ , NULL);
+
+ if (tags) {
+ config->new_tags = talloc_size (config, sizeof(char*) *
+ (len + 1));
+ for (i = 0; i < len; i++) {
+ /* Remove leading and trailing white space around the tag and
+* filter out empty tags. */
+ start = tags[i];
+ end = start + strlen (start) - 1;
+ while (isspace (*start)) start++;
+ while (end > start && isspace (*end)) end--;
+ if (end >= start) {
+ config->new_tags[config->new_tags_length++] =
+ talloc_strndup (config->new_tags, start,
+ end - start + 1);
+ }
+ }
+ config->new_tags[config->new_tags_length] = NULL;
+ g_strfreev (tags);
+ }
+}
+
+*length = config->new_tags_length;
+return config->new_tags;
+}
diff --git a/notmuch-new.c b/notmuch-new.c
index 9970407..af717b7 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -24,6 +24,8 @@
static volatile sig_atomic_t do_add_files_print_progress = 0;
+static notmuch_config_t *config = NULL;
+
static void
handle_sigalrm (unused (int signal))
{
@@ -68,6 +70,21 @@ add_files_print_progress (add_files_state_t *state)
fflush (stdout);
}
+static void
+apply_tags (notmuch_message_t *message)
+{
+char** tags;
+size_t count, i;
+
+if ((tags = notmuch_config_get_new_tags (config, )) == NULL)
+ return;
+
+for (i = 0; i < count; i++) {
+ if (tags[i])
+ notmuch_message_add_tag (message, tags[i]);
+}
+}
+
static int ino_cmp(const struct dirent **a, const struct dirent **b)
{
return ((*a)->d_ino < (*b)->d_ino) ? -1 : 1;
@@ -191,6 +208,7 @@ add_files_recursive (notmuch_database_t *notmuch,
/* success */
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
+ apply_tags (message);
break;
/* Non-fatal issues (go on to next file) */
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
@@ -388,7 +406,6 @@ count_files (const char *path, int *count)
int
notmuch_new_command (void *ctx, int argc, char *argv[])
{
-notmuch_config_t *config;
notmuch_database_t *notmuch;
add_files_state_t
[notmuch] [PATCH 1/5] notmuch-new: Remove tag_add_inbox_unread in favor of a generic solution.
Instead of adding 'inbox' and 'unread' tags directly in the code of
'notmuch-new', we can specify a list of tags to be added to newly
created messages with a configuration file option or a command line
option. That's more flexible, it allows the user to select which tags
should be added.
Signed-off-by: Jan Janak
---
notmuch-new.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index e32b92a..9970407 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -41,13 +41,6 @@ handle_sigint (unused (int sig))
}
static void
-tag_inbox_and_unread (notmuch_message_t *message)
-{
-notmuch_message_add_tag (message, "inbox");
-notmuch_message_add_tag (message, "unread");
-}
-
-static void
add_files_print_progress (add_files_state_t *state)
{
struct timeval tv_now;
@@ -198,7 +191,6 @@ add_files_recursive (notmuch_database_t *notmuch,
/* 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:
--
1.6.3.3
[notmuch] [PATCH 2/2] notmuch-search-add/remove-tag: restrict to messages in current query
Rather than tagging the everything in the thread. This is arguably more desirable behavior and is consistent with clearly desirably behavior of notmuch-search-operate-all. Note that this change applies indirectly to notmuch-search-archive-thread (which is actually equivalent behavior since this function is primarily used when browsing an inbox). Signed-off-by: Jed Brown j...@59a2.org --- notmuch.el |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/notmuch.el b/notmuch.el index 6adac9e..e9786c0 100644 --- a/notmuch.el +++ b/notmuch.el @@ -935,15 +935,19 @@ and will also appear in a buffer named \*Notmuch errors*\. (split-string (buffer-substring beg end)) (defun notmuch-search-add-tag (tag) + Add a tag to messages in the current thread matching the +active query. (interactive (list (notmuch-select-tag-with-completion Tag to add: ))) - (notmuch-call-notmuch-process tag (concat + tag) (notmuch-search-find-thread-id)) + (notmuch-call-notmuch-process tag (concat + tag) (notmuch-search-find-thread-id) and notmuch-search-query-string) (notmuch-search-set-tags (delete-dups (sort (cons tag (notmuch-search-get-tags)) 'string (defun notmuch-search-remove-tag (tag) + Remove a tag from messages in the current thread matching the +active query. (interactive (list (notmuch-select-tag-with-completion Tag to remove: (notmuch-search-find-thread-id - (notmuch-call-notmuch-process tag (concat - tag) (notmuch-search-find-thread-id)) + (notmuch-call-notmuch-process tag (concat - tag) (notmuch-search-find-thread-id) and notmuch-search-query-string) (notmuch-search-set-tags (delete tag (notmuch-search-get-tags (defun notmuch-search-archive-thread () -- 1.6.5.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Return unpropertized strings for filename and message-id
On Mon, 23 Nov 2009 17:57:31 +0100, Tassilo Horn tass...@member.fsf.org wrote: Hi! Here's my first patch. It changes that notmuch-show-get-filename and notmuch-show-get-message-id return simple strings and not propertited strings. Thanks, Tassilo! It's great to have a contribution from you in notmuch. I've pushed this out now. Two things with regards to your patch: 1. It's most convenient (for me) to apply emailed patches by sending directly to git am. And git am just happens to want to see the complete commit message as the first thing in the mail message, (continuing the summary of the commit which comes from the subject). So to satisfy git am, introductory and explanatory portions of the email, (Hi! and Here's my first patch), have to be relegated to past the --- divider). I actually don't love this about git am, since I think those introductory parts are essential to having cordial and friendly exchanges on the mailing list, (rather than just dryly shooting code back and forth). And it feels natural to have them first. One thing that might be interesting is to teach git am about an additional divider so that other text can came *before* the commit message. Alternately, one can put introductory text in one message, and the dry commit-only stuff as a reply. 2. Maybe I'll undermine my point above, but the commit here really *does* need a commit message beyond the first line. I've described this before as the one-line summary giving the what and the rest of the commit message giving the why. And this is a perfect case of that. I can see exactly what the patch does, and it makes sense. But I tried to write the rest of the commit message and found I couldn't. In what cases did the presence of text properties cause a problem? I don't know, and that's what the commit message should have said. I'd said before that I would bounce patches with only a one-line summary. I guess I'm still too soft, but do expect me to be more strict on this in the future. :-) -Carl ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
