Re: notmuch-search not excluding excluded tags

2024-04-16 Thread David Bremner
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


[emacs] handle unexpected stderr output from notmuch command

2024-04-14 Thread David Bremner


TIL that the running the notmuch command from inside "proxychains4
emacs", generates unexpected output on stderr, which messes up various
emacs commands. This can be worked around by running "proxychains4 -q
emacs", but it would be nice to handle output on stderr more
consistently. I got as far as localizing the bug in
notmuch-command-to-string.

PS. Now you see why we went such effort not to have the notmuch library
print to stderr.

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] perf-test/tag: add maildir sync tests

2024-04-05 Thread David Bremner
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: [PATCH] emacs: Mark "notmuch-tree" command for autoloading

2024-04-04 Thread David Bremner
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

2024-04-04 Thread David Bremner
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: Scheduling mails

2024-04-04 Thread David Bremner
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: Forward email error - forward-sexp: Scan error

2024-04-03 Thread David Bremner
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

2024-04-03 Thread David Bremner
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: Forward email error - forward-sexp: Scan error

2024-03-19 Thread David Bremner
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 ?

2024-03-18 Thread David Bremner
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`

2024-03-15 Thread David Bremner
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] NEWS: aspell(1)d few words

2024-03-12 Thread David Bremner
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


notmuch release 0.38.3 now available

2024-03-09 Thread David Bremner

I let this sit for several months because there were other things to
potentially include, but that hasn't happened, so here is the fix for
the bug reported in mid:87wmtvcor5@alyssa.is

Where to obtain notmuch 0.38.3
===
  https://notmuchmail.org/releases/notmuch-0.38.3.tar.xz

Which can be verified with:

  https://notmuchmail.org/releases/notmuch-0.38.3.tar.xz.sha256.asc
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  9af46cc80da58b4301ca2baefcc25a40d112d0315507e632c0f3f0f08328d054  
notmuch-0.38.3.tar.xz
  -BEGIN PGP SIGNATURE-
  
  iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmXtINkACgkQA0U5G1Wq
  FSHPxRAAklLSh2/Zr/swjFsz/4HkRRysfEuf48PfMm8f3Or4uo7PWXVlrQ2Q/if1
  7RETThoNi9agrs0HHJF+JzdBRIxt4IiWj8JbDjy+wKEN7Ar2S/dOmFOqN0G4Lk8K
  VXFq7/9l9Rs07yyE2wzkGsYIYamu8Oz1NYHjHQoFaGjGPnBTf4CFSxxoqzoX6eZA
  77kA2u89K3gf/pvdU0WWqOHXGwAy8nt21dOD9k0uaHIP/Z47L0Wvv0+Ya7vKDYsx
  cCVgwXcc586RLVxUaY8iCKrSaFFISL5H4+bAfoVHVFYZu4LPr3NcUSH0jY+g4wx0
  caAp3zCfS0xfeB/vFQlRMbYgVGz0CGKssh5Hr3f3jWsYuSzvzxRdw2yKYV9thXW1
  BBfhy8pctPwV+nN1edQMSR1LQdsSAXcYrrkWyErDzyLwXvTHSKvsPiHe4DtaUobp
  YFJAlTJshlHI7FpKqYqypdP+r25rFcwnomyWN6UymQh0OB6lhzurzMP25eSOa5BT
  STaKMHWyK/JLOczrZUsBXIebrUun7iD7zp6a1ICa7uBhsbg5EasHWxb57nfNUTJJ
  rsQudJmyoNwfVDUUXnCejn05QzWMgH3S3uqFyTY56G6qanuikkNcn5Oq9wxkdalZ
  VQ7VSFFCe/j/7RxkC3QYyGuP2Zte4szq0t/CRuZG04+YBQmy5Ck=
  =K3en
  -END PGP SIGNATURE-

  https://notmuchmail.org/releases/notmuch-0.38.3.tar.xz.asc
  (signed by David Bremner)

What's new in notmuch 0.38.3
=

CLI
---

Fix a bug in configuration code that caused the notmuch command to
erroneously report "Error: could not locate database" under some
circumstances.

What is notmuch
===
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
the Xapian library to provide fast, full-text search with a convenient
search syntax.

For more about notmuch, see https://notmuchmail.org



signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: user.other_email wildcard config?

2024-03-03 Thread David Bremner
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?

2024-03-03 Thread David Bremner
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: Individual tag file lines and removing all tags?

2024-02-14 Thread David Bremner
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?

2024-02-14 Thread David Bremner
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?

2024-02-12 Thread David Bremner
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 1/3] CLI/git: remove unused import

2024-01-16 Thread David Bremner
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?

2024-01-15 Thread David Bremner
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

2024-01-11 Thread David Bremner
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


Re: BUG: Python's Message.header fails for empty headers

2024-01-09 Thread 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?

> 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

2024-01-08 Thread 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.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: notmuch show decrypt into mbox format

2023-12-21 Thread David Bremner
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

2023-12-21 Thread David Bremner
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


[PATCH] CLI/show: warn if crypto options are used with mbox format

2023-12-21 Thread David Bremner
This limitation seems somewhat hard to fix, but at least try to warn
users when combining crypto operations with mbox output format.

Because the default is --decrypt=auto, the warning is omitted if
--decrypt=auto is specified. While this is not great, it seems more
wrong to always warn, or to change the default because of this.
---
We could also make this a fatal error, I'm not sure which is better
 notmuch-show.c|  7 +++
 test/T520-show.sh | 19 +++
 2 files changed, 26 insertions(+)

diff --git a/notmuch-show.c b/notmuch-show.c
index 7fb40ce9..97d0beb1 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -1399,6 +1399,13 @@ notmuch_show_command (notmuch_database_t *notmuch, int 
argc, char *argv[])
fprintf (stderr, "Error: specifying parts is incompatible with mbox 
output format.\n");
return EXIT_FAILURE;
}
+   if (params.crypto.decrypt != NOTMUCH_DECRYPT_FALSE
+   && params.crypto.decrypt !=NOTMUCH_DECRYPT_AUTO) {
+   fprintf (stderr, "Warning: mbox format does not support decryption 
(ignored)\n");
+   }
+   if (params.crypto.verify) {
+   fprintf (stderr, "Warning: mbox format does not support signature 
verification (ignored)\n");
+   }
 } else if (format == NOTMUCH_FORMAT_RAW) {
/* raw format only supports single message display */
single_message = true;
diff --git a/test/T520-show.sh b/test/T520-show.sh
index 6bcf109c..65d2ece6 100755
--- a/test/T520-show.sh
+++ b/test/T520-show.sh
@@ -17,6 +17,25 @@ notmuch show foo..
 exit_code=$?
 test_expect_equal 1 $exit_code
 
+test_begin_subtest "warning for --mbox --decrypt"
+notmuch show --format=mbox --decrypt=true '*' 1>/dev/null 2>OUTPUT
+echo $? >> OUTPUT
+cat < EXPECTED
+Warning: mbox format does not support decryption (ignored)
+Warning: mbox format does not support signature verification (ignored)
+0
+EOF
+test_expect_equal_file EXPECTED OUTPUT
+
+test_begin_subtest "warning for --mbox --verify"
+notmuch show --format=mbox --verify '*' 1>/dev/null 2>OUTPUT
+echo $? >> OUTPUT
+cat < EXPECTED
+Warning: mbox format does not support signature verification (ignored)
+0
+EOF
+test_expect_equal_file EXPECTED OUTPUT
+
 test_begin_subtest "notmuch show --sort=newest-first"
 notmuch show --entire-thread=true '*' > EXPECTED
 notmuch show --entire-thread=true --sort=newest-first '*' > OUTPUT
-- 
2.43.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: notmuch show decrypt into mbox format

2023-12-21 Thread David Bremner
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

2023-12-21 Thread David Bremner
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

2023-12-20 Thread David Bremner
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

2023-12-20 Thread David Bremner
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


Re: configure prefix ignored by make install

2023-12-20 Thread David Bremner
Sandra Snan  writes:

> I just ran
>
> ./configure --prefix=/tmp/notmuch
> make
> sudo make install
>
> It clobbered /usr/local instead of installing to the prefix.

I can't duplicate that on Debian testing with GNU Make. FWIW, it should
not be required to use sudo to install into /tmp (but as far as I know
it should work).
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v5] Add hook inside notmuch-mua-reply

2023-12-19 Thread David Bremner
Sandra Snan  writes:

> This hook is run after `notmuch reply` has been successfully called
> with the headers from the original message.


It seems like the commit message should be updated to match the changes
in the patch. With my "editor" hat on, it's also a bit ambigous what
"with the headers from the original message" applies to; it could be
read as `notmuch reply`

It would be nice to mention the motivation for the change (e.g. to
enable autocrypt). Our usual mantra (not _always_ followed, but we try),
is to say something about the "why" as well as the "what".

Thanks for your efforts,

David

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] Add hook inside notmuch-mua-reply

2023-12-11 Thread David Bremner
Tomi Ollila  writes:
>
> another thing what should be the parameters passed, and why. this change
> adds (just) message-id but no reasoning (nor documentation) there...
>

I wonder if we should pass the whole (parsed) original message, for
maximum flexibility?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] Add hook inside notmuch-mua-reply

2023-12-11 Thread David Bremner
Sandra Snan  writes:


> +(defvar in-notmuch-mua-reply-functions nil
> +  "Functions to run after `notmuch-reply' was called successfully
> +without erroring. The functions get the message-id as a string
> +argument.")
> +

Overall this looks reasonable to me, but I'm not sure about the
name. Since emacs doesn't have any namespace facility, I think that any
globals we define should probably start with 'notmuch-'

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [bug] error using company for address (auto)completion

2023-12-11 Thread David Bremner
Giovanni Biscuolo  writes:

> A previous running generation is using emacs 29.1 with company 0.9.13.
>
> It seems an incompatibility with company 0.10.2, no?
>

Seems likely. I have 0.10.0 running OK here.

If you are feeling motivated, you could try bisecting between 10.0 and 10.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [bug] error using company for address (auto)completion

2023-12-10 Thread David Bremner
Giovanni Biscuolo  writes:

> Hello,
>
> I recently upgraded my emacs applications, I'm using Guix as package
> manager on Debian.
>

What versions of emacs and company are you using?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Address Completion in Emacs

2023-12-08 Thread David Wen Riccardi-Zhu
Thank you, Sandra! With your advice, I was able to figure out that corfu
was overriding the Tab key from notmuch. If I disable it,
notmuch-address-expand-name works (with orderless and vertico). I'll see
if I can find a way to pipe it into corfu somehow.

Sandra Snan  writes:

