Re: bug#56442: gnus-search-run-search: Hits notmuch command line length limits
Sean Whitton writes:
> Hello,
>
> I'm running a pretty innocent notmuch query over a fairly small Maildir:
>
> "((List:debian-devel.lists.debian.org) or ... or
> (List:debian-haskell.lists.debian.org) or
> (List:debconf-discuss.lists.debian.org)) and (not path:annex/**)"
>
> but gnus-search-run-search fails to return any results. The reason is
> that Gnus first runs the query with --output=threads to obtain a list of
> thread ids, and then runs another query with --output=files and a query
> constructed from the output of the first query: "thread:d9d0
> or thread:d9e0 or thread:d268 or ..."
>
> The resulting command fails completely:
>
> emacs: /usr/bin/notmuch: Argument list too long
>
> Instead of running two searches like this, we can just surround the
> whole query like this: "thread:{QUERY}". The manual says it's exactly
> equivalent:
>
> ... the user should think of the query thread:{} as
> expanding to all of the thread IDs which match ; not‐
> much then performs a second search using the expanded query.
>
> This should be faster, too, with only running a single external command.
> Here is the patch I'm thinking I'll apply, if anyone has comments.
Huh, I tried this a couple months ago with a more complicated query,
like:
thread:{from:bob or from:jane}
and I remember notmuch barking at me about spaces or the "or" or
something -- anyway I got the impression that it couldn't accept
multi-part queries inside the "thread:{}" syntax. But looking at your
patch maybe I just needed to quote differently?
Anyway I'll give this a test this weekend. It would be *very* nice if we
could use this syntax rather than the ugly home-grown one.
Thanks for the report!
Eric
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[O] how to put into a journal info about the email sent
David Edmondson writes: > On Fri, Oct 24 2014, Eric Abrahamsen wrote: >> David Belohrad writes: >> >>> Dear All, >>> >>> i'm using org. And I'm using notmuch (that's why I address both mailing >>> lists). Now, writing an email in everyday bussiness requires a >>> non-significant time of your workhours. So I'd like to have this event >>> in my org agenda. So any time I send some email with a given subject, >>> I'd like to 'automatically' entry the information about it into >>> e.g. sentmails.org in form of a diary entry, with appropriate tag. >> >> I do something like this in Gnorb, which I'd recommend you use except >> it's mostly Gnus specific. >> >> I do it in two parts, but you could do it in one. Basically I add a >> function to the `message-header-hook' (which ensures that all the >> message headers have been generated properly). > > Does `message-generate-headers-first' not do what you want for this > specific part? Yeah, I think I looked at that previously. But this thing is going in a hook anyway, might as well use the hook that *doesn't* require me to call that function explicitly. >> Obviously the downside is that, without a "Gcc:" header, org can't >> actually make a real link to the message. It doesn't know where it's >> going to be. However if you know that all your sent messages can be >> reached with a link that looks like "notmuch:id#Message-id", then you >> can make that yourself in your org capture template with something like > > As you suggest, know the message-id should be good enough to generate a > notmuch link, though you may have to wait for the notmuch index to be > updated for the link to be valid. Yup, I've got the same issue with nnimap -- you have to wait for the next sync to get access to the message. So far it hasn't been a problem, though.
Re: [O] how to put into a journal info about the email sent
David Edmondson writes: > On Fri, Oct 24 2014, Eric Abrahamsen wrote: >> David Belohrad writes: >> >>> Dear All, >>> >>> i'm using org. And I'm using notmuch (that's why I address both mailing >>> lists). Now, writing an email in everyday bussiness requires a >>> non-significant time of your workhours. So I'd like to have this event >>> in my org agenda. So any time I send some email with a given subject, >>> I'd like to 'automatically' entry the information about it into >>> e.g. sentmails.org in form of a diary entry, with appropriate tag. >> >> I do something like this in Gnorb, which I'd recommend you use except >> it's mostly Gnus specific. >> >> I do it in two parts, but you could do it in one. Basically I add a >> function to the `message-header-hook' (which ensures that all the >> message headers have been generated properly). > > Does `message-generate-headers-first' not do what you want for this > specific part? Yeah, I think I looked at that previously. But this thing is going in a hook anyway, might as well use the hook that *doesn't* require me to call that function explicitly. >> Obviously the downside is that, without a "Gcc:" header, org can't >> actually make a real link to the message. It doesn't know where it's >> going to be. However if you know that all your sent messages can be >> reached with a link that looks like "notmuch:id#Message-id", then you >> can make that yourself in your org capture template with something like > > As you suggest, know the message-id should be good enough to generate a > notmuch link, though you may have to wait for the notmuch index to be > updated for the link to be valid. Yup, I've got the same issue with nnimap -- you have to wait for the next sync to get access to the message. So far it hasn't been a problem, though. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
encoding when forwarding messages
David Bremner writes: > Eric Abrahamsen writes: > >> I saw another message about the same problem on this list, in January, >> with the advice to upgrade to git, but I'm still seeing it on notmuch >> 0.16+7~gdc51bf0. Forwarding a message from within emacs using >> `notmuch-mua-forward-message' sometimes produces garbled encoding. >> Calling `notmuch-show-forward-message' on the same message, however, >> creates what appears to be a raw message, properly encoded. >> >> Is there something still amiss in the code? Am I using the wrong >> command? > > Do you really mean notmuch-mua-forward-message? That function is not > interactive, which would make it more work to call. > > In any case, notmuch-show-forward-message does take some care to read > the message in raw mode (via with-current-notmuch-show-message); when > you call notmuch-mua*forward-message, how are you filling the buffer? > > d Sorry! It was `notmuch-mua-new-forward-message' I've been using, apologies for the confusion. I'm not calling any particular filling commands. I've got this in .gnus.el: (add-hook 'message-mode-hook (lambda () (flyspell-mode) (orgstruct-mode))) And I've got the auto-fill minor mode enabled. I don't see any other minor modes that seem likely to interfere... Thanks! Eric
encoding when forwarding messages
I saw another message about the same problem on this list, in January, with the advice to upgrade to git, but I'm still seeing it on notmuch 0.16+7~gdc51bf0. Forwarding a message from within emacs using `notmuch-mua-forward-message' sometimes produces garbled encoding. Calling `notmuch-show-forward-message' on the same message, however, creates what appears to be a raw message, properly encoded. Is there something still amiss in the code? Am I using the wrong command? Thanks! Eric
Re: encoding when forwarding messages
David Bremner writes: > Eric Abrahamsen writes: > >> I saw another message about the same problem on this list, in January, >> with the advice to upgrade to git, but I'm still seeing it on notmuch >> 0.16+7~gdc51bf0. Forwarding a message from within emacs using >> `notmuch-mua-forward-message' sometimes produces garbled encoding. >> Calling `notmuch-show-forward-message' on the same message, however, >> creates what appears to be a raw message, properly encoded. >> >> Is there something still amiss in the code? Am I using the wrong >> command? > > Do you really mean notmuch-mua-forward-message? That function is not > interactive, which would make it more work to call. > > In any case, notmuch-show-forward-message does take some care to read > the message in raw mode (via with-current-notmuch-show-message); when > you call notmuch-mua*forward-message, how are you filling the buffer? > > d Sorry! It was `notmuch-mua-new-forward-message' I've been using, apologies for the confusion. I'm not calling any particular filling commands. I've got this in .gnus.el: (add-hook 'message-mode-hook (lambda () (flyspell-mode) (orgstruct-mode))) And I've got the auto-fill minor mode enabled. I don't see any other minor modes that seem likely to interfere... Thanks! Eric ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
encoding when forwarding messages
I saw another message about the same problem on this list, in January, with the advice to upgrade to git, but I'm still seeing it on notmuch 0.16+7~gdc51bf0. Forwarding a message from within emacs using `notmuch-mua-forward-message' sometimes produces garbled encoding. Calling `notmuch-show-forward-message' on the same message, however, creates what appears to be a raw message, properly encoded. Is there something still amiss in the code? Am I using the wrong command? Thanks! Eric ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
UTF-8 in mail headers (namely FROM) sent by bugzilla
Franz Fellner writes: > On Dienstag, 23. Juli 2013 11:30:28 CEST, Eric Abrahamsen wrote: >>> I have a problem with notmuch-vim (now: git master from 10 min. ago) >>> (also with alot and ner, not with 'notmuch show' or notmuch-emacs). >>> UTF-8-encoded From: (at least) does not show Umlauts but a weird >>> encoded-string. ... >> >> Looks like rfc 2047, which is a way of encoding non-ASCII characters in >> message headers. Gmail does the same thing, and I've had to work around >> that in emacs/gnus. >> >> http://www.ietf.org/rfc/rfc2047.txt > > OK, thx. So every app needs to get patched to display those strings properly? > Any chance this could be done directly in libnotmuch? > I grepped for "2047" inside te "emacs" subtree, but found nothing (had > the hope for a comment for the workaround). Would be interesting to > see how this is done, so I can at least try to create a patch (though > my ruby is quite basic). The version of gnus I'm using (git) comes with a rfc2047.el file, with all the appropriate functions. That might be of interest, even if the solution ends up being in the basic library... http://git.gnus.org/cgit/gnus.git/tree/lisp/rfc2047.el
UTF-8 in mail headers (namely FROM) sent by bugzilla
Franz Fellner writes: > Hi, > > I have a problem with notmuch-vim (now: git master from 10 min. ago) > (also with alot and ner, not with 'notmuch show' or notmuch-emacs). > UTF-8-encoded From: (at least) does not show Umlauts but a weird > encoded-string. > Example: > "Thomas L?bking" as one of the KWin devs comes in replies as > =?UTF-8?Q?Thomas=20L=C3=BCbking=20?= > In private conversations with Thomas everything is fine, so it seems to > depend on the way bugzilla encodes the "From:". > Subject is absolutely fine, btw. Looks like rfc 2047, which is a way of encoding non-ASCII characters in message headers. Gmail does the same thing, and I've had to work around that in emacs/gnus. http://www.ietf.org/rfc/rfc2047.txt
