Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
On Tuesday, 2019-11-26 at 16:25:29 -07, Sean Whitton wrote:
> On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote:
>
>> The poor behaviour is just a side effect of the way that queries are
>> composed to implement the filter functionality. Does the attached patch
>> help?
>
> Unfortunately, it is still broken in my test case.
Could you describe your test case please? (We could remove emacs-orgmode
for that conversation if you think it appropriate.)
>>> Further, my package 'mailscripts' tries to pass the current value of
>>> `notmuch-show-thread-id' to notmuch-extract-patch(1).
>>>
>>> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72
>>>
>>> https://manpages.debian.org/notmuch-extract-patch
>>>
>>> If `notmuch-show-thread-id' contains a query which returns a single
>>> message, the wrong value is passed to notmuch-extract-patch(1), such
>>> that it may not extract all of the patches in the thread.
>>
>> It's not clear to me that this is broken.
>>
>> notmuch-extract-patch seems to be properly extracting patches from the
>> messages that match the query.
>>
>> If the current `notmuch-show' buffer query doesn't match the entire
>> thread, why should `notmuch-extract-thread-patches' be expected to apply
>> patches from the whole thread?
>
> The purpose of `notmuch-extract-thread-patches' is to extract a whole
> git-send-email(1) patch series at a time, because that is usually what
> one wants to do. There are `notmuch-extract-message-patches' and
> `notmuch-show-pipe-message' for single patches.
Then I think the approach that you have (wrapping the query in
thread:{}) makes perfect sense.
> (I note that this is a mailscripts design question, not strictly
> relevant to the issue of ol-notmuch.el causing the
> notmuch-show-thread-id variable to be mispopulated. Thank you for your
> engagement with mailscripts, regardless!)
Well, I'm interested in the functionality that it provides :-)
Presumably this all arises because thread IDs are neither stable nor
portable, so they are inappropriate to store in an external document (as
an org-mode link in this case)?
dme.
--
Hello? Is anybody home? Well, you don't know me, but I know you.
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
On Tuesday, 2019-11-26 at 14:57:28 -07, Sean Whitton wrote:
> On Tue 26 Nov 2019 at 08:05PM +00, David Edmondson wrote:
>
>> Could you explain how you were using `notmuch-show-thread-id' in a way
>> that was broken by the presence of an arbitrary query?
>
> I've observed that the standard notmuch command
> `notmuch-show-filter-thread' doesn't work in a buffer opened by
> `org-notmuch-follow-link'.
The poor behaviour is just a side effect of the way that queries are
composed to implement the filter functionality. Does the attached patch
help?
> Further, my package 'mailscripts' tries to pass the current value of
> `notmuch-show-thread-id' to notmuch-extract-patch(1).
>
> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72
>
> https://manpages.debian.org/notmuch-extract-patch
>
> If `notmuch-show-thread-id' contains a query which returns a single
> message, the wrong value is passed to notmuch-extract-patch(1), such
> that it may not extract all of the patches in the thread.
It's not clear to me that this is broken.
notmuch-extract-patch seems to be properly extracting patches from the
messages that match the query.
If the current `notmuch-show' buffer query doesn't match the entire
thread, why should `notmuch-extract-thread-patches' be expected to apply
patches from the whole thread?
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e13ca3d7..ecbc03d2 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1311,7 +1311,7 @@ and THREAD. The next query is THREAD alone, and serves as a
fallback if the prior matches no messages."
(let (queries)
(push (list thread) queries)
-(if context (push (list thread "and (" context ")") queries))
+(if context (push (list "(" thread ") and (" context ")") queries))
queries))
(defun notmuch-show--build-buffer ( state)
dme.
--
I can't explain, you would not understand. This is not how I am.
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
On Thursday, 2019-11-21 at 14:37:44 -07, Sean Whitton wrote:
> The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls
> `notmuch-show' with an arbitrary notmuch search query. However, the
> docstring for `notmuch-show' specifies that a notmuch thread ID, rather
> than an arbitrary notmuch query, should be supplied to `notmuch-show'.
>
> The effect of this is that the variable `notmuch-show-thread-id' may
> contain an arbitrary search query rather than a thread ID. That broke
> some code of mine which uses that variable.
Could you explain how you were using `notmuch-show-thread-id' in a way
that was broken by the presence of an arbitrary query?
(Not arguing right or wrong, just trying to understand the problem.)
> `org-notmuch-follow-link' needs to continue to accept an arbitrary query
> (as notmuch thread IDs are not stable), but it should convert it to a
> thread ID before passing it to `notmuch-show'.
dme.
--
I'd rather be with you than flying through space.
Re: [O] how to put into a journal info about the email sent
On Wed, Oct 29 2014, David Belohrad wrote: - 'standard' behaviour is, that the email sent becomes read-only so with 'q' keystroke I can bury the buffer with the email. However when I have implemented this, I have noticed that when I 'confirm' the template, I go back into the buffer 'sent mail to...', but this the *THE BUFFER IS NOT READ ONLY* and 'q' will just generate a character, and then I have to kill this buffer using C-x k with additional 'yes' because the buffer was modified. Quite annoying and I don't know how to resolve this I'm unsure about this. The change below may fix it accidentally. - second thing is, that I'd like to avoid at all opening the capture template and just dump it into the file without any modifications ongoing. The only 'modification' which comes into my mind is a setup of an additional tag describing the email being attached to some project... Change the template to... (@ Email outgoing sync. USED INTERNALLY entry (file+datetree (concat my-org-files emails_sent.org)) * EMAIL %c :EMAIL:\n%?\nEntered on %T\n :immediate-finish t) (i.e. add :immediate-finish t) ...and you will never see the capture buffer for this entry.
Re: [O] how to put into a journal info about the email sent
On Fri, Oct 24 2014, Eric Abrahamsen wrote: David Belohrad da...@belohrad.ch 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? 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.
Re: [O] Agenda Bulk Scatter bug
* carsten.domi...@gmail.com [2011-06-10 Fri 09:20] Hi, I need a few testers: Something very strange is going on here. When I evaluate this form (decode-time (days-to-time (time-to-days (current-time I get a date in the year 3980. I think this used to work. Is there anyone who has an idea what is going on here? (decode-time (days-to-time (time-to-days (current-time = (0 0 1 10 6 3980 2 t 3600) With GNU Emacs 24.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2011-02-10 on keller, modified by Debian. (time-to-days) returns the number of days since 0001-12-31bce, which (days-to-time) converts into a time value. That time value is relative to 0001-12-31bce, _not_ relative to 1970-01-01, which is what (decode-time) is expecting. Hence you end up 1970 years out.