> David, I have message-completion-alist set to this value:
>
> (("^\\(Resent-\\)?\\(To\\|B?Cc\\|Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):"
>  
>   .  notmuch-address-expand-name) 
>  ("^\\(Newsgroups\\|Followup-To\\|Posted-To\\|Gcc\\):" . 
>  message-expand-group) ("^\\([^ :]*-\\)?\\(To\\|B?Cc\\|From\\):" . 
>  message-expand-name)) 
>
> That way, when I hit tab in the sender field, which is bound to 
> message-tab, it'll run notmuch-address-expand-name which can find 
> pretty much everyone I've ever heard of.
>
> I additionally have an old BBDB that I've been using for ages that 
> I can access with ESC TAB which is set to bbdb-complete-mail but I 
> literally only have 16 people in there (I just checked). I use 
> them for my most common faves so I can get their most canonical 
> address with just a few letters.
>
> As for weeding through the list of candidates, there are packages 
> such as orderless and vertico that can enhance all calls to 
> completing-read, including the one in notmuch-address-expand-name. 
> After using it a while it does a good job at giving me the 
> relevantest ones at the top and letting me filter through them 
> further.
>
> Corfu and company-mode, I have never heard of! So this is more of 
> an answer to the "alternatively" part you asked.
>
> Sandra
>
>
> David Wen Riccardi-Zhu  writes:
>
>> Hello,
>>
>> I had working address completion in Emacs with company-mode, but
>> recently switched to corfu. Has anyone been able to get address
>> completion to work with it?
>>
>> Alternatively, I'm wondering how the internal completion style works. Is
>> there a function I can call to get internal address completion to kick
>> in?
>>
>> Lastly, is it possible to remove addresses from the list of candidates?
>> I have a few addresses that were consistently recommended even though
>> they had typos in them.
>>
>> I have this in my config:
>>
>> (setq notmuch-address-command 'internal
>>   notmuch-address-internal-completion '(sent nil)
>>   notmuch-address-save-filename "~/org/contacts/notmuch-contacts"
>>   ;; ... 
>> )
>>
>> Can I manually clean up my notmuch-contacts file? 
>>
>> If yes, is it possible to add newlines to the file, to make it easier to
>> search and edit?
>>
>> Thank you!
>>
>> David
>>
>> -- 
>> dwrz|朱为文
>> ___
>> notmuch mailing list -- notmuch@notmuchmail.org
>> To unsubscribe send an email to notmuch-le...@notmuchmail.org

-- 
dwrz|朱为文
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Address Completion in Emacs

2023-12-08 Thread David Wen Riccardi-Zhu
Hello,

I had working address completion in Emacs with company-mode, but
recently switched to corfu. Has anyone been able to get address
completion to work with it?

Alternatively, I'm wondering how the internal completion style works. Is
there a function I can call to get internal address completion to kick
in?

Lastly, is it possible to remove addresses from the list of candidates?
I have a few addresses that were consistently recommended even though
they had typos in them.

I have this in my config:

(setq notmuch-address-command 'internal
  notmuch-address-internal-completion '(sent nil)
  notmuch-address-save-filename "~/org/contacts/notmuch-contacts"
  ;; ... 
)

Can I manually clean up my notmuch-contacts file? 

If yes, is it possible to add newlines to the file, to make it easier to
search and edit?

Thank you!

David

-- 
dwrz|朱为文
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: potential fix for wrong error message

2023-12-06 Thread David Bremner
Alyssa Ross  writes:

> David Bremner  writes:
>
>> Hi Alyssa
>>
>> I'm not sure if this is a fix for your bug, but it is a fix for a
>> very similar bug.
>
> This is a fix for my bug, thanks a lot!
>
> Tested-by: Alyssa Ross 

Applied to release and master.  Planning another point release, let me
know if there are other (small) bugfixes that should go in.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Advanced search with wildcard using notmuch for mutt

2023-12-04 Thread David Bremner
Olly Betts  writes:

> The development version of Xapian supports both `*` and `?` glob-style
> wildcards in any position.
>
> You can enable them for the QueryParser using FLAG_WILDCARD_MULTI,
> FLAG_WILDCARD_SINGLE or FLAG_WILDCARD_GLOB (the last one is just the
> first two combined).

I see FLAG_FUZZY as well, supporting edit distance. Sounds like release
1.5 will be a crowd pleaser ;)

d

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Advanced search with wildcard using notmuch for mutt

2023-12-04 Thread David Bremner
io  writes:

> what xapian 'indexing system' did was to index the entire sentence
> 'xxx_yyy' and you will not be able to find any sentence which contain
> the word 'yyy'?

I'm curious that you refer to xxx_yyy as a sentence. In the contexts I
am familiar with, the point of _ is to join things together into one
word (or one identifier/token). Other than that your understanding seems
correct.

> xapian should have this simple wildcard feature which 'grep'(search)
> offer. ($grep '*word*' file). It is strange that xapian restrict the
> search to 'trailing wildcard' only.

I guess the restriction is based on what is easy to do efficiently with
the Xapian database (find prefixes).  If I remember correctly there was
some work in progress to support leading wildcards in Xapian. I can't
find relevant discussion now, but I CC'ed the Xapian list in case
someone remembers that.

> Novice user who get introduce to notmuch just want to run the search
> and get the result straight away.

Generally the focus of Xapian (and thus notmuch) is on words and
phrases like "bob ate my pizza". I agree this is disappointing for
someone who wants "all the flexibility of grep, but faster".
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 1/2] test: add known broken test for incorrect error message

2023-12-03 Thread David Bremner
Duplicate bug reported in id:87wmtvcor5@alyssa.is

The error message is nonsense, because notmuch config list actually
includes the database in those two cases.
---
 test/T055-path-config.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/test/T055-path-config.sh b/test/T055-path-config.sh
index efc79e8b..fcaf09d3 100755
--- a/test/T055-path-config.sh
+++ b/test/T055-path-config.sh
@@ -374,6 +374,12 @@ EOF
   notmuch new
   test_expect_equal "$(xapian-metadata get ${XAPIAN_PATH} version)" 3
   ;;
+   home_mail|maildir_env)
+  test_begin_subtest "No errors from config list ($config)"
+  test_subtest_known_broken
+  notmuch config list 2>OUTPUT 1>/dev/null
+  test_expect_equal_file /dev/null OUTPUT
+  ;;
*)
   backup_database
   test_begin_subtest ".notmuch without xapian/ handled gracefully 
($config)"
-- 
2.42.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


potential fix for wrong error message

2023-12-03 Thread David Bremner
Hi Alyssa

I'm not sure if this is a fix for your bug, but it is a fix for a
very similar bug.

d

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 2/2] lib: clear error message on success in _choose_database_path

2023-12-03 Thread David Bremner
Previously we both found a database and returned a message saying that
the database could not be found (along with a success code). This
change should prevent spurious error output.
---
 lib/open.cc  | 5 +
 test/T055-path-config.sh | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/open.cc b/lib/open.cc
index 005872dc..463e38bf 100644
--- a/lib/open.cc
+++ b/lib/open.cc
@@ -249,6 +249,11 @@ _choose_database_path (notmuch_database_t *notmuch,
return NOTMUCH_STATUS_NO_DATABASE;
 }
 
+if (*message) {
+   free (*message);
+   *message = NULL;
+}
+
 return NOTMUCH_STATUS_SUCCESS;
 }
 
diff --git a/test/T055-path-config.sh b/test/T055-path-config.sh
index fcaf09d3..1feb5624 100755
--- a/test/T055-path-config.sh
+++ b/test/T055-path-config.sh
@@ -376,7 +376,6 @@ EOF
   ;;
home_mail|maildir_env)
   test_begin_subtest "No errors from config list ($config)"
-  test_subtest_known_broken
   notmuch config list 2>OUTPUT 1>/dev/null
   test_expect_equal_file /dev/null OUTPUT
   ;;
-- 
2.42.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [BUG] "Error: Cannot open database…" when loading config

2023-12-03 Thread David Bremner
Alyssa Ross  writes:

> Since commit 1c10d91d ("Pass error message from GLib ini parser to CLI"),
> when I run "notmuch config list", I get this error message at the start
> of the output:
>
>   Error: Cannot open database at /home/qyliss/state/notmuch/default: No 
> such file or directory.
>
> Presumably this is because my database is in a non-default location,
> which it doesn't know until it's loaded the config.

I suspect something is being reported as an error when it really isn't
(the library tries a sequence of things when starting up).

If you can tell me a bit more about your setup, I can try and duplicate
the bug. For starters, where is your config file located, and where is
your database?

You could also try the following patch, which is a bit of a wild guess

diff --git a/notmuch.c b/notmuch.c
index 814b9e42..7e396d43 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -563,7 +563,7 @@ main (int argc, char *argv[])
   NULL,
   ,
   _string);
-   if (status_string) {
+   if (status && status_string) {
fputs (status_string, stderr);
free (status_string);
status_string = NULL;
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Inconsistency in quoting probabilistic prefixes?

2023-12-03 Thread David Bremner
"artur.brzozowski"  writes:

> Hey,
>
> Trying to add List matching to my notmuch tagging and I found
> something that surprises me. Namely,

This is a duplicate message, my fault, I saw it in the moderation queue,
didn't realize it already went to the list.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Inconsistency in quoting probabilistic prefixes?

2023-12-02 Thread David Bremner
"artur.brzozowski"  writes:

> Hi!
>
> Trying to add List matching to my notmuch tagging and I found
> something that surprises me. Namely,
>
> 1) when I want to match a bunch of alternatives for 
> prefix, I have to quote the parenthesis to get the results:
>
> $ notmuch search 'from:"(b...@some.io or m...@example.com)"'
> 
> $ notmuch search 'from:(b...@some.io or m...@example.com)'
> 
>
> 2) when I want to do the same to a parenthesised set of 
> alternatives, I must leave it unquoted to get the results.
>
> $ notmuch search 'List:"(freebsd-annou...@freebsd.org or m...@openbsd.org)"'
> 
> $ notmuch search 'List:(freebsd-annou...@freebsd.org or m...@openbsd.org)'
> 
>
> I use the standard "index.header.List=List-Id" key-value as
> pointed out in notmuch-config(1).
>
> Is this expected behaviour? If so, why?

Unfortunately there are likely to be inconsistencies between those
fields supporting regex queries (like from) and "true" probabilistic
prefixes. I think that these problems are tricky to fix because of the
way notmuch extends the Xapian query parser, namely by reparsing a
"boolean" term.

The sexp query parser should not have these issues.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] notmuch-emacs-mua: avoid extra separators at the end of the line

2023-12-01 Thread David Bremner
Jani Nikula  writes:

> Currently the --to/--cc/--bcc options add "u...@example.com, " to the
> message headers, with the the unnecessary ", " separator after the
> last address, regardless of how many addresses are being added.
>
> This used to be fine, but with recent emacs mm, trying to send the
> email with the trailing commas leads to prompt:
>
>   Email address  looks invalid; send anyway? (y or n)
>
> Fix this by only adding the commas between addresses, avoiding the
> trailing commas.

