Re: Lazily loading notmuch into Emacs
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 notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] add NEWS for 0.30
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) > = > > +S/MIME > +-- > + > +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 notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
broken bash completion
Hello, (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 Uwe signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] doc: field processor support now always included, adjust manual pages
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
file.
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.
**built_with.**
Compile time feature . Current possibilities include
-"compact" (see **notmuch-compact(1)**) and "field_processor" (see
-**notmuch-search-terms(7)**).
+"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
b/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**
thread:{}
-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:..
query:
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)**.
property:=
The **property:** prefix searches for messages with a particular
@@ -353,23 +349,21 @@ since 1970-01-01 00:00:00 UTC. For example:
date:@..@
-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
-Monday.
-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.
-XAPIAN FIELD PROCESSORS
-===
-
-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
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 txn.abort() 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 db.close() 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() notmuch2._capi.notmuch_database_being_atomic(db._db_p) 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 term. > 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? Probably. Thanks for caring! Cheers, Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Lazily loading notmuch into Emacs
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 >compose-mail-other-window >compose-mail-other-frame >notmuch-jump-search >notmuch-hello)) > (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.) dme. -- Everybody's got something to hide, 'cept me and my monkey. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
