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
[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
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
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
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
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
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
Re: How to move from end of one thread to beginning of next by pressing "n"?
Jon Fineman writes: > Jon Fineman writes: > >> "Richard H. Stanton" writes: >> >>> I’ve recently installed notmuch with lieer and now have it successfully >>> bringing my mail over from gmail so I can read it locally inside Emacs. >>> This is very nice, and I particularly love the speed of notmuch’s searches. >>> However, I’m not seeing how to get notmuch to do something that seems >>> desirable (and obvious) to me: >>> >>> If I press RETURN to view a message, “n” and “p” move to the next/previous >>> message *in the thread*, but motion with “n” stops when you get to the end >>> of the thread. Is there a way to set things so that “n” moves from the end >>> of the current thread to the beginning of the next? This would make going >>> through my emails a lot more convenient, especially as most of my “threads” >>> only have one message in them. >>> >>> Thanks for any suggestions. >>> >>> Richard Stanton >>> ___ >>> notmuch mailing list -- notmuch@notmuchmail.org >>> To unsubscribe send an email to notmuch-le...@notmuchmail.org >> >> For me it is capital "N" and "P", (notmuch-show-next-message), >> (notmuch-show-previous-message). > > I am sorry, I goofed. > > It is M-p (notmuch-show-previous-thread-show) and M-n > (notmuch-show-next-thread-show) > > As far as I can tell it comes mapped to those keys. That works! Thanks, Jon. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to move from end of one thread to beginning of next by pressing "n"?
Jon Fineman writes: > "Richard H. Stanton" writes: > >> I’ve recently installed notmuch with lieer and now have it successfully >> bringing my mail over from gmail so I can read it locally inside Emacs. This >> is very nice, and I particularly love the speed of notmuch’s searches. >> However, I’m not seeing how to get notmuch to do something that seems >> desirable (and obvious) to me: >> >> If I press RETURN to view a message, “n” and “p” move to the next/previous >> message *in the thread*, but motion with “n” stops when you get to the end >> of the thread. Is there a way to set things so that “n” moves from the end >> of the current thread to the beginning of the next? This would make going >> through my emails a lot more convenient, especially as most of my “threads” >> only have one message in them. >> >> Thanks for any suggestions. >> >> Richard Stanton >> ___ >> notmuch mailing list -- notmuch@notmuchmail.org >> To unsubscribe send an email to notmuch-le...@notmuchmail.org > > For me it is capital "N" and "P", (notmuch-show-next-message), > (notmuch-show-previous-message). I am sorry, I goofed. It is M-p (notmuch-show-previous-thread-show) and M-n (notmuch-show-next-thread-show) As far as I can tell it comes mapped to those keys. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to move from end of one thread to beginning of next by pressing "n"?
Is there a way to have all searches use tree mode by default? I know I can set this as part of each individual search, but it would save typing if there were a setting to make this the default. > On Apr 8, 2024, at 10:26 AM, Richard H. Stanton > wrote: > > Thanks, Carl. Using tree mode seems to solve my problem. > >> On Apr 8, 2024, at 10:23 AM, Carl Worth wrote: >> >> On Mon, Apr 08 2024, Richard H. Stanton wrote: >>> If I press RETURN to view a message, “n” and “p” move to the >>> next/previous message *in the thread*, but motion with “n” stops when >>> you get to the end of the thread. Is there a way to set things so that >>> “n” moves from the end of the current thread to the beginning of the >>> next? This would make going through my emails a lot more convenient, >>> especially as most of my “threads” only have one message in them. >> >> I don't think that exists as a current option. >> >> You can use the space bar to advance to the next thread. >> >> -Carl > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to move from end of one thread to beginning of next by pressing "n"?
"Richard H. Stanton" writes: > I’ve recently installed notmuch with lieer and now have it successfully > bringing my mail over from gmail so I can read it locally inside Emacs. This > is very nice, and I particularly love the speed of notmuch’s searches. > However, I’m not seeing how to get notmuch to do something that seems > desirable (and obvious) to me: > > If I press RETURN to view a message, “n” and “p” move to the next/previous > message *in the thread*, but motion with “n” stops when you get to the end of > the thread. Is there a way to set things so that “n” moves from the end of > the current thread to the beginning of the next? This would make going > through my emails a lot more convenient, especially as most of my “threads” > only have one message in them. > > Thanks for any suggestions. > > Richard Stanton > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org For me it is capital "N" and "P", (notmuch-show-next-message), (notmuch-show-previous-message). ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to move from end of one thread to beginning of next by pressing "n"?
Thanks, Carl. Using tree mode seems to solve my problem. > On Apr 8, 2024, at 10:23 AM, Carl Worth wrote: > > On Mon, Apr 08 2024, Richard H. Stanton wrote: >> If I press RETURN to view a message, “n” and “p” move to the >> next/previous message *in the thread*, but motion with “n” stops when >> you get to the end of the thread. Is there a way to set things so that >> “n” moves from the end of the current thread to the beginning of the >> next? This would make going through my emails a lot more convenient, >> especially as most of my “threads” only have one message in them. > > I don't think that exists as a current option. > > You can use the space bar to advance to the next thread. > > -Carl ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: How to move from end of one thread to beginning of next by pressing "n"?
On Mon, Apr 08 2024, Richard H. Stanton wrote: > If I press RETURN to view a message, “n” and “p” move to the > next/previous message *in the thread*, but motion with “n” stops when > you get to the end of the thread. Is there a way to set things so that > “n” moves from the end of the current thread to the beginning of the > next? This would make going through my emails a lot more convenient, > especially as most of my “threads” only have one message in them. I don't think that exists as a current option. You can use the space bar to advance to the next thread. -Carl ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] perf-test/tag: add maildir sync tests
David Bremner writes: > Today someone asked me the (reasonable) question of how much > performance impact there is from synching tags to maildir flags. It > turns out it is noticeable, about a 50% overhead compared to > non-synched tags (according to these tests). In practice I don't know > if it's a big problem for users, since I don't know what fraction of > tagging operations involve "special" tags. Applied to master. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Hi there, > I might be wrong, but I don't think the Gnus agent can be easily reused > from notmuch. We could perhaps save the message as a draft upon C-c C-j, > and then have a periodic timer that checks if any of the drafts has > expired (maybe using a special, additional tag for the search) and send > it? I have solved this myself using `gnus-delay-article` as a basis. I am attaching here my current code, it is my intention to (time permitting) turn this over a patch for inclusion into notmuch itself. What is preventing such patch right now: - Writting tests, - I'm trying to find something like `killing-new-buffers` builtin but will probably just include the code. A side of the attached file you will need the `killing-new-buffers` macro, pasted below. (defmacro killing-new-buffers ( body) "Run BODY and kill any buffers that were not already open." (declare (debug t)) (cl-with-gensyms (initial-buffers) `(let ((,initial-buffers (buffer-list))) (unwind-protect ,(macroexp-progn body) (dolist (b (buffer-list)) (unless (memq b ,initial-buffers) (kill-buffer b))) Hope this helps, marc notmuch-delay.el Description: application/emacs-lisp ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Mark "notmuch-tree" command for autoloading
Dmitry Bogatov writes: > Some people (e.g: me) prefer to read their email with threaded > representation by default. > Applied to master. 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
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 ___ 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 all, El dom. 24 de mar. 2024, Marc escribió: > I am attaching a new patch that includes an additional test on > T630-emacs-draft.sh. > > On the test only `References` is at the top (hence hidden by emacs), not > `In-Reply-To`. I guess that does rely on some configuration. > > In any case, the test reproduces the problem (lost headers on draft > save), and the patch fixes it! Following up on this, has anyone had a chance to review the proposed patch (the one including tests)? Let me know if there's anything else I can do to get the fix into notmuch! Marc ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Hi there, > I might be wrong, but I don't think the Gnus agent can be easily reused > from notmuch. We could perhaps save the message as a draft upon C-c C-j, > and then have a periodic timer that checks if any of the drafts has > expired (maybe using a special, additional tag for the search) and send > it? I have solved this myself using `gnus-delay-article` as a basis. I am attaching here my current code, it is my intention to (time permitting) turn this over a patch for inclusion into notmuch itself. What is preventing such patch right now: - Writting tests, - I'm trying to find something like `killing-new-buffers` builtin but will probably just include the code. A side of the attached file you will need the `killing-new-buffers` macro, pasted below. (defmacro killing-new-buffers ( body) "Run BODY and kill any buffers that were not already open." (declare (debug t)) (cl-with-gensyms (initial-buffers) `(let ((,initial-buffers (buffer-list))) (unwind-protect ,(macroexp-progn body) (dolist (b (buffer-list)) (unless (memq b ,initial-buffers) (kill-buffer b))) Hope this helps, marc notmuch-delay.el Description: application/emacs-lisp ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
João Pedro writes: > Ah, indeed message properties seem to be more appropriate. Are they > persisted, or are they tied to an Emacs session? They are persisted in the database, and backed up with notmuch dump. > >> but your periodic search would still have to search for all of the >> scheduled=time properties (wildcard search is currently only supported >> using s-exp queries). > > How about having a list of '(MESSAGE-ID . SCHEDULED-TIME), with the > periodic check looking in that list for the scheduled times? It would > have the issue of it not being persistent between Emacs sessions, but I > think that could be addressed by letting the users know this lack of > persistance, and documenting how you could achieve it with > `savehist-additional-variables'. One advantage of doing it outside emacs (in the notmuch database) is that you could have the delivery also managed outside emacs. So cron / systemd-timer / whatever. I guess the downside is it might be more work to prototype. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Em quarta, 03/04/2024 às 07:06 (-03), David Bremner escreveu: > Message properties might work a bit better than tags Ah, indeed message properties seem to be more appropriate. Are they persisted, or are they tied to an Emacs session? Because I would like to have it so that even if I kill my Emacs session and open a new one, if the message has the `:scheduled' property with the right time, it should be sent. There's also concerns on what to do when Emacs was not up when the scheduled time arrived. Do we 1. send it immediately? or 2. inform the user it was not able to deliver the message? Going with the latter has the caveat that it might be missed by the user, and one would be clueless to the fact that their message hadn't arrived. > but your periodic search would still have to search for all of the > scheduled=time properties (wildcard search is currently only supported > using s-exp queries). How about having a list of '(MESSAGE-ID . SCHEDULED-TIME), with the periodic check looking in that list for the scheduled times? It would have the issue of it not being persistent between Emacs sessions, but I think that could be addressed by letting the users know this lack of persistance, and documenting how you could achieve it with `savehist-additional-variables'. > I would suggest having a look at the existing draft handling, as what > you describe sounds like it is related. Taking a quick glance at it, it seems like we could have a similar thing, where scheduled messages are saved to the database somewhere, with either the tag, as it is with drafts, or just the message property as you suggested. -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forward email error - forward-sexp: Scan error
Jon Fineman writes: > Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 22384 > 32216) > scan-sexps(22384 1) > forward-sexp() > mml-expand-html-into-multipart-related((part (type . "text/html") (charset > . "UTF-8") (nofile . "yes") (tag-location . 907) (contents . "
Re: Scheduling mails
João Pedro writes: > Em terça, 02/04/2024 às 02:05 (+01), Jose A Ortega Ruiz > escreveu: > >> I might be wrong, but I don't think the Gnus agent can be easily reused >> from notmuch. We could perhaps save the message as a draft upon C-c C-j, >> and then have a periodic timer that checks if any of the drafts has >> expired (maybe using a special, additional tag for the search) and send >> it? > > I think we should be able to use a similar logic to > `gnus-delay-article': it adds an X-Gnus-Delayed header with a timestamp > and seems to, as you proposed, periodically check for scheduled > messages. The header holds a timestamp for the prompted scheduled time > (which can be given in as an absolute date, or relative to the current > time) and we could add to that a `scheduled' tag or something along > those lines. Message properties might work a bit better than tags, but your periodic search would still have to search for all of the scheduled=time properties (wildcard search is currently only supported using s-exp queries). I would suggest having a look at the existing draft handling, as what you describe sounds like it is related. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Em terça, 02/04/2024 às 02:05 (+01), Jose A Ortega Ruiz escreveu: > I might be wrong, but I don't think the Gnus agent can be easily reused > from notmuch. We could perhaps save the message as a draft upon C-c C-j, > and then have a periodic timer that checks if any of the drafts has > expired (maybe using a special, additional tag for the search) and send > it? I think we should be able to use a similar logic to `gnus-delay-article': it adds an X-Gnus-Delayed header with a timestamp and seems to, as you proposed, periodically check for scheduled messages. The header holds a timestamp for the prompted scheduled time (which can be given in as an absolute date, or relative to the current time) and we could add to that a `scheduled' tag or something along those lines. -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Hi, On Mon, Apr 01 2024, João Pedro wrote: > I am using notmuch in Emacs, with mbsync and msmtp (I actually use > smtpmail.el in Emacs, but it uses the `sendmail' command, which is > symlinked to msmtp) and the only thing I miss from other mail clients > is the ability to schedule a mail to be sent on a certain time. I do > also use `message-mode' to compose my emails, and it has > `gnus-delay-article' bound to C-c C-j, which at first sight seems to > be exactly what I need. The problem is, when calling it from > =notmuch-message-mode= I get a `wrong-type-argument' from the first > line of `gnus-agent-queue-setup', I might be wrong, but I don't think the Gnus agent can be easily reused from notmuch. We could perhaps save the message as a draft upon C-c C-j, and then have a periodic timer that checks if any of the drafts has expired (maybe using a special, additional tag for the search) and send it? Sounds doable, but maybe there's an easier way: what do more knowleadgeble people think? Cheers, jao -- Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. - Alan Perlis, Epigrams on Programming ___ 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 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. I just saw on the archives that David Bremner replied to my original patch, I have no idea why that email didn't reach me :( David: > Although it is significantly more work, it would be very helpful if > you could come up with an automated test in the style of those in > T630-emacs-draft.sh. There is one that checks for an internal header, > so perhaps it could be modified to check for In-Reply-To? I am attaching a new patch that includes an additional test on T630-emacs-draft.sh. On the test only `References` is at the top (hence hidden by emacs), not `In-Reply-To`. I guess that does rely on some configuration. In any case, the test reproduces the problem (lost headers on draft save), and the patch fixes it! Hope all is good!! :D marc >From 77e8a775571458962ff11af549d1a0428a17435e Mon Sep 17 00:00:00 2001 From: Marc Fargas Date: Thu, 14 Mar 2024 15:56:49 +0100 Subject: [PATCH] Use `without-restriction` in `with-temporary-notmuch-message-buffer` This ensures that the temporary copy of the current message-mode buffer is whole and not limited by a current restriction. An example of such restriction is the default one established by message-mode when composing a reply, that hides the References, In-Reply-To and similar headers. --- emacs/notmuch-maildir-fcc.el | 17 + test/T630-emacs-draft.sh | 32 2 files changed, 41 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index 5102078..cf50e85 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -145,14 +145,15 @@ 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." - `(let ((case-fold-search t) - (buf (current-buffer)) - (mml-externalize-attachments message-fcc-externalize-attachments)) - (with-current-buffer (get-buffer-create " *message temp*") - (message-clone-locals buf) ;; for message-encoded-mail-cache - (erase-buffer) - (insert-buffer-substring buf) - ,@body))) + `(without-restriction + (let ((case-fold-search t) + (buf (current-buffer)) + (mml-externalize-attachments message-fcc-externalize-attachments)) + (with-current-buffer (get-buffer-create " *message temp*") + (message-clone-locals buf) ;; for message-encoded-mail-cache + (erase-buffer) + (insert-buffer-substring buf) + ,@body (defun notmuch-maildir-setup-message-for-saving () "Setup message for saving. diff --git a/test/T630-emacs-draft.sh b/test/T630-emacs-draft.sh index c443f41..1fad58a 100755 --- a/test/T630-emacs-draft.sh +++ b/test/T630-emacs-draft.sh @@ -71,4 +71,36 @@ Fcc: MAIL_DIR/sent <#secure method=pgpmime mode=sign> EOF test_expect_equal_file EXPECTED OUTPUT.clean + +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) +(insert "Subject: draft-test-reply\n") + (test-output "DRAFT") + (notmuch-draft-postpone) + (notmuch-show "subject:draft-test-reply") + (notmuch-show-resume-message) + (test-output)' +notmuch_dir_sanitize OUTPUT > OUTPUT.clean + +cat < EXPECTED +References: <87d10042pu@curie.anarc.at> <87woy8vx7i@tesseract.cs.unb.ca> <87a7v42bv9@curie.anarc.at> <874llc2bkp@curie.anarc.at> +From: Notmuch Test Suite +To: Antoine Beaupré +Subject: draft-test-reply +In-Reply-To: <874llc2bkp@curie.anarc.at> +Fcc: MAIL_DIR/sent +--text follows this line-- +Antoine Beaupré writes: + +> And obviously I forget the frigging attachment. +> +> +> PS: don't we have a "you forgot to actually attach the damn file" plugin +> when we detect the word "attachment" and there's no attach? :p +EOF +test_expect_equal_file EXPECTED OUTPUT.clean + test_done -- 2.44.0 ___ 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
Hello, 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. marc >From 48efd572e6b8e6d214fc8b4e7b28f001fc13345a Mon Sep 17 00:00:00 2001 From: Marc Fargas Date: Thu, 14 Mar 2024 15:56:49 +0100 Subject: [PATCH] Use `without-restriction` in `with-temporary-notmuch-message-buffer` This ensures that the temporary copy of the current message-mode buffer is whole and not limited by a current restriction. An example of such restriction is the default one established by message-mode when composing a reply, that hides the References, In-Reply-To and similar headers. --- emacs/notmuch-maildir-fcc.el | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index 5102078..cf50e85 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -145,14 +145,15 @@ 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." - `(let ((case-fold-search t) - (buf (current-buffer)) - (mml-externalize-attachments message-fcc-externalize-attachments)) - (with-current-buffer (get-buffer-create " *message temp*") - (message-clone-locals buf) ;; for message-encoded-mail-cache - (erase-buffer) - (insert-buffer-substring buf) - ,@body))) + `(without-restriction + (let ((case-fold-search t) + (buf (current-buffer)) + (mml-externalize-attachments message-fcc-externalize-attachments)) + (with-current-buffer (get-buffer-create " *message temp*") + (message-clone-locals buf) ;; for message-encoded-mail-cache + (erase-buffer) + (insert-buffer-substring buf) + ,@body (defun notmuch-maildir-setup-message-for-saving () "Setup message for saving. -- 2.44.0 ___ 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
Hello, 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. marc PS: Resent while properly attaching the patch file (I hope, and apologies). >From 48efd572e6b8e6d214fc8b4e7b28f001fc13345a Mon Sep 17 00:00:00 2001 From: Marc Fargas Date: Thu, 14 Mar 2024 15:56:49 +0100 Subject: [PATCH] Use `without-restriction` in `with-temporary-notmuch-message-buffer` This ensures that the temporary copy of the current message-mode buffer is whole and not limited by a current restriction. An example of such restriction is the default one established by message-mode when composing a reply, that hides the References, In-Reply-To and similar headers. --- emacs/notmuch-maildir-fcc.el | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index 5102078..cf50e85 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -145,14 +145,15 @@ 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." - `(let ((case-fold-search t) - (buf (current-buffer)) - (mml-externalize-attachments message-fcc-externalize-attachments)) - (with-current-buffer (get-buffer-create " *message temp*") - (message-clone-locals buf) ;; for message-encoded-mail-cache - (erase-buffer) - (insert-buffer-substring buf) - ,@body))) + `(without-restriction + (let ((case-fold-search t) + (buf (current-buffer)) + (mml-externalize-attachments message-fcc-externalize-attachments)) + (with-current-buffer (get-buffer-create " *message temp*") + (message-clone-locals buf) ;; for message-encoded-mail-cache + (erase-buffer) + (insert-buffer-substring buf) + ,@body (defun notmuch-maildir-setup-message-for-saving () "Setup message for saving. -- 2.44.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] implement a capf for address completion
On 2024-03-19 16:12:04, Antoine Beaupré wrote: [...] > The closest we have in the archive is (author in CC): > > <71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org> > > ... which writes a new `kea/notmuch-address-message-capf' function from > scratch. It might, however, do a better job than i do at taking into > account the "harvest" process, which I only discovered after writing the > patch and decided I would pretend it doesn't exist (and is probably > inaccurate). So that might be a flaw with my patch already, but in my > defense, WTF is that harvest thing!? :) Thinking about this more, I *think* the capf *can* return a *function* instead of a list of strings, so we might be able to refactor this a bit better and send a function that waits for the harvesting to complete, or stream the results or something. Above my pay grade, at this point. -- We have no friends but the mountains. - Kurdish saying ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] implement a capf for address completion
I have *just* realized, after writing all this code and sending the patch, that someone else might have discussed this here. Oops. So, turns out, it *has* been discussed, but it doesn't look like anyone tackled that problem fully just yet. The closest we have in the archive is (author in CC): <71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org> ... which writes a new `kea/notmuch-address-message-capf' function from scratch. It might, however, do a better job than i do at taking into account the "harvest" process, which I only discovered after writing the patch and decided I would pretend it doesn't exist (and is probably inaccurate). So that might be a flaw with my patch already, but in my defense, WTF is that harvest thing!? :) Another discussion about capf was about integration with EUDC: <8a437e3f646f7972c86c4aae57ae7452%40condition-alpha.com> But I don't quite understand what EUDC is or why it matters here. Might be *some* overlap, not sure. Finally, there's this whole other thread from 2022 about capf, but it's quite diffuse and I couldn't make heads or tails of it. The head of the thread according to the online archives is: ... but that's a reply to... something else, so I'm not sure. As usual, your mileage may vary. :) To test my patch, you apply it, restart Emacs (or rewire `message-completion-alist' like Keith Amidon did), fire off a new email, start entering an address, and hit TAB (or, if you have corfu, just wait for the timeout). a. -- We don't need any more heroes. We just need someone to take out recycling. - Banksy ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forward email error - forward-sexp: Scan error
David Bremner writes: > Jon Fineman writes: > >> Received this error while trying to forward a complex html email from ebay. >> >> Unfortunately there is probably some PII embedded in it, so trying to >> remove that to include the email might confuse things. >> >> Any suggestions on how to find the error? >> >> >> Sending... >> forward-sexp: Scan error: "Unbalanced parentheses", 22384, 32216 >> >> > > Does "M-x toggle-debug-on-error" yield a useful backtrace? Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 22384 32216) scan-sexps(22384 1) forward-sexp() mml-expand-html-into-multipart-related((part (type . "text/html") (charset . "UTF-8") (nofile . "yes") (tag-location . 907) (contents .
Re: Forward email error - forward-sexp: Scan error
Jon Fineman writes: > Received this error while trying to forward a complex html email from ebay. > > Unfortunately there is probably some PII embedded in it, so trying to > remove that to include the email might confuse things. > > Any suggestions on how to find the error? > > > Sending... > forward-sexp: Scan error: "Unbalanced parentheses", 22384, 32216 > > Does "M-x toggle-debug-on-error" yield a useful backtrace? ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: (Emacs) Use tree view by default from notmuch-hello and notmuch-jump ?
David Bremner writes: Michael Graham writes: I have a bunch of saved searches, which I configure like this: (push '(:name "Personal Unscreened" :query "tag:inbox AND tag:unread AND (NOT query:screened-addresses)" :key "u" :search-type 'tree) notmuch-saved-searches) But when I run the search, it always the results in search view (notmuch-search-mode). I think it's just a problem with too much quoting (try tree without ', since you already quoted the outside expression). Thank you, David! This fixed it: (push '(:name "Personal Unscreened" :query "tag:inbox AND tag:unread AND (NOT query:screened-addresses) :key "u" :search-type tree) notmuch-saved-searches) I had actually tried 'tree and "tree" but not just the unquoted: tree Even for people that prefer not to use customize, inspecting the expression that M-x customize-variable generates can help debug these kind of problems (that's what I did to see what was wrong with your example). Thank you, that's good advice. I think it's probably time for me to spend some time understanding elisp quoting. I'm always a little confused by it. Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: (Emacs) Use tree view by default from notmuch-hello and notmuch-jump ?
Michael Graham writes: > I'm new at notmuch (and the list), so I'm probably doing something > wrong. > > I prefer tree view (notmuch-tree-mode) to search view > (notmuch-search-mode), and I would like my saved searches to open > in tree view automatically. > > I have a bunch of saved searches, which I configure like this: > (push '(:name "Personal Unscreened" > :query "tag:inbox AND tag:unread AND (NOT > query:screened-addresses)" :key "u" :search-type 'tree) > notmuch-saved-searches) > > But when I run the search, it always the results in search view > (notmuch-search-mode). > I think it's just a problem with too much quoting (try tree without ', since you already quoted the outside expression). Even for people that prefer not to use customize, inspecting the expression that M-x customize-variable generates can help debug these kind of problems (that's what I did to see what was wrong with your example). d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] Use `without-restriction` in `with-temporary-notmuch-message-buffer`
Marc Fargas writes: > I hope my previous e-mails was properly sent. > Yes, it worked fine. > I have been testing the patch and.. does it work? The code looks proper > to me but testing on my computer it is not working properly, as if the > `without-restrictions` was being ignored. It seems to work here _but_ I did not notice the problem with postponed replies being orphaned before so maybe it is an issue of your local setup? To test this idea you can try ./devel/try-emacs-mua -q Equally likely is that I have not understood the problem yet. > > (Just Reply to an email, postpone; see if the saved draft is kept in the > thread with its headers or becomes an orphan in drafts). > Although it is significantly more work, it would be very helpful if you could come up with an automated test in the style of those in T630-emacs-draft.sh. There is one that checks for an internal header, so perhaps it could be modified to check for In-Reply-To? David ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] Use `without-restriction` in `with-temporary-notmuch-message-buffer`
Hi, I hope my previous e-mails was properly sent. I have been testing the patch and.. does it work? The code looks proper to me but testing on my computer it is not working properly, as if the `without-restrictions` was being ignored. I think I do not understand `defmacro` properly to see where the problem is. Please someone test the patch just to make sure its not a local problem of my setup. (Just Reply to an email, postpone; see if the saved draft is kept in the thread with its headers or becomes an orphan in drafts). Thanks, marc El jue. 14 de mar. 2024, Marc escribió: > This ensures that the temporary copy of the current message-mode > buffer is whole and not limited by a current restriction. > > An example of such restriction is the default one established by > message-mode when composing a reply, that hides the References, > In-Reply-To and similar headers. ___ 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
On Wed, Mar 13 2024, Marc Fargas wrote: > Hi there, Hi, Marc! > I'm not sure if this is the appropiate mailing list for bugs regarding > notmuch.el (Notmuch in Emacs). Also, I'm not subscribed so please keep > me in CC! Yes, this is a fine place to report things > I recently noticed that when saving drafts in notmuch I would loose all > the headers that are not normally visible on the compose > buffer. References, In-Reply-To and the likes. Thanks for the bug report, as well as the fix you provided. I haven't run it, but it looks totally reasonable. > Note that when resuming the draft later on all headers will be visible, > still working out how to restore the narrow restriction there. That seems worth chasing down, but shouldn't prevent the acceptance of your fix here which seems like only progress in the right direction. 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. Thanks again, -Carl ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] NEWS: aspell(1)d few words
tomi.oll...@iki.fi writes: > From: Tomi Ollila > > Executed aspell -l en -c NEWS > > and replaced few obvious cases. Applied to master. Or should I say Aplyde to mastre, based on evidence presented. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 2/3] emacs: Allow notmuch-saved-searches to hide excluded messages
David Bremner writes: Hi, sorry, took me so long to get back to this XD. I've opted to squash the 3 separate commits in this patch series into one commit so that should address the commit message questions. > mohk...@kisara.moe writes: > >> + :excludedWhether to show mail with excluded tags in the >> + search. Possible values are `hide', `show', >> + or nil. Nil means use the default value of >> + `notmuch-search-hide-excluded'. > > So if I understand correctly, toggling excludes will not affect saved > searches with a :excluded key. Is this what we want? > > I guess the alternative is to AND notmuch-search-hide-excluded with the > value derived from the saved-search? I think this is the last pending question. This shouldn't be the case. When you open a search from notmuch saved searches it'll contain whatever value you specify in :excluded but you can interactively change that with the new toggle-exclude commands and the workflow should be as you expect. I did notice while testing this that notmuch-jump currently doesn't respect the exclude option you add to saved searches but I've addressed that in this next patch version. -- Mohsin Kaleem ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: user.other_email wildcard config?
Charles Cazabon writes: > David Bremner wrote: >> Charles Cazabon writes: >> >> > Is there a way to have a wildcard, glob, or regex serve as the >> > configuration for other_email? >> >> [...] the code currently assumes that is a list of literal email addresses. >> I guess the emacs front-end would require some adaptation to change that to >> a list of regexes, but probably not a heroic amount. The function >> address_match in notmuch-reply.c would also need to be adjusted. > > Thanks for the reply, David. I'm not an Emacs user, just using notmuch with > mutt. If this functionality isn't on the roadmap, I can give it a crack > myself - but my time for working on other projects seems to be at a premium > these days. If I get anywhere with it, I'll send it in. I hear you. I am also very slow on notmuch patch reviewing at the moment, but we will get there in the end. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: user.other_email wildcard config?
David Bremner wrote: > Charles Cazabon writes: > > > Is there a way to have a wildcard, glob, or regex serve as the > > configuration for other_email? > > [...] the code currently assumes that is a list of literal email addresses. > I guess the emacs front-end would require some adaptation to change that to > a list of regexes, but probably not a heroic amount. The function > address_match in notmuch-reply.c would also need to be adjusted. Thanks for the reply, David. I'm not an Emacs user, just using notmuch with mutt. If this functionality isn't on the roadmap, I can give it a crack myself - but my time for working on other projects seems to be at a premium these days. If I get anywhere with it, I'll send it in. Charles -- -- Charles Cazabon Software, consulting, and services available at http://pyropus.ca/ -- ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: user.other_email wildcard config?
Charles Cazabon writes: > I've searched the list archives but have only found references to setting > user.other_email to a list of actual addresses. Is there a way to have a > wildcard, glob, or regex serve as the configuration for other_email? Have I > missed something in the documentation? No, you didn't miss anything; the code currently assumes that is a list of literal email addresses. I guess the emacs front-end would require some adaptation to change that to a list of regexes, but probably not a heroic amount. The function address_match in notmuch-reply.c would also need to be adjusted. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Narrow text body when composing/replying to mails
Thanks for your fast reply Sandra. On So, Feb 25 2024 11:28, Sandra Snan wrote > Huh, there is a bug here, apparently, looking at the raw version > of what I sent. It doesn't properly insert the RFC 2646 > line-ending spaces. In fact, it does not work for me either. I commented my lines of code and used your code snippet below. Hence auto-fill-mode was kept on while testing it on my side. >>> Instead, do this: >>> >>> (add-hook 'message-mode-hook >>> (lambda () >>> (use-hard-newlines 3 t))) Maybe there are some settings interfering with the right placement/insertion of RFC2646. Any thoughts on this? -- Jan Detke ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
Awesome, and I see you're already upstreaming hooks. But I think you can simplify this because every reply buffer has a hidden "In-Reply-To" header (can be shown with `message-widen-and-recenter`). You should be able to attach a hook to `message-setup-hook`, I think? Ideally you'd use `message-header-hook`, but that doesn't appear to be run by notmuch. So, something like should get you the ID of the message to which we're replying. (save-restriction (message-narrow-to-headers) (mail-header-parse-address-lax (mail-fetch-field "In-Reply-To"))) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Narrow text body when composing/replying to mails
Huh, there is a bug here, apparently, looking at the raw version of what I sent. It doesn't properly insert the RFC 2646 line-ending spaces. Sandra Snan writes: Sandra Snan writes: Instead, do this: (add-hook 'message-mode-hook (lambda () (use-hard-newlines 3 t))) While keeping auto-fill-mode on, I mean. This sets the format flowed header according to RFC 2646 so that your fills reads as if they were softwrapped for the recipient. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Narrow text body when composing/replying to mails
Sandra Snan writes: Instead, do this: (add-hook 'message-mode-hook (lambda () (use-hard-newlines 3 t))) While keeping auto-fill-mode on, I mean. This sets the format flowed header according to RFC 2646 so that your fills reads as if they were softwrapped for the recipient. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Narrow text body when composing/replying to mails
Jan Detke writes: With that I got an issue where my text body is verry narrow while composing/replying to mails (as you can see). Instead, do this: (add-hook 'message-mode-hook (lambda () (use-hard-newlines 3 t))) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
Steven Allen writes: There's actually a pretty decent autocrypt package[1] for Emacs, only lacking notmuch integration. But writing that based on the mu4e integration should be pretty trivial. [1]: https://git.sr.ht/~pkal/autocrypt/ I've been working on that actually so check out that project's mailing lists for the patches I've been sending. I've been seeing some weird behavior when testing and I wanna iron out all the kinks before we merge it, but patches-to-my-patches in that regard are more than welcome.♥︎ There are some huge differences between notmuch and mu4e with regards to the timing of message access and hooks. Please check the commit history of my patches on pkal's mailing list, or get my dev repo at git clone https://idiomdrottning.org/autocrypt I think my code here is solid and my remaining issues (I've been seeing incompabilities with Delta Chat) are with the autocrypt library and not with my interface code, but, more eyes would be good. Note that since autocrypt aspires to become an ELPA project you need FSF assignment forms to work on it. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
There's actually a pretty decent autocrypt package[1] for Emacs, only lacking notmuch integration. But writing that based on the mu4e integration should be pretty trivial. [1]: https://git.sr.ht/~pkal/autocrypt/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
On 2024-02-22 22:22:13, Antoine Beaupré wrote: > On 2023-04-26 12:10:09, Antoine Beaupré wrote: [...] > ... but it feels a bit too intrusive... Do I really want to divulge my > cryptographic identity to the world constantly? I'm using ed25519 keys > now, so the header is small, but for other users, that grows the message > size significantly... After talking with dkg on IRC, I realized my concerns were overblown: autocrypt actually strips out the other identities, so i'm not divulging more than already present in the mail (apart from the public key material itself of course). So I've reverted this. -- One of the things the Web teaches us is that everything is connected (hyperlinks) and we all should work together (standards). Too often school teaches us that everything is separate (many different 'subjects') and that we should all work alone. - Aaron Swartz ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
On 2023-04-26 12:10:09, Antoine Beaupré wrote: [...] > And while autocrypt has a nice beautiful and brilliant spec that does > everything, that's not what I'm looking at right now. And I don't think > it's productive to block in this way at this point. > > So I made a bespoke implementation that just calls out to sequoia (and > yes, also gpg, hopefully one day the latter can just go away) to insert > autocrypt headers to outgoing mail. Here's the implementation: > > https://gitlab.com/anarcat/emacs-d/-/blob/354fabad24100f69310dd16a0d30ac3bd96d7244/notmuch-config.el#L14-31 > > It's brittle, but it works for my case. > > I don't think this is something that can be merged as-is in notmuch. It > depends on gnupg and sequoia, and it's probably incorrect as far as the > Autocrypt spec is concerned (in particular it doesn't use a UID to > fingerprint map), but this all seems like things could be improved. A small update on this: I just realized I was sending autocrypt headers regardless of whether or not I was signing / encrypting mails. I'm not sure this is a good idea. The spec says that I "SHOULD", I believe: https://autocrypt.org/level1.html#header-injection-in-outbound-mail ... but it feels a bit too intrusive... Do I really want to divulge my cryptographic identity to the world constantly? I'm using ed25519 keys now, so the header is small, but for other users, that grows the message size significantly... Patch is: https://gitlab.com/anarcat/emacs-d/-/commit/c79495f8580735c23748a62db99b3d9f34f413f5 Interestingly, i had to make a new mml-* function; there's a predicate to check if a message is encrypted, but not if it's signed, which seems silly. So I vendored and improved the code, which also feels silly. So there you go, diverging from the standard already. :) A. -- You Are What You Is - Frank Zappa ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] config: allow custom separators in author lists
On Fri, Dec 22 2023, Lars Kotthoff wrote: > 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). > > Cheers, > > 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.38.3 (?) > += The format for yet-unreleased news block here would be: Notmuch 0.39 (UNRELEASED) = If there is going to be 0.38.3 with this included, then, at that time the version string is adjusted accordingly. > + > +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) > === > // stuff deleted // > 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 "| "; Spaces instead of tabs above ? > 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 Just noticed the above and that there are more tabs/spaces inconsistencies, -- and using 4 (instead of 8) in tab width is another thing that makes the code to be inconsistently laid out. Otherwise the code looks pretty straightforward, we'll see... Tomi ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] config: allow custom separators in author lists
Any chance of this being included? Thanks, Lars On Fri, 22 Dec 2023 14:15:32 -0700, Lars Kotthoff wrote: > 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). > > Cheers, > > Lars > ___ > 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: Individual tag file lines and removing all tags?
* David Bremner: > My assumption is that the overhead of multiple invocations is only > noticible for (at a guess) 1000s of calls to notmuch-tag. Well, that certainly would mean that my proposal has negligible merit in terms of efficiency. Matters of convenience and aesthetics probably don't offer enough justification either. Unless somebody is bored and looking for things to do, that is. ;-) -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
Ralph Seichter writes: > > notmuch-tag(1) states that batch tagging operations are "more efficient > than repeated notmuch tag invocations" (this is not qualified further). > I don't know if the efficiency advantage of batch tagging would justify > the time/effort required to implement the feature? > My assumption is that the overhead of multiple invocations is only noticible for (at a guess) 1000s of calls to notmuch-tag. For two or three it probably doesn't make much difference. batch-tag is really just saving the cost of exec as far as I remember. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
The current tags file system already makes common things simple and efficient, while still keeping unusual things possible. Pretty happy about that ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
* David Bremner: > Is there a benefit beyond simplifying this shell script (and maybe > aesthetics)? In addition to what you mentioned, and more importantly, I am thinking about efficiency. notmuch-tag(1) states that batch tagging operations are "more efficient than repeated notmuch tag invocations" (this is not qualified further). I don't know if the efficiency advantage of batch tagging would justify the time/effort required to implement the feature? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
Ralph Seichter writes: > I currently use a custom wrapper script to call notmuch-tag multiple > times for this very reason. I would prefer being able to use the '-*' > syntax shown in my OP with "notmuch tag --batch". > > Is this a reasonable new-feature-suggestion, or do you guys think it > too exotic? Am I perhaps the only one who finds this useful? Is there a benefit beyond simplifying this shell script (and maybe aesthetics)? d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
Ralph Seichter writes: I currently use a custom wrapper script to call notmuch-tag multiple times for this very reason. That is the appropriate solution. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
* David Bremner: > As far as I understand your request, this would currently need 3 > different calls to notmuch-tag (or some scripting in e.g. python). I currently use a custom wrapper script to call notmuch-tag multiple times for this very reason. I would prefer being able to use the '-*' syntax shown in my OP with "notmuch tag --batch". Is this a reasonable new-feature-suggestion, or do you guys think it too exotic? Am I perhaps the only one who finds this useful? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
Ralph Seichter writes: > Looking at the notmuch-tag(1) man page, I wonder if something like the > following tag file content is currently possible: > > -* +deleted -- folder:.Trash > -* +ancient -- date:..10_years_ago > +foo -- from:f...@example.com > > What I am trying to achieve with lines 1 and 2 is replacing all existing > tags (symbolised by '-*') with the 'deleted' or 'ancient' tag, > respectively. With line 3, I want to add the 'foo' tag, but leaving any > existing tags untouched (this is already works, of course). As far as I understand your request, this would currently need 3 different calls to notmuch-tag (or some scripting in e.g. python). ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] Check for erroneous subjects
Just checking in to see how this is doing :)
On Sun, Oct 29 2023 08:49, Tony Zorman wrote:
> Hi,
>
> this adds a new custom variable, `notmuch-mua-subject-regexp`, and an
> associated function, `notmuch-mua-subject-check`, to warn the user when
> the subject contains potentially troublesome things (e.g., nothing at
> all). The idea is the same as `notmuch-mua-attachment-regexp`—which has
> saved my skin quite a few times in the past—but for the subject instead
> of an attachment. By default, it checks for empty subjects, as that
> seems to be a reasonable thing to safeguard against.
>
> I've not found any NEWS entry (nor any documentation) for
> `notmuch-mua-attachment-regexp`, so I wasn't sure whether to add any
> myself. So far, I haven't done so, but that can of course quickly be
> fixed.
>
> Best,
> Tony
>
> From 3ccd1f36cbda55766bf21578b5258b21105e0803 Mon Sep 17 00:00:00 2001
> From: Tony Zorman
> Date: Sun, 29 Oct 2023 08:26:32 +0100
> Subject: [PATCH 1/2] emacs/mua: optionally check for erroneous subjects
>
> This works much like notmuch-mua-attachment-regexp, but for the
> subject instead. By default, check for empty subjects, as that seems a
> reasonable thing to safeguard against.
> ---
> emacs/notmuch-mua.el | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index e4b7e9d1..5750f181 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -142,6 +142,16 @@ to `notmuch-mua-send-hook'."
>:type 'regexp
>:group 'notmuch-send)
>
> +(defcustom notmuch-mua-subject-regexp
> + "[[:blank:]]*$"
> + "Message subject indicating that something may be amiss.
> +By default, this checks for empty subject lines.
> +
> +This is not used unless `notmuch-mua-subject-check' is added to
> +`notmuch-mua-send-hook'."
> + :type 'regexp
> + :group 'notmuch-send)
> +
> ;;; Various functions
>
> (defun notmuch-mua-attachment-check ()
> @@ -179,6 +189,19 @@ Typically this is added to `notmuch-mua-send-hook'."
> ;; ...signal an error.
> (error "Missing attachment")))
>
> +(defun notmuch-mua-subject-check ()
> + "Signal an error if the subject seems amiss.
> +More precisely, if the subject conforms to
> +`notmuch-mua-subject-regexp'.
> +
> +Typically this is added to `notmuch-mua-send-hook'."
> + (or (save-excursion
> +(message-goto-subject)
> +(message-beginning-of-header t)
> +(not (looking-at-p notmuch-mua-subject-regexp)))
> + (y-or-n-p "Subject may be erroneous – is that okay?")
> + (error "Erroneous subject")))
> +
> (defun notmuch-mua-get-switch-function ()
>"Get a switch function according to `notmuch-mua-compose-in'."
>(pcase notmuch-mua-compose-in
> --
> 2.42.0
>
> From df875e9dcacda21bc09ccef869c883424a2b4467 Mon Sep 17 00:00:00 2001
> From: Tony Zorman
> Date: Sun, 29 Oct 2023 08:25:21 +0100
> Subject: [PATCH 2/2] test/emacs: test notmuch-mua-subject-check
>
> ---
> test/T740-emacs-subject-warnings.sh | 12
> test/emacs-subject-warnings.el | 48 +
> 2 files changed, 60 insertions(+)
> create mode 100755 test/T740-emacs-subject-warnings.sh
> create mode 100644 test/emacs-subject-warnings.el
>
> diff --git a/test/T740-emacs-subject-warnings.sh
> b/test/T740-emacs-subject-warnings.sh
> new file mode 100755
> index ..f9d27140
> --- /dev/null
> +++ b/test/T740-emacs-subject-warnings.sh
> @@ -0,0 +1,12 @@
> +#!/usr/bin/env bash
> +
> +test_description="emacs subject warnings"
> +. $(dirname "$0")/test-lib.sh || exit 1
> +. $NOTMUCH_SRCDIR/test/test-lib-emacs.sh || exit 1
> +
> +test_require_emacs
> +
> +test_begin_subtest "notmuch-test-subject-warning part 1"
> +test_emacs_expect_t '(notmuch-test-subject-warning-1)'
> +
> +test_done
> diff --git a/test/emacs-subject-warnings.el b/test/emacs-subject-warnings.el
> new file mode 100644
> index ..1e547429
> --- /dev/null
> +++ b/test/emacs-subject-warnings.el
> @@ -0,0 +1,48 @@
> +(require 'cl-lib)
> +(require 'notmuch-mua)
> +
> +(defun subject-check-test ( fn)
> + "Test `notmuch-mua-subject-check'.
> +Optionally, evaluate FN before doing the test.
> +
> +Return t if the message would be sent, and nil otherwise."
> + (notmuch-mua-mail)
> + (message-goto-subject)
> + (when fn
> +(funcall fn))
> + (prog1
> + (condition-case nil
> + ;; Force `y-or-n-p' to always return `nil', as if the user
> + ;; pressed "n".
> + (cl-letf (((symbol-function 'y-or-n-p)
> + (lambda ( args) nil)))
> + (notmuch-mua-subject-check)
> + t)
> + ('error nil))
> +(set-buffer-modified-p nil)
> +(kill-buffer (current-buffer
> +
> +(defvar subject-check-tests
> + '(;; These are okay.
> +(t . (lambda () (insert "something")))
> +;; These should not be okay.
> +(nil)
> +(nil . (lambda () (insert " ")))
> +(nil . (lambda () (insert " ")))
> +
Re: [PATCH 1/3] CLI/git: remove unused import
Jakub Wilk writes:
> shutil was used only for the tempfile.TemporaryDirectory backport,
> which was removed in commit b7c31f658121a0cf ("CLI/git: drop support for
> python < 3.2").
Series applied to master.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Tips re syncing notmuch database and maildir via iCloud?
On Mon, Jan 15, 2024 at 08:35:37PM -0400, David Bremner wrote: > HGV writes: > > > Does anyone have experience syncing the notmuch database or an entire > > maildir directory via iCloud? I keep most of my email archive offline > > but since iCloud added end-to-end encryption, I've considered syncing my > > archived mail and notmuch database via iCloud. But I'm worried that > > iCloud might introduce issues either directly with the notmuch database > > or by slightly altering the mail files/directories. Any tips about > > syncing the notmuch database or a maildir directory (whether iCloud or > > via another service) would be appreciated. > > Since you didn't get any answer on the notmuch list, I'm forwarding your > mail to the Xapian list. I guess if Xapian syncs fine in general to > iCloud, notmuch should be likely (but not guaranteed) OK. I know nothing about iCloud, but assuming it syncs the filenames and contents correctly then the potential concerns I can see if you're syncing a Xapian database are: * On the machine being synced from you need to ensure that indexing doesn't happen during syncing or else the synced version may be corrupted - if you run "notmuch new" in a mail delivery hook or from cron or similar that's problematic * On the side being synced to searches may fail or work incorrectly during syncing Xapian's replication feature knows how to sync changes safely avoiding these potential problems, but I've no idea if you could make it work with iCloud. Cheers, Olly ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Tips re syncing notmuch database and maildir via iCloud?
HGV writes: > Does anyone have experience syncing the notmuch database or an entire > maildir directory via iCloud? I keep most of my email archive offline > but since iCloud added end-to-end encryption, I've considered syncing my > archived mail and notmuch database via iCloud. But I'm worried that > iCloud might introduce issues either directly with the notmuch database > or by slightly altering the mail files/directories. Any tips about > syncing the notmuch database or a maildir directory (whether iCloud or > via another service) would be appreciated. Since you didn't get any answer on the notmuch list, I'm forwarding your mail to the Xapian list. I guess if Xapian syncs fine in general to iCloud, notmuch should be likely (but not guaranteed) OK. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [BUG] notmuch-search: notmuch search process already running for query
Sławomir Grochowski writes: > Dear All, > > I just have started using notmuch with Emacs. > > When I run `notmuch-poll-and-refresh-this-buffer` which run script > '.notmuch/hooks/pre-new': > > #!/bin/sh > mbsync -L gmail > > Most of the time it gives me an error & message: > "notmuch-search: notmuch search process already running for query > ‘tag:inbox’". > I could reliably duplicate this in two ways: one is calling the function twice in a row, like (defun doit () (interactive) (notmuch-poll-and-refresh-this-buffer) (message "completed %f" (float-time)) (notmuch-poll-and-refresh-this-buffer)) the second way is calling (notmuch-poll-and-refresh-this-buffer) or just (notmuch-refresh-this-buffer) in a buffer when the search was still being loaded. That can happen with larger searches (more than 10k threads, roughly). Do either of those cases seem possible to you? ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Tips re syncing notmuch database and maildir via iCloud?
Does anyone have experience syncing the notmuch database or an entire maildir directory via iCloud? I keep most of my email archive offline but since iCloud added end-to-end encryption, I've considered syncing my archived mail and notmuch database via iCloud. But I'm worried that iCloud might introduce issues either directly with the notmuch database or by slightly altering the mail files/directories. Any tips about syncing the notmuch database or a maildir directory (whether iCloud or via another service) would be appreciated. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Am Di., 9. Jan. 2024 um 13:38 Uhr schrieb David Bremner : > > Michael J Gruber writes: > > >> > >> I agree the bindings documentation does not make much sense. I suspect > >> that the bindings should follow the underlying library and return "" if > >> the library does. I don't use the bindings that much, so I am curious > >> what others think. > > > > I might be misunderstanding the OP,and I didn't check the RFC, but > > isn't there a difference between a missing header and an empty header? > > Are you suggesting the library should change as well? I don't know. Missing vs. empty are two different cases. It may be that in terms of e-mail standards (RFC), a missing header is equivalent to an empty one. Then one can argue whether an empty header is a missing header (raise error) or a missing header is an empty header (return None) ... Or one may distinguish between mandatory headers and optional ones. I'd really check the RFC. In Python, there is a difference between a dictionary key with an empty value and a key which is not present, of course. So, if I think of the headers as a dictionary, I would expect to differentiate between those cases, unless the data which the dict represents (e-mail headers) treats them as equal by RFC. > > If there is, this may come down to the difference between testing for > > an empty string, None or False in dynamically typed python ... > > But it does make sense for the bindings to return an empty string or > > None for an empty header and LookUpError for a missing header. I have > > not checked whether our bindings in fact do. > > > > AFAICT it checks explicitely for NULL, but then throws LookupError on > any falsy return from capi.ffi.string > > ret = capi.lib.notmuch_message_get_header(self._msg_p, name) > if ret == capi.ffi.NULL: > raise errors.NullPointerError() > hdr = capi.ffi.string(ret) > if not hdr: > raise LookupError > return hdr.decode(encoding='utf-8') That clarifies what OP observed :) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Michael J Gruber writes: >> >> I agree the bindings documentation does not make much sense. I suspect >> that the bindings should follow the underlying library and return "" if >> the library does. I don't use the bindings that much, so I am curious >> what others think. > > I might be misunderstanding the OP,and I didn't check the RFC, but > isn't there a difference between a missing header and an empty header? Are you suggesting the library should change as well? > If there is, this may come down to the difference between testing for > an empty string, None or False in dynamically typed python ... > But it does make sense for the bindings to return an empty string or > None for an empty header and LookUpError for a missing header. I have > not checked whether our bindings in fact do. > AFAICT it checks explicitely for NULL, but then throws LookupError on any falsy return from capi.ffi.string ret = capi.lib.notmuch_message_get_header(self._msg_p, name) if ret == capi.ffi.NULL: raise errors.NullPointerError() hdr = capi.ffi.string(ret) if not hdr: raise LookupError return hdr.decode(encoding='utf-8') ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Am Di., 9. Jan. 2024 um 00:09 Uhr schrieb David Bremner : > > Vojtěch Káně writes: > > > At first, this sounds reasonable: the subject is empty, so it is > > effectively missing. That would indicate a bug in Lieer itself and would > > be fixed by a try-catch block. Notmuch's source for Message.header, > > however, states: > > > >>:returns: The header value, an empty string if the header is not present. > >>:rtype: str > > > > This makes an impression that no error should be raised and a harmless > > value (at least for the above-mentioned code) should be returned. Yet > > the docs continue with > > > >>:raises LookupError: if the header is not present. > > > > completely contradicting itself. > > > > And so here the questions: > > Is my confusion justified? What is the expected nm's behavior? Can we > > fix the docs and possible the implementation? > > > > I agree the bindings documentation does not make much sense. I suspect > that the bindings should follow the underlying library and return "" if > the library does. I don't use the bindings that much, so I am curious > what others think. I might be misunderstanding the OP,and I didn't check the RFC, but isn't there a difference between a missing header and an empty header? If there is, this may come down to the difference between testing for an empty string, None or False in dynamically typed python ... But it does make sense for the bindings to return an empty string or None for an empty header and LookUpError for a missing header. I have not checked whether our bindings in fact do. Also, note that *sending* via lieer (i.e. via GMail API) provides more pitfalls. For example, message IDs are rewritten, which makes it unusable for patch series. Cheers, Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Vojtěch Káně writes: > At first, this sounds reasonable: the subject is empty, so it is > effectively missing. That would indicate a bug in Lieer itself and would > be fixed by a try-catch block. Notmuch's source for Message.header, > however, states: > >>:returns: The header value, an empty string if the header is not present. >>:rtype: str > > This makes an impression that no error should be raised and a harmless > value (at least for the above-mentioned code) should be returned. Yet > the docs continue with > >>:raises LookupError: if the header is not present. > > completely contradicting itself. > > And so here the questions: > Is my confusion justified? What is the expected nm's behavior? Can we > fix the docs and possible the implementation? > I agree the bindings documentation does not make much sense. I suspect that the bindings should follow the underlying library and return "" if the library does. I don't use the bindings that much, so I am curious what others think. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] config: allow custom separators in author lists
Thanks for your suggestion! This doesn't work unfortunately because the author string doesn't contain the email addresses, i.e. no @ symbols (unless somebody includes that in their name). Cheers, Lars On Fri, 22 Dec 2023 23:24:37 +0100, Sandra Snan wrote: > Curses, flowed again! I'm just gonna attach the file > > ___ > 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: [PATCH] config: allow custom separators in author lists
Curses, flowed again! I'm just gonna attach the file email_list = "Diaz, Marco , s...@mewni.com, Marco Diaz , s...@mewni.com" addresses = [] current_address = "" for char in email_list: if char == ',' and '@' in current_address: addresses.append(current_address.strip()) current_address = "" else: current_address += char addresses.append(current_address.strip()) # Adding the last address print(addresses) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] config: allow custom separators in author lists
Lars Kotthoff writes: Python […] 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). email_list = "Diaz, Marco , s...@mewni.com, Marco Diaz , s...@mewni.com" addresses = [] current_address = "" for char in email_list: if char == ',' and '@' in current_address: addresses.append(current_address.strip()) current_address = "" else: current_address += char addresses.append(current_address.strip()) # Adding the last address print(addresses) ## prints ['Diaz, Marco ', 's...@mewni.com', 'Marco Diaz ', 's...@mewni.com'] ## (Trying again since use-hard-newlines borked the flow) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] config: allow custom separators in author lists
Lars Kotthoff writes: Python […] 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). email_list = "Diaz, Marco , s...@mewni.com, Marco Diaz , s...@mewni.com" addresses = [] current_address = "" for char in email_list: if char == ',' and '@' in current_address: addresses.append(current_address.strip()) current_address = "" else: current_address += char addresses.append(current_address.strip()) # Adding the last address print(addresses) ## prints ['Diaz, Marco ', 's...@mewni.com', 'Marco Diaz ', 's...@mewni.com'] ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
David Bremner writes: probably not out of the box, but I guess it might be easier to hack notmuch-extract-* on the emacs side than to extend 'notmuch show --format=mbox' Those elpa-mailscripts also rely on calling notmuch show --format=mbox. The elisp files (similar to what I had been using) shell out to the same Python scripts I was originally using (from the mailscripts package, but same source package on Debian) and the Python scripts in turn wrap notmuch show --format=mbox. So that's where I already was before starting the thread; scripts that don't work because --format=mbox doesn't decrypt the patches. (Even though I am working on moving from them to b4 since someone told me it supposedly does a slightly better job at guessing the base commit when people send patches for old versions without formatting the patch with --base so I was NIH making my own wrappers for notmuch show --format=mbox similar to the ones in mailscripts.) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
Sandra Snan writes: > David Bremner writes: >> By the way, the mailscripts package (elpa-mailscripts on Debian) >> contains some some add-on functions that might reduce the manual >> labour in situations like this. > > That's what I had been using, do they really work when the patches > are encrypted? probably not out of the box, but I guess it might be easier to hack notmuch-extract-* on the emacs side than to extend 'notmuch show --format=mbox' ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
David Bremner writes: By the way, the mailscripts package (elpa-mailscripts on Debian) contains some some add-on functions that might reduce the manual labour in situations like this. That's what I had been using, do they really work when the patches are encrypted? I've been trying to go to b4 instead since I heard it was better at guessing what commit the patches were made on if the sender forgot to use the --base option when sending, and that uses mbox which for sure does not work with encrypted patches. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
Sandra Snan writes: > Finally saving the patches one by one with w in the Emacs interface to > notmuch gave me patches I could apply. (Just in case someone else > searches the mailing list for the same issue.) By the way, the mailscripts package (elpa-mailscripts on Debian) contains some some add-on functions that might reduce the manual labour in situations like this. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
Sandra Snan writes: > David Bremner writes: >> I guess we could add a second code path that parsed and >> decrypted the messages before re-serializing them again. > > Or, as a stop gap measure, a warning when the flags are used > together that mbox doesn't support decrypt. That seems do-able, thanks for the suggestion. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: configure prefix ignored by make install
Sandra Snan writes: > I did not run configure again, I just went straight to make. I'd think > that after 20 years of using autotools I wouldn't make that mistake > but that's what I found when I scrolled back up the buffer and looked > more carefully. Sounds like it's working for you now. I guess the "ease of use" tradeoff here is that we currently run configure automatically from the Makefile, while in you case it would have been more helpful to stop and say "hey, run configure" ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
David Bremner writes: I guess we could add a second code path that parsed and decrypted the messages before re-serializing them again. Or, as a stop gap measure, a warning when the flags are used together that mbox doesn't support decrypt. I tried decrypting the pgp'd parts of the mbox export manually but it had =20 =2D characters that confused git am. Finally saving the patches one by one with w in the Emacs interface to notmuch gave me patches I could apply. (Just in case someone else searches the mailing list for the same issue.) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: configure prefix ignored by make install
David Bremner writes: Fair enough, but can you try without sudo to try to narrow down where the issue is? I found the problem. Sudo wasn't the issue. It was that after ./configure had failed to find some of the build deps and asked me to sudo apt-get install libxapian-dev libgmime-3.0-dev libtalloc-dev zlib1g-dev I did not run configure again, I just went straight to make. I'd think that after 20 years of using autotools I wouldn't make that mistake but that's what I found when I scrolled back up the buffer and looked more carefully. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch show decrypt into mbox format
Sandra Snan writes: > This didn't decrypt: > > notmuch show --format=mbox --entire-thread=true --decrypt=true > > The default text format to notmuch show does decrypt the parts just > fine. I wanted the mbox format so I could use it with b4 to extract > patches. Hmm. The code (format_part_mbox in notmuch-show.c) is pretty simple, it basically reads the raw messages (up to gunzip and '^From ' escaping. I guess we could add a second code path that parsed and decrypted the messages before re-serializing them again. At the moment I don't have a clear idea how much code that would be. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: configure prefix ignored by make install
Sandra Snan writes: > I used sudo for the install because /tmp/ isn't gonna be my > ultimate destdir and I don't want my own user to own these files, > root should own them. I was planning to use fpm in --dir mode. > Although I didn't get that far because it instead installed into > /usr/local. Fair enough, but can you try without sudo to try to narrow down where the issue is? Thanks, David ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
