Re: Lazily loading notmuch into Emacs

2020-06-02 Thread Sean Whitton
Hello David,

On Tue 02 Jun 2020 at 12:41PM +01, David Edmondson wrote:

> I'd hoped that:
> (require 'notmuch-mua)
> (setq mail-user-agent 'notmuch-user-agent)
> would be sufficient to get things wired up, but it doesn't seem to be.
> If we fix that, would it seem more appropriate? If we get it right then
> it shouldn't load any other notmuch code (including notmuch-config.el)
> until you actually use one of the functions.

It's probably better than using advice-add, assuming that bytecompiled
notmuch-mua.el loads quickly.

I wonder if maybe notmuch-mua.el could be split into a small file the
user can 'require in their init, which just has the
define-mail-user-agent call, and then there's a larger .el file
containing an autoload cookie and definition for 'notmuch-mua-mail, and
everything else?

I'm also advising notmuch-jump-search and notmuch-hello, as otherwise I
noticed notmuch-config.el doesn't get loaded if you use one of those
right after starting Emacs.  I think the fix there is to add (require
'notmuch) to the top of notmuch-jump.el and notmuch-hello.el?

Sean Whitton
notmuch mailing list

Re: [PATCH] add NEWS for 0.30

2020-06-02 Thread Tomi Ollila

post-push comments =D

On Mon, Jun 01 2020, Daniel Kahn Gillmor wrote:

> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  NEWS | 35 +++
>  1 file changed, 35 insertions(+)
> diff --git a/NEWS b/NEWS
> index 14db7f6f..1921127f 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,6 +1,41 @@
>  Notmuch 0.30 (2020-06-01)
>  =
> +--
> +
> +Handle S/MIME (PKCS#7) messages -- one-part signed messages, encrypted
> +messages, and multilayer messages.  Treat them symmetrically to
> +OpenPGP messages.  This includes handling protected headers
> +gracefully.

2 spaces after period (.) ending sentence. I've been told that thiis is
(official) style somewhere (which I personally dislike, but...) -- anyway
that style is inconsistent with NEWS entries done previously 
(possibly not all of the NEWS entries I quickly looked but).

> +
> +If you're using Notmuch with S/MIME, you currently need to configure
> +gpgsm appropriately.
> +
> +Mixed-up MIME Repair
> +
> +
> +Detect and automatically repair a common form of message mangling
> +created by Microsoft Exchange. (see index.repaired=mixedup in
> +notmuch-properties(7).

No closing paren for (see...

What about period (.) after Exchange. 

> +
> +Protected Headers
> +-
> +
> +Avoid indexing the legacy-display part of an encrypted message that
> +has protected headers. (see
> +index.repaired=skip-protected-headers-legacy-display in
> +notmuch-properties(7).

ditto ((see ...)

ditto (period (.) after headers.)

> +
> +Python
> +--
> +
> +Drop compatibility with python2, focus on python3.

Was 'compatibility' completely dropped. Doesn't old bindings still
work with python2 ?

> +Introduce new CFFI-based python bindings in the python module named
> +"notmuch2".  Officially deprecate (but still support) the older
> +"notmuch" module.
> +
>  Notmuch 0.29.3 (2019-11-27)
>  ===
> -- 
> 2.26.2
notmuch mailing list

broken bash completion

2020-06-02 Thread Uwe Kleine-K├Ânig

(already reported in #notmuch, bremner asked to forward to this list)

Using bash (Debian, 5.0-4) and notmuch (also Debian, 0.29.3-1+b2) I
noticed a breakage in notmuch's bash completion:

$ notmuch --config=/hobash: [: too many arguments
bash: declare: cannot use `-f' to make functions

(I pressed  after "notmuch --config=/ho".)

I didn't look into that but would expect this info is enough for someone
to fix this. If not, please tell me; either in #notmuch or by mail.
(Note, I'm not subscribed to the list.)

Best regards

Description: PGP signature
notmuch mailing list

[PATCH] doc: field processor support now always included, adjust manual pages

2020-06-02 Thread Tomi Ollila
The features that require field processor support, are now just
documented w/o mentioning **Xapian Field Processors**' is needed
for those.

Replaced "compact" and "field_processor" with "retry_lock" in
build_with config option, as it is currently the only one that
is optionally excluded. The former 2 are now documented as
features always included.

Dropped one 'we' "passive" in notmuch-search-terms.rst. It was the
only one, and inconsistent with rest of the documentation in that

Dropped message about conditional open-ended ranges support, as
those are now always supported.
 doc/man1/notmuch-config.rst   |  5 +--
 doc/man7/notmuch-search-terms.rst | 54 +--
 2 files changed, 18 insertions(+), 41 deletions(-)

diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
index 323a8b65..769f336a 100644
--- a/doc/man1/notmuch-config.rst
+++ b/doc/man1/notmuch-config.rst
@@ -198,8 +198,9 @@ The available configuration items are described below.
 Compile time feature . Current possibilities include
-"compact" (see **notmuch-compact(1)**) and "field_processor" (see
+"retry_lock" (configure option, included by default).
+(since notmuch 0.30, "compact" and "field_processor" are
+always included.)
 **query.** **[STORED IN DATABASE]**
 Expansion for named query called . See
diff --git a/doc/man7/notmuch-search-terms.rst 
index 1dd2dc58..28fca737 100644
--- a/doc/man7/notmuch-search-terms.rst
+++ b/doc/man7/notmuch-search-terms.rst
@@ -37,9 +37,8 @@ In addition to free text, the following prefixes can be used 
to force
 terms to match against specific portions of an email, (where 
 indicate user-supplied values).
-If notmuch is built with **Xapian Field Processors** (see below) some
-of the prefixes with  forms can be also used to restrict the
-results to those whose value matches a regular expression (see
+Some of the prefixes with  forms can be also used to restrict
+the results to those whose value matches a regular expression (see
 **regex(7)**) delimited with //, for example::
notmuch search 'from:"/bob@.*[.]example[.]com/"'
@@ -87,8 +86,7 @@ thread:
 of output from **notmuch search**
-If notmuch is built with **Xapian Field Processors** (see below),
-threads may be searched for indirectly by providing an arbitrary
+Threads may be searched for indirectly by providing an arbitrary
 notmuch query in **{}**. For example, the following returns
 threads containing a message from mallory and one (not necessarily
 the same message) with Subject containing the word "crypto".
@@ -158,9 +156,7 @@ lastmod:..
 The **query:** prefix allows queries to refer to previously saved
-queries added with **notmuch-config(1)**. Named queries are only
-available if notmuch is built with **Xapian Field Processors**
-(see below).
+queries added with **notmuch-config(1)**.
 The **property:** prefix searches for messages with a particular
@@ -353,23 +349,21 @@ since 1970-01-01 00:00:00 UTC. For example:
-date:..! can be used as a shorthand for date:... The
-expansion takes place before interpretation, and thus, for example,
-date:monday..! matches from the beginning of Monday until the end of
-With **Xapian Field Processor** support (see below), non-range
-date queries such as date:yesterday will work, but otherwise
-will give unexpected results; if in doubt use date:yesterday..!
-Currently, we do not support spaces in range expressions. You can
+Currently, spaces in range expressions are not supported. You can
 replace the spaces with '\_', or (in most cases) '-', or (in some cases)
 leave the spaces out altogether. Examples in this man page use spaces
 for clarity.
-Open-ended ranges are supported (since Xapian 1.2.1), i.e. it's possible
-to specify date:.. or date:.. to not limit the start or
-end time, respectively. Pre-1.2.1 Xapian does not report an error on
-open ended ranges, but it does not work as expected either.
+Open-ended ranges are supported. I.e. it's possible to specify
+date:.. or date:.. to not limit the start or
+end time, respectively.
+Single expression
+date: works as a shorthand for date:...
+For example, date:monday matches from the beginning of Monday until
+the end of Monday.
 Relative date and time
@@ -446,24 +440,6 @@ Time zones
 Some time zone codes, e.g. UTC, EET.
-Certain optional features of the notmuch query processor rely on the
-presence of the Xapian field processor API. You can determine if your
-notmuch was built against a sufficiently recent version of Xapian by running
-  % notmuch config get built_with.field_processor
-Currently the following features require field processor support:

Re: status of the new python bindings

2020-06-02 Thread Floris Bruynooghe
Hi Anton,

Great that you're looking at this API!  My apologies for the late
response, this slipped by me probably as I was bulk marking things as
read when I came back from a few weeks away.

On Thu 07 May 2020 at 15:57 +0200, Anton Khirnov wrote:
> 1) What is the logic behind choosing whether something is exported as
> a property or as a method? E.g. Database.needs_upgrade is a property,
> while Database.revision() is a method. In my own python code, I tend to
> use @property for things that are "cheap" - i.e. do not involve
> (significant) IO or heavy computation and methods for those that do. But
> both of the above attributes involve library calls, presumably(?) of
> similar complexity. Would be nice if this was consistent.

Choosing when something should be a property is sometimes indeed tricky
and in general I agree you're right to expect property calls to be not
too expensive.  But I wouldn't go so far to consider every call into
libnotmuch as expensive.  I think there is also an element of how static
something is.  Usually I expect properties to behave more like
attributes, that is after all the point of them, and thus I don't expect
them to change often without explicitly manipulating them.

So that could justifies why I choose Database.version as a property
while Database.revision() is a method.  The revision changes all the
time as a side-effect of other things.  I think it also justifies
generally why tags are exposed as properties.

Database.needs_upgrade is indeed a more questionable choice, especially
given its naming which is more of a question being asked and thus
probably more suitable as a method.  It does change rarely, but does so
by interaction with another method - Database.upgrade().  So I would
agree that this perhaps wasn't the best choice and maybe that was better
as a method.

> 2) Atomic transactions are now exported as a context manager, which is
> nice and convenient for the usual use cases, but AFAIU does not have the
> same power. E.g. my tagging script does the tagging as a single atomic
> transaction and has a "dry-run" mode in which it omits the end_atomic()
> call, which is documented to throw away all the changes. This seems to
> not be possible with the new bindings.
> Would it be okay to add bindings for explicitly calling
> start/end_atomic()? Or is my approach considered invalid?

This is indeed a good usecase that I overlooked, I stopped reading at
the part where is says being and end atomic must always be used in
pairs...  But yes, we should add support for this too.  What would you
think of a .abort() on the context manager instead of directly exposing
the start/end?  E.g.:

db = notmuch2.Database()
with db.atomic() as txn:
# do stuff

However if I read the docs correctly the transaction only actually is
aborted once the database is closed?  But when I try this:

with db.atomic():
# do stuff

I discover that after calling .close() it's very easy to segfault by
making other calls, e.g. the above currently segfaults.  I thought this
wasn't so bad but perhaps .close() should immediately destroy the
database too.  This would again disallow some funky behaviour that the
raw C API allows I guess where some objects might still be valid to use.
But this is really hard to get right I think and I'd prefer to vote on
the side of safety in the Python bindings.

Still, it could be reasonable to make AtomicContext.abort() also close
the database and then make sure it doesn't call
notmuch_database_end_atomic() on exit.  I tried this locally and it
seems reasonable.  What do you think?

Lastly you can do this today by calling the C API directly:

db = notmuch2.Database()

Yes, that uses a lot of internal stuff but it's also pretty advanced
usage.  I'm only suggesting you this to maybe unblock you in the short

> 3) There seem to be no bindings for notmuch_database_set_config().

There are still bits of the API missing indeed.  Would be great to add
them but would be even better to have someone who needs it to validate
the API.  There were recently some good patches posted to expose the
config stuff, would be good to see that merged indeed.

> 4) The setup for building the documentation seems to be missing.

Hmm, yes.  The docstrings are written to work with sphinx autodoc but a
doc directory with sphinx configured never got added.  Perhaps we should
do this so that people can at least build docs locally.

> Anything else of note that remains to be implemented?


Thanks for caring!

notmuch mailing list

Re: Lazily loading notmuch into Emacs

2020-06-02 Thread David Edmondson
On Monday, 2020-06-01 at 10:36:16 -07, Sean Whitton wrote:

> Hello,
> I don't want to put (require 'notmuch) into my Emacs init because that
> will slow down initial Emacs startup a fair bit, especially since my
> (file which is equivalent to) notmuch-config.el does quite a bit of
> processing to populate notmuch-saved-searches.
> So I have this:
> ;; Ensure notmuch does its `message-mode' configuration and that my
> ;; notmuch-config.el gets loaded before certain commands happen.  An
> ;; alternative to advising `compose-mail' and friends here would be
> ;; to remap its keys to `notmuch-mua-new-mail', but it is nice to
> ;; have things work correctly if some lisp code somewhere calls
> ;; `compose-mail' or friends
> (defun spw/load-notmuch ( ignore)
>   (require 'notmuch))
> (dolist (cmd '(compose-mail
>   (advice-add cmd :before #'spw/load-notmuch))
> (global-set-key "\C-cs" #'notmuch-search)
> (global-set-key "\C-cm" #'notmuch-jump-search)
> (global-set-key "\C-cM" #'notmuch-hello)
> This is not a very idiomatic way to make use of an ELPA package,
> however.  Does anyone have a better approach that does not involve
> advice-add?  I'm using the elpa-notmuch package on Debian.

I'd hoped that:

(require 'notmuch-mua)
(setq mail-user-agent 'notmuch-user-agent)

would be sufficient to get things wired up, but it doesn't seem to be.

If we fix that, would it seem more appropriate? If we get it right then
it shouldn't load any other notmuch code (including notmuch-config.el)
until you actually use one of the functions.

(None of this will configure your chosen bindings of course, you'll
still have to do that yourself.)

Everybody's got something to hide, 'cept me and my monkey.
notmuch mailing list