[PATCH] NEWS: initial set of NEWS for 0.37.
There are one or two more changes to apply (and potentially document) before release, but this covers most of my commits. --- NEWS | 35 +++ 1 file changed, 35 insertions(+) diff --git a/NEWS b/NEWS index 44551b82..1e0b6a6c 100644 --- a/NEWS +++ b/NEWS @@ -1,12 +1,47 @@ Notmuch 0.37 (UNRELEASED) = +Library +--- + +Fix uninitialized field in message objects. + +Improve exception handling and error propagation for message objects. + +Sexp Queries + + +Add one sided lastmod ranges for sexp queries. + +Expand macro parameters inside regex and wildcard modifiers. + +Command Line Interface +-- + +`notmuch help` now works for external commands. + +`NOTMUCH_CONFIG` is now passed to external commands and hooks. + +Promote the development tool `nmbug` to a user facing tool +`notmuch-git`. See notmuch-git(1) for details. + Emacs - The function `notmuch-mua-mail` now moves point depending on the provided arguments. +Restrict what mime types are inlined in replies and on refresh. + +The functions in notmuch-query.el are now obsolete and may be removed +in a future version of Notmuch. + +Add some controls for lazy display of message bodies (See "Dealing +with large messages and threads" in the notmuch-emacs documentation). + +Allow the user to select (with '%') a different duplicate message file +to display. + Notmuch 0.36 (2022-04-25) = -- 2.35.2 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 2/2] emacs/show: restrict inlined mimetypes on refresh.
This fixes the bug reported by Al [1]. Essentially apply the same fix as [2] in a different place. [1]: id:877d41nmr1@gmail.com [2]: 90a7c1af368a527700dcde9b0dcbd760afc7bd92 --- emacs/notmuch-show.el | 1 + test/T450-emacs-show.sh | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 1bc3b319..c072e81d 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1528,6 +1528,7 @@ non-nil) then the state of the buffer (open/closed messages) is reset based on the original query." (interactive "P") (let ((inhibit-read-only t) + (mm-inline-override-types (notmuch--inline-override-types)) (state (unless reset-state (notmuch-show-capture-state ;; `erase-buffer' does not seem to remove overlays, which can lead diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh index b77f8c0e..e161ee4f 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -339,7 +339,6 @@ EOF test_expect_equal_file EXPECTED OUTPUT test_begin_subtest "tar not inlined by default on refresh" -test_subtest_known_broken test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") (notmuch-show-refresh-view) (test-visible-output "OUTPUT")' -- 2.35.2 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 1/2] test/emacs: add known broken test for inlining on refresh.
This duplicates the bug reported by Al [1] [1]: id:877d41nmr1@gmail.com --- test/T450-emacs-show.sh | 22 ++ 1 file changed, 22 insertions(+) diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh index 37940c96..b77f8c0e 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -338,6 +338,28 @@ when we detect the word "attachment" and there's no attach? :p EOF test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest "tar not inlined by default on refresh" +test_subtest_known_broken +test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") + (notmuch-show-refresh-view) + (test-visible-output "OUTPUT")' +cat < EXPECTED +Antoine Beaupré (2018-03-19) (attachment inbox) +Subject: Re: bug: "no top level messages" crash on Zen email loops +To: David Bremner , notmuch@notmuchmail.org +Date: Mon, 19 Mar 2018 13:56:54 -0400 + +[ multipart/mixed ] +[ text/plain ] +And obviously I forget the frigging attachment. +[ zendesk-email-loop2.tgz: application/x-gtar-compressed ] +[ text/plain ] + +PS: don't we have a "you forgot to actually attach the damn file" plugin +when we detect the word "attachment" and there's no attach? :p +EOF +test_expect_equal_file EXPECTED OUTPUT + add_email_corpus duplicate ID3=87r2ecrr6x@zephyr.silentflame.com -- 2.35.2 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: lastmod based on date/time
Al Haji-Ali writes: > Would it be possible to search for lastmod messages based on time > rather than revision ID? Using revision ID is convenient for > tools/scripts, but not for actual everyday use. > The modification time is not saved in the database. > I sometimes find myself needing to find a message that I accidentally > archived/moved and it would be convenient if I can list all the > messages that I modified (tag or otherwise) in the past day for > example. I currently use the current value of revision ID minus a few > hundreds as a proxy for time. A workaround could be to run a cron job or equivalent that logs (lastmod,timestamp) pairs to a file. Of course that would make using the information a bit inconvenient without further tooling. Because of concerns about performance, we have so far resisted having a "tagging hook". 'lastmod:' was added at some point because it addressed some of the usecases for a tagging hook. At the time (2014) we chose the counter approach over timestamps because of the difficulty of synchronizing clocks between machines and the possibility of clock changes on a given machine [1]. In principle modification timestamps could be added as additional data for each message. I'm not sure about the cost/benefit here (either for implementation or performance) but if someone wants to investigate further I can point them in the right direction (mostly, copy the lastmod stuff). [1]: I think most of the discussion is in the thread https://nmbug.notmuchmail.org/nmweb/show/1396800683-9164-1-git-send-email-eg%40gaute.vetsj.com ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
lastmod based on date/time
Would it be possible to search for lastmod messages based on time rather than revision ID? Using revision ID is convenient for tools/scripts, but not for actual everyday use. I sometimes find myself needing to find a message that I accidentally archived/moved and it would be convenient if I can list all the messages that I modified (tag or otherwise) in the past day for example. I currently use the current value of revision ID minus a few hundreds as a proxy for time. If there's no way of doing this currently, is the time of modification saved in the database but is inaccessible through the current interface? Best regards, -- Al ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Sending mail succeeded but signaled failure
Dan Čermák writes: > Justus Winter writes: > >> David Bremner writes: >> >>> Justus Winter writes: >>> Hello, I just embarrassed myself a little by sending the same mail over and over again. The reason for that is that notmuch-emacs signaled failure, i.e. it displayed an error message in the status buffer and didn't close the compose buffer, yet it did in fact send the mail. I suspect that my configuration has to do with that and someone is trying to be helpful. So I use msmtp with the authentication password encrypted using OpenPGP. Then, I use 'gpg --no-tty -q -d ...' as msmtp's passwordeval function. Now, my OpenPGP key has expired, but that doesn't stop GnuPG from decrypting the secret, and in fact it returns the status code 0. It also prints gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST to stderr, which is picked up by notmuch-emacs, it says sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST in the status buffer while the compose buffer stays open. I suspect that this is not notmuch's fault, but I don't know where else to turn to with this bug report. >>> >>> I guess the first step is to see if you can duplicate the problem with >>> plain M-x message-mode. The mechanics of sending should be identical in >>> notmuch-message-mode unless (surprise!) I misremember something. >> >> It does indeed happen with the plain message mode. And I think I have >> identified the code in emacs that turns any output, stdout and stderr, >> into errors: >> >> % cat -n emacs/lisp/mail/sendmail.el >> [...] >> 1343(exit-value (apply #'call-process-region >> args))) >> 1344 (cond ((or (null exit-value) (eq 0 exit-value))) >> 1345 ((numberp exit-value) >> 1346 (setq error t) >> 1347 (error "Sending...failed with exit value >> %d" exit-value)) >> 1348 ((stringp exit-value) >> 1349 (setq error t) >> 1350 (error "Sending...terminated by signal: >> %s" exit-value)) >> 1351 (t >> 1352 (setq error t) >> 1353 (error "SENDMAIL-SEND-IT -- fall >> through: %S" exit-value >> 1354 (or fcc-was-found >> 1355 (error "No recipients"))) >> 1356 (if mail-interactive >> 1357 (with-current-buffer errbuf >> 1358 (goto-char (point-min)) >> 1359 (while (re-search-forward "\n\n* *" nil t) >> 1360 (replace-match "; ")) >> 1361 (unless (zerop (buffer-size)) >> 1362 (setq error t) >> 1363 (error "Sending...failed to %s" >> 1364(buffer-substring (point-min) >> (point-max))) >> >> Apparently, that behavior goes back to the initial checkin of that >> file. I refuse to believe that Dan and me are the only ones having >> problems with that in 30 years... I'll report it upstream. > > Can you paste the upstream bug number here as well please? Sure thing: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56855 Best, Justus ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Sending mail succeeded but signaled failure
Justus Winter writes: > David Bremner writes: > >> Justus Winter writes: >> >>> Hello, >>> >>> I just embarrassed myself a little by sending the same mail over and >>> over again. The reason for that is that notmuch-emacs signaled failure, >>> i.e. it displayed an error message in the status buffer and didn't close >>> the compose buffer, yet it did in fact send the mail. >>> >>> I suspect that my configuration has to do with that and someone is >>> trying to be helpful. So I use msmtp with the authentication password >>> encrypted using OpenPGP. Then, I use 'gpg --no-tty -q -d ...' as >>> msmtp's passwordeval function. Now, my OpenPGP key has expired, but >>> that doesn't stop GnuPG from decrypting the secret, and in fact it >>> returns the status code 0. It also prints >>> >>> gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 >>> 05:31:26 PM CEST >>> >>> to stderr, which is picked up by notmuch-emacs, it says >>> >>> sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon >>> 25 Jul 2022 05:31:26 PM CEST >>> >>> in the status buffer while the compose buffer stays open. >>> >>> I suspect that this is not notmuch's fault, but I don't know where else >>> to turn to with this bug report. >> >> I guess the first step is to see if you can duplicate the problem with >> plain M-x message-mode. The mechanics of sending should be identical in >> notmuch-message-mode unless (surprise!) I misremember something. > > It does indeed happen with the plain message mode. And I think I have > identified the code in emacs that turns any output, stdout and stderr, > into errors: > > % cat -n emacs/lisp/mail/sendmail.el > [...] > 1343 (exit-value (apply #'call-process-region > args))) > 1344(cond ((or (null exit-value) (eq 0 exit-value))) > 1345 ((numberp exit-value) > 1346 (setq error t) > 1347 (error "Sending...failed with exit value > %d" exit-value)) > 1348 ((stringp exit-value) > 1349 (setq error t) > 1350 (error "Sending...terminated by signal: > %s" exit-value)) > 1351 (t > 1352 (setq error t) > 1353 (error "SENDMAIL-SEND-IT -- fall > through: %S" exit-value > 1354(or fcc-was-found > 1355(error "No recipients"))) > 1356 (if mail-interactive > 1357 (with-current-buffer errbuf > 1358(goto-char (point-min)) > 1359(while (re-search-forward "\n\n* *" nil t) > 1360 (replace-match "; ")) > 1361(unless (zerop (buffer-size)) > 1362 (setq error t) > 1363 (error "Sending...failed to %s" > 1364 (buffer-substring (point-min) > (point-max))) > > Apparently, that behavior goes back to the initial checkin of that > file. I refuse to believe that Dan and me are the only ones having > problems with that in 30 years... I'll report it upstream. Can you paste the upstream bug number here as well please? Thanks, Dan ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