applied to master, released as part of 0.38.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


notmuch release 0.38.2 now available

2023-12-01 Thread David Bremner

Where to obtain notmuch 0.38.2
===
  https://notmuchmail.org/releases/notmuch-0.38.2.tar.xz

Which can be verified with:

  https://notmuchmail.org/releases/notmuch-0.38.2.tar.xz.sha256.asc
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  5282ebe4742b03ee00fc3ab835969f94d229279db7232112bdc5009d861e947e  
notmuch-0.38.2.tar.xz
  -BEGIN PGP SIGNATURE-
  
  iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmVpycUACgkQA0U5G1Wq
  FSE38BAAslqoCjta0Gd+PD5AtIdhkCba6EaJHyPbIFDkNS3JJJDVjP9PDLVNseVj
  U46lUooMkOU32FIaEqYkm/Ym4C81sWa4H3jy4HXQRIlzdeOr+JZTwApSRHjjjBIY
  Mejo1V3eObBTk+8AljDdCEH4uHBEWP6Pt1VaDq6o6KkuVoZNwiEiw5KnSZ4XNSC3
  b0XZ61UOYtWbJSx8x9avbtPZiVYDK3/uVZoywwHuwqZNSBTCFt7ed7vNFi2OwxGd
  GVTATlQy9vWhaQvMxL5pWNa3QYTscxzgQnodghfOaeJ4gGhg5jYyKsaMl5jeTjnR
  iYrJ7EdpQsiLUTAWTTqsB5kfaxUmt/RFdmAHVmNVt17s7zoz9CTiznFvHa1o06X5
  5JH1abyqd1PxvaY06LoOpnwm5jvlTUDL2LdcKqUktxmbC+ZSWN3+2QoII41wnI4p
  M9BliMWIuDwEXHKnbf2Drjaw38gaKg03Hcps5KpPlremmaDrXSQgMvWlq88LjFlL
  3V1H6UwNp7YPyZttk7o0aSMkVRAnk0Cq6EuecZIdlgsuYoh5DbVEGQlAYidvwtNj
  qrHYEYDQg7P5d3OosIWd31VIKzMCD1xgfTCRi665BBAt5lMEr7giJ2he2Po4ADTX
  7XYnjA2J3NdnMOsoBtq6u8pQovDHa5uOoj6rJjMx1VJpo9dcxug=
  =XF0A
  -END PGP SIGNATURE-

  https://notmuchmail.org/releases/notmuch-0.38.2.tar.xz.asc
  (signed by David Bremner)

What's new in notmuch 0.38.2
=

Library
---

Make sorting of string maps lexicographic on (key,value) pairs. This
avoids some test failures due to variation in message property output
order.

Emacs
-

Avoid extra separators after the last address in `notmuch-emacs-mua`.


What is notmuch
===
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
the Xapian library to provide fast, full-text search with a convenient
search syntax.

For more about notmuch, see https://notmuchmail.org


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Advanced search with wildcard using notmuch for mutt

2023-11-30 Thread David Bremner
Michael J Gruber  writes:


> Using xapian commands, one could extract all stems and grep those for a
> term which one "remembers partially" (often happened to me), and then feed
> that into notmuch. Might be worthwhile scripting or even integrating into
> notmuch (sexp?).

The words are stored unstemmed as well, so in principle we could extract
those and do some kind of fuzzy search on them to construct
queries. This is what notmuch already does for regex searches on fields
other than from, subject, and mid. The reason this is not too attractive
for the message body is that it works on a per word basis, and most uses
of regex (although not the one under discussion) involve matching
multiple words. Currently Xapian only supports trailing wildcards (which
would not help here), but we could do that for body words. It just
doesn't (or hasn't) seemed like such a common use case. 

Alas, none of the forward looking discussion really helps the original
poster.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] lib/string_map: simulate stable sorting

2023-11-28 Thread David Bremner
Tomi Ollila  writes:

> On Sat, Nov 25 2023, David Bremner wrote:
>
>> qsort(3) does not promise stability, and recent versions of glibc have
>> been showing more unstable behaviour [2]. Michael Gruber observed [1] test
>> breakage due to changing output order for message properties.
>>
>> We provide a sorting order of (key,value) pairs that _looks_ stable by
>> breaking ties based on value if keys are equal. Internally there may
>> be some instability in the case of duplicate (key,value) pairs, but it
>> should not be observable via the iterator API.
>
> I don't know (from the visible context here) why this is needed, but I
> can image it is useful, so
>
> LGTM.
>
> Tomi

Applied to release and master.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: macOS and go language bindings

2023-11-26 Thread David Bremner
Reto  writes:

[thanks for the explanation of how aerc uses notmuch]

>
> Go will execute a C compiler / linker as usual.
> In your case, you basically need to setup 2 things:
>
>   1) notmuch.h in some include dir, normally /usr/include/notmuch.h or 
> some such,
>   which is needed by the compiler.
>
>   2) libnotmuch.so, which is normally located at /usr/lib/libnotmuch.so 
> or some such,
>   which is needed by the linker.
>
> I have no clue where brew stores those things, shouldn't be too hard to 
> figure out though.

macOS has a different naming scheme for shared libraries (and maybe they
are not ELF?). Notmuch should install libnotmuch.NN.dylib (where NN is
currently 5) and libnotmuch.dylib somewhere (given ./configure
--prefix=somewhere)

I hope this helps, even if it is second hand information.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] lib/string_map: simulate stable sorting

2023-11-25 Thread David Bremner
qsort(3) does not promise stability, and recent versions of glibc have
been showing more unstable behaviour [2]. Michael Gruber observed [1] test
breakage due to changing output order for message properties.

We provide a sorting order of (key,value) pairs that _looks_ stable by
breaking ties based on value if keys are equal. Internally there may
be some instability in the case of duplicate (key,value) pairs, but it
should not be observable via the iterator API.

[1]: id:caa19uishjvfmwh0pmc7wwdycoszu3yqnbuyhu3zmennrh31...@mail.gmail.com
[2]: id:87msv3i44u@oldenburg.str.redhat.com
---
 lib/string-map.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/string-map.c b/lib/string-map.c
