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 (&optional 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 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.
