Re: Editing the raw mail file?
Morten Kjeldgaard writes: > I would love to have just one function that carries out both tasks, > opening the file in a temporary buffer, and after you finish with C-c > C-c, it automatically does the reindexing for you. Unfortunately it's > above my current Elisp skills to write this. > Maybe something like the re-edit draft as new interface (e), although allowing arbitrary edits is a bit of a footgun, so we'd probably want to make people confirm "are you sure, this could destroy your message" or similar. I'm too far behind to do this myself, but I'll (eventually) look at patches if someone wants to work something up. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Editing the raw mail file?
David Bremner wrote: > you can use "c F" to copy the file name of the current message into the > the kill ring, then just yank wherever useful (e.g. to visit the file in > emacs). > > After editing you will need to reindex that file. One way would be > to use "c i" to copy the message id into the kill ring, then yank it > into a shell command like > > notmuch reindex id: > > If that seems to do what you want, then the steps can be automated > within emacs. It works! But as you suggested I made two functions to make it easier, I enclose them below in case others could benefit. One function opens the mbox file in an edit buffer, the other runs the reindexing, both need to be run in the context of the message. I would love to have just one function that carries out both tasks, opening the file in a temporary buffer, and after you finish with C-c C-c, it automatically does the reindexing for you. Unfortunately it's above my current Elisp skills to write this. Thanks for your help! Cheers, Morten ---8<- snip --- (defun mok/notmuch-edit-raw-mail () "Within the context of a mail message, open the raw mbox file in a buffer." (interactive) (let ((mbox-file-name (notmuch-show-get-filename))) (message "edit %s" mbox-file-name) (find-file mbox-file-name))) (defun mok/notmuch-reindex-id () "Within the context of a mail message, reindex the message to update header information" (interactive) (let ((id (notmuch-show-get-message-id))) (message "reindex %s" id) (notmuch--call-process notmuch-command nil t nil "reindex" id))) ---8<- snip --- ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Editing the raw mail file?
Morten Kjeldgaard writes: > > It's tedious to use the notmuch CLI client to search for the mail and > then copy/paste the filename, and edit it to correct the date. It would > be so much easier if it were possible to edit the raw file directly in > Emacs. I can use 'V' to view the raw file, and then 'E' to be allowed to > edit it, but Emacs has no idea of what file it is editing. > > Is there a way to solve this problem? Notmuch of course already knows > the original filename. you can use "c F" to copy the file name of the current message into the the kill ring, then just yank wherever useful (e.g. to visit the file in emacs). After editing you will need to reindex that file. One way would be to use "c i" to copy the message id into the kill ring, then yank it into a shell command like notmuch reindex id: If that seems to do what you want, then the steps can be automated within emacs. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Editing the raw mail file?
Hi, I have ported all om my mail since 1991 into notmuch and I am thrilled that I can now organize and easily see everything I have been doing for the last 30+ years. However, some of the mail messages have wrong information in the RFC822 header, probably because of bad mail delivery agents that were used at the time. Especially, I have a whole bunch of mails that are assigned the date 1970-01-01, and when I look in the file itself, it turns out it has the year 100, which of course was year 2000. Other messages have a faulty Content-Type: text header, which means the content is wrapped in [ application/octet-stream ] which is annoying because the message isn't immediately visible. It's tedious to use the notmuch CLI client to search for the mail and then copy/paste the filename, and edit it to correct the date. It would be so much easier if it were possible to edit the raw file directly in Emacs. I can use 'V' to view the raw file, and then 'E' to be allowed to edit it, but Emacs has no idea of what file it is editing. Is there a way to solve this problem? Notmuch of course already knows the original filename. Cheers, Morten ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] config: allow custom separators in author lists
Sorry, I dropped the ball on this -- here's the patch again with space/tab
inconsistencies fixed. I wasn't entirely sure about this as it's inconsistent
in the existing source, so I tried to make it as consistent as possible. Cover
included again below.
The attached patch allows to customize the default ", " and "| " separators in
author lists. The main rationale for supporting this is that the Python API
uses the same functionality to get the list of authors -- if I want to separate
them again afterwards, I have to split the returned string, which is
error-prone with comma separators (e.g. name in email address is of form
Lastname, Firstname).
Thanks,
Lars
From 60aab0c8a9a8164abb32ea306b7fd894a18a2477 Mon Sep 17 00:00:00 2001
From: Lars Kotthoff
Date: Fri, 22 Dec 2023 14:06:34 -0700
Subject: [PATCH] config: allow custom separators in author lists
---
NEWS| 11 +++
doc/man1/notmuch-config.rst | 13 +
lib/config.cc | 8
lib/notmuch.h | 2 ++
lib/thread.cc | 19 ++-
test/T030-config.sh | 2 ++
test/T055-path-config.sh| 4
test/T590-libconfig.sh | 10 ++
8 files changed, 64 insertions(+), 5 deletions(-)
diff --git a/NEWS b/NEWS
index 315f4136..b306d095 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+Notmuch 0.39 (UNRELEASED)
+=
+
+General
+---
+
+Allow to customize the separator between individual and matched and non-matched
+authors when showing threads. See `search.authors_separator` and
+`search.authors_matched_separator` in notmuch-config(1).
+
+
Notmuch 0.38.2 (2023-12-01)
===
diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
index bd34afa4..5106655f 100644
--- a/doc/man1/notmuch-config.rst
+++ b/doc/man1/notmuch-config.rst
@@ -273,6 +273,19 @@ paths are presumed relative to `$HOME` for items in section
Default: empty list. Note that :any:`notmuch-setup(1)` puts
``deleted;spam`` here when creating new configuration file.
+.. nmconfig:: search.authors_separator
+
+The string to separate authors when showing a thread.
+
+Default: ,
+
+.. nmconfig:: search.authors_matched_separator
+
+The string to separate matched from non-matched authors when showing a
+thread.
+
+Default: |
+
.. nmconfig:: show.extra_headers
By default :any:`notmuch-show(1)` includes the following headers
diff --git a/lib/config.cc b/lib/config.cc
index 6cd15fab..a3102dce 100644
--- a/lib/config.cc
+++ b/lib/config.cc
@@ -608,6 +608,10 @@ _notmuch_config_key_to_string (notmuch_config_key_t key)
return "database.autocommit";
case NOTMUCH_CONFIG_EXTRA_HEADERS:
return "show.extra_headers";
+case NOTMUCH_CONFIG_AUTHORS_SEPARATOR:
+ return "search.authors_separator";
+case NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR:
+ return "search.authors_matched_separator";
case NOTMUCH_CONFIG_INDEX_AS_TEXT:
return "index.as_text";
default:
@@ -658,6 +662,10 @@ _notmuch_config_default (notmuch_database_t *notmuch, notmuch_config_key_t key)
return "";
case NOTMUCH_CONFIG_AUTOCOMMIT:
return "8000";
+case NOTMUCH_CONFIG_AUTHORS_SEPARATOR:
+ return ", ";
+case NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR:
+ return "| ";
case NOTMUCH_CONFIG_EXTRA_HEADERS:
case NOTMUCH_CONFIG_HOOK_DIR:
case NOTMUCH_CONFIG_BACKUP_DIR:
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 4e2b0fa4..937fa24e 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -2565,6 +2565,8 @@ typedef enum {
NOTMUCH_CONFIG_AUTOCOMMIT,
NOTMUCH_CONFIG_EXTRA_HEADERS,
NOTMUCH_CONFIG_INDEX_AS_TEXT,
+NOTMUCH_CONFIG_AUTHORS_SEPARATOR,
+NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR,
NOTMUCH_CONFIG_LAST
} notmuch_config_key_t;
diff --git a/lib/thread.cc b/lib/thread.cc
index 60e9a666..8d70b489 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -122,21 +122,28 @@ _thread_add_matched_author (notmuch_thread_t *thread,
/* Construct an authors string from matched_authors_array and
* authors_array. The string contains matched authors first, then
- * non-matched authors (with the two groups separated by '|'). Within
- * each group, authors are listed in date order. */
+ * non-matched authors (with the two groups separated by '|' or the custom
+ * separator defined in the configuration). Within each group, authors are
+ * listed in date order and separated by ',' or the custom separator defined in
+ * the configuration. */
static void
_resolve_thread_authors_string (notmuch_thread_t *thread)
{
unsigned int i;
char *author;
int first_non_matched_author = 1;
+const char *authors_sep = notmuch_config_get (thread->notmuch,
+ NOTMUCH_CONFIG_AUTHORS_SEPARATOR);
+const char *authors_matched_sep = notmuch_config_get (thread->notmuch,
+ NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR);
/* First, list all
Re: Error when running notmuch new
Aidan Jones writes: >> >> This is the only line that caught my eye. >> >> Can you try >> >> $ notmuch config set maildir.synchronize_flags true > > That did it. Thanks for the help! Glad to hear it. We should try to provide a more informative error message here. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Error when running notmuch new
Sent with Proton Mail secure email. On Thursday, June 27th, 2024 at 10:39 AM, David Bremner wrote: > Aidan Jones arjones...@protonmail.ch writes: > > > > > maildir.synchronize_flags=sync > > > This is the only line that caught my eye. > > Can you try > > $ notmuch config set maildir.synchronize_flags true That did it. Thanks for the help! ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Error when running notmuch new
Aidan Jones writes: > maildir.synchronize_flags=sync This is the only line that caught my eye. Can you try $ notmuch config set maildir.synchronize_flags true ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Error when running notmuch new
Sent with Proton Mail secure email. On Wednesday, June 26th, 2024 at 3:44 PM, David Bremner wrote: > Aidan Jones arjones...@protonmail.ch writes: > > > I am new to notmuch, so I apologize if this is just an operator > > error. I have a local maildir created using offlineimap. I have ran > > notmuch setup and configured notmuch to use the maildir as its > > archive. However, running notmuch new returns 'notmuch new: Illegal > > argument for function' Any ideas what I am doing wrong? > > > Can you share your configuration? It sounds like it might be a bad > regex. > > d I don't see any regex in the output of 'notmuch config list', which is attached as a file. The only configuring I've done is through the 'notmuch setup' command. Thanks, Aidanbuilt_with.compact=true built_with.field_processor=true built_with.retry_lock=true built_with.sexp_queries=false database.autocommit=8000 database.backup_dir=/home/user/.mail/protonmail/.notmuch/backups database.hook_dir=/home/user/.mail/protonmail/.notmuch/hooks database.mail_root=/home/user/.mail/protonmail database.path=/home/user/.mail/protonmail index.as_text= maildir.synchronize_flags=sync new.ignore= new.tags=inbox;unread; search.exclude_tags=ignore user.name=Aidan Jones user.primary_email=arjones...@protonmail.ch ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Error when running notmuch new
Aidan Jones writes: > I am new to notmuch, so I apologize if this is just an operator > error. I have a local maildir created using offlineimap. I have ran > notmuch setup and configured notmuch to use the maildir as its > archive. However, running notmuch new returns 'notmuch new: Illegal > argument for function' Any ideas what I am doing wrong? Can you share your configuration? It sounds like it might be a bad regex. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Fwd: [PATCH] Fix saved-search buffer titles
Ping. Start of forwarded message From: Rudolf Adamkovič To: notmuch@notmuchmail.org Subject: [PATCH] Fix saved-search buffer titles Date: Thu, 14 Dec 2023 23:50:14 +0100 Fellow hackers, So, I have always wondered why Notmuch uses the strangest buffer titles ever, and yesterday I decided to take a look under the hood... I found that the code in 'notmuch-search-buffer-title' defines and uses a pair of variables, named 'longest' and 'longest-length', but never sets the latter, which causes the strange buffer titles I observe. Please see the attached patch with a fix. P.S. I could not make the test suite work, not in the time I had for the fix, so ... see the test in the commit message. :) Rudy >From c0cb08a843b5c904642da639f94c4a5e43d1ef14 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Wed, 13 Dec 2023 22:39:02 +0100 Subject: [PATCH] emacs: Fix saved-search buffer titles REPRODUCTION STEPS: (let ((notmuch-saved-searches (list (list :name "Emacs List" :query "query:lists-emacs") (list :name "All Lists" :query "query:lists" (notmuch-search-buffer-title "query:lists-emacs" )) ACTUAL: "*notmuch-saved-search-[ All Lists ]-emacs*" EXPECTED: "*notmuch-saved-search-Emacs List*" --- emacs/notmuch.el | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 6eef4af1..1ac145f0 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -964,17 +964,20 @@ unthreaded) and whether it's SAVED (t or nil)." (defun notmuch-search-buffer-title (query type) "Returns the title for a buffer with notmuch search results." (let* ((saved-search - (let (longest - (longest-length 0)) - (cl-loop for tuple in notmuch-saved-searches - if (let ((quoted-query - (regexp-quote -(notmuch-saved-search-get tuple :query - (and (string-match (concat "^" quoted-query) query) - (> (length (match-string 0 query)) - longest-length))) - do (setq longest tuple)) - longest)) + (cl-loop with match + with match-length = 0 + for candidate in notmuch-saved-searches + for length = (let* ((query* (notmuch-saved-search-get + candidate + :query)) + (regexp (concat "^" + (regexp-quote query* + (and (string-match regexp query) + (length (match-string 0 query + if (and length (> length match-length)) + do (setq match candidate + match-length length) + finally return match)) (saved-search-name (notmuch-saved-search-get saved-search :name)) (saved-search-type (notmuch-saved-search-get saved-search :search-type)) (saved-search-query (notmuch-saved-search-get saved-search :query))) -- 2.39.3 (Apple Git-145) -- "The introduction of suitable abstractions is our only mental aid to organize and master complexity." --- Edsger Wybe Dijkstra, 1930-2002 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia End of forwarded message -- "I do not fear death. I had been dead for billions and billions of years before I was born, and had not suffered the slightest inconvenience from it." --- Mark Twain, paraphrased Rudolf Adamkovič [he/him] http://adamkovic.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Error when running notmuch new
Hello notmuch mailing list, I am new to notmuch, so I apologize if this is just an operator error. I have a local maildir created using offlineimap. I have ran notmuch setup and configured notmuch to use the maildir as its archive. However, running notmuch new returns 'notmuch new: Illegal argument for function' Any ideas what I am doing wrong? Thanks___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: desktop file to open mailto URLs in Emacs notmuch-message-mode
Hi Tomi, >> Lovely! This is exactly what I am looking for. But, in addition, we also >> need another desktop file that uses emacsclient instead of emacs. It >> would be great if notmuch provided that. > > That is kinda provided, if u get the ./emacs/notmuch-emacs-mua.desktop > file and did > > @@ -38 +38 @@ NO_WINDOW= > -USE_EMACSCLIENT= > +USE_EMACSCLIENT=yes > > there ;D Yes, we're almost there. It would be nice if such a desktop file is provided (in addition to the notmuch-emacs-mua.desktop that we already provide) along with notmuch so that users don't have to make that modification themselves. In other words, provide something like a notmuch-emacsclient-mua.desktop. That would make for a slightly smoother user experience. Thanks, Arun ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: desktop file to open mailto URLs in Emacs notmuch-message-mode
On Tue, Jun 18 2024, Arun Isaac wrote: > Hi David, > >> There is emacs/notmuch-mua-mail.desktop in the source. This seems to do >> what you ask for? > > Lovely! This is exactly what I am looking for. But, in addition, we also > need another desktop file that uses emacsclient instead of emacs. It > would be great if notmuch provided that. That is kinda provided, if u get the ./emacs/notmuch-emacs-mua.desktop file and did @@ -38 +38 @@ NO_WINDOW= -USE_EMACSCLIENT= +USE_EMACSCLIENT=yes there ;D > > Thanks, > Arun Tomi ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Selection bug
David Bremner writes: > > This reproduces the problem for me. Indeed it looks a bit like a similar > "cursor jumping" problem I have seen (and someone else has reported on > IRC). I will see if I can figure anything more out now that I have a > reproducer. I think the following is a (simpler) reproducer of the same problem. 1) Do a search with at least 10 results 2) goto line 10 3) hit 'g' For me this consistently leaves the point on line 10 but the hl-line bar on line 1. I have not debugged it yet, but the proximate cause is that when notmuch-hl-line-mode is called, (point) is 1, so the bar ends up on the first line. The whys and wherefores I don't know yet. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 2/2] Replace `delete-line` with its definition
michaeljgruber+grubix+...@gmail.com writes:
> From: Michael J Gruber
>
> 37c022ae ("Use `without-restriction` in
> `with-temporary-notmuch-message-buffer`", 2024-03-14)
> introduced `delete-line` in a test, but this is Emacs 29 and above only.
> Replace it with its (almost) definition.
both v2 patches applied to master.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 2/2] Replace `delete-line` with its definition
Am Di., 18. Juni 2024 um 07:58 Uhr schrieb Marc Fargas
:
>
> Hi,
>
> El lun. 17 de jun. 2024, David escribió:
> >
> >> From: Michael J Gruber
> >>
> >> 37c022ae ("Use `without-restriction` in
> >> `with-temporary-notmuch-message-buffer`", 2024-03-14)
> >> introduced `delete-line` in a test, but this is Emacs 29 and above only.
> >> Replace it with its (almost) definition.
> >
> > The changes look reasonable to me. But so did the last ones ;P.
:-)
Builds: https://copr.fedorainfracloud.org/coprs/mjg/notmuch-git/build/7621439/
Source:
https://copr-dist-git.fedorainfracloud.org/cgit/mjg/notmuch-git/notmuch.git/tree/?id=365e56a86826e13bdb6f716993ad33d5d570b7b6
>> Any
> > feedback Marc?
>
> Ok for me! And sorry for not considering backwards compatibility on my
> patch :(
I just happen to test against old versions because I maintain notmuch
for Fedora and EPEL, i.e. extra packages for RHEL and such, and they
often come with older versions as a stable base platform.
Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 2/2] Replace `delete-line` with its definition
Hi,
El lun. 17 de jun. 2024, David escribió:
>
>> From: Michael J Gruber
>>
>> 37c022ae ("Use `without-restriction` in
>> `with-temporary-notmuch-message-buffer`", 2024-03-14)
>> introduced `delete-line` in a test, but this is Emacs 29 and above only.
>> Replace it with its (almost) definition.
>
> The changes look reasonable to me. But so did the last ones ;P. Any
> feedback Marc?
Ok for me! And sorry for not considering backwards compatibility on my
patch :(
marc
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: desktop file to open mailto URLs in Emacs notmuch-message-mode
Hi David, > There is emacs/notmuch-mua-mail.desktop in the source. This seems to do > what you ask for? Lovely! This is exactly what I am looking for. But, in addition, we also need another desktop file that uses emacsclient instead of emacs. It would be great if notmuch provided that. Thanks, Arun ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 2/2] Replace `delete-line` with its definition
michaeljgruber+grubix+...@gmail.com writes:
> From: Michael J Gruber
>
> 37c022ae ("Use `without-restriction` in
> `with-temporary-notmuch-message-buffer`", 2024-03-14)
> introduced `delete-line` in a test, but this is Emacs 29 and above only.
> Replace it with its (almost) definition.
The changes look reasonable to me. But so did the last ones ;P. Any
feedback Marc?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH v2 2/2] Replace `delete-line` with its definition
From: Michael J Gruber
37c022ae ("Use `without-restriction` in
`with-temporary-notmuch-message-buffer`", 2024-03-14)
introduced `delete-line` in a test, but this is Emacs 29 and above only.
Replace it with its (almost) definition.
---
With this one, all my reported chroots build again.
test/T630-emacs-draft.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/T630-emacs-draft.sh b/test/T630-emacs-draft.sh
index 1fad58a8..7d0da21a 100755
--- a/test/T630-emacs-draft.sh
+++ b/test/T630-emacs-draft.sh
@@ -76,7 +76,7 @@ add_email_corpus attachment
test_begin_subtest "Saving a draft keeps hidden headers"
test_emacs '(notmuch-mua-new-reply "id:874llc2bkp@curie.anarc.at")
(message-goto-subject)
-(delete-line)
+(delete-region (line-beginning-position) (line-beginning-position
2))
(insert "Subject: draft-test-reply\n")
(test-output "DRAFT")
(notmuch-draft-postpone)
--
2.45.2.749.g54362de8d7
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH v2 1/2] Replace `without-restriction` with `save-restriction`
From: Michael J Gruber
37c022ae ("Use `without-restriction` in
`with-temporary-notmuch-message-buffer`", 2024-03-14)
introduced a fix for draft saving in a way which is supported on Emacs
29 and above only. Replace this with a construct which we have used
before, so that we keep the same compatibility level.
---
unchanged
emacs/notmuch-maildir-fcc.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index cf50e855..c7b403cf 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -145,7 +145,8 @@ Otherwise set it according to `notmuch-fcc-dirs'."
(defmacro with-temporary-notmuch-message-buffer ( body)
"Set-up a temporary copy of the current message-mode buffer."
- `(without-restriction
+ `(save-restriction
+ (widen)
(let ((case-fold-search t)
(buf (current-buffer))
(mml-externalize-attachments message-fcc-externalize-attachments))
--
2.45.2.749.g54362de8d7
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
Marc Fargas writes: > Hi, > > El lun. 17 de jun. 2024, Marc escribió: >> >> El lun. 17 de jun. 2024, Michael escribió: (...) >>> >>> Does this depend on emacs version by any chance, i.e. is >>> `without-restriction` defined on all emacsen? In Fedora's copr >>> infrastructure, all builds succeed but some tests fail with >>> `Symbol'€™s function definition is void: without-restriction`. The >>> picture is the following: > > So, I will have to update the patch in order to make the use of > `without-restriction` conditional on its availability. > > I asked on Emacs chat @ Matrix on how to do this nicely and yantar92 > (org contributor) proposed the following macro: > >(defmacro notmuch--without-restriction ( body) > "Run BODY within `without-restriction', when it is available." > (declare (debug (body))) > (if (fboundp 'without-restriction) > `(without-restriction ,@body) >`(progn ,@body))) Assuming fboundp works for macros (without-restriction is a macro), then sure ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] Replace `without-restriction` with `save-restriction`
From: Michael J Gruber
37c022ae ("Use `without-restriction` in
`with-temporary-notmuch-message-buffer`", 2024-03-14)
introduced a fix for draft saving in a way which is supported on Emacs
29 and above only. Replace this with a construct which we have used
before, so that we keep the same compatibility level.
---
So, this fixes one incompatibility, and as per the emacs docs, those
should be equivalent.
Alas: T630-emacs-draft introduced another incompatibility by using
`delete-line`, it seems. I haven't checked versions nor substitutes
yet.
emacs/notmuch-maildir-fcc.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index cf50e855..c7b403cf 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -145,7 +145,8 @@ Otherwise set it according to `notmuch-fcc-dirs'."
(defmacro with-temporary-notmuch-message-buffer ( body)
"Set-up a temporary copy of the current message-mode buffer."
- `(without-restriction
+ `(save-restriction
+ (widen)
(let ((case-fold-search t)
(buf (current-buffer))
(mml-externalize-attachments message-fcc-externalize-attachments))
--
2.45.2.749.g54362de8d7
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
Hi, El lun. 17 de jun. 2024, Marc escribió: > > El lun. 17 de jun. 2024, Michael escribió: >>> (...) >> >> Does this depend on emacs version by any chance, i.e. is >> `without-restriction` defined on all emacsen? In Fedora's copr >> infrastructure, all builds succeed but some tests fail with >> `Symbol'€™s function definition is void: without-restriction`. The >> picture is the following: So, I will have to update the patch in order to make the use of `without-restriction` conditional on its availability. I asked on Emacs chat @ Matrix on how to do this nicely and yantar92 (org contributor) proposed the following macro: (defmacro notmuch--without-restriction ( body) "Run BODY within `without-restriction', when it is available." (declare (debug (body))) (if (fboundp 'without-restriction) `(without-restriction ,@body) `(progn ,@body))) David, would such solution be OK? If so I'll prepare a new patch. Marc ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
Hi, El lun. 17 de jun. 2024, Michael escribió: >> (...) > > Does this depend on emacs version by any chance, i.e. is > `without-restriction` defined on all emacsen? In Fedora's copr > infrastructure, all builds succeed but some tests fail with > `Symbol'€™s function definition is void: without-restriction`. The > picture is the following: Apparently it was introduced in Emacs 29[1]. Strange that tests pass at all on previous versions. What is the earliest Emacs version supported by notmuch? I can't find any specific version in notmuch documentation. The patch could be updated to only use without-restriction when available, of course. marc [1]: https://github.com/emacs-mirror/emacs/blob/7be66d8223e49489b2803c0ff027f1824d774441/etc/NEWS.29#L3512 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
David Bremner writes: > Marc Fargas writes: > >> Hi, >> >> El lun. 17 de jun. 2024, Michael escribió: (...) >>> >>> Does this depend on emacs version by any chance, i.e. is >>> `without-restriction` defined on all emacsen? In Fedora's copr >>> infrastructure, all builds succeed but some tests fail with >>> `Symbol'€™s function definition is void: without-restriction`. The >>> picture is the following: >> >> Apparently it was introduced in Emacs 29[1]. Strange that tests pass at >> all on previous versions. >> >> What is the earliest Emacs version supported by notmuch? I can't find >> any specific version in notmuch documentation. > > According to the docs, it is supposed to work with 25.1. Personally I > would be fine updating this to 26.x or 27.x, but of course that won't > help you here. Using "docs", loosly here. This is the most recent announcement in NEWS, which matches emacs/notmuch-pkg.el.tmpl ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
Marc Fargas writes: > Hi, > > El lun. 17 de jun. 2024, Michael escribió: >>> (...) >> >> Does this depend on emacs version by any chance, i.e. is >> `without-restriction` defined on all emacsen? In Fedora's copr >> infrastructure, all builds succeed but some tests fail with >> `Symbol'€™s function definition is void: without-restriction`. The >> picture is the following: > > Apparently it was introduced in Emacs 29[1]. Strange that tests pass at > all on previous versions. > > What is the earliest Emacs version supported by notmuch? I can't find > any specific version in notmuch documentation. According to the docs, it is supposed to work with 25.1. Personally I would be fine updating this to 26.x or 27.x, but of course that won't help you here. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
Am Sa., 15. Juni 2024 um 19:57 Uhr schrieb David Bremner : > > Marc Fargas writes: > > > Hi again, > > > > El dom. 24 de mar. 2024, Marc escribió: > >> El mié. 13 de mar. 2024, Carl escribió: > >>> (...) > >>> Could you put your fix together in the form of a git-appliable patch? > >>> Such as by applying it to the notmuch source, running `git commit` and > >>> then `git format-patch HEAD~` or similar. > >> > >> Please disregard the previous patch, consider the one attached > >> here. Hope I did the "format-patch" thing properly. > >> > >> I had to move the `without-restriction` call to the top of the > >> `with-temporary-notmuch-message-buffer` defmacro. It does work properly > >> now. > > Applied to master. Sorry for the long-ish silence. > Does this depend on emacs version by any chance, i.e. is `without-restriction` defined on all emacsen? In Fedora's copr infrastructure, all builds succeed but some tests fail with `Symbol'€™s function definition is void: without-restriction`. The picture is the following: PASS: centos-stream+epel-next-8 with emacs 26.1-11.el8 rhel+epel-8 with emacs 26.1-11.el8 fedora-39 with emacs 29.3-1.fc39 (plus all newer fedoras) FAIL: centos-stream+epel-next-9 with emacs 27.2-9.el9 rhel+epel-9 with emacs 27.2-9.el9 Yes, RHEL 8 is EOled. I find it strange that tests pass on both emacs 26 and 29 but not 27.2. But said code path is not executed on emacs 26 at all? The failing 42 tests are mostly around json and crypto, but not all. Cheers Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el, needs without-restriction to properly save draft
Marc Fargas writes: > Hi again, > > El dom. 24 de mar. 2024, Marc escribió: >> El mié. 13 de mar. 2024, Carl escribió: >>> (...) >>> Could you put your fix together in the form of a git-appliable patch? >>> Such as by applying it to the notmuch source, running `git commit` and >>> then `git format-patch HEAD~` or similar. >> >> Please disregard the previous patch, consider the one attached >> here. Hope I did the "format-patch" thing properly. >> >> I had to move the `without-restriction` call to the top of the >> `with-temporary-notmuch-message-buffer` defmacro. It does work properly >> now. Applied to master. Sorry for the long-ish silence. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] test/cli: Add known broken test for (missing) quoting in From
David Bremner writes: > In [1], Jakub Wilk observes that the current behaviour is confusing > since it looks like there are two mailboxes in From, while in fact > there is only one. It seems to me that notmuch should at least quote > the display-name part of a mailbox if it has "funny" characters in it, > and perhaps always quote it. Either way will require changing the > indexing code, since the structure is lost when writing the headers to > the database. > applied to master. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Emacs: text/calendar rendering fix
David Bremner writes: > The actual fix here is quite trivial, but it takes some work to test. > Compared to the previous version in the thread at [1], this updates > the 3rd patch in the series to actually duplicate the problem, and > adds the 4th patch with the actual fix. > > [1]: id:m2wmneguh8@gmail.com Thread applied to master. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
desktop file to open mailto URLs in Emacs notmuch-message-mode
Hi, This is a feature request. Emacs comes with emacs-mail.desktop and emacsclient-mail.desktop files that allows opening mailto URLs in message-mode. Can we provide similar desktop files for notmuch-emacs so that one can open mailto URLs in notmuch-message-mode? Thank you for your consideration! Regards, Arun ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: desktop file to open mailto URLs in Emacs notmuch-message-mode
Arun Isaac writes: > This is a feature request. > > Emacs comes with emacs-mail.desktop and emacsclient-mail.desktop files > that allows opening mailto URLs in message-mode. Can we provide similar > desktop files for notmuch-emacs so that one can open mailto URLs in > notmuch-message-mode? There is emacs/notmuch-mua-mail.desktop in the source. This seems to do what you ask for? ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to disable image and PDF preview in emacs notmuch-show buffer?
Viktor Larkin writes:
> Hello, David. Seems like I've got it wrong. Could you please provide an
> example of how I should change mm-inline-override-types? I've tried this
> way
>
> (setq mm-inline-override-types '("image/.*"))
>
> It didn't work as I expect it to. I still see images in notmuch-show
> buffer as images, not as attachments.
I used M-x customize variable and your example worked fine for me. I
guess you will either need to use customize or find the right
incantation (setq-default maybe, but I did not test it).
Hope this helps
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to disable image and PDF preview in emacs notmuch-show buffer?
Hello, David. Seems like I've got it wrong. Could you please provide an
example of how I should change mm-inline-override-types? I've tried this
way
(setq mm-inline-override-types '("image/.*"))
It didn't work as I expect it to. I still see images in notmuch-show
buffer as images, not as attachments.
Cheers.
David Bremner writes:
> curiousbarbar...@posteo.net writes:
>
>> Hello.
>>
>> Is it possible to disable preview of images and PDF files in
>> notmuch-show buffer in emacs? I've tried to set gnus-inhibit-image to t,
>> but it looks like it doesn't affect previewing. Any possible built-in
>> solutions?
>>
>> Emacs 29.2
>> notmuch 0.37
>
> Try customizing mm-inline-override-types. Note that notmuch normally
> adds "application/.*" to this, but won't if you customize it, so you may
> want to add in to your list.
>
> d
--
С уважением,
В. А. Ларкин
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Autoload notmuch-user-agent related functions
Jelle Licht writes: > Thanks for applying the patch, but I just noticed I made a mistake; each > of the lines now have a ";;;#autoload" comment, instead of the proper > ";;;###autoload" cookie. My apologies. Should I send a patch fixing > this, or will you push a fix yourself? Please send a patch, thanks d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Autoload notmuch-user-agent related functions
Hi David, David Bremner writes: > jli...@fsfe.org writes: > >> >> ;;; _ >> - >> +;;;#autoload >> (define-mail-user-agent 'notmuch-user-agent >>'notmuch-mua-mail >>'notmuch-mua-send-and-exit > > Applied to master with the deleted blank line put back Thanks for applying the patch, but I just noticed I made a mistake; each of the lines now have a ";;;#autoload" comment, instead of the proper ";;;###autoload" cookie. My apologies. Should I send a patch fixing this, or will you push a fix yourself? Kind regards, Jelle Licht ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to disable image and PDF preview in emacs notmuch-show buffer?
curiousbarbar...@posteo.net writes: > Hello. > > Is it possible to disable preview of images and PDF files in > notmuch-show buffer in emacs? I've tried to set gnus-inhibit-image to t, > but it looks like it doesn't affect previewing. Any possible built-in > solutions? > > Emacs 29.2 > notmuch 0.37 Try customizing mm-inline-override-types. Note that notmuch normally adds "application/.*" to this, but won't if you customize it, so you may want to add in to your list. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
How to disable image and PDF preview in emacs notmuch-show buffer?
Hello. Is it possible to disable preview of images and PDF files in notmuch-show buffer in emacs? I've tried to set gnus-inhibit-image to t, but it looks like it doesn't affect previewing. Any possible built-in solutions? Emacs 29.2 notmuch 0.37 Cheers, CB. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
tags starting with / are effectively forbidden
Via ukleink on IRC % notmuch tag --batch +/foo -- id:87edveqpj6@tethera.net notmuch tag: A Xapian exception occurred A Xapian exception occurred parsing query: unmatched regex delimiter in '/foo' Query string was: ( id:87edveqpj6@tethera.net ) and (not tag:/foo) % notmuch tag +/foo -- id:87edveqpj6@tethera.net notmuch tag: A Xapian exception occurred A Xapian exception occurred parsing query: unmatched regex delimiter in '/foo' Query string was: ( id:87edveqpj6@tethera.net ) and (not tag:/foo) The problem here is the implicit query to avoid re-tagging things already tagged /foo. There is some unfortunate use of strings to construct a query in notmuch-tag.c. This string is parsed by same parser as other notmuch queries, which means it attempts to support regexes. In retrospect using strings to construct queries is pretty obviously a bad idea, but we don't currently have a C API for constructing queries. The closest is the sexp parse, but this would still require constructing a serialized query (as a sexp) and then parsing it again. Some potential solutions (roughly in order of effort and flexibility) include - pushing the query optimization code inside libnotmuch, using the Xapian API directly. This has the advantage that it makes it available to all bindings users. - extend the notmuch_query API to allow updating the underlying query using some operator and a single term, something like notmuch_query_modify(query, NOTMUCH_OP_ANDNOT, "tag", "/foo") - providing a low level wrapper around Xapian::Query, taking care of translating prefixes. At the moment I think only this last would allow the elimination of constructing strings in the CLI code to pass to libnotmuch. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Selection bug
Justus Winter writes:
> David Bremner writes:
>
> Uh, you are right. I meant to pick mails form notmuch@, but this one is
> from another list. I actually reduced the example further:
>
> mkdir -p /tmp/selection-bug/{tmp,new,cur}
> echo "[database]
> path=/tmp/selection-bug" > /tmp/selection-bug/notmuch-config
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch new
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config emacs -q --eval "(require
> 'notmuch)"
> # M-x notmuch-hello, search for '*'
> notmuch show --format=raw id:87edvlanuh@tethera.net |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, press down once, i.e. navigate to "End of search
> results".
> notmuch show --format=raw id:87fsfuuxwn.fsf@thinkbox |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, bug: your mail is green, mine is opened on pressing
> enter
This reproduces the problem for me. Indeed it looks a bit like a similar
"cursor jumping" problem I have seen (and someone else has reported on
IRC). I will see if I can figure anything more out now that I have a
reproducer.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Allow customizing :excluded in notmuch-saved-searches
mohk...@kisara.moe writes: > From: Mohsin Kaleem > applied to master, with a slightly expanded commit message. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 1/4] test: re-enable duplicate UI tests in T460-emacs-tree
David Bremner writes: > These were disabled (accidentally?) in f63d14a8c12a. > --- > test/T460-emacs-tree.sh | 2 -- > 1 file changed, 2 deletions(-) applied to master. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 2/4] test/emacs: add regression test for display of calendar parts.
This will hopefully catch breakage due to either changes in Emacs (especially Gnus) or changes to the notmuch-show code. --- 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 559df8aa..438a7b9b 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -318,6 +318,28 @@ test_expect_equal "$(cat MESSAGES)" "COMPLETE" add_email_corpus attachment +test_begin_subtest "display of text/calendar" +test_emacs '(let ((notmuch-show-all-multipart/alternative-parts t)) + (notmuch-show "id:yt3pr01mb10572efc9f7c81f9446214768ce...@yt3pr01mb10572.canprd01.prod.outlook.com")) + (test-visible-output "OUTPUT")' +cat < EXPECTED +David Bremner (1970-01-01) (inbox) +Subject: test +To: "da...@tethera.net" +Date: Thu, 01 Jan 1970 00:00:00 + + +[ multipart/alternative ] +[ text/plain ] +This meeting will could have been an email +[ text/calendar ] +%%(and (diary-cyclic 1 5 27 2024) (diary-block 5 27 2024 8 27 2024)) 17:00-17:30 test [In-person] + Desc: This meeting will could have been an email + + + Organizer: mailto:brem...@example.com +EOF +test_expect_equal_file EXPECTED OUTPUT + test_begin_subtest "tar not inlined by default" test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") (test-visible-output "OUTPUT")' -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 4/4] emacs/show: fix for text/calendar display
In certain scenarios involving symlinks and setting find-file-visit-truename, text/calendar parts were not displayed properly. Following a suggestion of Al Haji-Ali [1], replace the use of get-file-buffer with find-buffer-visiting. [1]: id:m2wmneguh8@gmail.com --- emacs/notmuch-show.el | 2 +- test/T450-emacs-show.sh | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 4c0ad74d..14e3c698 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -864,7 +864,7 @@ will return nil if the CID is unknown or cannot be retrieved." (unless (icalendar-import-buffer file t) (error "Icalendar import error. %s" "See *icalendar-errors* for more information")) - (set-buffer (get-file-buffer file)) + (set-buffer (find-buffer-visiting file)) (setq result (buffer-substring (point-min) (point-max))) (set-buffer-modified-p nil) (kill-buffer (current-buffer))) diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh index 027062cd..7c6a946a 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -341,7 +341,6 @@ EOF test_expect_equal_file EXPECTED OUTPUT test_begin_subtest "display of text/calendar, symlinked tmpdir" -test_subtest_known_broken mkdir real-tmp ln -s real-tmp tmp test_emacs "(let ((notmuch-show-all-multipart/alternative-parts t) -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 3/4] test/emacs: add tests for rendering text/calendar parts
The first test is just a general regression test, while the second duplicates the problem discussed in the thread starting at [1]. [1]: id:m2leo2u0uo@gmail.com --- test/T450-emacs-show.sh | 27 +++ 1 file changed, 27 insertions(+) diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh index 438a7b9b..027062cd 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -340,6 +340,33 @@ This meeting will could have been an email EOF test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest "display of text/calendar, symlinked tmpdir" +test_subtest_known_broken +mkdir real-tmp +ln -s real-tmp tmp +test_emacs "(let ((notmuch-show-all-multipart/alternative-parts t) + (temporary-file-directory \"tmp\") + (find-file-visit-truename t)) +(notmuch-show \"id:yt3pr01mb10572efc9f7c81f9446214768ce...@yt3pr01mb10572.canprd01.prod.outlook.com\")) + (test-visible-output \"OUTPUT\")" +cat < EXPECTED +David Bremner (1970-01-01) (inbox) +Subject: test +To: "da...@tethera.net" +Date: Thu, 01 Jan 1970 00:00:00 + + +[ multipart/alternative ] +[ text/plain ] +This meeting will could have been an email +[ text/calendar ] +%%(and (diary-cyclic 1 5 27 2024) (diary-block 5 27 2024 8 27 2024)) 17:00-17:30 test [In-person] + Desc: This meeting will could have been an email + + + Organizer: mailto:brem...@example.com +EOF +test_expect_equal_file EXPECTED OUTPUT + test_begin_subtest "tar not inlined by default" test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") (test-visible-output "OUTPUT")' -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 1/4] test/corpora: add example with text/calendar attachment
Initially for testing rendering in Emacs. --- test/corpora/attachment/text-calendar.eml | 55 +++ 1 file changed, 55 insertions(+) create mode 100644 test/corpora/attachment/text-calendar.eml diff --git a/test/corpora/attachment/text-calendar.eml b/test/corpora/attachment/text-calendar.eml new file mode 100644 index ..8e064f9b --- /dev/null +++ b/test/corpora/attachment/text-calendar.eml @@ -0,0 +1,55 @@ +From: David Bremner +To: "da...@tethera.net" +Subject: test +Date: Thu Jan 01 00:00:10 + +Message-ID: + +Accept-Language: en-CA, en-US +Content-Language: en-CA +Content-Type: multipart/alternative; + boundary="_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_" +MIME-Version: 1.0 + +--_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_ +Content-Type: text/plain; charset="iso-8859-1" +Content-Transfer-Encoding: quoted-printable + +This meeting will could have been an email + + +--_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_ +Content-Type: text/calendar; charset="utf-8"; method=REQUEST +Content-Transfer-Encoding: base64 + +QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n +ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBdGxhbnRp +YyBTdGFuZGFyZCBUaW1lDQpCRUdJTjpTVEFOREFSRA0KRFRTVEFSVDoxNjAxMDEwMVQwMjAwMDAN +ClRaT0ZGU0VURlJPTTotMDMwMA0KVFpPRkZTRVRUTzotMDQwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 +SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQ0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlM +SUdIVA0KRFRTVEFSVDoxNjAxMDEwMVQwMjAwMDANClRaT0ZGU0VURlJPTTotMDQwMA0KVFpPRkZT +RVRUTzotMDMwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05U +SD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5JWkVS +O0NOPURhdmlkIEJyZW1uZXI6bWFpbHRvOmJyZW1uZXJAZXhhbXBsZS5jb20NCkFUVEVOREVFO1JP +TEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049ZGF2 +aWRAdGV0aA0KIGVyYS5uZXQ6bWFpbHRvOmRhdmlkQHRldGhlcmEubmV0DQpERVNDUklQVElPTjtM +QU5HVUFHRT1lbi1DQTpUaGlzIG1lZXRpbmcgd2lsbCBjb3VsZCBoYXZlIGJlZW4gYW4gZW1haWxc +blxuDQpSUlVMRTpGUkVRPURBSUxZO1VOVElMPTIwMjQwODI3VDE3MDAwMFo7SU5URVJWQUw9MQ0K +VUlEOjA0MDAwMDAwODIwMEUwMDA3NEM1QjcxMDFBODJFMDA4MDAwMDAwMDAwRUE4NDFFNzk5QUZE +QTAxMDAwMDAwMDAwMDAwMDAwDQogMDEwMDAwMDAwNjkyRkRFNzQzMzNGQ0I0N0JFNEY0REU5MDk0 +OThDQkUNClNVTU1BUlk7TEFOR1VBR0U9ZW4tQ0E6dGVzdCBbSW4tcGVyc29uXQ0KRFRTVEFSVDtU +WklEPUF0bGFudGljIFN0YW5kYXJkIFRpbWU6MjAyNDA1MjdUMTQwMDAwDQpEVEVORDtUWklEPUF0 +bGFudGljIFN0YW5kYXJkIFRpbWU6MjAyNDA1MjdUMTQzMDAwDQpDTEFTUzpQVUJMSUMNClBSSU9S +SVRZOjUNCkRUU1RBTVA6MjAyNDA1MjZUMTgyNDEwWg0KVFJBTlNQOk9QQVFVRQ0KU1RBVFVTOkNP +TkZJUk1FRA0KU0VRVUVOQ0U6MA0KTE9DQVRJT047TEFOR1VBR0U9ZW4tQ0E6DQpYLU1JQ1JPU09G +VC1DRE8tQVBQVC1TRVFVRU5DRTowDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MjEyMjcw +MDA0Ng0KWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1D +RE8tSU5URU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNF +DQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6 +MQ0KWC1NSUNST1NPRlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElT +QUxMT1ctQ09VTlRFUjpGQUxTRQ0KWC1NSUNST1NPRlQtUkVRVUVTVEVEQVRURU5EQU5DRU1PREU6 +SU5QRVJTT05SRVFVSVJFRA0KWC1NSUNST1NPRlQtSVNSRVNQT05TRVJFUVVFU1RFRDpUUlVFDQpY +LU1JQ1JPU09GVC1MT0NBVElPTlM6W10NCkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046UkVNSU5E +RVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkFDVElPTjpESVNQTEFZDQpFTkQ6VkFM +QVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= + +--_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_-- -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Emacs: text/calendar rendering fix
The actual fix here is quite trivial, but it takes some work to test. Compared to the previous version in the thread at [1], this updates the 3rd patch in the series to actually duplicate the problem, and adds the 4th patch with the actual fix. [1]: id:m2wmneguh8@gmail.com ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 3/3] WIP/test: add tests for rendering text/calendar parts
Ah, apologies. I should've done more testing. Turns out I have `find-file-visit-truename` set to non-nil which causes the behaviour I describe. Best regards, -- Al On 28/05/2024, David Bremner wrote: > Al Haji-Ali writes: > >> >> On my setup (MacOS, Emacs 29.1) this prints something like >> >> , >> | Filename: /Users/al/link-tmp/notmuch-ical7MtHvd >> | get-file-buffer: nil >> | find-buffer-visiting: # >> | buffer-file-name: /private/tmp/notmuch-ical7MtHvd >> ` > > Here it prints > > Filename: /home/bremner/link-tmp/notmuch-icalDC01xk > get-file-buffer: # > find-buffer-visiting: # > buffer-file-name: /home/bremner/link-tmp/notmuch-icalDC01xk > > So I guess this is some system dependent (or emacs dependent; I have > 29.3 here) behaviour. I can convert the test to a regression test after > the change is applied. It's not as nice, but it's better than not > testing it at all. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 3/3] WIP/test: add tests for rendering text/calendar parts
Al Haji-Ali writes: > > On my setup (MacOS, Emacs 29.1) this prints something like > > , > | Filename: /Users/al/link-tmp/notmuch-ical7MtHvd > | get-file-buffer: nil > | find-buffer-visiting: # > | buffer-file-name: /private/tmp/notmuch-ical7MtHvd > ` Here it prints Filename: /home/bremner/link-tmp/notmuch-icalDC01xk get-file-buffer: # find-buffer-visiting: # buffer-file-name: /home/bremner/link-tmp/notmuch-icalDC01xk So I guess this is some system dependent (or emacs dependent; I have 29.3 here) behaviour. I can convert the test to a regression test after the change is applied. It's not as nice, but it's better than not testing it at all. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 3/3] WIP/test: add tests for rendering text/calendar parts
Yes, that is strange. Based on just looking at the test code, I think this test should indeed fail (I am not able to run in on my machine). In a similar situation, my inline calendar text shows , | !!! Bodypart handler `notmuch-show-insert-part-text/calendar' threw an error: | !!! Wrong type argument: stringp, nil | !!! Bodypart handler `notmuch-show-insert-part-*/*' threw an error: | !!! Wrong type argument: char-or-string-p, gnus-decoded ` To see the basic issue, check what this code outputs on your setup: , | (let ((tmp-link "~/link-tmp")) | (make-symbolic-link "/tmp/" tmp-link) | (let* ((temporary-file-directory tmp-link) | (file (make-temp-file "notmuch-ical"))) | (find-file-noselect file) | (message | "Filename: %s | get-file-buffer: %S | find-buffer-visiting: %S | buffer-file-name: %s" | file | (get-file-buffer file) | (find-buffer-visiting file) | (buffer-file-name (find-buffer-visiting file))) | (kill-buffer (find-buffer-visiting file)) | (delete-file tmp-link) | (delete-file file))) | ` On my setup (MacOS, Emacs 29.1) this prints something like , | Filename: /Users/al/link-tmp/notmuch-ical7MtHvd | get-file-buffer: nil | find-buffer-visiting: # | buffer-file-name: /private/tmp/notmuch-ical7MtHvd ` So `get-file-buffer` returns nil. Reason is that the buffer-file-name has the resolved path (without symlinks). The documentation for `get-file-buffer` says: "The buffer's buffer-file-name must match exactly the expansion of FILENAME". `find-buffer-visiting` gets the truename of the filename before looking for its buffer. The function `notmuch-show-insert-part-text/calendar` essentially does the same as my code above. Note also that `find-buffer-visiting` is used instead of `get-file-buffer` in `icalendar-import-buffer` for example. -- Al On 26/05/2024, David Bremner wrote: > The second test should apparently fail, but it doesn't. > --- > test/T450-emacs-show.sh | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh > index 438a7b9b..85851e70 100755 > --- a/test/T450-emacs-show.sh > +++ b/test/T450-emacs-show.sh > @@ -340,6 +340,32 @@ This meeting will could have been an email > EOF > test_expect_equal_file EXPECTED OUTPUT > > +test_begin_subtest "display of text/calendar, symlinked tmpdir" > +test_subtest_known_broken > +mkdir real-tmp > +ln -s real-tmp tmp > +test_emacs "(let ((notmuch-show-all-multipart/alternative-parts t) > +(temporary-file-directory \"tmp\")) > +(notmuch-show > \"id:yt3pr01mb10572efc9f7c81f9446214768ce...@yt3pr01mb10572.canprd01.prod.outlook.com\")) > + (test-visible-output \"OUTPUT\")" > +cat < EXPECTED > +David Bremner (1970-01-01) (inbox) > +Subject: test > +To: "da...@tethera.net" > +Date: Thu, 01 Jan 1970 00:00:00 + > + > +[ multipart/alternative ] > +[ text/plain ] > +This meeting will could have been an email > +[ text/calendar ] > +%%(and (diary-cyclic 1 5 27 2024) (diary-block 5 27 2024 8 27 2024)) > 17:00-17:30 test [In-person] > + Desc: This meeting will could have been an email > + > + > + Organizer: mailto:brem...@example.com > +EOF > +test_expect_equal_file EXPECTED OUTPUT > + > test_begin_subtest "tar not inlined by default" > test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") > (test-visible-output "OUTPUT")' ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Meaning of offset in notmuch search --output=files --offset=
* 2024-05-27 09:05:01-0400, Daniel Kahn Gillmor wrote: > I don't see much difference between any of these versions, Then it needs more work still. We want to make it clear for everybody, don't we? Let's go back to my original confusion. Currently it reads: --offset=[-]N Skip displaying the first N results. With the leading '-', start at the Nth result from the end. What "results"? The search match or the output? Two interpretations: 1. "Notmuch search" results an internal message list. "--offset=N" will skip N messages in the internal message list and then starts printing the rest of the messages in the "--output" format. [This is what Notmuch really does.] 2. "Notmuch search" results an internal message list and it starts printing them in "--output" format. It will use "--offset=N" to skip N output items, regardless of what they are: summary, threads, messages, files, tags. [This is the wrong interpretation.] So, how do we improve the notmuch-search manual so that everybody understands "--offset=N" correctly? -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Meaning of offset in notmuch search --output=files --offset=
On Sun 2024-05-26 10:57:14 +0300, Teemu Likonen wrote: > * 2024-05-25 13:20:58+0200, Michael J. Gruber wrote: > >>> Teemu Likonen writes: --offset=[-]N Skip displaying the first N results. With the leading '-', start at the Nth result from the end. What if we change the first sentence to "Skip displaying the first N search results"? > >> Maybe even "Skip displaying output for the first N search results", in >> an effort to hint at said difference? > > Yours is better than the current and mine. Thanks. I don't see much difference between any of these versions, but i also don't think any of them make the text concretely worse. So if more people understand what is meant by the version suggested by Michael J Gruber, i'd be fine with going with that version. --dkg signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Xapian commits unexpectedly slow
On Sun, May 26, 2024 at 09:12:57AM -0300, David Bremner wrote: > Apologies, it looks like I never replied to this thread. Probably you > are not longer interested, but I can make a few observations, mainly > that there are a few relevant improvements in later notmuch. Wow! What reminded you of this after all this time? A lot certainly has changed since then. I don't remember whether my problem was ever resolved on that machine, but a few months later I moved to a new laptop with an SSD, and I've now been a happy Notmuch user for several years. I think we can move on from this. Thanks for continuing to work on improving this great tool! -- Matthew Schauer ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: emacs warnings related to notmuch
Daniel Kahn Gillmor writes: > Hey notmuch folks-- > > when i launch emacs these days i see the following in my *Warnings* > buffer: > > Warning (comp): notmuch-hello.el:719:22: Warning: docstring wider than 80 > characters Disable showing Disable logging > Warning (comp): notmuch-hello.el:855:8: Warning: docstring wider than 80 > characters Disable showing Disable logging > Warning (comp): notmuch-hello.el:489:15: Warning: the function > ‘notmuch-search-format-buffer-name’ is not known to be defined. Disable > showing Disable logging > Warning (comp): notmuch-show.el:2479:8: Warning: docstring wider than 80 > characters Disable showing Disable logging These should be fixed in the next (major) release of notmuch, i.e. 0.39 and not 0.38.4 (if the latter happens). ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 1/3] test/corpora: add example with text/calendar attachment
Initially for testing rendering in Emacs. --- test/corpora/attachment/text-calendar.eml | 55 +++ 1 file changed, 55 insertions(+) create mode 100644 test/corpora/attachment/text-calendar.eml diff --git a/test/corpora/attachment/text-calendar.eml b/test/corpora/attachment/text-calendar.eml new file mode 100644 index ..8e064f9b --- /dev/null +++ b/test/corpora/attachment/text-calendar.eml @@ -0,0 +1,55 @@ +From: David Bremner +To: "da...@tethera.net" +Subject: test +Date: Thu Jan 01 00:00:10 + +Message-ID: + +Accept-Language: en-CA, en-US +Content-Language: en-CA +Content-Type: multipart/alternative; + boundary="_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_" +MIME-Version: 1.0 + +--_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_ +Content-Type: text/plain; charset="iso-8859-1" +Content-Transfer-Encoding: quoted-printable + +This meeting will could have been an email + + +--_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_ +Content-Type: text/calendar; charset="utf-8"; method=REQUEST +Content-Transfer-Encoding: base64 + +QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n +ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBdGxhbnRp +YyBTdGFuZGFyZCBUaW1lDQpCRUdJTjpTVEFOREFSRA0KRFRTVEFSVDoxNjAxMDEwMVQwMjAwMDAN +ClRaT0ZGU0VURlJPTTotMDMwMA0KVFpPRkZTRVRUTzotMDQwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 +SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQ0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlM +SUdIVA0KRFRTVEFSVDoxNjAxMDEwMVQwMjAwMDANClRaT0ZGU0VURlJPTTotMDQwMA0KVFpPRkZT +RVRUTzotMDMwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05U +SD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5JWkVS +O0NOPURhdmlkIEJyZW1uZXI6bWFpbHRvOmJyZW1uZXJAZXhhbXBsZS5jb20NCkFUVEVOREVFO1JP +TEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049ZGF2 +aWRAdGV0aA0KIGVyYS5uZXQ6bWFpbHRvOmRhdmlkQHRldGhlcmEubmV0DQpERVNDUklQVElPTjtM +QU5HVUFHRT1lbi1DQTpUaGlzIG1lZXRpbmcgd2lsbCBjb3VsZCBoYXZlIGJlZW4gYW4gZW1haWxc +blxuDQpSUlVMRTpGUkVRPURBSUxZO1VOVElMPTIwMjQwODI3VDE3MDAwMFo7SU5URVJWQUw9MQ0K +VUlEOjA0MDAwMDAwODIwMEUwMDA3NEM1QjcxMDFBODJFMDA4MDAwMDAwMDAwRUE4NDFFNzk5QUZE +QTAxMDAwMDAwMDAwMDAwMDAwDQogMDEwMDAwMDAwNjkyRkRFNzQzMzNGQ0I0N0JFNEY0REU5MDk0 +OThDQkUNClNVTU1BUlk7TEFOR1VBR0U9ZW4tQ0E6dGVzdCBbSW4tcGVyc29uXQ0KRFRTVEFSVDtU +WklEPUF0bGFudGljIFN0YW5kYXJkIFRpbWU6MjAyNDA1MjdUMTQwMDAwDQpEVEVORDtUWklEPUF0 +bGFudGljIFN0YW5kYXJkIFRpbWU6MjAyNDA1MjdUMTQzMDAwDQpDTEFTUzpQVUJMSUMNClBSSU9S +SVRZOjUNCkRUU1RBTVA6MjAyNDA1MjZUMTgyNDEwWg0KVFJBTlNQOk9QQVFVRQ0KU1RBVFVTOkNP +TkZJUk1FRA0KU0VRVUVOQ0U6MA0KTE9DQVRJT047TEFOR1VBR0U9ZW4tQ0E6DQpYLU1JQ1JPU09G +VC1DRE8tQVBQVC1TRVFVRU5DRTowDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MjEyMjcw +MDA0Ng0KWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1D +RE8tSU5URU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNF +DQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6 +MQ0KWC1NSUNST1NPRlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElT +QUxMT1ctQ09VTlRFUjpGQUxTRQ0KWC1NSUNST1NPRlQtUkVRVUVTVEVEQVRURU5EQU5DRU1PREU6 +SU5QRVJTT05SRVFVSVJFRA0KWC1NSUNST1NPRlQtSVNSRVNQT05TRVJFUVVFU1RFRDpUUlVFDQpY +LU1JQ1JPU09GVC1MT0NBVElPTlM6W10NCkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046UkVNSU5E +RVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkFDVElPTjpESVNQTEFZDQpFTkQ6VkFM +QVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= + +--_000_YT3PR01MB10572EFC9F7C81F9446214768CEF72YT3PR01MB10572CA_-- -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 2/3] test/emacs: add regression test for display of calendar parts.
This will hopefully catch breakage due to either changes in Emacs (especially Gnus) or changes to the notmuch-show code. --- 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 559df8aa..438a7b9b 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -318,6 +318,28 @@ test_expect_equal "$(cat MESSAGES)" "COMPLETE" add_email_corpus attachment +test_begin_subtest "display of text/calendar" +test_emacs '(let ((notmuch-show-all-multipart/alternative-parts t)) + (notmuch-show "id:yt3pr01mb10572efc9f7c81f9446214768ce...@yt3pr01mb10572.canprd01.prod.outlook.com")) + (test-visible-output "OUTPUT")' +cat < EXPECTED +David Bremner (1970-01-01) (inbox) +Subject: test +To: "da...@tethera.net" +Date: Thu, 01 Jan 1970 00:00:00 + + +[ multipart/alternative ] +[ text/plain ] +This meeting will could have been an email +[ text/calendar ] +%%(and (diary-cyclic 1 5 27 2024) (diary-block 5 27 2024 8 27 2024)) 17:00-17:30 test [In-person] + Desc: This meeting will could have been an email + + + Organizer: mailto:brem...@example.com +EOF +test_expect_equal_file EXPECTED OUTPUT + test_begin_subtest "tar not inlined by default" test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") (test-visible-output "OUTPUT")' -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 3/3] WIP/test: add tests for rendering text/calendar parts
The second test should apparently fail, but it doesn't. --- test/T450-emacs-show.sh | 26 ++ 1 file changed, 26 insertions(+) diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh index 438a7b9b..85851e70 100755 --- a/test/T450-emacs-show.sh +++ b/test/T450-emacs-show.sh @@ -340,6 +340,32 @@ This meeting will could have been an email EOF test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest "display of text/calendar, symlinked tmpdir" +test_subtest_known_broken +mkdir real-tmp +ln -s real-tmp tmp +test_emacs "(let ((notmuch-show-all-multipart/alternative-parts t) + (temporary-file-directory \"tmp\")) + (notmuch-show \"id:yt3pr01mb10572efc9f7c81f9446214768ce...@yt3pr01mb10572.canprd01.prod.outlook.com\")) + (test-visible-output \"OUTPUT\")" +cat < EXPECTED +David Bremner (1970-01-01) (inbox) +Subject: test +To: "da...@tethera.net" +Date: Thu, 01 Jan 1970 00:00:00 + + +[ multipart/alternative ] +[ text/plain ] +This meeting will could have been an email +[ text/calendar ] +%%(and (diary-cyclic 1 5 27 2024) (diary-block 5 27 2024 8 27 2024)) 17:00-17:30 test [In-person] + Desc: This meeting will could have been an email + + + Organizer: mailto:brem...@example.com +EOF +test_expect_equal_file EXPECTED OUTPUT + test_begin_subtest "tar not inlined by default" test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at") (test-visible-output "OUTPUT")' -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
notmuch-show-insert-part-text/calendar
Dear Al; I'm not able to reproduce the problem you mention. Can you try (or look at) the tests in this series and see if the second one matches the problem you are trying to fix? d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch.el question: reading all messages in thread
Matt Armstrong writes: > Sometimes a notmuch query matches only a subset of messages in a thread. > When this happens only that subset of messages will be "open". Many > notmuch commands operate on the "open" messages only. For example: SPC, > 'n', 'p'. > > Often this is what I want. It works well when I'm looking for a > specific piece of information, or when I am interested in reading only > the unread messages in a long thread that I have seen previously. > > Often this is not what I want. I'm interested in seeing all messages > when I am looking for entire conversations where a topic is being > discussed. E.g. when I want to re-read a long forgotten thread, or one > that surfaced through specific search terms that appear only in a few of > the messages in the thread. In notmuch-show mode, M- opens all messages. > I looked for a way to easily re-query a tree view buffer such that all > messages in all threads shown are "open" but did not find it. Does this > exist? Not exactly an answer, but maybe this helps someone: In tree-mode I would suggest using "N" and "P" to ignore the open/closed status of a message. Or just move using the arrow keys / mouse and hit return on the message you want to read. If you really rarely want to the "*-matching-message" versions, then you could swap the bindings ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] test/cli: Add known broken test for (missing) quoting in From
In [1], Jakub Wilk observes that the current behaviour is confusing
since it looks like there are two mailboxes in From, while in fact
there is only one. It seems to me that notmuch should at least quote
the display-name part of a mailbox if it has "funny" characters in it,
and perhaps always quote it. Either way will require changing the
indexing code, since the structure is lost when writing the headers to
the database.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021614
---
test/T520-show.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/test/T520-show.sh b/test/T520-show.sh
index 6bcf109c..8121c3db 100755
--- a/test/T520-show.sh
+++ b/test/T520-show.sh
@@ -45,6 +45,12 @@ if [ "${NOTMUCH_HAVE_SFSEXP-0}" = "1" ]; then
fi
+test_begin_subtest "quoting in From"
+test_subtest_known_broken
+add_message '[from]="=?UTF-8?Q?=3Cfoo=40example.org=3E=2C?=
"'
+output=$(notmuch show id:${gen_msg_id}|grep From:)
+test_expect_equal "${output}" 'From: "," '
+
add_email_corpus duplicate
ID1=debian/2.6.1.dfsg-4-1-g87ea161@87ea161e851dfb1ea324af00e4ecfccc18875e15
--
2.43.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Xapian commits unexpectedly slow
Matthew Schauer writes: > > Nifty! Here are the results -- I assume you know how to interpret them > better than I do: > > T00-new.sh: Testing notmuch new [0.4 large] > Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) > Initial notmuch new 1163.05 854.26 45.97 444304 2343120/13645200 > notmuch new #22.230.020.0393842144/8 > notmuch new #30.010.010.0094600/8 > notmuch new #40.010.010.0094280/8 > notmuch new #50.010.000.0094680/8 > notmuch new #60.010.010.0096920/8 > new (52374 mv)1351.01 537.75 235.45 959524 1027288/8531616 > new (52374 mv back) 834.15 489.27 213.97 967040 184/4754016 > new (52374 cp)747.23 284.03 105.51 941992 0/4007120 > Apologies, it looks like I never replied to this thread. Probably you are not longer interested, but I can make a few observations, mainly that there are a few relevant improvements in later notmuch. 1) This is about 3x slower than my current benchmark machine [1]. My current machine is probably 4 years newer, so I would expect some improvement in performance. 2) I don't know if this is typical for spinning rust, but about about 25% of the time is (apparently) IO wait, since it it does not show up in CPU time. I do have access to a machine with both SSD and spinning rust, but the latter is in some complicated RAID formation, so I don't know how representative the results would be. 3) Some time after you reported these issues I implemented an "autocommit" parameter, which should should help avoid large Xapian large commits. 4) Your results show that notmuch new could be extra slow when dealing with moving files on disk. This should be somewhat improved by changes in notmuch 0.32 (I also see fairly dramatic impovements in notmuch-reindex relative to notmuch new, but the underlying cause is less clear). [1] e.g. https://notmuchmail.org/perf-test-results/2024-05-26-minkowski/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Multiple files per message in emacs
Rafael Ávila de Espíndola writes: > Rafael Ávila de Espíndola writes: > >>> If you can build from source, there is new support for viewing >>> duplicates in master. >> > > Just tested with 0.37 and it works. One thing that still seems to be > missing is handling different tags. For example, there is no way to mark > a new duplicated message as read. Catching up on old messages in the mailing list, I'm not sure I understand the desired behaviour. In principle if you get a second copy of the same message, it should inherit the read/unread status of the other copies (since tags are associated with message-ids). There are some known limitations/bugs with that, but they are not emacs related afaik. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Meaning of offset in notmuch search --output=files --offset=
* 2024-05-25 13:20:58+0200, Michael J. Gruber wrote: >> Teemu Likonen writes: >>> --offset=[-]N >>> Skip displaying the first N results. With the leading '-', >>> start at the Nth result from the end. >>> >>> What if we change the first sentence to "Skip displaying the first N >>> search results"? > Maybe even "Skip displaying output for the first N search results", in > an effort to hint at said difference? Yours is better than the current and mine. Thanks. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Meaning of offset in notmuch search --output=files --offset=
Am Sa., 25. Mai 2024 um 12:06 Uhr schrieb David Bremner : > > Teemu Likonen writes: > > > > >> Perhaps the manual page needs a few more words to make it clear. > > > > --offset=[-]N > > Skip displaying the first N results. With the leading '-', > > start at the Nth result from the end. > > > > What if we change the first sentence to "Skip displaying the first N > > search results"? > > For me personally that doesn't make it that much clearer, but I'm > willing to follow a concensus if there is one. ... because it was clear to you before, already ;-) Once you are aware of the conceptual difference between "search" and "output", the change makes it clearer. Maybe even "Skip displaying output for the first N search results", in an effort to hint at said difference? Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Meaning of offset in notmuch search --output=files --offset=
Teemu Likonen writes: > >> Perhaps the manual page needs a few more words to make it clear. > > --offset=[-]N > Skip displaying the first N results. With the leading '-', > start at the Nth result from the end. > > What if we change the first sentence to "Skip displaying the first N > search results"? For me personally that doesn't make it that much clearer, but I'm willing to follow a concensus if there is one. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Meaning of offset in notmuch search --output=files --offset=
* 2024-05-20 21:24:01+0300, Teemu Likonen wrote: > It doesn't seem clear how offset is counted on command like > > notmuch search --output=files --offset=10 ... > > Does it skip 10 output files (which may belong to less than 10 messages) > or does it skip 10 messages (so it possibly skips more than 10 files)? > Manual page speaks of "results" but I think it can be interpreted either > as "displayed output results" or "search match results (messages)". I tested and the answer is: --offset option skips that many search match messages. So it looks to me that command notmuch search --output=files --offset=10 ... internally lists all matched messages, skips to the offset, and then starts printing the file names of the rest of the message list. > Perhaps the manual page needs a few more words to make it clear. --offset=[-]N Skip displaying the first N results. With the leading '-', start at the Nth result from the end. What if we change the first sentence to "Skip displaying the first N search results"? -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
I added the following definitions to my init.el file, which seems to solve the problem: (defun org-notmuch-search-open (path _) "Follow a notmuch search link specified by PATH." (notmuch-search path notmuch-search-oldest-first notmuch-search-hide-excluded)) (defun notmuch-search-default(path) "Add default options to notmuch-search" (notmuch-search path notmuch-search-oldest-first notmuch-search-hide-excluded)) > On May 21, 2024, at 6:32 AM, David Bremner wrote: > > erik colson writes: > >> >> Thanks for the hint, but tried setting the var with setq-default, but >> still same issue.. : >> >> notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’. >> >> Its value is nil >> Original value was t >> Local in buffer *notmuch-saved-tree-1week and unread*; global value is t >> >> Hide mail tagged with a excluded tag. >> > > Hmm. I can't duplicate that here. Can you try with a minimal > configuration? If you have the source you can run "./devel/try-emacs-mua > -q" to run without any personal configuration. > > Another thing to try is to hit "i" in a search view and see if it > toggles properly. > > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
erik colson writes: > > Thanks for the hint, but tried setting the var with setq-default, but > still same issue.. : > > notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’. > > Its value is nil > Original value was t > Local in buffer *notmuch-saved-tree-1week and unread*; global value is t > > Hide mail tagged with a excluded tag. > Hmm. I can't duplicate that here. Can you try with a minimal configuration? If you have the source you can run "./devel/try-emacs-mua -q" to run without any personal configuration. Another thing to try is to hit "i" in a search view and see if it toggles properly. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
David Bremner writes: > It might matter how you are setting notmuch-search-hide-excluded. It > is buffer-local (that changed recently, I think) so you need to either > use customize or setq-default. Hi, Thanks for the hint, but tried setting the var with setq-default, but still same issue.. : notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’. Its value is nil Original value was t Local in buffer *notmuch-saved-tree-1week and unread*; global value is t Hide mail tagged with a excluded tag. -- erik colson - T:0475.83.75.66 BEAVER NV/SA - BE0417.279.944 Woluwelaan 8 - 1831 Diegem ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
erik colson writes: > Hi, > > I recently upgraded from an older version in which excluded tags in the > notmuch config were nicely hidden. Now I have exactly the same problem > as Stanton described. I can see notmuch-search-hide-excluded is set > globally to t, but in every search buffer it seems to be set to nil. I > can't figure what code I should change for thi to work as before.. It might matter how you are setting notmuch-search-hide-excluded. It is buffer-local (that changed recently, I think) so you need to either use customize or setq-default. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
David Bremner writes: > Richard Stanton writes: > >> I have spam and trash defined as excluded tags for notmuch searches and when >> I run (at the command line) the command >> >> notmuch search tag:unread >> >> I get a list of unread messages that does *not* include unread spam or trash >> emails. But when I put the following into my *scratch* buffer and execute it: >> >> (notmuch-search “tag:unread”) >> >> I now get ALL unread messages, including those tagged as spam or trash. Am I >> missing something? Hi, I recently upgraded from an older version in which excluded tags in the notmuch config were nicely hidden. Now I have exactly the same problem as Stanton described. I can see notmuch-search-hide-excluded is set globally to t, but in every search buffer it seems to be set to nil. I can't figure what code I should change for thi to work as before.. thx -- erik colson - T:0475.83.75.66 BEAVER NV/SA - BE0417.279.944 Woluwelaan 8 - 1831 Diegem ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Meaning of offset in notmuch search --output=files --offset=
It doesn't seem clear how offset is counted on command like notmuch search --output=files --offset=10 ... Does it skip 10 output files (which may belong to less than 10 messages) or does it skip 10 messages (so it possibly skips more than 10 files)? Manual page speaks of "results" but I think it can be interpreted either as "displayed output results" or "search match results (messages)". Perhaps the manual page needs a few more words to make it clear. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 4/4] emacs/tree: sanitize subjects when drawing tree
This fixes the bug reported in
id:6f2ef901-8b4b-44ff-83c5-22f732ba9...@gmail.com
Unfortunately it turns out our test data has several tabs in the
subject lines. The expected output was updated to reflect their
removal and the ripple effect of several more subjects matching the
previous ones.
---
emacs/notmuch-tree.el | 4 +++-
test/T460-emacs-tree.sh | 1 -
test/emacs-tree.expected-output/inbox-outline | 14 ++--
.../notmuch-tree-single-thread| 4 ++--
.../notmuch-tree-tag-inbox| 22 +--
.../notmuch-tree-tag-inbox-oldest-first | 22 +--
.../notmuch-tree-tag-inbox-tagged | 22 +--
.../notmuch-tree-tag-inbox-thread-tagged | 22 +--
.../result-format-function| 22 +--
9 files changed, 67 insertions(+), 66 deletions(-)
diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index faec89c4..2332f020 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -946,7 +946,9 @@ unchanged ADDRESS if parsing fails."
'face face)))
((string-equal field "subject")
- (let ((bare-subject (notmuch-show-strip-re (plist-get headers :Subject)))
+ (let ((bare-subject
+(notmuch-sanitize
+ (notmuch-show-strip-re (plist-get headers :Subject
(previous-subject notmuch-tree-previous-subject)
(face (if match
'notmuch-tree-match-subject-face
diff --git a/test/T460-emacs-tree.sh b/test/T460-emacs-tree.sh
index 69a9df74..4243f65a 100755
--- a/test/T460-emacs-tree.sh
+++ b/test/T460-emacs-tree.sh
@@ -223,7 +223,6 @@ test_emacs '(let ((notmuch-tree-outline-enabled t))
test_expect_equal_file $EXPECTED/notmuch-tree-tag-inbox OUTPUT
test_begin_subtest "notmuch-tree for message with subject with embedded CRNL"
-test_subtest_known_broken
add_message "[subject]=\"=?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your
=?UTF-8?Q?workout=0D=0A?=\" [body]=the-message-body"
test_emacs "(notmuch-tree \"id:${gen_msg_id}\")
(notmuch-test-wait)
diff --git a/test/emacs-tree.expected-output/inbox-outline
b/test/emacs-tree.expected-output/inbox-outline
index 9119a916..4acb62a9 100644
--- a/test/emacs-tree.expected-output/inbox-outline
+++ b/test/emacs-tree.expected-output/inbox-outline
@@ -1,24 +1,24 @@
2010-12-29 François Boulogne ─►[aur-general] Guidelines: cp, mkdir vs
install (inbox unread)
2010-12-16 Olivier Berger─►Essai accentué
(inbox unread)
2009-11-18 Chris Wilson ─►[notmuch] [PATCH 1/2] Makefile: evaluate
pkg-config once (inbox unread)
- 2009-11-18 Alex Botero-Lowry ┬►[notmuch] [PATCH] Error out if no query
is supplied to searchinstead of going into an infinite loop (attachment
inbox unread)
+ 2009-11-18 Alex Botero-Lowry ┬►[notmuch] [PATCH] Error out if no query
is supplied to search instead of going into an infinite loop (attachment inbox
unread)
2009-11-17 Ingmar Vanhassel ┬►[notmuch] [PATCH] Typsos
(inbox unread)
2009-11-17 Adrian Perez de Cast ┬►[notmuch] Introducing myself
(inbox signed unread)
2009-11-17 Israel Herraiz┬►[notmuch] New to the list
(inbox unread)
2009-11-17 Jan Janak ┬►[notmuch] What a great idea!
(inbox unread)
2009-11-17 Jan Janak ┬►[notmuch] [PATCH] Older versions of
install do not support -C. (inbox unread)
2009-11-17 Aron Griffis ┬►[notmuch] archive
(inbox unread)
- 2009-11-17 Keith Packard ┬►[notmuch] [PATCH] Make notmuch-show 'X'
(and 'x') commands removeinbox (and unread) tags (inbox unread)
+ 2009-11-17 Keith Packard ┬►[notmuch] [PATCH] Make notmuch-show 'X'
(and 'x') commands remove inbox (and unread) tags (inbox unread)
2009-11-17 Lars Kellogg-Stedman ┬►[notmuch] Working with Maildir storage?
(inbox signed unread)
- 2009-11-17 Mikhail Gusarov ┬►[notmuch] [PATCH 1/2] Close message file
after parsing message headers (inbox unread)
- 2009-11-18 Keith Packard ┬►[notmuch] [PATCH] Create a default
notmuch-show-hook thathighlights URLs and uses word-wrap (inbox unread)
+ 2009-11-17 Mikhail Gusarov ┬►[notmuch] [PATCH 1/2] Close message file
after parsing message headers (inbox unread)
+ 2009-11-18 Keith Packard ┬►[notmuch] [PATCH] Create a default
notmuch-show-hook that highlights URLs and uses word-wrap (inbox unread)
2009-11-18 Alexander Botero-Low ─►[notmuch] request for pull
(inbox unread)
2009-11-18 Jjgod Jiang ┬►[notmuch] Mac OS X/Darwin compatibility
issues (inbox unread)
2009-11-18 Rolland Santimano
[PATCH 1/4] test: re-enable duplicate UI tests in T460-emacs-tree
These were disabled (accidentally?) in f63d14a8c12a. --- test/T460-emacs-tree.sh | 2 -- 1 file changed, 2 deletions(-) diff --git a/test/T460-emacs-tree.sh b/test/T460-emacs-tree.sh index 6ef5c54a..9388a8ed 100755 --- a/test/T460-emacs-tree.sh +++ b/test/T460-emacs-tree.sh @@ -222,8 +222,6 @@ test_emacs '(let ((notmuch-tree-outline-enabled t)) # folding all messages by height or depth should look the same test_expect_equal_file $EXPECTED/notmuch-tree-tag-inbox OUTPUT -test_done - add_email_corpus duplicate ID3=87r2ecrr6x@zephyr.silentflame.com -- 2.43.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 2/4] test/emacs-show: add regression test for subjects with CR/NL
This subject is known to be problematic for notmuch-tree.
---
test/T450-emacs-show.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh
index 559df8aa..f7486e42 100755
--- a/test/T450-emacs-show.sh
+++ b/test/T450-emacs-show.sh
@@ -412,4 +412,19 @@ subject4=$(grep '^Subject:' $FILE4)
subject=$(grep '^Subject:' OUTPUT)
test_expect_equal "$subject4" "$subject"
+test_begin_subtest "notmuch-show for message with subject with embedded CRNL"
+add_message "[subject]=\"=?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your
=?UTF-8?Q?workout=0D=0A?=\" [body]=the-message-body"
+test_emacs "(notmuch-show \"id:${gen_msg_id}\")
+ (test-output \"OUTPUT.raw\")"
+cat OUTPUT
+test_expect_equal_file EXPECTED OUTPUT
+
test_done
--
2.43.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 3/4] test/emacs-tree: add known broken test for subject with CR/NL
The test is intentionally vague as it's hard to pin down the correct
output before the code is fixed.
---
test/T460-emacs-tree.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/test/T460-emacs-tree.sh b/test/T460-emacs-tree.sh
index 9388a8ed..69a9df74 100755
--- a/test/T460-emacs-tree.sh
+++ b/test/T460-emacs-tree.sh
@@ -222,6 +222,15 @@ test_emacs '(let ((notmuch-tree-outline-enabled t))
# folding all messages by height or depth should look the same
test_expect_equal_file $EXPECTED/notmuch-tree-tag-inbox OUTPUT
+test_begin_subtest "notmuch-tree for message with subject with embedded CRNL"
+test_subtest_known_broken
+add_message "[subject]=\"=?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your
=?UTF-8?Q?workout=0D=0A?=\" [body]=the-message-body"
+test_emacs "(notmuch-tree \"id:${gen_msg_id}\")
+ (notmuch-test-wait)
+ (test-output)"
+# one line of output, plus "End of search results."
+test_expect_equal "$(wc -l < OUTPUT)" 2
+
add_email_corpus duplicate
ID3=87r2ecrr6x@zephyr.silentflame.com
--
2.43.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Carriage returns in subject line cause problems in unthreaded and tree mode
On Thu, May 16 2024, Richard Stanton wrote: > Today I received an email with (raw) subject line > > Subject: =?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your > =?UTF-8?Q?workout=0D=0A?= > > When displayed in Emacs in either unthreaded or tree mode, “^M” appears after > the word “workout”, and the displayed line is split into two, like this: > > Today 07:12 Jabra️ A SALE to boost your workout^M >(important inbox) > > It would probably be a good idea to check for, and remove, carriage return > characters in the subject line. It depends how common it is to see those (ugly?) ^M characters there? ... and is it so that the Newline(=0A) splits the line in two. -- and is the behavior different in some other modes (I (mostly) just use notmuch-search and notmuch-show modes so cannot recall how other views look like... The problem would be worse if carriage return (=0D) moved the cursor to the beginning of line and following text ovewrote what were there. Tomi > (Note that the message displays fine in the default threaded mode.) > > Richard Stanton > > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Carriage returns in subject line cause problems in unthreaded and tree mode
Today I received an email with (raw) subject line Subject: =?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your =?UTF-8?Q?workout=0D=0A?= When displayed in Emacs in either unthreaded or tree mode, “^M” appears after the word “workout”, and the displayed line is split into two, like this: Today 07:12 Jabra️ A SALE to boost your workout^M (important inbox) It would probably be a good idea to check for, and remove, carriage return characters in the subject line. (Note that the message displays fine in the default threaded mode.) Richard Stanton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: I don't understand the results of this search query, is this a bug?
Hello, Thanks a lot for your answers, I'm happy to have received such thoughtful replies. Like you both pointed out, and from what I get, Notmuch works with message-ids, and since it may happen that several files in different folders have the same message-id, it explains what I was seeing. My goal was to try to sync somehow how emails on my computer are organized using Notmuch and its tags with folders on the IMAP servers of the many email accounts I'm syncing to my ~/mail dir, using mbsync. I guess this is a common endeavour some people want, so for example if you browse one of your email account using a webmail interface, or an app on your phone, then there is some continuity between how your emails are sorted on your computer and how you find them on other interfaces. But I also see that this isn't that simple to implement. Being centered on message-ids, Notmuch doesn't seem to easily be able to recognize on which email account an email is (like in cases where one of my email account send an email to another of my account, or when some of my accounts receive the same email from somewhere else... basically, when there are duplicates). I also found out that moving email files might disrupt mbsync, so it is another issue I would need to look at. I also understand the important differences between organizing emails using tags, and using folders. I just wanted to see if, with some shell scripting, I could arrange something somewhat similar. But it seems harder to do than I hoped. I am still new to Notmuch, I use it on Emacs, maybe my efforts weren't necessary, and so I will keep using it and see how my needs and preferences go. Thanks again for your replies, much appreciated! Renaud Le mar. 14 mai 2024, à 04 h 19, Michael J Gruber < michaeljgruber+grubix+...@gmail.com> a écrit : > Am Mo., 13. Mai 2024 um 23:38 Uhr schrieb Carl Worth : > > > > Hi Renaud, > > > > I was able to see similar behavior in my own mail store. And I agree > > that this behavior is confusing! > > > > The documentation for the --files option of notmuch search documents the > > cause (and predicts that this will be confusing): > > > > > In general, I'm not a fan of software documenting "this may be > > confusing". That suggests the authors of the documentation know that the > > :-) > > > software is not behaving as the user intends, so it would be preferable > > for the software to behave as intended. That said, I also understand the > > implementation details that lead to this behavior. So I wouldn't be > > opposed to improving the behavior of notmuch to reduce this behavior, > > (but that implementation might not be trivial or even fully feasible). > > I wouldn't call it an implementation detail in this case, though, > rather than the guiding principle of notmuch: it is all about > *messages* as identified by a mid. > > Consequently, notmuch stores information by message, searches by > message and outputs information by message. This in turn has > consequences, for better or worse, e.g. when different mail files with > the same mid have different (maildir) flags. But without grasping the > main guiding principle you'll get confused sooner or later. > > As soon as you introduce "do what I mean" into the CLI design the > outcome depends on the "I" implementing it, who may "mean" very > different things compared to the "I" using the CLI. This creates > confusion which cannot be resolved by pointing out a guiding > principle, but rather "when we do x it is often convenient to imply y > and that's why do z". You can witness that to some extent in git's > CLI. > > Also, dwim'ing in the case at hand seems difficult - you'd have to > extract "path:" tokens from a possibly complex query, track logical > operators applying to them and filter the output accordingly. Compare > that to "find -type f dirWhichIWant" which would have solved OP's use > case ... > > Cheers > Michael > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: I don't understand the results of this search query, is this a bug?
Am Mo., 13. Mai 2024 um 23:38 Uhr schrieb Carl Worth : > > Hi Renaud, > > I was able to see similar behavior in my own mail store. And I agree > that this behavior is confusing! > > The documentation for the --files option of notmuch search documents the > cause (and predicts that this will be confusing): > > In general, I'm not a fan of software documenting "this may be > confusing". That suggests the authors of the documentation know that the :-) > software is not behaving as the user intends, so it would be preferable > for the software to behave as intended. That said, I also understand the > implementation details that lead to this behavior. So I wouldn't be > opposed to improving the behavior of notmuch to reduce this behavior, > (but that implementation might not be trivial or even fully feasible). I wouldn't call it an implementation detail in this case, though, rather than the guiding principle of notmuch: it is all about *messages* as identified by a mid. Consequently, notmuch stores information by message, searches by message and outputs information by message. This in turn has consequences, for better or worse, e.g. when different mail files with the same mid have different (maildir) flags. But without grasping the main guiding principle you'll get confused sooner or later. As soon as you introduce "do what I mean" into the CLI design the outcome depends on the "I" implementing it, who may "mean" very different things compared to the "I" using the CLI. This creates confusion which cannot be resolved by pointing out a guiding principle, but rather "when we do x it is often convenient to imply y and that's why do z". You can witness that to some extent in git's CLI. Also, dwim'ing in the case at hand seems difficult - you'd have to extract "path:" tokens from a possibly complex query, track logical operators applying to them and filter the output accordingly. Compare that to "find -type f dirWhichIWant" which would have solved OP's use case ... Cheers Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: I don't understand the results of this search query, is this a bug?
Hi Renaud, I was able to see similar behavior in my own mail store. And I agree that this behavior is confusing! The documentation for the --files option of notmuch search documents the cause (and predicts that this will be confusing): Note that each message may have multiple filenames associ‐ ated with it. All of them are included in the output (un‐ less limited with the --duplicate=N option). This may be particularly confusing for folder: or path: searches in a specified directory, as the messages may have duplicates in other directories that are included in the output, al‐ though these files alone would not match the search. For my case, I ran a little shell-script one-liner to verify that the duplicated messages where causing this behavior. This one-liner will loop over each message-id matched by the path: pattern and will print all filenames for each: for id in $(notmuch search --output=messages path:YOUR_PATTERN_HERE); do \ echo "=== $id ==="; \ notmuch search --output=files $id; \ echo; \ done If you run the above with your own pattern substituted for YOUR_PATTERN_HERE I imagine you'll see the same thing I did, (that for any filename paths that don't match the pattern, they have a message-id which _also_ appears in the database for another path that _does_ match the pattern). In general, I'm not a fan of software documenting "this may be confusing". That suggests the authors of the documentation know that the software is not behaving as the user intends, so it would be preferable for the software to behave as intended. That said, I also understand the implementation details that lead to this behavior. So I wouldn't be opposed to improving the behavior of notmuch to reduce this behavior, (but that implementation might not be trivial or even fully feasible). Hopefully, the duplicate message-id issue explains what you're seeing. And further, I hope that you just being aware of this issue gives you a way to cleanly solve your problem, (either by filtering the output of "notmuch search --output=files" or by instead doing something along the lines of the "notmuch search --output=messages" approach I show above). Let us know if you need anything further. And good luck! -Carl On Mon, May 13 2024, Renaud B. wrote: > Hello, > > If I do: > > notmuch search --output=files path:r...@kosmopolis.ca/** > > I get the following results: > > /home/rb/.mail/r...@kosmopolis.ca/Inbox/cur/1715564710.62398_2.tp,U=2:2,S > /home/rb/.mail/ > cont...@renaudbussieres.com/Inbox/cur/1715541329.42568_1.tp,U=2:2,S > /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_6.tp,U=4:2,S > /home/rb/.mail/ > cont...@renaudbussieres.com/Inbox/cur/1714698543.61892_1.tp,U=1:2,S > /home/rb/.mail/r...@kosmopolis.ca/Inbox/cur/1715564710.62398_1.tp,U=1:2,S > /home/rb/.mail/r...@kosmopolis.ca/Trash/cur/1715564710.62398_7.tp,U=1:2,S > /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_5.tp,U=3:2,S > /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_4.tp,U=2:2,S > /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_3.tp,U=1:2,S > > As you can see, two of these files are located under "~/.mail/ > cont...@renaudbussieres.com/". It shouldn't be the case, because of the " > path:r...@kosmopolis.ca/**" which means explicitly "everything under the > ~/.mail/r...@kosmopolis.ca/ directory" (if I understand correctly). > > Likewise, if I do: > > notmuch search --output=files path:cont...@renaudbussieres.com/** > > It returns: > > /home/rb/.mail/ > cont...@renaudbussieres.com/Inbox/cur/1715541329.42568_1.tp,U=2:2,S > /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_6.tp,U=4:2,S > /home/rb/.mail/ > cont...@renaudbussieres.com/Inbox/cur/1714698543.61892_1.tp,U=1:2,S > /home/rb/.mail/r...@kosmopolis.ca/Inbox/cur/1715564710.62398_1.tp,U=1:2,S > > Again, there are 2 false results. > > Do you have any idea what's happening? My goal is simply to get all emails > under each directories in my "~/.mail" folder, one at a time. > > Thanks, > Renaud B. > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
I don't understand the results of this search query, is this a bug?
Hello, If I do: notmuch search --output=files path:r...@kosmopolis.ca/** I get the following results: /home/rb/.mail/r...@kosmopolis.ca/Inbox/cur/1715564710.62398_2.tp,U=2:2,S /home/rb/.mail/ cont...@renaudbussieres.com/Inbox/cur/1715541329.42568_1.tp,U=2:2,S /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_6.tp,U=4:2,S /home/rb/.mail/ cont...@renaudbussieres.com/Inbox/cur/1714698543.61892_1.tp,U=1:2,S /home/rb/.mail/r...@kosmopolis.ca/Inbox/cur/1715564710.62398_1.tp,U=1:2,S /home/rb/.mail/r...@kosmopolis.ca/Trash/cur/1715564710.62398_7.tp,U=1:2,S /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_5.tp,U=3:2,S /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_4.tp,U=2:2,S /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_3.tp,U=1:2,S As you can see, two of these files are located under "~/.mail/ cont...@renaudbussieres.com/". It shouldn't be the case, because of the " path:r...@kosmopolis.ca/**" which means explicitly "everything under the ~/.mail/r...@kosmopolis.ca/ directory" (if I understand correctly). Likewise, if I do: notmuch search --output=files path:cont...@renaudbussieres.com/** It returns: /home/rb/.mail/ cont...@renaudbussieres.com/Inbox/cur/1715541329.42568_1.tp,U=2:2,S /home/rb/.mail/r...@kosmopolis.ca/Sent/cur/1715564710.62398_6.tp,U=4:2,S /home/rb/.mail/ cont...@renaudbussieres.com/Inbox/cur/1714698543.61892_1.tp,U=1:2,S /home/rb/.mail/r...@kosmopolis.ca/Inbox/cur/1715564710.62398_1.tp,U=1:2,S Again, there are 2 false results. Do you have any idea what's happening? My goal is simply to get all emails under each directories in my "~/.mail" folder, one at a time. Thanks, Renaud B. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[emacs] getting the text part of the body programmatically
Hello, The emacs interface to notmuch is great in helping me collect messages from a public mailing list for a newsletter. I’m trying to automate more of it, and I wonder if there is a way to get the text of the message body programmatically in notmuch-show-mode. This is what I am doing currently: (defun as/notmuch-get-body () (let* ((msg (notmuch-show-get-message-properties)) (part (notmuch-show-get-part-properties))) (notmuch-get-bodypart-text msg part nil))) It works, but I first have to put the cursor in the part for the `notmuch-show-get-part-properties' to work. Is there a way to get the text part of the body without moving the cursor (i.e., when it is still in the headers)? Thanks, Alan signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Hiding text/plain with notmuch-multipart/alternative-discouraged
Jon Fineman writes:
> I see that if I set this variable to the below value it will hide
> text/plain, which is what I would like.
>
> notmuch-multipart/alternative-discouraged '("text/plain" "multipart/related")
>
> However I see that when I forward an email that has a text/plain part
> that part does not show up in the forwarded email. Just the text/html
> part.
>
> Is there a way to hide parts while displaying an email and not hide or
> hide different parts when forwarding?
>
> Thanks.
>
> Jon
>
I was testing this further and was not able to recreate it. So
apparently I must have been hallucinating. Sorry for the noise.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Hiding text/plain with notmuch-multipart/alternative-discouraged
I see that if I set this variable to the below value it will hide
text/plain, which is what I would like.
notmuch-multipart/alternative-discouraged '("text/plain" "multipart/related")
However I see that when I forward an email that has a text/plain part
that part does not show up in the forwarded email. Just the text/html
part.
Is there a way to hide parts while displaying an email and not hide or
hide different parts when forwarding?
Thanks.
Jon
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[RFC PATCH] CLI/reply: Remove Received by domain From detection
This creates too many false positives in a world with huge free mail
providers. Using Gmail as the foremost example: Many people have Gmail
accounts. If a user with a secondary Gmail account imports mail from a
list archive (meaning none of their personal addresses will be present
in the messages) and then uses a Notmuch client to reply to a message
that was sent by a Gmail user, their own secondary Gmail account will be
used.
It gets worse with organizations who pay Microsoft to host their email.
If a user imports a message from ubc.ca and replies to it, their
secondary outlook.com address will be used because ubc.ca email
currently happens to be provided by Microsoft through their outlook.com
servers. For users unfamiliar with the internal details of email
protocols, this behavior is inscrutable.
In these scenarios, it makes more sense to fall back to the user’s
configured primary address, particularly because the primary address
/will/ be used when replying to any messages that do not happen to
involve a sender who uses the same email provider as one of the user’s
secondary addresses. To new users who aren’t familiar with the internal
details of notmuch-reply, it will appear as though their secondary
addresses are used intermittently when composing replies to imported
mail for no apparent reason.
This function theoretically adds value for users with multiple addresses
who want to use a secondary address when replying to imported mail from
a list hosted on the same infrastructure as the secondary address (e.g.
someone wants to use their gnu.org email address to reply “with their
GNU hat on” to imported messages from gnu.org lists). But such users are
also more likely to be outright subscribed to such lists anyway.
Therefore, it seems preferable to reduce confusion for the much more
common use case by making From address discovery “dumber” but more
predictable.
---
Hi Notmuch developers,
I have secondary Gmail and Outlook.com accounts and ran into this
confusing behavior. I’m by no means an email expert and could definitely
be missing use cases for the original behavior, so let me know what you
think.
Also, I made the tests pass in the lowest-effort way possible; if the
patch makes sense, let me know if you prefer something else.
notmuch-reply.c| 74 --
test/T280-from-guessing.sh | 2 +-
2 files changed, 1 insertion(+), 75 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 44297251..bce38b23 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -144,15 +144,6 @@ user_address_in_string (const char *str,
notmuch_database_t *notmuch)
return address_match (str, notmuch, USER_ADDRESS_IN_STRING);
}
-/* Do any of the addresses configured as one of the user's "primary"
- * or "other" addresses contain the given string. If so, return the
- * matching address, NULL otherwise. */
-static const char *
-string_in_user_address (const char *str, notmuch_database_t *notmuch)
-{
-return address_match (str, notmuch, STRING_IN_USER_ADDRESS);
-}
-
/* Is the given address configured as one of the user's "primary" or
* "other" addresses. */
static bool
@@ -396,69 +387,6 @@ guess_from_in_received_for (notmuch_database_t *notmuch,
const char *received)
return user_address_in_string (ptr, notmuch);
}
-/*
- * Parse all the " by MTA ..." parts in received headers to guess the
- * email address that this was originally delivered to.
- *
- * Extract just the MTA here by removing leading whitespace and
- * assuming that the MTA name ends at the next whitespace. Test for
- * *(by+4) to be non-'\0' to make sure there's something there at all
- * - and then assume that the first whitespace delimited token that
- * follows is the receiving system in this step of the receive chain.
- *
- * Return the address that was found, if any, and NULL otherwise.
- */
-static const char *
-guess_from_in_received_by (notmuch_database_t *notmuch, const char *received)
-{
-const char *addr;
-const char *by = received;
-char *domain, *tld, *mta, *ptr, *token;
-
-while ((by = strstr (by, " by ")) != NULL) {
- by += 4;
- if (*by == '\0')
- break;
- mta = xstrdup (by);
- token = strtok (mta, " \t");
- if (token == NULL) {
- free (mta);
- break;
- }
- /*
-* Now extract the last two components of the MTA host name as
-* domain and tld.
-*/
- domain = tld = NULL;
- while ((ptr = strsep (, ". \t")) != NULL) {
- if (*ptr == '\0')
- continue;
- domain = tld;
- tld = ptr;
- }
-
- if (domain) {
- /*
-* Recombine domain and tld and look for it among the
-* configured email addresses. This time we have a known
-* domain name and nothing else - so the test is the other
-* way around: we check if this is a substring of one of
-
`notmuch-message-headers` interpreted case-sensitively
Hello! Not sure if this is a bug or intentional behaviour but it did surprise me: When I added "Message-Id" to `notmuch-message-headers` I noticed that sometimes the header would be shown and sometimes not. It turns out that some MUAs generate the header as "Message-Id" and others as "Message-ID" with a slightly different capitalization. Only when I included both, "Message-Id" and "Message-ID", in `notmuch-message-headers` I was able to workaround this issue. the culprit seems to be the function below which does no attempt to retrieve the respective header case-insensitively via `plist-get` as it constructs a symbol :Message-Id or :Message-id respectively which are not equal as the `eq` comparison is used by default: --8<---cut here---start->8--- (defun notmuch-show-insert-headers (headers) "Insert the headers of the current message." (let ((start (point))) (mapc (lambda (header) (let* ((header-symbol (intern (concat ":" header))) (header-value (plist-get headers header-symbol))) (when (and header-value (not (string-equal "" header-value))) (notmuch-show-insert-header header header-value notmuch-message-headers) (save-excursion (save-restriction (narrow-to-region start (point-max)) (run-hooks 'notmuch-show-markup-headers-hook) --8<---cut here---end--->8--- ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [BUG] Custom headers in `notmuch-message-headers` are broken
>> The end result is that `notmuch-message-headers` variable has no effect.
> Not sure if you are still interested, but this should be fixed in
> notmuch 0.35 (see show.extra_headers in notmuch-config(1)).
I just stumbled over this issue when trying to add "Message-Id" to the
list of shown messages as the docstring of the custom variable
definition in 'notmuch-show.el' didn't mention that I needed to tweak my
config or that only a small subset of headers might be supported:
--8<---cut here---start->8---
(defcustom notmuch-message-headers '("Subject" "To" "Cc" "Date")
"Headers that should be shown in a message, in this order.
For an open message, all of these headers will be made visible
according to `notmuch-message-headers-visible' or can be toggled
with `notmuch-show-toggle-visibility-headers'. For a closed message,
only the first header in the list will be visible."
:type '(repeat string)
:group 'notmuch-show)
--8<---cut here---end--->8---
I suggest adding a hint there that tweaking 'show.extra_headers' might
be necessary.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] emacs: Allow customizing :excluded in notmuch-saved-searches
From: Mohsin Kaleem --- emacs/notmuch-hello.el | 6 ++ 1 file changed, 6 insertions(+) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index b6d1e2ae..b3228d43 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -116,6 +116,12 @@ searches so they still work in customize." (const :tag "Default" nil) (const :tag "Oldest-first" oldest-first) (const :tag "Newest-first" newest-first))) +(group :format "%v" :inline t + (const :format "" :excluded) + (choice :tag " Hide Excluded" + (const :tag "Default" nil) + (const :tag "Hide" hide) + (const :tag "Show" show))) (group :format "%v" :inline t (const :format "" :search-type) (choice :tag " Search Type" -- 2.44.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
In case anyone else is affected by this, the problem I was having was that notmuch-search org links (defined in ol-notmuch.el) were returning results that included spam and trash messages even though I had asked to exclude these. To get around this, redefine org-notmuch-search-open to explicitly pass some additional options to notmuch-search: (defun org-notmuch-search-open (path _) "Follow a notmuch search link specified by PATH." (notmuch-search path notmuch-search-oldest-first notmuch-search-hide-excluded)) > On Apr 16, 2024, at 3:53 PM, Richard H. Stanton > wrote: > > Actually, I think the code might be working as intended. Calling > notmuch-search interactively things work just fine, and in the comments I see > the note > > "When called interactively, this will prompt for a query and use the > configured default sort order.” > > This sounds like it deliberately ignores the default settings when the > function is called non-interactively, but why…? > > > > > >> On Apr 16, 2024, at 3:40 PM, Richard H. Stanton >> wrote: >> >> I used edebug to trace through the execution of notmuch-search in notmuch.el. >> >> At line 1096, we have the code >> >> (let ((proc (notmuch-start-notmuch >>"notmuch-search" buffer #'notmuch-search-process-sentinel >>"search" "--format=sexp" "--format-version=5" >>(if oldest-first >> "--sort=oldest-first" >> "--sort=newest-first") >>(if hide-excluded >> "--exclude=true" >> "--exclude=false") >>query))) >> >> I think the problem is the line >> >> (If hide-excluded >> >> This is the (optional) argument passed to notmuch-search. If it was not >> passed, this test fails and “—exclude=false” gets selected. I think we’re >> testing the wrong variable here. It looks like it should be >> >> (If notmuch-search-hide-excluded >> >> instead, since this variable is set to its default value if no argument is >> passed to notmuch-search. >> >> [Similarly with the preceding test for oldest-first, I think.] >> >> >> >> >> >>> On Apr 16, 2024, at 3:22 PM, Richard H. Stanton >>> wrote: >>> >>> Running >>> >>> (notmuch-search "tag:unread" t t) >>> >>> gives the correct results, so it looks like notmuch-search-hide-excluded is >>> not getting set to the correct default value. >>> On Apr 16, 2024, at 3:15 PM, Richard H. Stanton wrote: Oh, wait… It's not working on my office machine either. I’ll start tracing things and see what happens. By the way, (notmuch-config-get "search.exclude_tags”) returns "spam trash" which is what it should be returning. > On Apr 16, 2024, at 12:00 PM, Richard H. Stanton > wrote: > > Thanks, David. > > It all seems to be working fine on my work machine! > > I can’t decide if that’s good or bad news… I suspect it’ll take me longer > to track down what’s going on than if the behavior were consistent on my > two machines. > >> On Apr 16, 2024, at 7:23 AM, David Bremner wrote: >> >> Richard Stanton writes: >> >>> I have spam and trash defined as excluded tags for notmuch searches and >>> when I run (at the command line) the command >>> >>> notmuch search tag:unread >>> >>> I get a list of unread messages that does *not* include unread spam or >>> trash emails. But when I put the following into my *scratch* buffer and >>> execute it: >>> >>> (notmuch-search “tag:unread”) >>> >>> I now get ALL unread messages, including those tagged as spam or trash. >>> Am I missing something? >> >> Hi Richard; >> >> As for as I know it _should_ work (modulo the curly quotes being invalid >> syntax). I don't have any real hypothesis for what is going wrong, but a >> few ideas for gather data. >> >> 1) As a start, maybe try evaluating >> >> (notmuch-config-get "search.exclude_tags") >> >> in emacs and make sure it matches the corresponding >> >> notmuch config get search.exclude_tags >> >> 2) If possible, run notmuch with a minimal configuration (i.e. just >> loading >> notmuch, no personal configuration or other packages). There is a script >> ./devel/try-emacs-mua in the source if you have a self-built notmuch. > >>> >> > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
Actually, I think the code might be working as intended. Calling notmuch-search interactively things work just fine, and in the comments I see the note "When called interactively, this will prompt for a query and use the configured default sort order.” This sounds like it deliberately ignores the default settings when the function is called non-interactively, but why…? > On Apr 16, 2024, at 3:40 PM, Richard H. Stanton > wrote: > > I used edebug to trace through the execution of notmuch-search in notmuch.el. > > At line 1096, we have the code > > (let ((proc (notmuch-start-notmuch > "notmuch-search" buffer #'notmuch-search-process-sentinel > "search" "--format=sexp" "--format-version=5" > (if oldest-first > "--sort=oldest-first" > "--sort=newest-first") > (if hide-excluded > "--exclude=true" > "--exclude=false") > query))) > > I think the problem is the line > > (If hide-excluded > > This is the (optional) argument passed to notmuch-search. If it was not > passed, this test fails and “—exclude=false” gets selected. I think we’re > testing the wrong variable here. It looks like it should be > > (If notmuch-search-hide-excluded > > instead, since this variable is set to its default value if no argument is > passed to notmuch-search. > > [Similarly with the preceding test for oldest-first, I think.] > > > > > >> On Apr 16, 2024, at 3:22 PM, Richard H. Stanton >> wrote: >> >> Running >> >> (notmuch-search "tag:unread" t t) >> >> gives the correct results, so it looks like notmuch-search-hide-excluded is >> not getting set to the correct default value. >> >>> On Apr 16, 2024, at 3:15 PM, Richard H. Stanton >>> wrote: >>> >>> Oh, wait… It's not working on my office machine either. I’ll start tracing >>> things and see what happens. >>> >>> By the way, >>> >>> (notmuch-config-get "search.exclude_tags”) >>> >>> returns >>> >>> "spam >>> trash" >>> >>> which is what it should be returning. >>> On Apr 16, 2024, at 12:00 PM, Richard H. Stanton wrote: Thanks, David. It all seems to be working fine on my work machine! I can’t decide if that’s good or bad news… I suspect it’ll take me longer to track down what’s going on than if the behavior were consistent on my two machines. > On Apr 16, 2024, at 7:23 AM, David Bremner wrote: > > Richard Stanton writes: > >> I have spam and trash defined as excluded tags for notmuch searches and >> when I run (at the command line) the command >> >> notmuch search tag:unread >> >> I get a list of unread messages that does *not* include unread spam or >> trash emails. But when I put the following into my *scratch* buffer and >> execute it: >> >> (notmuch-search “tag:unread”) >> >> I now get ALL unread messages, including those tagged as spam or trash. >> Am I missing something? > > Hi Richard; > > As for as I know it _should_ work (modulo the curly quotes being invalid > syntax). I don't have any real hypothesis for what is going wrong, but a > few ideas for gather data. > > 1) As a start, maybe try evaluating > >(notmuch-config-get "search.exclude_tags") > > in emacs and make sure it matches the corresponding > > notmuch config get search.exclude_tags > > 2) If possible, run notmuch with a minimal configuration (i.e. just > loading > notmuch, no personal configuration or other packages). There is a script > ./devel/try-emacs-mua in the source if you have a self-built notmuch. >>> >> > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
I used edebug to trace through the execution of notmuch-search in notmuch.el. At line 1096, we have the code (let ((proc (notmuch-start-notmuch "notmuch-search" buffer #'notmuch-search-process-sentinel "search" "--format=sexp" "--format-version=5" (if oldest-first "--sort=oldest-first" "--sort=newest-first") (if hide-excluded "--exclude=true" "--exclude=false") query))) I think the problem is the line (If hide-excluded This is the (optional) argument passed to notmuch-search. If it was not passed, this test fails and “—exclude=false” gets selected. I think we’re testing the wrong variable here. It looks like it should be (If notmuch-search-hide-excluded instead, since this variable is set to its default value if no argument is passed to notmuch-search. [Similarly with the preceding test for oldest-first, I think.] > On Apr 16, 2024, at 3:22 PM, Richard H. Stanton > wrote: > > Running > > (notmuch-search "tag:unread" t t) > > gives the correct results, so it looks like notmuch-search-hide-excluded is > not getting set to the correct default value. > >> On Apr 16, 2024, at 3:15 PM, Richard H. Stanton >> wrote: >> >> Oh, wait… It's not working on my office machine either. I’ll start tracing >> things and see what happens. >> >> By the way, >> >> (notmuch-config-get "search.exclude_tags”) >> >> returns >> >> "spam >> trash" >> >> which is what it should be returning. >> >>> On Apr 16, 2024, at 12:00 PM, Richard H. Stanton >>> wrote: >>> >>> Thanks, David. >>> >>> It all seems to be working fine on my work machine! >>> >>> I can’t decide if that’s good or bad news… I suspect it’ll take me longer >>> to track down what’s going on than if the behavior were consistent on my >>> two machines. >>> On Apr 16, 2024, at 7:23 AM, David Bremner wrote: Richard Stanton writes: > I have spam and trash defined as excluded tags for notmuch searches and > when I run (at the command line) the command > > notmuch search tag:unread > > I get a list of unread messages that does *not* include unread spam or > trash emails. But when I put the following into my *scratch* buffer and > execute it: > > (notmuch-search “tag:unread”) > > I now get ALL unread messages, including those tagged as spam or trash. > Am I missing something? Hi Richard; As for as I know it _should_ work (modulo the curly quotes being invalid syntax). I don't have any real hypothesis for what is going wrong, but a few ideas for gather data. 1) As a start, maybe try evaluating (notmuch-config-get "search.exclude_tags") in emacs and make sure it matches the corresponding notmuch config get search.exclude_tags 2) If possible, run notmuch with a minimal configuration (i.e. just loading notmuch, no personal configuration or other packages). There is a script ./devel/try-emacs-mua in the source if you have a self-built notmuch. >>> >> > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
Running (notmuch-search "tag:unread" t t) gives the correct results, so it looks like notmuch-search-hide-excluded is not getting set to the correct default value. > On Apr 16, 2024, at 3:15 PM, Richard H. Stanton > wrote: > > Oh, wait… It's not working on my office machine either. I’ll start tracing > things and see what happens. > > By the way, > > (notmuch-config-get "search.exclude_tags”) > > returns > > "spam > trash" > > which is what it should be returning. > >> On Apr 16, 2024, at 12:00 PM, Richard H. Stanton >> wrote: >> >> Thanks, David. >> >> It all seems to be working fine on my work machine! >> >> I can’t decide if that’s good or bad news… I suspect it’ll take me longer to >> track down what’s going on than if the behavior were consistent on my two >> machines. >> >>> On Apr 16, 2024, at 7:23 AM, David Bremner wrote: >>> >>> Richard Stanton writes: >>> I have spam and trash defined as excluded tags for notmuch searches and when I run (at the command line) the command notmuch search tag:unread I get a list of unread messages that does *not* include unread spam or trash emails. But when I put the following into my *scratch* buffer and execute it: (notmuch-search “tag:unread”) I now get ALL unread messages, including those tagged as spam or trash. Am I missing something? >>> >>> Hi Richard; >>> >>> As for as I know it _should_ work (modulo the curly quotes being invalid >>> syntax). I don't have any real hypothesis for what is going wrong, but a >>> few ideas for gather data. >>> >>> 1) As a start, maybe try evaluating >>> >>> (notmuch-config-get "search.exclude_tags") >>> >>> in emacs and make sure it matches the corresponding >>> >>> notmuch config get search.exclude_tags >>> >>> 2) If possible, run notmuch with a minimal configuration (i.e. just loading >>> notmuch, no personal configuration or other packages). There is a script >>> ./devel/try-emacs-mua in the source if you have a self-built notmuch. >> > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
Oh, wait… It's not working on my office machine either. I’ll start tracing things and see what happens. By the way, (notmuch-config-get "search.exclude_tags”) returns "spam trash" which is what it should be returning. > On Apr 16, 2024, at 12:00 PM, Richard H. Stanton > wrote: > > Thanks, David. > > It all seems to be working fine on my work machine! > > I can’t decide if that’s good or bad news… I suspect it’ll take me longer to > track down what’s going on than if the behavior were consistent on my two > machines. > >> On Apr 16, 2024, at 7:23 AM, David Bremner wrote: >> >> Richard Stanton writes: >> >>> I have spam and trash defined as excluded tags for notmuch searches and >>> when I run (at the command line) the command >>> >>> notmuch search tag:unread >>> >>> I get a list of unread messages that does *not* include unread spam or >>> trash emails. But when I put the following into my *scratch* buffer and >>> execute it: >>> >>> (notmuch-search “tag:unread”) >>> >>> I now get ALL unread messages, including those tagged as spam or trash. Am >>> I missing something? >> >> Hi Richard; >> >> As for as I know it _should_ work (modulo the curly quotes being invalid >> syntax). I don't have any real hypothesis for what is going wrong, but a >> few ideas for gather data. >> >> 1) As a start, maybe try evaluating >> >> (notmuch-config-get "search.exclude_tags") >> >> in emacs and make sure it matches the corresponding >> >> notmuch config get search.exclude_tags >> >> 2) If possible, run notmuch with a minimal configuration (i.e. just loading >> notmuch, no personal configuration or other packages). There is a script >> ./devel/try-emacs-mua in the source if you have a self-built notmuch. > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
Thanks, David. It all seems to be working fine on my work machine! I can’t decide if that’s good or bad news… I suspect it’ll take me longer to track down what’s going on than if the behavior were consistent on my two machines. > On Apr 16, 2024, at 7:23 AM, David Bremner wrote: > > Richard Stanton writes: > >> I have spam and trash defined as excluded tags for notmuch searches and when >> I run (at the command line) the command >> >> notmuch search tag:unread >> >> I get a list of unread messages that does *not* include unread spam or trash >> emails. But when I put the following into my *scratch* buffer and execute it: >> >> (notmuch-search “tag:unread”) >> >> I now get ALL unread messages, including those tagged as spam or trash. Am I >> missing something? > > Hi Richard; > > As for as I know it _should_ work (modulo the curly quotes being invalid > syntax). I don't have any real hypothesis for what is going wrong, but a > few ideas for gather data. > > 1) As a start, maybe try evaluating > >(notmuch-config-get "search.exclude_tags") > > in emacs and make sure it matches the corresponding > > notmuch config get search.exclude_tags > > 2) If possible, run notmuch with a minimal configuration (i.e. just loading > notmuch, no personal configuration or other packages). There is a script > ./devel/try-emacs-mua in the source if you have a self-built notmuch. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch-search not excluding excluded tags
Richard Stanton writes: > I have spam and trash defined as excluded tags for notmuch searches and when > I run (at the command line) the command > > notmuch search tag:unread > > I get a list of unread messages that does *not* include unread spam or trash > emails. But when I put the following into my *scratch* buffer and execute it: > > (notmuch-search “tag:unread”) > > I now get ALL unread messages, including those tagged as spam or trash. Am I > missing something? Hi Richard; As for as I know it _should_ work (modulo the curly quotes being invalid syntax). I don't have any real hypothesis for what is going wrong, but a few ideas for gather data. 1) As a start, maybe try evaluating (notmuch-config-get "search.exclude_tags") in emacs and make sure it matches the corresponding notmuch config get search.exclude_tags 2) If possible, run notmuch with a minimal configuration (i.e. just loading notmuch, no personal configuration or other packages). There is a script ./devel/try-emacs-mua in the source if you have a self-built notmuch. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
notmuch-search not excluding excluded tags
I have spam and trash defined as excluded tags for notmuch searches and when I run (at the command line) the command notmuch search tag:unread I get a list of unread messages that does *not* include unread spam or trash emails. But when I put the following into my *scratch* buffer and execute it: (notmuch-search “tag:unread”) I now get ALL unread messages, including those tagged as spam or trash. Am I missing something? Thanks. Richard Stanton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[emacs] handle unexpected stderr output from notmuch command
TIL that the running the notmuch command from inside "proxychains4 emacs", generates unexpected output on stderr, which messes up various emacs commands. This can be worked around by running "proxychains4 -q emacs", but it would be nice to handle output on stderr more consistently. I got as far as localizing the bug in notmuch-command-to-string. PS. Now you see why we went such effort not to have the notmuch library print to stderr. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