index e3a81b4f..99bc2ea2 100644
--- a/lib/string-map.c
+++ b/lib/string-map.c
@@ -86,10 +86,14 @@ _notmuch_string_map_append (notmuch_string_map_t *map,
 static int
 cmppair (const void *pa, const void *pb)
 {
+int cmp = 0;
 notmuch_string_pair_t *a = (notmuch_string_pair_t *) pa;
 notmuch_string_pair_t *b = (notmuch_string_pair_t *) pb;
 
-return strcmp (a->key, b->key);
+cmp = strcmp (a->key, b->key);
+if (cmp == 0)
+   cmp = strcmp (a->value, b->value);
+return cmp;
 }
 
 static void
-- 
2.42.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: T610 failing on Fedora rawhide

2023-11-24 Thread David Bremner
Michael J Gruber  writes:

> Hi there,
>
> during my first tests for Python 3.13 (hooray...) I noticed that some tests
> in T610 started to fail independent of that. It seems that with notmuch
> 0.38.1 on current Fedora rawhide,  `notmuch_message_get_properties()`
> returns properties in a different order, while the tests expect a specific
> order. So I'm wondering:
> - Is there a particular order which the interface promises to deliver?
> - If yes: What could cause it to be different?
> If not there's some work to do making the tests independent of the order ...
> This is not glib again, is it?

Can you try the following patch?

diff --git a/lib/string-map.c b/lib/string-map.c
index e3a81b4f..99bc2ea2 100644
--- a/lib/string-map.c
+++ b/lib/string-map.c
@@ -86,10 +86,14 @@ _notmuch_string_map_append (notmuch_string_map_t *map,
 static int
 cmppair (const void *pa, const void *pb)
 {
+int cmp = 0;
 notmuch_string_pair_t *a = (notmuch_string_pair_t *) pa;
 notmuch_string_pair_t *b = (notmuch_string_pair_t *) pb;

-return strcmp (a->key, b->key);
+cmp = strcmp (a->key, b->key);
+if (cmp == 0)
+   cmp = strcmp (a->value, b->value);
+return cmp;
 }

 static void
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: T610 failing on Fedora rawhide

2023-11-24 Thread David Bremner
David Bremner  writes:

> Michael J Gruber  writes:
>
>> during my first tests for Python 3.13 (hooray...) I noticed that some tests
>> in T610 started to fail independent of that. It seems that with notmuch
>> 0.38.1 on current Fedora rawhide,  `notmuch_message_get_properties()`
>> returns properties in a different order, while the tests expect a specific
>> order. So I'm wondering:
>> - Is there a particular order which the interface promises to deliver?
>> - If yes: What could cause it to be different?
>> If not there's some work to do making the tests independent of the order ...
>> This is not glib again, is it?
>
> The order is the result of sorting the keys (property names) using the
> system qsort. So the first is potentially explicable, but the second
> suggests a strange (to me) collation order. Do you happen to know the
> locale used by these runs?
>
> Ultimately the comparisons are done with strcmp (string-map.c).

OK, I misread the output (there seems to be some confusing line
wrapping). The test with #= is not actually a key, just a line
marker. The underlying problem seems to be the same: qsort behaving
differently, or perhaps (but less likely, I think) different input to
qsort from Xapian.  We could force the output to be stable by sorting on
lexicographic order (include the property value in the comparison).
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: T610 failing on Fedora rawhide

2023-11-24 Thread David Bremner
Michael J Gruber  writes:

> during my first tests for Python 3.13 (hooray...) I noticed that some tests
> in T610 started to fail independent of that. It seems that with notmuch
> 0.38.1 on current Fedora rawhide,  `notmuch_message_get_properties()`
> returns properties in a different order, while the tests expect a specific
> order. So I'm wondering:
> - Is there a particular order which the interface promises to deliver?
> - If yes: What could cause it to be different?
> If not there's some work to do making the tests independent of the order ...
> This is not glib again, is it?

The order is the result of sorting the keys (property names) using the
system qsort. So the first is potentially explicable, but the second
suggests a strange (to me) collation order. Do you happen to know the
locale used by these runs?

Ultimately the comparisons are done with strcmp (string-map.c).

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 26/27] emacs: avoid binding unnamed commands in keymaps

2023-10-29 Thread David Bremner
Ryan Tate  writes:

> Jonas Bernoulli  writes:
>
>> - -(defun notmuch-tree-close-message-pane-and (func) -  "Close 
>> message pane and execute FUNC. 
>
> I am confused why a function used in config files and documented 
> on the notmuch website (to this moment) as an example of how to 
> configure something would be removed, and to be removed without 
> any announcement.

We try our best to minimize the amount of breaking changes (and to
announce them when they happen), but sometimes things slip through. BTW
notmuchmail.org is mostly a wiki, and we rely on the user community to
update it. If you would like to help with that (e.g. to mark those
snippets as broken), see

https://notmuchmail.org/wikiwriteaccess/

> I argue that a user (who is not literally an author of notmuch)
> should be able to reliably use the software, which involves configuring
> it and having that configuration continue to work. 

Sure, that the intention. This is somewhat challenging with the emacs UI
as it exists, since the line between API that people can rely on and
internals is not well drawn in the older code. The changes under
discussion actually make that a bit better by marking some macros as
internal.

As far as your specific technical issue, I guess you can recover the
deleted functions and put them (possibly renamed) in your init.el.

Since you are using Debian, you might be interested in using notmuch
from stable backports; this would mean you will not see several years of
changes all at once.  It's a personal thing whether you prefer more
smaller disruptions over fewer larger ones.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


notmuch release 0.38.1 now available

2023-10-26 Thread David Bremner

Where to obtain notmuch 0.38.1
===
  https://notmuchmail.org/releases/notmuch-0.38.1.tar.xz

Which can be verified with:

  https://notmuchmail.org/releases/notmuch-0.38.1.tar.xz.sha256.asc
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  c1418760d0e53efad1f35267eb99a50f8b7fa2855c1473e0a4c982b86f8ecdd4  
notmuch-0.38.1.tar.xz
  -BEGIN PGP SIGNATURE-
  
  iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmU69HgACgkQA0U5G1Wq
  FSFW2g//S7B96YPiQRZFp/hfSdKx+2pvakEDcPOmioOPF1w2egEHsbK09kn+jhh5
  MwnIX85dIK9aClA8QgQIlscXRTPLQvtLfAYoZusqcIfB7YWzvFZTJNCEtnXS6cRW
  6gs3bpjjQvhCaCsAK8oqtRXai56YG0JG9e+zMvtLggVYEtUtCLD2HNup7jC8b1bW
  Ide0Io65PeO0Ki8bppwnYcjW6Y/dWIWFKWDiqEa4qSpTK3l8227Xe+tG4DHDAwaw
  QMsLDxuJF8eJsKjnJ8vCNNxnaid0O3K3w+rrUI1Kow66z4yceO6UmqIOMKpgpZcG
  yR7UyurPDpK6a6HS3/34T3z1xSv8kiVWhsNKplyBQSScOxuqkr62BaaO6HGDKNgO
  565VaW/Hp7T1UWhYRdhg1thm+t5lh+STD+uziP8yuNErfX5xBwKkUnNYo1nnOG/T
  c3YlUwFUaZrymRbj1PzWCylsHpIIgb4B6bbdYAUlmnWcghEycvlApFBu2+leDRR3
  nNmSgKgBeiHh1kBBmZUlG/7Ml6EOiIAyuGhMPESMbz6WC67WYSx5x9o9IDprKitv
  5hzYVkBKMuEKBJ+OUNbl1oMyU680kH0V/uENHkoCUfDLd2Jwo50vwminzjDxqEIG
  cYonAe7C5d7BIyPaSQV1rLMtNT0saRktv+gZbzjD5a+8cXDjx6g=
  =qc1o
  -END PGP SIGNATURE-

  https://notmuchmail.org/releases/notmuch-0.38.1.tar.xz.asc
  (signed by David Bremner)

What's new in notmuch 0.38.1
=

CLI
---

Report parse errors in config files.

Emacs
-

Fix image toggling for Emacs >= 29.1.

notmuch-mutt


Fix syntax error in script.

What is notmuch
===
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
the Xapian library to provide fast, full-text search with a convenient
search syntax.

For more about notmuch, see https://notmuchmail.org



signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] notmuch-mutt: fix Perl syntax of hash index lookups

2023-10-12 Thread David Bremner
Paul Wise  writes:

> Fixes: commit 239fdbbbf0cbd6cd6ebafb87e88cdb3cded75364
> ---
>  contrib/notmuch-mutt/notmuch-mutt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/notmuch-mutt/notmuch-mutt 
> b/contrib/notmuch-mutt/notmuch-mutt
> index 1ac68065..b81252c8 100755
> --- a/contrib/notmuch-mutt/notmuch-mutt
> +++ b/contrib/notmuch-mutt/notmuch-mutt
> @@ -67,7 +67,7 @@ sub check_search_cache_maildir($) {
>  foreach my $d (@contents) {
>  -l "$maildir/$d" and die_dir( $maildir, "contains symlink $d");
>  -d "$maildir/$d" or die_dir( $maildir, "contains non-directory $d");
> -exists($required[$d]) or die_dir( $maildir, "contains directory $d");
> +exists($required{$d}) or die_dir( $maildir, "contains directory $d");
>  }
>  }
>  
> -- 
> 2.42.0
>
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

applied to release and master (will be part of 0.38.1)

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 4/4] emacs/mua: change name of ignored parameter

2023-10-06 Thread David Bremner
Suppress compiler warning.
---
 emacs/notmuch-mua.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 3679d7d7..e4b7e9d1 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -403,7 +403,7 @@ instead of `message-mode' and SWITCH-FUNCTION is mandatory."
 
 (defun notmuch-mua-mail ( to subject other-headers _continue
   switch-function yank-action send-actions
-  return-action  ignored)
+  return-action  _ignored)
   "Invoke the notmuch mail composition window.
 
 The position of point when the function returns differs depending
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 3/4] emacs/address: rewrite docstring for n-a-selection-function

2023-10-06 Thread David Bremner
The previous version essentially repeated the source code, and
generated a compiler warning.
---
 emacs/notmuch-address.el | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 1a4cdda2..f756254c 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -153,8 +153,7 @@ matching `notmuch-address-completion-headers-regexp'."
 ;;; Setup
 
 (defun notmuch-address-selection-function (prompt collection initial-input)
-  "Call (`completing-read'
-  PROMPT COLLECTION nil nil INITIAL-INPUT 'notmuch-address-history)"
+  "Default address selection function: delegate to completing read."
   (completing-read
prompt collection nil nil initial-input 'notmuch-address-history))
 
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 2/4] emacs: wrap docstrings

2023-10-06 Thread David Bremner
Suppress byte-compiler warnings about >80 character docstrings.
---
 emacs/notmuch-hello.el | 23 ++-
 emacs/notmuch-show.el  | 19 ---
 emacs/notmuch-tree.el  |  9 ++---
 3 files changed, 32 insertions(+), 19 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 2d4fdc02..47ece536 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -717,7 +717,8 @@ with `notmuch-hello-query-counts'."
   "Keymap for \"notmuch hello\" buffers.")
 
 (define-derived-mode notmuch-hello-mode fundamental-mode "notmuch-hello"
-  "Major mode for convenient notmuch navigation. This is your entry portal 
into notmuch.
+  "Major mode for convenient notmuch navigation. This is your entry
+portal into notmuch.
 
 Saved searches are \"bookmarks\" for arbitrary queries. Hit RET
 or click on a saved search to view matching threads. Edit saved
@@ -853,7 +854,8 @@ Complete list of currently available key bindings:
(widget-create 'notmuch-search-item :value search :size width)
 
 (defun notmuch-hello-insert-searches (title query-list  options)
-  "Insert a section with TITLE showing a list of buttons made from QUERY-LIST.
+  "Insert a section with TITLE showing a list of buttons made from
+QUERY-LIST.
 
 QUERY-LIST should ideally be a plist but for backwards
 compatibility other forms are also accepted (see
@@ -867,13 +869,16 @@ Supports the following entries in OPTIONS as a plist:
 :show-empty-searches - show buttons with no matching messages
 :hide-if-empty - hide if no buttons would be shown
(only makes sense without :show-empty-searches)
-:filter - This can be a function that takes the search query as its argument 
and
-   returns a filter to be used in conjunction with the query for that search 
or nil
-   to hide the element. This can also be a string that is used as a combined 
with
-   each query using \"and\".
-:filter-count - Separate filter to generate the count displayed each search. 
Accepts
-   the same values as :filter. If :filter and :filter-count are specified, this
-   will be used instead of :filter, not in conjunction with it."
+:filter - This can be a function that takes the search query as
+   its argument and returns a filter to be used in conjunction
+   with the query for that search or nil to hide the
+   element. This can also be a string that is used as a combined
+   with each query using \"and\".
+:filter-count - Separate filter to generate the count displayed
+   each search. Accepts the same values as :filter. If :filter
+   and :filter-count are specified, this will be used instead of
+   :filter, not in conjunction with it."
+
   (widget-insert title ": ")
   (when (and notmuch-hello-first-run (plist-get options :initially-hidden))
 (add-to-list 'notmuch-hello-hidden-sections title))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 4cc5aa57..4c0ad74d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -2507,10 +2507,12 @@ kill-ring."
 (defun notmuch-show-stash-mlarchive-link ( mla)
   "Copy an ML Archive URI for the current message to the kill-ring.
 
-This presumes that the message is available at the selected Mailing List 
Archive.
+This presumes that the message is available at the selected
+Mailing List Archive.
 
-If optional argument MLA is non-nil, use the provided key instead of prompting
-the user (see `notmuch-show-stash-mlarchive-link-alist')."
+If optional argument MLA is non-nil, use the provided key instead
+of prompting the user (see
+`notmuch-show-stash-mlarchive-link-alist')."
   (interactive)
   (let ((url (cdr (assoc
   (or mla
@@ -2527,12 +2529,15 @@ the user (see 
`notmuch-show-stash-mlarchive-link-alist')."
(concat url (notmuch-show-get-message-id t))
 
 (defun notmuch-show-stash-mlarchive-link-and-go ( mla)
-  "Copy an ML Archive URI for the current message to the kill-ring and visit 
it.
+  "Copy an ML Archive URI for the current message to the
+ kill-ring and visit it.
 
-This presumes that the message is available at the selected Mailing List 
Archive.
+This presumes that the message is available at the selected
+Mailing List Archive.
 
-If optional argument MLA is non-nil, use the provided key instead of prompting
-the user (see `notmuch-show-stash-mlarchive-link-alist')."
+If optional argument MLA is non-nil, use the provided key instead
+of prompting the user (see
+`notmuch-show-stash-mlarchive-link-alist')."
   (interactive)
   (notmuch-show-stash-mlarchive-link mla)
   (browse-url (current-kill 0 t)))
diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index b58fa6a6..7fa403fc 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -200,7 +200,8 @@ Note that the author string should not contain whitespace
 
 (defface notmuch-tree-match-tree-face
   nil
-  "Face used in tree mode for the thread tree block graphics in messages 
matching the query."
+  "Face used in tree mode for the thread tree block 

[PATCH 1/4] emacs: update quoting in docstrings

2023-10-06 Thread David Bremner
The complicated looking escapes are needed to avoid compile time
warnings.  (info "(elisp) Text Quoting Style") for details.
---
 emacs/notmuch-hello.el  |  2 +-
 emacs/notmuch-lib.el|  6 +++---
 emacs/notmuch-parser.el |  8 
 emacs/notmuch-print.el  |  4 ++--
 emacs/notmuch-tag.el| 12 ++--
 emacs/notmuch-wash.el   |  2 +-
 6 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 4662e704..2d4fdc02 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -145,7 +145,7 @@ a plist. Supported properties are
or nil. Nil means use the default sort order.
   :search-type Specify whether to run the search in search-mode,
tree mode or unthreaded mode. Set to `tree' to
-   specify tree mode, 'unthreaded to specify
+   specify tree mode, \\='unthreaded to specify
unthreaded mode, and set to nil (or anything
except tree and unthreaded) to specify search
mode.
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index a09f4ab8..14469a90 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -414,9 +414,9 @@ This is similar to `describe-function' for the current major
 mode, but bindings tables are shown with documentation strings
 rather than command names.  By default, this uses the first line
 of each command's documentation string.  A command can override
-this by setting the 'notmuch-doc property of its command symbol.
+this by setting the \\='notmuch-doc property of its command symbol.
 A command that supports a prefix argument can explicitly document
-its prefixed behavior by setting the 'notmuch-prefix-doc property
+its prefixed behavior by setting the \\='notmuch-prefix-doc property
 of its command symbol."
   (interactive)
   (let ((doc (substitute-command-keys
@@ -726,7 +726,7 @@ single element face list."
 (list face)))
 
 (defun notmuch-apply-face (object face  below start end)
-  "Combine FACE into the 'face text property of OBJECT between START and END.
+  "Combine FACE into the \\='face text property of OBJECT between START and 
END.
 
 This function combines FACE with any existing faces between START
 and END in OBJECT.  Attributes specified by FACE take precedence
diff --git a/emacs/notmuch-parser.el b/emacs/notmuch-parser.el
index f04b07c2..710c60e1 100644
--- a/emacs/notmuch-parser.el
+++ b/emacs/notmuch-parser.el
@@ -35,7 +35,7 @@ complete S-expression from the input.  However, it extends 
this
 with an additional function that requires the next value in the
 input to be a list and descends into it, allowing its elements to
 be read one at a time or further descended into.  Both functions
-can return 'retry to indicate that not enough input is available.
+can return \\='retry to indicate that not enough input is available.
 
 The parser always consumes input from point in the current
 buffer.  Hence, the caller is allowed to delete any data before
@@ -52,10 +52,10 @@ point and may resynchronize after an error by moving point."
 (defun notmuch-sexp-read (sp)
   "Consume and return the value at point in the current buffer.
 
-Returns 'retry if there is insufficient input to parse a complete
+Returns \\='retry if there is insufficient input to parse a complete
 value (though it may still move point over whitespace).  If the
 parser is currently inside a list and the next token ends the
-list, this moves point just past the terminator and returns 'end.
+list, this moves point just past the terminator and returns \\='end.
 Otherwise, this moves point to just past the end of the value and
 returns the value."
   (skip-chars-forward " \n\r\t")
@@ -125,7 +125,7 @@ returns the value."
 (defun notmuch-sexp-begin-list (sp)
   "Parse the beginning of a list value and enter the list.
 
-Returns 'retry if there is insufficient input to parse the
+Returns \\='retry if there is insufficient input to parse the
 beginning of the list.  If this is able to parse the beginning of
 a list, it moves point past the token that opens the list and
 returns t.  Later calls to `notmuch-sexp-read' will return the
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
index 85fa1f21..8d9f1b08 100644
--- a/emacs/notmuch-print.el
+++ b/emacs/notmuch-print.el
@@ -41,11 +41,11 @@
 ;;; Utility functions
 
 (defun notmuch-print-run-evince (file)
-  "View FILE using 'evince'."
+  "View FILE using `evince'."
   (start-process "evince" nil "evince" file))
 
 (defun notmuch-print-run-muttprint ( output)
-  "Pass the contents of the current buffer to 'muttprint'.
+  "Pass the contents of the current buffer to `muttprint'.
 
 Optional OUTPUT allows passing a list of flags to muttprint."
   (apply #'notmuch--call-process-region (point-min) (point-max)
diff --git a/emacs/notmuch-tag.el b/emacs/notmuch-tag.el
index 95977881..81101828 100644
--- a/emacs/notmuch-tag.el
+++ 

partial cleanup of warnings from byte compilation

2023-10-06 Thread David Bremner
This is almost all docstring formatting, except for the last
patch.

This is really just some low hanging fruit, but presumable eliminating
some warnings is better than nothing. The warnings are more annoying
now that native compilation exposes them to every user.


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: automatically changing FCC when From changes (or fill FCC only when sending)

2023-10-02 Thread David Pinto
On Fri, 22 Sept 2023 at 10:25, David Bremner  wrote:
> David Pinto  writes:
> > [...]
> > You mention updating the "From" when the "To" changes with the
> > notmuch-address-post-completion-functions hook.  Could there be a hook
> > for when the "From" changes which I could use to change the FCC?
>
> My partial-solution relies on using completion to change To. If you are
> OK with that (i.e. manual editing without completion would not update
> Fcc), then the same scheme could work.
>
> Another option that seems technically feasible, but would involve some
> elisp programming, would be to write a command that re-applies the
> calculation of Fcc from From that already exists, and run that manually
> or perhaps opt-in to running it automatically on send.

Thank you for the hints.  I followed your hint and read the code for
notmuch-fcc-header-setup.  Then I wrote a function that updates the
FCC header and I hooked it to the address-post-completion:

(defun update-fcc-header (addr)
  "Replace FCC header appropriate for given address"
  (let ((subdir (cdr (assoc addr notmuch-fcc-dirs 'string-match-p
(when subdir
  (save-excursion
(message-goto-fcc)
(delete-region (line-beginning-position) (point))
(insert "Fcc: " subdir)

(defun update-fcc-header-when-from-address-completion (addr)
  "To hook on notmuch-address-post-completion-functions"
  (let ((cline (thing-at-point 'line)))
(when (or (string-prefix-p "From:" cline)
  (string-prefix-p "Resent-From:" cline))
  (update-fcc-header addr

(setq notmuch-address-post-completion-functions
  '(update-fcc-header-when-from-address-completion))

It's here for anyone interested on the same functionality in the
future.

Do you think this is an interesting feature to be part of notmuch?  If
so, I could improve it and add some checks to cover for the different
notmuch-fcc-dirs types of values.

Best wishes
David
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: v2 Image toggle fixes for emacs 29.1

2023-10-01 Thread David Bremner
Michael J Gruber  writes:

> Am So., 1. Okt. 2023 um 13:13 Uhr schrieb David Bremner :
>>
>> I have applied this series to release and master (and uploaded a
>> pre-release for 0.38.1)
>
> Is "pre" the new "rc", or how is this supposed to sort?
>
> Michael

sorry about that. yeah, luckily rc1 sorts after pre0, so I guess I can
switch if/when there is a second release candidate.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: v2 Image toggle fixes for emacs 29.1

2023-10-01 Thread David Bremner
David Bremner  writes:

> This obsoletes the series
>
>  id:20230916235137.334886-2-da...@tethera.net
>
> The update consists of the following bugfix:
>

I have applied this series to release and master (and uploaded a
pre-release for 0.38.1)

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Change duplicate priority?

2023-09-30 Thread David Bremner
Jesse Rosenthal  writes:

>
> Depending on how long the scan takes, getmail might pull down both of
> these emails. The second duplicate is available through the emacs change
> index command, but the attachment is not available (since it tries to
> pull the first attachment from the first version, which is just an html
> part).

Hmm. That seems like a bug, the attachement should be drawn from the
"current" version. I will see if I can replicate this with a simple test
case.

> I can usually solve this by deleting the first one by hand, something
> like:
>
> notmuch search --output=files id: | head -1 | xargs rm
>
> This has a couple of problems, though. (1) It's relying on the Maildir file
> name being a time stamp to get rid of the earlier file, and (2) it
> doesn't actually reindex the file when I run notmuch new, just treating
> it as a rename, so I still get the search results for the older deleted
> file.

What if you use notmuch-reindex instead of notmuch-new after the deletion?

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] perf-test/tag: add maildir sync tests

2023-09-30 Thread David Bremner
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.
---
 performance-test/T02-tag.sh | 9 +
 1 file changed, 9 insertions(+)

diff --git a/performance-test/T02-tag.sh b/performance-test/T02-tag.sh
index 9c895d6a..47fdb0c2 100755
--- a/performance-test/T02-tag.sh
+++ b/performance-test/T02-tag.sh
@@ -11,4 +11,13 @@ time_run 'tag * +existing_tag' "notmuch tag +new_tag '*'"
 time_run 'tag * -existing_tag' "notmuch tag -new_tag '*'"
 time_run 'tag * -missing_tag' "notmuch tag -new_tag '*'"
 
+time_run 'tag * +maildir_flag F' "notmuch tag +flagged '*'"
+time_run 'tag * -maildir_flag F' "notmuch tag -flagged '*'"
+time_run 'tag * +maildir_flag P' "notmuch tag +passed '*'"
+time_run 'tag * -maildir_flag P' "notmuch tag -passed '*'"
+time_run 'tag * +maildir_flag D' "notmuch tag +draft '*'"
+time_run 'tag * -maildir_flag D' "notmuch tag -draft '*'"
+time_run 'tag * +maildir_flag S' "notmuch tag -unread '*'"
+time_run 'tag * -maildir_flag S' "notmuch tag +unread '*'"
+
 time_done
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Fixed Message-ID trouble

2023-09-27 Thread David Bremner
Teemu Likonen  writes:

> Some person on debian-user mailing list seems to be sending messages
> with fixed Message-ID field: the same ID in different messages. In
> Notmuch it is creating trouble because it connects unrelated threads to
> one. The person has different messages in different threads but Notmuch
> thinks they are the same message because the Message-ID is the same.
>
> This is potentially a "denial of service" for Notmuch. Well, not quite,
> but is harmful nonetheless. How would a Notmuch user fix the mess or
> protect himself against it?

By the way, if using the emacs front-end did you try the unthreaded view
(U)? That would at least mitigate damage from people replying to the
poisoned messages.

I could imagine a future version of notmuch considering the
identification of files with the same message id as part of "threading",
and allowing an unthreaded view to just show all the files, effectively
ignoring the message-id. The next step would be to do that selectively
for some messages.  This all requires a complete redesign of the
database schema, so I don't know how realistic it is.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Fixed Message-ID trouble

2023-09-26 Thread David Bremner
Teemu Likonen  writes:

> Will Notmuch also break the thread so that this edited message will
> start a new thread? Maybe the message itself but its follow-ups need to
> be fixed too. Often "References" points several earlier messages in the
> chain. So, to detach a subthread from bigger thread would need manual
> editing for more than one message:

Yeah, once people start replying to the broken messages, it becomes more
complicated, as you point out.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Fixed Message-ID trouble

2023-09-26 Thread David Bremner
Alexander Adolf  writes:

>
> Bearing in mind that re-recognising a message which has arrived
> multiple times via different routes is a worthwhile feature, it would
> seem to me that a hash over the invariant part of the message, that is
> the body, would allow for such detection. In that light, it would seem
> to me that the tuple (body_hash, message_id) could be a candidate for
> a “unique enough”(tm) identifier?

I always had the impression that the message body had too variation
imposed by different delivery routes for this to be very helpful:
essentially the hash would be different for every file due to trailers
added by mailing lists, re-encoding, stupid "external message" headers
added by malicious^Wcorporate mail servers, etc...

I could be wrong, maybe hashing is a useful approach, but I'd need to
see some numbers to be convinced.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Fixed Message-ID trouble

2023-09-26 Thread David Bremner
Teemu Likonen  writes:

> * 2023-09-25 07:33:23-0400, Daniel Corbe wrote:
>
>> Silly question, I know, but have you actually tried reaching out to
>> the user?
>
> Not silly, but I don't even know who the person is. All I see is the
> mess, and everything else is my interpretation of the cause. Notmuch
> Emacs tree mode shows messages' relations but they are not accurate if
> references are messed up. It's difficult to dig into Message-ID level of
> relations.
>
> Perhaps my wish is that there was an easy way to break threads: mark a
> message as origin of a new thread. Or perhaps I just use my custom
> ignore mechanism to mark messed threads automatically as read and move
> on.

How about if you delete the Message-ID, References, and In-Reply-To
headers from the bad messages and re-index? Notmuch will synthesize a
unique Message-Id if there is none present.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: The unread tag is being swallowed on PGP-signed messages

2023-09-24 Thread David Bremner
Daniel Corbe  writes:

> Hey All,
>
> I’m currently running notmuch 0.38 on Mac OS installed via brew:

I can duplicate this behaviour running 0.38 on Debian.

> When running notmuch new, the unread tag is being swallowed up by the signed 
> tag on messages that have been PGP-signed:
>
> ❯ notmuch search 'to:notmuch-...@corbe.net'
> thread:0001f166  8 mins. ago [1/1(2)] Daniel Corbe; Test da fourth! 
> (inbox signed)

>
> Any idea what might be causing this?

I suspect it's related to having multiple copies of the file, one
without the ,S maildir flag (because the message was already known when
notmuch found that file). There is some related discussion at [1] (and
particularly [2]) but alas not much progress since then.

[1]: 
https://nmbug.notmuchmail.org/nmweb/show/871rqp97o0@iris.silentflame.com
[2]: https://nmbug.notmuchmail.org/nmweb/show/87zgjy4xto.fsf%40tethera.net
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 4/4] emacs/show: special case toggling display of images

2023-09-24 Thread David Bremner
According to emacs upstream [1], we can't expect overlay invisibility
and images to get along. This commit uses the previously stashed
undisplayer functions to actually remove the images from the buffer.
When the image is toggled, it is essentially redisplayed from scratch,
using the previously stashed redisplay data.

[1]: https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00593.html
---
 emacs/notmuch-show.el | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 54cf00c6..4cc5aa57 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -644,8 +644,24 @@ message at DEPTH in the current thread."
(when show
  (button-put button :notmuch-lazy-part nil)
  (notmuch-show-lazy-part lazy-part button))
- ;; else there must be an overlay.
- (overlay-put overlay 'invisible (not show))
+ (let* ((part (plist-get properties :notmuch-part))
+(undisplayer (plist-get part :undisplayer))
+(mime-type (plist-get part :computed-type))
+(redisplay-data (button-get button
+:notmuch-redisplay-data))
+(imagep (string-match "^image/" mime-type)))
+   (cond
+((and imagep (not show) undisplayer)
+ ;; call undisplayer thunk created by gnus.
+ (funcall undisplayer)
+ ;; there is an extra newline left
+ (delete-region
+  (+ 1 (button-end button))
+  (+ 2 (button-end button
+((and imagep show redisplay-data)
+ (notmuch-show-lazy-part redisplay-data button))
+(t
+ (overlay-put overlay 'invisible (not show)
  t)))
 
 ;;; Part content ID handling
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 3/4] emacs: save image redisplay data during non-lazy display

2023-09-24 Thread David Bremner
This data will eventually be used to redisplay hidden images. A
certain amount of refactoring is done here to avoid code
duplication.
---
 emacs/notmuch-show.el | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 107ce1b8..54cf00c6 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1109,14 +1109,18 @@ is t, hide the part initially and show the button."
 (and deep button)
 (and high button)
 (and long button
-(content-beg (point)))
+(content-beg (point))
+(part-data (list msg part mime-type nth depth button)))
 ;; Store the computed mime-type for later use (e.g. by attachment 
handlers).
 (plist-put part :computed-type mime-type)
-(if show-part
-   (notmuch-show-insert-bodypart-internal msg part mime-type nth depth 
button)
+(cond
+ (show-part
+  (apply #'notmuch-show-insert-bodypart-internal part-data)
+  (when (and button (string-match "^image/" mime-type))
+   (button-put button :notmuch-redisplay-data part-data)))
+ (t
   (when button
-   (button-put button :notmuch-lazy-part
-   (list msg part mime-type nth depth button
+   (button-put button :notmuch-lazy-part part-data
 ;; Some of the body part handlers leave point somewhere up in the
 ;; part, so we make sure that we're down at the end.
 (goto-char (point-max))
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 1/4] emacs: save undisplayer function for MIME parts

2023-09-24 Thread David Bremner
For some kinds of MIME parts (at least images), our trickery with
overlays will not work, so save the more drastic function created by
Gnus that actually deletes the part from the buffer. In an ideal world
we would return this function as (part of) a value, but here the call
stack is too complicated for anything that simple, so we stash it in
the part plist and rely on that being preserved (unlike the mm handle,
which is transient).
---
 emacs/notmuch-lib.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 84ba8c5e..a09f4ab8 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -703,6 +703,7 @@ current buffer, if possible."
  (when (mm-inlinable-p handle)
(set-buffer display-buffer)
(mm-display-part handle)
+   (plist-put part :undisplayer (mm-handle-undisplayer handle))
t))
 
 ;;; Generic Utilities
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


v2 Image toggle fixes for emacs 29.1

2023-09-24 Thread David Bremner
This obsoletes the series

 id:20230916235137.334886-2-da...@tethera.net

The update consists of the following bugfix:

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7a4b489d..4cc5aa57 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1036,7 +1036,7 @@ will return nil if the CID is unknown or cannot be 
retrieved."
   ;; We have to save the depth as we can't find the depth
   ;; when narrowed.
   (depth (notmuch-show-get-depth))
-  (mime-type (plist-get part-args :computed-type)))
+  (mime-type (plist-get (cadr part-args) :computed-type)))
   (save-restriction
(narrow-to-region part-beg part-end)
(delete-region part-beg part-end)



___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 2/4] emacs/show: save redisplay redisplay data when showing lazy part.

2023-09-24 Thread David Bremner
This data will be used to redisplay an image that is hidden by
deleting it from the buffer.  We cannot easily delay until the image
is hidden, as we won't have the original data at that point.
---
 emacs/notmuch-show.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 36cce619..107ce1b8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1019,10 +1019,13 @@ will return nil if the CID is unknown or cannot be 
retrieved."
   (part-end (copy-marker (point) t))
   ;; We have to save the depth as we can't find the depth
   ;; when narrowed.
-  (depth (notmuch-show-get-depth)))
+  (depth (notmuch-show-get-depth))
+  (mime-type (plist-get (cadr part-args) :computed-type)))
   (save-restriction
(narrow-to-region part-beg part-end)
(delete-region part-beg part-end)
+   (when (and mime-type (string-match "^image/" mime-type))
+ (button-put button :notmuch-redisplay-data part-args))
(apply #'notmuch-show-insert-bodypart-internal part-args)
(indent-rigidly part-beg
part-end
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] NEWS: add NEWS item for config error reporting.

2023-09-23 Thread David Bremner
As well as the immediate change, give a bit of the backround on
upcoming breaking changes from GLib.
---
 NEWS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/NEWS b/NEWS
index 34bdfca2..407aded9 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,15 @@
 Notmuch 0.38.1 (UNRELEASED)
 ===
 
+General
+---
+
+Report config parsing errors from GLib. Previously notmuch silently
+exited with success (0) on parsing errors. Upcoming releases of GLib
+will be more strict about parsing escape codes, causing previously
+parsed config files to report errors. Provide diagnostics to help
+users correct their config files.
+
 Notmuch 0.38 (2023-09-12)
 =
 
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Report GLib errors

2023-09-23 Thread David Bremner
David Bremner  writes:

> This series obsoletes the WIP series [0].  I think it's probably worth
> doing a point release with this fix as it is not too intrusive, and
> upcoming GLib releases will likely cause more users to experience the
> problems Eric found [1].
>
> [0]: id:20230913005636.135665-1-da...@tethera.net
> [1]: id:5a7paaqa2dvdo5lmnxvaeacfwhdytfnkr4gfh6mtlotdviki2s@ro4gz4m2aqsw

Series applied (with a couple of whitespace and commit message fixups)
to release and master. 
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: automatically changing FCC when From changes (or fill FCC only when sending)

2023-09-22 Thread David Bremner
David Bremner  writes:

>
> Another option that seems technically feasible, but would involve some
> elisp programming, would be to write a command that re-applies the
> calculation of Fcc from From that already exists, and run that manually
> or perhaps opt-in to running it automatically on send.

I guess if you have message-templ installed, there is really not any
programming. My hook usage looks like

(setq notmuch-address-post-completion-functions
  '((lambda (lst) (message-templ-config-exec

You could certainly bind #'message-templ-config-exec to a key and
(although then you have to trust it does the right thing) run it when
sending e.g. from message-send-hook.

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: automatically changing FCC when From changes (or fill FCC only when sending)

2023-09-22 Thread David Bremner
David Pinto  writes:

>
> I see what you mean, how changing the FCC would prevent the ability to
> manually edit the FCC.  But what about updating the FCC when the
> "From" changes?

I don't know how to efficiently detect changes to
From. (notmuch-)message-mode is essentially a text editor buffer,
including the header area, so I think one would have to reparse the
buffer after every keystroke. I think that would be annoyingly slow, but
I haven't tried it. The hook is called "post-command-hook" if you are
feeling adventurous, but see the warnings in the docstring.

> You mention updating the "From" when the "To" changes with the
> notmuch-address-post-completion-functions hook.  Could there be a hook
> for when the "From" changes which I could use to change the FCC?

My partial-solution relies on using completion to change To. If you are
OK with that (i.e. manual editing without completion would not update
Fcc), then the same scheme could work.

Another option that seems technically feasible, but would involve some
elisp programming, would be to write a command that re-applies the
calculation of Fcc from From that already exists, and run that manually
or perhaps opt-in to running it automatically on send.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: automatically changing FCC when From changes (or fill FCC only when sending)

2023-09-21 Thread David Pinto
On Sat, 16 Sept 2023 at 16:17, David Bremner  wrote:
>
> David Pinto  writes:
>
> [...]
> > Is there a way to either have the FCC header changed when the "From"
> > address changes?  Or maybe only add the FCC header when sending
> > the message?
>
> Generally I think people like the ability to hand-edit the header, so I
> don't think adding it at send time would work for everyone. I do
> something related based on address completion: I update the From header
> based on To.

Thank you for your reply.

I see what you mean, how changing the FCC would prevent the ability to
manually edit the FCC.  But what about updating the FCC when the
"From" changes?

When starting a new message, and assuming that there is more that one
possible "From", the default "From" will often be wrong.  I would also
expect one to set the "From" before any manual changes to "FCC".  If
so, then I think it could make sense to update the "FCC" when the
"From" changes since there would be no manual adjustment to FCC lost.

You mention updating the "From" when the "To" changes with the
notmuch-address-post-completion-functions hook.  Could there be a hook
for when the "From" changes which I could use to change the FCC?

> I use message-templ [1], along with
> notmuch-address-post-completion-functions. My solution is a bit niche
> because message-templ is a bit obscure, but I'm happy to go into details
> if you are interested.

This message-templ seems ideal for another issue of mine.  I will look
more into it.

Thank you
David
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] CLI: update commentary in config file to better match code

2023-09-21 Thread David Bremner
This comment has been out of date since notmuch 0.32. Although it
isn't really possible to explain all the options here, explain both
one new "split" way of doing things and the traditional one with
database inside $MAIL_ROOT/.notmuch.
---
 notmuch-config.c| 12 +++-
 test/setup.expected-output/config-with-comments | 12 +++-
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/notmuch-config.c b/notmuch-config.c
index 8123e438..f7e59f1e 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -40,11 +40,13 @@ static const struct config_group {
"database",
" Database configuration\n"
"\n"
-   " The only value supported here is 'path' which should be the 
top-level\n"
-   " directory where your mail currently exists and to where mail will 
be\n"
-   " delivered in the future. Files should be individual email messages.\n"
-   " Notmuch will store its database within a sub-directory of the path\n"
-   " configured here named \".notmuch\".\n"
+   " Supported values are 'mail_root' and 'path'. The recommended option\n"
+   " is to set 'mail_root' to the directory where your mail currently 
exists\n"
+   " and to where mail will be delivered in the future. Files should be\n"
+   " individual email messages. By default notmuch will store its 
database\n"
+   " in $XDG_DATA_HOME/notmuch; you can override this by setting 'path'.\n"
+   " If only 'path' is set, this directory is for 'mail_root' and for\n"
+   " the database location (in a subdirectory called \".notmuch\").\n"
 },
 {
"user",
diff --git a/test/setup.expected-output/config-with-comments 
b/test/setup.expected-output/config-with-comments
index d925acea..5d96be7f 100644
--- a/test/setup.expected-output/config-with-comments
+++ b/test/setup.expected-output/config-with-comments
@@ -3,11 +3,13 @@
 # For more information about notmuch, see https://notmuchmail.org
 # Database configuration
 #
-# The only value supported here is 'path' which should be the top-level
-# directory where your mail currently exists and to where mail will be
-# delivered in the future. Files should be individual email messages.
-# Notmuch will store its database within a sub-directory of the path
-# configured here named ".notmuch".
+# Supported values are 'mail_root' and 'path'. The recommended option
+# is to set 'mail_root' to the directory where your mail currently exists
+# and to where mail will be delivered in the future. Files should be
+# individual email messages. By default notmuch will store its database
+# in $XDG_DATA_HOME/notmuch; you can override this by setting 'path'.
+# If only 'path' is set, this directory is for 'mail_root' and for
+# the database location (in a subdirectory called ".notmuch").
 #
 [database]
 path=/path/to/maildir
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v2 1/2] test: showcase thread-unsafe s-expression query parser

2023-09-19 Thread David Bremner
Kevin Boulain  writes:

> The test fails reliably when Notmuch is compiled as such:
>   ./configure
>   make CFLAGS=-fsanitize=thread LDFLAGS=-fsanitize=thread
> It's still unclear how the test suite could be run with the correct
> compilation flags.

At the moment I can think of 3 options:

1) have the test file check if the library is built with tsan, and to skip
if not. Something like "nm lib/libnotmuch.a| grep -q __tsan_init" seems
to do the trick here, although I don't know how portable it is.

2) Provide a "--with-tsan" option to set CFLAGS/LDFLAGS and also
   some variable that the tests can check

3) Do (2) by default if TSAN is detected, and provide --without-tsan to
disable it. This is only possible if the ruby bindings build is fixed to
ignore/work-with TSAN; currently it pretty much explodes.

All three options would need some thought as to how to support (if at
all) testing installed notmuch (new in 0.38, used by some CI systems).
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] .gitignore: ignore __pycache__

2023-09-19 Thread David Bremner
Eric Blake  writes:

> Python likes to leave behind cache files; noticeable when doing an
> in-tree build.

Applied to master. BTW, "make distclean" should now clean up those cache
directories; I think it did not when you sent in the patch.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] NEWS: NEWS for 0.38

2023-09-19 Thread David Bremner
David Bremner  writes:

> ---
> I did my best to reconstruct the changes since 0.37. Let me know any 
> suggested corrections or updates in the next few days.
>

this (or something very close) has now been released as part of 0.38
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] devel/nmweb: read mail files in binary mode.

2023-09-18 Thread David Bremner
Tomi Ollila  writes:

>
> Looks good to me. I've been experiencing "text" mode defaulting to 'ascii'
> (and had to include encoding='utf-8') lately. Another problem one may
> encounter when there are \r chars in the file, text mode may remove those
> (In the same case I had a file using '\r\r' as list content separator,
> and failed until changing open to binary mode)
>
> Tomi
>

thanks for the review. Applied to master and deployed that (again) to
nmbug.notmuchmail.org. Probably I should think of a deployment method
that does not involve git merge :(.


d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 1/4] emacs: save undisplayer function for MIME parts

2023-09-16 Thread David Bremner
For some kinds of MIME parts (at least images), our trickery with
overlays will not work, so save the more drastic function created by
Gnus that actually deletes the part from the buffer. In an ideal world
we would return this function as (part of) a value, but here the call
stack is too complicated for anything that simple, so we stash it in
the part plist and rely on that being preserved (unlike the mm handle,
which is transient).
---
 emacs/notmuch-lib.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 84ba8c5e..a09f4ab8 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -703,6 +703,7 @@ current buffer, if possible."
  (when (mm-inlinable-p handle)
(set-buffer display-buffer)
(mm-display-part handle)
+   (plist-put part :undisplayer (mm-handle-undisplayer handle))
t))
 
 ;;; Generic Utilities
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 4/4] emacs/show: special case toggling display of images

2023-09-16 Thread David Bremner
According to emacs upstream [1], we can't expect overlay invisibility
and images to get along. This commit uses the previously stashed
undisplayer functions to actually remove the images from the buffer.
When the image is toggled, it is essentially redisplayed from scratch,
using the previously stashed redisplay data.

[1]: https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00593.html
---
 emacs/notmuch-show.el | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9f281a4b..7a4b489d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -644,8 +644,24 @@ message at DEPTH in the current thread."
(when show
  (button-put button :notmuch-lazy-part nil)
  (notmuch-show-lazy-part lazy-part button))
- ;; else there must be an overlay.
- (overlay-put overlay 'invisible (not show))
+ (let* ((part (plist-get properties :notmuch-part))
+(undisplayer (plist-get part :undisplayer))
+(mime-type (plist-get part :computed-type))
+(redisplay-data (button-get button
+:notmuch-redisplay-data))
+(imagep (string-match "^image/" mime-type)))
+   (cond
+((and imagep (not show) undisplayer)
+ ;; call undisplayer thunk created by gnus.
+ (funcall undisplayer)
+ ;; there is an extra newline left
+ (delete-region
+  (+ 1 (button-end button))
+  (+ 2 (button-end button
+((and imagep show redisplay-data)
+ (notmuch-show-lazy-part redisplay-data button))
+(t
+ (overlay-put overlay 'invisible (not show)
  t)))
 
 ;;; Part content ID handling
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 3/4] emacs: save image redisplay data during non-lazy display

2023-09-16 Thread David Bremner
This data will eventually be used to redisplay hidden images. A
certain amount of refactoring is done here to avoid code
duplication.
---
 emacs/notmuch-show.el | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 8e1bc9b8..9f281a4b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1109,14 +1109,18 @@ is t, hide the part initially and show the button."
 (and deep button)
 (and high button)
 (and long button
-(content-beg (point)))
+(content-beg (point))
+(part-data (list msg part mime-type nth depth button)))
 ;; Store the computed mime-type for later use (e.g. by attachment 
handlers).
 (plist-put part :computed-type mime-type)
-(if show-part
-   (notmuch-show-insert-bodypart-internal msg part mime-type nth depth 
button)
+(cond
+ (show-part
+  (apply #'notmuch-show-insert-bodypart-internal part-data)
+  (when (and button (string-match "^image/" mime-type))
+   (button-put button :notmuch-redisplay-data part-data)))
+ (t
   (when button
-   (button-put button :notmuch-lazy-part
-   (list msg part mime-type nth depth button
+   (button-put button :notmuch-lazy-part part-data
 ;; Some of the body part handlers leave point somewhere up in the
 ;; part, so we make sure that we're down at the end.
 (goto-char (point-max))
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 2/4] emacs/show: save redisplay redisplay data when showing lazy part.

2023-09-16 Thread David Bremner
This data will be used to redisplay an image that is hidden by
deleting it from the buffer.  We cannot easily delay until the image
is hidden, as we won't have the original data at that point.
---
 emacs/notmuch-show.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 36cce619..8e1bc9b8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1019,10 +1019,13 @@ will return nil if the CID is unknown or cannot be 
retrieved."
   (part-end (copy-marker (point) t))
   ;; We have to save the depth as we can't find the depth
   ;; when narrowed.
-  (depth (notmuch-show-get-depth)))
+  (depth (notmuch-show-get-depth))
+  (mime-type (plist-get part-args :computed-type)))
   (save-restriction
(narrow-to-region part-beg part-end)
(delete-region part-beg part-end)
+   (when (and mime-type (string-match "^image/" mime-type))
+ (button-put button :notmuch-redisplay-data part-args))
(apply #'notmuch-show-insert-bodypart-internal part-args)
(indent-rigidly part-beg
part-end
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Fix image toggling for emacs 29.1

2023-09-16 Thread David Bremner
This obsoletes the WIP patch at

 id:20230903114215.60583-1-da...@tethera.net

The main changes are breaking the patch up into more managable pieces,
and only saving redisplay data for images.

I am more or less satisfied with the performance impact of this
change. I ran the following test before and after and didn't see a
noticable impact in memory use (in fact it seemed to go down in some
cases, which is a mystery to me).

(profiler-start 'mem)
(notmuch-show "mimetype:image and date:2023")
(profiler-stop)
(profiler-report)

More scientific testing or personal experience welcome. And of course
I'd like to know if this breaks, the code I'm modifying is fairly
complex and has accreted over a decade or so.


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: automatically changing FCC when From changes (or fill FCC only when sending)

2023-09-16 Thread David Bremner
David Pinto  writes:

>
> My case is that I have multiple email accounts and want the sent
> messages saved on different directories based on the "From" address.
> I've setup 'notmuch-fcc-dirs' accordingly.  Now, when I start
> composing a message (notmuch-user-agent), the FCC header is set to
> whatever is the default "From" address.  But if I change the "From"
> address, the FCC header is not updated.

That is the expected behaviour, yeah.

> Is there a way to either have the FCC header changed when the "From"
> address changes?  Or maybe only add the FCC header when sending
> the message?

Generally I think people like the ability to hand-edit the header, so I
don't think adding it at send time would work for everyone. I do
something related based on address completion: I update the From header
based on To.

I use message-templ [1], along with
notmuch-address-post-completion-functions. My solution is a bit niche
because message-templ is a bit obscure, but I'm happy to go into details
if you are interested.


[1]: https://git.tethera.net/message-templ.git/
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] devel/nmweb: read mail files in binary mode.

2023-09-16 Thread David Bremner
"ju" reported on IRC that browsing


https://nmbug.notmuchmail.org/nmweb/show/20160719094205.qmf5sjnja6crt5t3%40gotlib

crashed. The underlying issue is that python3 defaults to utf8
decoding files unless they are opened in binary mode. The file in
question (in the nmbug archive; it depends a bit on the routing the
message took) has

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

and some of it is not valid utf8.
---

I have already deployed this as a hotfix, but not applied it to master or 
release. 


 devel/notmuch-web/nmweb.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/devel/notmuch-web/nmweb.py b/devel/notmuch-web/nmweb.py
index b0d4d5cd..e0e87b49 100755
--- a/devel/notmuch-web/nmweb.py
+++ b/devel/notmuch-web/nmweb.py
@@ -207,7 +207,7 @@ env.globals['thread_nav'] = thread_nav
 
 def format_message(nm_msg, mid):
   fn = list(nm_msg.filenames())[0]
-  msg = MaildirMessage(open(fn))
+  msg = MaildirMessage(open(fn, 'rb'))
   return format_message_walk(msg, mid)
 
 def decodeAnyway(txt, charset='ascii'):
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


automatically changing FCC when From changes (or fill FCC only when sending)

2023-09-16 Thread David Pinto
Hi everyone

I've recently started using notmuch and I've found it works amazing.
It's so fast!  Thank you.

However, I've been struggling a lot with saving sent messages in the
right place (Emacs notmuch-user-agent).  I think I finally got to the
bottom of it and maybe I just had the wrong expectations.  I was
hoping someone could confirm and suggest a workaround.

My case is that I have multiple email accounts and want the sent
messages saved on different directories based on the "From" address.
I've setup 'notmuch-fcc-dirs' accordingly.  Now, when I start
composing a message (notmuch-user-agent), the FCC header is set to
whatever is the default "From" address.  But if I change the "From"
address, the FCC header is not updated.

Is there a way to either have the FCC header changed when the "From"
address changes?  Or maybe only add the FCC header when sending
the message?

Many thanks
David
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: tagging threads

2023-09-15 Thread David Bremner
Jon Fineman  writes:

> I have followed this guide to tag a message/thread for deletion that a
> shell script will then delete.
> 

Just for the record, "k d" will add the "deleted" tag by default in
search, tree and show mode

>
> However an unwanted byproduct of tagging the thread is if I have
> tagged (moved) an individual message to another folder, the thread
> tagging will go through all messages and tag those too for deletion.

I don't understand this part. What is the relationship between a thread
and a folder for you?

> Any thoughts on how I might prevent an individual message from being
> tagged by a tag thread action?

You can make some other query that doesn't match the whole thread, then
use * to tag all the messages match that query (perhaps using unthreaded
view).

I don't know a nice UI to do that with a few keystrokes.  I suppose I'd
probably give the message in question a tag:tmp and the search for
tag:tmp and tag:deleted in order to "undelete" it. All of that with the
disclaimer that I don't really understand the problem description.

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 4/4] Pass error message from GLib ini parser to CLI

2023-09-15 Thread David Bremner
The function _notmuch_config_load_from_file is only called in two
places in open.cc. Update internal API to match the idiom in open.cc.
Adding a newline is needed for consistency with other status strings.

Based in part on a patch [1] from Eric Blake.

[1]: id:20230906153402.101471-1-ebl...@redhat.com
---
 lib/config.cc | 13 +++--
 lib/notmuch-private.h |  2 +-
 lib/open.cc   |  4 ++--
 notmuch.c |  6 ++
 test/T030-config.sh   |  1 -
 5 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/lib/config.cc b/lib/config.cc
index 2323860d..6cd15fab 100644
--- a/lib/config.cc
+++ b/lib/config.cc
@@ -416,7 +416,8 @@ _expand_path (void *ctx, const char *key, const char *val)
 
 notmuch_status_t
 _notmuch_config_load_from_file (notmuch_database_t *notmuch,
-   GKeyFile *file)
+   GKeyFile *file,
+   char **status_string)
 {
 notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
 gchar **groups = NULL, **keys, *val;
@@ -435,6 +436,7 @@ _notmuch_config_load_from_file (notmuch_database_t *notmuch,
for (gchar **keys_p = keys; *keys_p; keys_p++) {
char *absolute_key = talloc_asprintf (notmuch, "%s.%s", *grp,  
*keys_p);
char *normalized_val;
+   GError *gerr = NULL;
 
/* If we opened from a given path, do not overwrite it */
if (strcmp (absolute_key, "database.path") == 0 &&
@@ -442,7 +444,14 @@ _notmuch_config_load_from_file (notmuch_database_t 
*notmuch,
notmuch->xapian_db)
continue;
 
-   val = g_key_file_get_string (file, *grp, *keys_p, NULL);
+   val = g_key_file_get_string (file, *grp, *keys_p, );
+   if (gerr) {
+   if (status_string)
+   IGNORE_RESULT (asprintf (status_string,
+"GLib: %s\n",
+gerr->message));
+   g_error_free (gerr);
+   }
if (! val) {
status = NOTMUCH_STATUS_FILE_ERROR;
goto DONE;
diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index c19ee8e2..367e23e6 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -726,7 +726,7 @@ notmuch_status_t
 _notmuch_config_load_from_database (notmuch_database_t *db);
 
 notmuch_status_t
-_notmuch_config_load_from_file (notmuch_database_t *db, GKeyFile *file);
+_notmuch_config_load_from_file (notmuch_database_t *db, GKeyFile *file, char 
**status_string);
 
 notmuch_status_t
 _notmuch_config_load_defaults (notmuch_database_t *db);
diff --git a/lib/open.cc b/lib/open.cc
index 54d1faf3..005872dc 100644
--- a/lib/open.cc
+++ b/lib/open.cc
@@ -555,7 +555,7 @@ _finish_open (notmuch_database_t *notmuch,
goto DONE;
 
if (key_file)
-   status = _notmuch_config_load_from_file (notmuch, key_file);
+   status = _notmuch_config_load_from_file (notmuch, key_file, 
);
if (status)
goto DONE;
 
@@ -961,7 +961,7 @@ notmuch_database_load_config (const char *database_path,
 }
 
 if (key_file) {
-   status = _notmuch_config_load_from_file (notmuch, key_file);
+   status = _notmuch_config_load_from_file (notmuch, key_file, );
if (status)
goto DONE;
 }
diff --git a/notmuch.c b/notmuch.c
index 69a18131..814b9e42 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -563,6 +563,12 @@ main (int argc, char *argv[])
   NULL,
   ,
   _string);
+   if (status_string) {
+   fputs (status_string, stderr);
+   free (status_string);
+   status_string = NULL;
+   }
+
switch (status) {
case NOTMUCH_STATUS_NO_CONFIG:
if (! (command->mode & NOTMUCH_COMMAND_CONFIG_CREATE)) {
diff --git a/test/T030-config.sh b/test/T030-config.sh
index 11428e8a..8aee9dc9 100755
--- a/test/T030-config.sh
+++ b/test/T030-config.sh
@@ -201,7 +201,6 @@ printf '[query]\nq3=from:\xff\n' >>bad-config
 test_expect_code 1 "notmuch --config=./bad-config config list"
 
 test_begin_subtest "Specific error message about bad utf8"
-test_subtest_known_broken
 notmuch --config=./bad-config config list 2>ERRORS
 cat < EXPECTED
 GLib: Key file contains key “q3” with value “from:�” which is not UTF-8
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 3/4] test: add known broken subtest for the bad config error message

2023-09-15 Thread David Bremner
This is a bit fragile w.r.t. glib changing their error message, but it
already helped me find one formatting bug, so for now I think it's
worth it, instead of just grepping for "UTF-8".
---
 test/T030-config.sh | 9 +
 1 file changed, 9 insertions(+)

diff --git a/test/T030-config.sh b/test/T030-config.sh
index 8b3ef436..11428e8a 100755
--- a/test/T030-config.sh
+++ b/test/T030-config.sh
@@ -200,5 +200,14 @@ cp initial-config bad-config
 printf '[query]\nq3=from:\xff\n' >>bad-config
 test_expect_code 1 "notmuch --config=./bad-config config list"
 
+test_begin_subtest "Specific error message about bad utf8"
+test_subtest_known_broken
+notmuch --config=./bad-config config list 2>ERRORS
+cat < EXPECTED
+GLib: Key file contains key “q3” with value “from:�” which is not UTF-8
+Error: unable to load config file.
+EOF
+test_expect_equal_file EXPECTED ERRORS
+
 test_done
 
-- 
2.40.1

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


  1   2   3   4   5   6   7   8   9   10   >