Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package.
Hello, On Wed 21 Dec 2022 at 07:53AM -04, David Bremner wrote: > Sean Whitton writes: > >> >> I know that you don't want to commit notmuch-pkg.el to git, and that's >> in fact undesirable from a NonGNU ELPA point of view, it turns out. But >> given how there is already version.txt and version.py, could we have a >> header in notmuch.el too, do you think? > > The existence of version.py is a bug that we hope to fix soon. It is > used only by the obsolete and deprecated python bindings. Current > bindings (under bindings/python-cffi) use version.txt. > > Adding a version header to notmuch.el and maintaining it > semi-automatically in the way version.py is seems more fragile (sed'ing > a file also edited by humans) and more work (the code to generate > notmuch-pkg.el already exists). Okay, thanks. We can investigate whether we can get the branch-filtering script to substitute in the version. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package.
Hello notmuch maintainers,
As discussed on IRC, I'm seeing if I can add notmuch.el to NonGNU ELPA.
Currently the build is failing and Stefan Monnier, who designed the
packaging scripts, suggests adding a Version: header to notmuch.el:
On Tue 20 Dec 2022 at 02:44PM -05, Stefan Monnier wrote:
>> + :make ("emacs/notmuch-pkg.el" "emacs/notmuch-version.el")
>
> (Non)GNU ELPA really wants to create the -pkg.el from the headers
> in the .el main file. The above may sometimes work but will bite
> us sooner or later.
>
>> + ;; FIXME: notmuch-pkg.el is not committed to Git.
>
> Please don't fix this. If it's in the Git it gets worse (tends to
> create spurious conflicts while building the package. Our scripts
> *should* be resilient to such problems, but based on past experience,
> I doubt they are yet in all cases).
> [...]
> The fix should start by adding a `Version:` to the `notmuch.el` file.
> [...]
> But in any case, a `grep 0.37` in the repository shows that they already
> have two copies of the version number (one in `version.txt` and one in
> `bindings/python/notmuch/version.py`), so adding a third shouldn't
> be a big deal.
I know that you don't want to commit notmuch-pkg.el to git, and that's
in fact undesirable from a NonGNU ELPA point of view, it turns out. But
given how there is already version.txt and version.py, could we have a
header in notmuch.el too, do you think?
Thanks.
--
Sean Whitton
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Database location bug when database does not already exist
Hello, On Sat 03 Sep 2022 at 08:34AM -03, David Bremner wrote: > Sean Whitton writes: > >> Hello, >> >> In the following situation: >> >> - only notmuch config is ~/.notmuch-config >> - database.mail_root is set >> - database.path is not set >> - notmuch database does not yet exist >> >> then notmuch wants to create its db under mail_root/.notmuch, contrary >> to notmuch-config(1). >> > > This bug should be fixed as of commit 84e4e130e2c920b3dee91901582c4ab6276e2630 Nice, thanks! -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Database location bug when database does not already exist
Hello, In the following situation: - only notmuch config is ~/.notmuch-config - database.mail_root is set - database.path is not set - notmuch database does not yet exist then notmuch wants to create its db under mail_root/.notmuch, contrary to notmuch-config(1). -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: bug#56442: gnus-search-run-search: Hits notmuch command line length limits
Hello, On Sat 09 Jul 2022 at 09:11AM -07, Eric Abrahamsen wrote: > But looking at your patch maybe I just needed to quote differently? Right, notmuch has this unusual " -> "" quoting thing. > Anyway I'll give this a test this weekend. It would be *very* nice if > we could use this syntax rather than the ugly home-grown one. Let me know the results of your test, and if it's also continuing to work for me by then, I'll install the change. Thanks for taking a look. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
bug#56442: gnus-search-run-search: Hits notmuch command line length limits
Hello,
I'm running a pretty innocent notmuch query over a fairly small Maildir:
"((List:debian-devel.lists.debian.org) or ... or
(List:debian-haskell.lists.debian.org) or
(List:debconf-discuss.lists.debian.org)) and (not path:annex/**)"
but gnus-search-run-search fails to return any results. The reason is
that Gnus first runs the query with --output=threads to obtain a list of
thread ids, and then runs another query with --output=files and a query
constructed from the output of the first query: "thread:d9d0
or thread:d9e0 or thread:d268 or ..."
The resulting command fails completely:
emacs: /usr/bin/notmuch: Argument list too long
Instead of running two searches like this, we can just surround the
whole query like this: "thread:{QUERY}". The manual says it's exactly
equivalent:
... the user should think of the query thread:{} as
expanding to all of the thread IDs which match ; not‐
much then performs a second search using the expanded query.
This should be faster, too, with only running a single external command.
Here is the patch I'm thinking I'll apply, if anyone has comments.
--
Sean Whitton
>From d62398cc27abd317d31d8f07e151a82081444217 Mon Sep 17 00:00:00 2001
From: Sean Whitton
Date: Thu, 7 Jul 2022 09:34:04 -0700
Subject: [PATCH] Use notmuch thread:{} operator instead of performing two
searches
This also avoids some command line length limit problems.
* gnus-search.el
(gnus-search-run-search (engine gnus-search-notmuch)): Delete method.
(gnus-search-indexed-search-command (engine gnus-search-notmuch)):
When searching for threads, wrap whole query in thread:{} operator.
Always use --output=files, never --output=threads.
---
lisp/gnus/gnus-search.el | 46 +---
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/lisp/gnus/gnus-search.el b/lisp/gnus/gnus-search.el
index 369df81d9b..53b6d1b4c6 100644
--- a/lisp/gnus/gnus-search.el
+++ b/lisp/gnus/gnus-search.el
@@ -1672,43 +1672,6 @@ gnus-search-transform-expression
(format "date:%s.." (notmuch-date (cdr expr
(t (ignore-errors (cl-call-next-method))
-(cl-defmethod gnus-search-run-search :around ((engine gnus-search-notmuch)
- server query groups)
- "Handle notmuch's thread-search routine."
- ;; Notmuch allows for searching threads, but only using its own
- ;; thread ids. That means a thread search is a \"double-bounce\":
- ;; once to find the relevant thread ids, and again to find the
- ;; actual messages. This method performs the first \"bounce\".
- (if (alist-get 'thread query)
- (with-slots (program proc-buffer) engine
- (let* ((qstring
- (gnus-search-make-query-string engine query))
- (cp-list (gnus-search-indexed-search-command
- engine qstring query groups))
- thread-ids proc)
- (with-current-buffer proc-buffer
- (erase-buffer)
- (setq proc (apply #'start-process (format "search-%s" server)
- proc-buffer program cp-list))
- (while (process-live-p proc)
- (accept-process-output proc))
-(goto-char (point-min))
- (while (re-search-forward
-"^thread:\\([^[:space:]\n]+\\)"
-(point-max) t)
- (cl-pushnew (match-string 1) thread-ids :test #'equal)))
- (cl-call-next-method
- engine server
- ;; If we found threads, completely replace the query with
- ;; our new thread-based one.
- (if thread-ids
- `((query . ,(mapconcat (lambda (thrd)
-(concat "thread:" thrd))
- thread-ids " or ")))
- query)
- nil)))
-(cl-call-next-method engine server query groups)))
-
(cl-defmethod gnus-search-indexed-search-command ((engine gnus-search-notmuch)
(qstring string)
query _groups)
@@ -1721,13 +1684,14 @@ gnus-search-indexed-search-command
(append
(list (format "--config=%s" config-file)
"search"
- (if thread
- "--output=threads"
- "--output=files"))
+ "--output=files")
(unless thread '("--duplicate=1"))
(when limit (list (format "--limit=%d" limit)))
switches
- (list qstring)
+ (list (if thread
+ (format "thread:\"{%s}\""
+ (string-replace "\"" "\"\"" qstring))
+ qstring))
;;; Mairix interface
--
2.30.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Ignoring unknown messages for git.safe_fraction
Hello, On one machine I have only some of my mail, and so 'notmuch git status' will always have a lot of lines starting with "U". But then git.safe_fraction will always be exceeded. How about ignoring status['missing'] in check_safe_fraction, by default? -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: WIP: promote nmbug to user sync tool
Hello, On Sat 07 May 2022 at 09:01pm -03, David Bremner wrote: > Sean Whitton writes: > >> Just looking at my current usage, there are two cases where I've wrapped >> nmbug in some additional myrepos scripting. The first is a status >> command: >> >> status = >> nmbug-spw status | grep -v "^U\s" || true >> # `nmbug status` does not catch committed but unpushed changes >> git --no-pager log --branches \ >> --not --remotes \ >> --simplify-by-decoration --decorate --oneline >> >> Possibly notmuch-git could learn how to do this? > > Perhaps. I think I would prefer something a bit more concise like a > count of unpushed commits. Do you tend to actually have meaningful > commit messages? I don't. I just want output if there are unpushed changes and no output if not. A count sounds good to me. > Personally I would be more worried about checkout (e.g. after init) > wiping out my notmuch database, since an errant commit can always be > reverted. Both cases seem to be covered by your heuristic. Perhaps we > could just count the size of the update, and insist on a --force option > if it is too large. I think you're right. It makes sense to build in safety features only for the case of accidentally wiping out the db. Either instead or in addition to something size-based, how about requiring --force if there do not exist any tags with the prefix in the notmuch database already? The size thing is brittle; in my scripting attempts, I've encountered several annoying edge cases. > For what it's worth, you can already call > > notmuch git -C $HOME/lib/nmbug-spw -p spw:: ... > > if that is more convenient. > > The defaults have already changed in my latest working branch so the > default repo is under $XDG_DATA_HOME/notmuch/$NOTMUCH_PROFILE/git, and > the default prefix is ''. But re-reading this, I see see we polled two > people and got two answers for what a reasonable default prefix is, so a > configuration item is definitely needed for prefix. Probably it is also > reasonable to have one for repo location. Coolio. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forcing a sync of maildir flags?
Hello, On Tue 03 May 2022 at 09:14AM -03, David Bremner wrote: > I have the same intuition. Unfortunately it is not as simple as adding > in a couple calls to this function. The complications I am aware of so > far are > > 1) We need to distinguish between when a newly discovered file should > update tags, and when the newly discovered file should have it's flags > updated. > > 2) Renaming files in the middle of notmuch new needs to be done > carefully in order that notmuch doesn't lose track of the files. They > are only lost until the next run of notmuch-new, but it's not ideal. Okay, thanks for the info. Nice to have it all recorded in this thread. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forcing a sync of maildir flags?
Hello David, On Sun 01 May 2022 at 08:23PM -03, David Bremner wrote: > Sean Whitton writes: >> >> Thanks. Let me record in this thread what I will believe it will take a >> reproduce this in a test: >> >> 1) inbox and sent are Maildirs >> >> 1) Compose mail to a mailing list which will return copies of >>submissions, with `Fcc: sent -unread` > > Since you mention Fcc, are you using notmuch insert? notmuch-maildir-use-notmuch-insert is t so I think I am? > # next line is a no-op, because it already doesn't have the unread tag > notmuch tag -unread folder:sent Seems also worth noting that to my mind it ultimately shouldn't be necessary to run that command -- notmuch should notice that one copy of the message has different maildir flags to the other in a way that's out of sync with the notmuch tags it has. > The key point is that from notmuch's point of view the message never has > the unread tag, so there is no change for "notmuch tag" to sync with > maildir flags. > > It doesn't seem to make a difference if I put the copy in inbox/new or > inbox/cur, so I don't think it is related to the previous efforts not to > prematurely move files out of new/. > > As far as I can tell, notmuch-new (unlike notmuch-insert) does not call > notmuch_message_tags_to_maildir_flags, so the maildir flags on the newly > discovered copy are not updated. Perhaps it should, but that seems like > a pretty big change, so I want to proceed with caution. It makes sense to me for notmuch-new to call that function too, fwiw. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: WIP: promote nmbug to user sync tool
[please keep me CCed]
Hello David,
On Sat 23 Apr 2022 at 10:38am -03, David Bremner wrote:
> One of the things that new (and old) users of notmuch often miss is a
> way to sync tags between hosts. muchsync exists, but it's a third
> party tool, and (if I understand correctly) it directly modifies the
> notmuch database. Meanwhile we ship a moderately complex python script
> called 'nmbug' which can be used to sync arbitrary tags between hosts.
> This series is my (first pass at an) attempt to promote nmbug to a
> notmuch subcommand "notmuch git". My plan is to replace my own
> homebrew "commit notmuch dump output to git" script with this new
> command; I think it may appeal to other users as well. As a bonus, it
> provides a simple (for the user) way to do incremental backups of the
> notmuch database.
>
> I had to add a couple of caching tricks to make the script usable for
> my database, but it is now reasonably fast (say 20s) to commit a days
> worth of changes on my machine.
I think I'm the person who's already been using nmbug for personal tags
for an appreciable length of time. It is great to see these caching
improvements and the addition of a test suite.
> There are still some rough edges, mainly due to the heritage of the
> script. Some I am aware of include:
>
> - the (new) man page is inadequate
> - notmuch git doesn't understand the common arguments to notmuch (--config
> and friends)
> - the defaults for prefix and git repo are wrong for most users. I was
> thinking about either a
> --nmbug argument to set the old defaults, or having the script recognize if
> it is invoked as nmbug.
> - There are a few too many global variables
> - I just remembered, MAX_LASTMOD is unused, leftover from a previous design
> for querying tags.
Just looking at my current usage, there are two cases where I've wrapped
nmbug in some additional myrepos scripting. The first is a status
command:
status =
nmbug-spw status | grep -v "^U\s" || true
# `nmbug status` does not catch committed but unpushed changes
git --no-pager log --branches \
--not --remotes \
--simplify-by-decoration --decorate --oneline
Possibly notmuch-git could learn how to do this?
Secondly, I've got this auto-commit command:
autoci =
nmbug-spw status | perl -ne'/^[AD][ad]?\s/ and $i++ > 500 and exit 1' \
&& nmbug-spw commit
The guard has two purposes. Firstly, it avoids wiping out git as part
of a cronjob auto-commit because the nmbug repo has just been cloned but
'nmbug checkout' hasn't been run. Secondly, it avoids doing any
committing if there are any known remote changes that haven't been
integrated. The latter thing is probably just a personal preference.
As for the former thing, I wonder if instead there could be some
mechanism, connected with the new caching, to associate nmbug repos with
the notmuch database, and refuse to operate unless that association
already exists? So, 'nmbug checkout' would mark it as safe to sync back
and forth between the database and that repo no matter the number of
changes.
On Sat 23 Apr 2022 at 03:49pm -03, David Bremner wrote:
> Related, the current script does not understand NOTMUCH_PROFILE. That
> would be a natural way to locate the default git repo.
It would, but it wouldn't help with configuring a default prefix.
Perhaps an entry in .notmuch-config for that? Currently I use a tiny
wrapper script:
#!/bin/sh
NMBGIT="$HOME/lib/nmbug-spw" NMBPREFIX="spw::" nmbug "$@"
but it would be great to just be able to type 'notmuch git ...'.
--
Sean Whitton
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forcing a sync of maildir flags?
Hello, On Tue 22 Mar 2022 at 12:44pm -07, Sean Whitton wrote: > I am seeing this bug, or a closely related one, a whole lot right now. > Messages are coming back as unread over and over again. I recently made > some changes to my notmuch cronjobs, so that probably has something to > do with it, but I have no guesses as to what the problem is. > > As a first thing to try, I am going to add something to my pre-new hook > to perform the new/ -> cur/ move as specified by maildir(5) on all my > synced maildirs, so that notmuch never sees messages in new/ except when > it writes new drafts and sent mail there (and they'll get moved on the > next sync). > > I'll drop the 'notmuch tag -unread -- folder:sent' workaround at the > same time to see what happens. Seems to be working well. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forcing a sync of maildir flags?
Hello David, On Thu 20 Feb 2020 at 08:22AM -04, David Bremner wrote: > Sean Whitton writes: > >> I have this in my post-new hook: >> >> notmuch tag -unread -- folder:sent >> >> The idea is that copies of my sent mail which get returned to me and >> stored in my inbox, e.g. by mailing lists, would get maildir Seen tags >> added to them. But that does not happen. > > I guess this is most likely a bug. It would be nice to have a test in > T340-maildir-sync.sh that duplicated it. I suspect the problem is > related to messages in the new/ subdirectory. Some non-notmuch clients > (prominently mutt) interpret being in new/ has having user-visible > semantics, so notmuch tries not to move files out of there > unnecessarily, On the other hand the maildir spec says that files in > new/ cannot have flags, so they cannot have their unread tag removed > without moving the file to cur/ I am seeing this bug, or a closely related one, a whole lot right now. Messages are coming back as unread over and over again. I recently made some changes to my notmuch cronjobs, so that probably has something to do with it, but I have no guesses as to what the problem is. As a first thing to try, I am going to add something to my pre-new hook to perform the new/ -> cur/ move as specified by maildir(5) on all my synced maildirs, so that notmuch never sees messages in new/ except when it writes new drafts and sent mail there (and they'll get moved on the next sync). I'll drop the 'notmuch tag -unread -- folder:sent' workaround at the same time to see what happens. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 1/2] test: known broken tests for bracketed terms in subject
Hello, On Sat 19 Mar 2022 at 07:38am -03, David Bremner wrote: > David Bremner writes: > >> The heuristics in the field processor currently incorrectly trigger >> phrase parsing. > > I have applied this series to master Nice, thanks! -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Parenthesised query breaks query it is embedded in
Hello,
I have this subquery:
subject:("Cron
Re: [PATCH v2] nmbug: write tags out to a temporary file, not 'nmbug.index'
Hello, On Sun 13 Feb 2022 at 09:54am -07, Sean Whitton wrote: > If more than nmbug process is running at once, then each will try to > read and write the same file. The particular failure I've seen is > that the process which finishes first deletes nmbug.index, and then > the other process dies with a FileNotFoundError. So use a distinct > temporary file per process. > --- > devel/nmbug/nmbug | 44 ++-- > 1 file changed, 22 insertions(+), 22 deletions(-) > > Here is a second attempt, though I'm afraid I have little idea whether it is > idiomatic Python. It would seem this causes 'nmbug status' to output just one result. I'll leave the fix to someone with more Python experience. Sorry for the improperly tested v2 patch. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH v2] nmbug: write tags out to a temporary file, not 'nmbug.index'
If more than nmbug process is running at once, then each will try to
read and write the same file. The particular failure I've seen is
that the process which finishes first deletes nmbug.index, and then
the other process dies with a FileNotFoundError. So use a distinct
temporary file per process.
---
devel/nmbug/nmbug | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
Here is a second attempt, though I'm afraid I have little idea whether it is
idiomatic Python.
diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index 043c1863..396098d0 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -586,37 +586,38 @@ def get_status():
'deleted': {},
'missing': {},
}
-index = _index_tags()
-maybe_deleted = _diff_index(index=index, filter='D')
-for id, tags in maybe_deleted.items():
-(_, stdout, stderr) = _spawn(
-args=['notmuch', 'search', '--output=files', 'id:{0}'.format(id)],
-stdout=_subprocess.PIPE,
-wait=True)
-if stdout:
-status['deleted'][id] = tags
-else:
-status['missing'][id] = tags
-status['added'] = _diff_index(index=index, filter='A')
-_os.remove(index)
-return status
-
-
-def _index_tags():
-"Write notmuch tags to the nmbug.index."
-path = _os.path.join(NMBGIT, 'nmbug.index')
+(_, index) = _tempfile.mkstemp()
+try:
+_index_tags(index)
+maybe_deleted = _diff_index(index=index, filter='D')
+for id, tags in maybe_deleted.items():
+(_, stdout, stderr) = _spawn(
+args=['notmuch', 'search', '--output=files',
'id:{0}'.format(id)],
+stdout=_subprocess.PIPE,
+wait=True)
+if stdout:
+status['deleted'][id] = tags
+else:
+status['missing'][id] = tags
+status['added'] = _diff_index(index=index, filter='A')
+return status
+finally:
+_os.remove(index)
+
+def _index_tags(index):
+"Write notmuch tags to a file."
query = ' '.join('tag:"{tag}"'.format(tag=tag) for tag in get_tags())
prefix = '+{0}'.format(_ENCODED_TAG_PREFIX)
_git(
args=['read-tree', '--empty'],
-additional_env={'GIT_INDEX_FILE': path}, wait=True)
+additional_env={'GIT_INDEX_FILE': index}, wait=True)
with _spawn(
args=['notmuch', 'dump', '--format=batch-tag', '--', query],
stdout=_subprocess.PIPE) as notmuch:
with _git(
args=['update-index', '--index-info'],
stdin=_subprocess.PIPE,
-additional_env={'GIT_INDEX_FILE': path}) as git:
+additional_env={'GIT_INDEX_FILE': index}) as git:
for line in notmuch.stdout:
if line.strip().startswith('#'):
continue
@@ -629,7 +630,6 @@ def _index_tags():
for line in _index_tags_for_message(
id=id, status='A', tags=tags):
git.stdin.write(line)
-return path
def _index_tags_for_message(id, status, tags):
--
2.30.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] nmbug: write tags out to a temporary file, not 'nmbug.index'
If more than nmbug process is running at once, then each will try to
read and write the same file. The particular failure I've seen is
that the process which finishes first deletes nmbug.index, and then
the other process dies with a FileNotFoundError. So use a distinct
temporary file per process.
---
devel/nmbug/nmbug | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index 043c1863..3c069701 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -603,8 +603,8 @@ def get_status():
def _index_tags():
-"Write notmuch tags to the nmbug.index."
-path = _os.path.join(NMBGIT, 'nmbug.index')
+"Write notmuch tags to a temporary index."
+(_ , path) = _tempfile.mkstemp()
query = ' '.join('tag:"{tag}"'.format(tag=tag) for tag in get_tags())
prefix = '+{0}'.format(_ENCODED_TAG_PREFIX)
_git(
--
2.30.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] Revert "emacs: notmuch-search: avoid wiping out buffer-local variables"
Hello, On Sun 08 Nov 2020 at 06:49PM +01, Jonas Bernoulli wrote: > This reverts commit f9fbd1ee3bfd679175d88af403752d87a730349f. > > Emacs provides a mechanism for avoiding wiping out buffer-local > variables: marking them as "permanent local", which essentially > means "don't wip out the local value when enabling major-mode". > > (put 'the-variable 'permanent-local t) > > See (info "(elisp)Creating Buffer-Local"). > > Whether refreshing the buffer contents should involve re-enable the > mode is a different question, which should not be decided based on > the fact that we want keep the value of some random variable, not > least because some other (e.g. cache) variables are likely expected > to be wiped. Nice, thank you for the info. I've tested that my usecase works after reverting the patch so I support reverting it. Reviewed-by: Sean Whitton -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2] emacs: Use pop-to-buffer-same-window rather than switch-to-buffer
Hello, On Sat 22 Aug 2020 at 12:04PM +03, Tomi Ollila wrote: > On Tue, Aug 11 2020, Sean Whitton wrote: > >> This means that notmuch commands obey display-buffer-alist so the user >> can customize how buffers show up. >> >> It also permits the use of C-x 4 4, C-x 5 5 and C-x t t, available in >> Emacs 28. For example, one can use C-x 4 4 M-x notmuch-jump-search RET >> to open a saved search in another window rather than the current window. >> Or in notmuch-search mode, C-x 5 5 RET to view the message at point in >> a new frame. >> >> notmuch-tree has custom buffer display logic, so bind >> display-buffer-overriding-action to make pop-to-buffer-same-window >> behave exactly as switch-to-buffer while that function is running. >> --- >> Changes since v1: rebased onto latest master. > > I've been having this in my emacs setup (one-notmuch.elc =D) couple > of days, and haven't seen anything strange. Thanks both for testing it! -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH v2] emacs: Use pop-to-buffer-same-window rather than switch-to-buffer
This means that notmuch commands obey display-buffer-alist so the user can customize how buffers show up. It also permits the use of C-x 4 4, C-x 5 5 and C-x t t, available in Emacs 28. For example, one can use C-x 4 4 M-x notmuch-jump-search RET to open a saved search in another window rather than the current window. Or in notmuch-search mode, C-x 5 5 RET to view the message at point in a new frame. notmuch-tree has custom buffer display logic, so bind display-buffer-overriding-action to make pop-to-buffer-same-window behave exactly as switch-to-buffer while that function is running. --- Changes since v1: rebased onto latest master. emacs/notmuch-draft.el | 3 ++- emacs/notmuch-hello.el | 2 +- emacs/notmuch-show.el | 8 emacs/notmuch-tree.el | 13 + emacs/notmuch.el | 4 ++-- 5 files changed, 18 insertions(+), 12 deletions(-) diff --git a/emacs/notmuch-draft.el b/emacs/notmuch-draft.el index 759e6c9e..283830ad 100644 --- a/emacs/notmuch-draft.el +++ b/emacs/notmuch-draft.el @@ -232,7 +232,8 @@ applied to newly inserted messages)." (draft (equal tags (notmuch-update-tags tags notmuch-draft-tags (when (or draft (yes-or-no-p "Message does not appear to be a draft: edit as new? ")) - (switch-to-buffer (get-buffer-create (concat "*notmuch-draft-" id "*"))) + (pop-to-buffer-same-window + (get-buffer-create (concat "*notmuch-draft-" id "*"))) (setq buffer-read-only nil) (erase-buffer) (let ((coding-system-for-read 'no-conversion)) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index c127bba9..bb60a890 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -973,7 +973,7 @@ following: (let ((notmuch-hello-auto-refresh nil)) (if no-display (set-buffer "*notmuch-hello*") - (switch-to-buffer "*notmuch-hello*"))) + (pop-to-buffer-same-window "*notmuch-hello*"))) ;; Install auto-refresh hook (when notmuch-hello-auto-refresh (add-hook 'window-configuration-change-hook diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index b0f2d28b..98d9c935 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1241,7 +1241,7 @@ matched." (eval (car (get 'mm-inline-override-types 'standard-value (cons "application/*" mm-inline-override-types) mm-inline-override-types))) -(switch-to-buffer (get-buffer-create buffer-name)) +(pop-to-buffer-same-window (get-buffer-create buffer-name)) ;; No need to track undo information for this buffer. (setq buffer-undo-list t) (notmuch-show-mode) @@ -1998,7 +1998,7 @@ to show, nil otherwise." (let* ((id (notmuch-show-get-message-id)) (buf (get-buffer-create (concat "*notmuch-raw-" id "*"))) (inhibit-read-only t)) -(switch-to-buffer buf) +(pop-to-buffer-same-window buf) (erase-buffer) (let ((coding-system-for-read 'no-conversion)) (call-process notmuch-command nil t nil "show" "--format=raw" id)) @@ -2057,7 +2057,7 @@ message." (set-buffer-modified-p nil) (setq buffer-read-only t) (unless (zerop exit-code) - (switch-to-buffer-other-window buf) + (pop-to-buffer buf) (message (format "Command '%s' exited abnormally with code %d" shell-command exit-code @@ -2465,7 +2465,7 @@ If the part is displayed in an external application then close the new buffer." (let ((buf (get-buffer-create (generate-new-buffer-name (concat " *notmuch-internal-part*") -(switch-to-buffer buf) +(pop-to-buffer-same-window buf) (if (eq (mm-display-part handle) 'external) (kill-buffer buf) (goto-char (point-min)) diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el index fbba4bb3..f36a6e72 100644 --- a/emacs/notmuch-tree.el +++ b/emacs/notmuch-tree.el @@ -543,9 +543,14 @@ NOT change the database." (setq notmuch-tree-message-window (split-window-vertically (/ (window-height) 4))) (with-selected-window notmuch-tree-message-window - ;; Since we are only displaying one message do not indent. - (let ((notmuch-show-indent-messages-width 0) - (notmuch-show-only-matching-messages t)) + (let (;; Since we are only displaying one message do not indent. + (notmuch-show-indent-messages-width 0) + (notmuch-show-only-matching-messages t) + ;; Ensure that `pop-to-buffer-same-window' uses the + ;; window we want it to use. + (display-buffer-overriding-action +'((display-buffer-same-window) + (inhibit-same-window . nil (setq buffer (notmuch-show id ;; We need the `let' as notmuch-tree-message-window is buffer local. (let ((window notmuch-tree-message-window)) @@ -1076,7 +1081,7 @@ The arguments
[PATCH] emacs: Use pop-to-buffer-same-window rather than switch-to-buffer
This means that notmuch commands obey display-buffer-alist so the user can customize how buffers show up. It also permits the use of C-x 4 4, C-x 5 5 and C-x t t, available in Emacs 28. For example, one can use C-x 4 4 M-x notmuch-jump-search RET to open a saved search in another window rather than the current window. Or in notmuch-search mode, C-x 5 5 RET to view the message at point in a new frame. notmuch-tree has custom buffer display logic, so bind display-buffer-overriding-action to make pop-to-buffer-same-window behave exactly as switch-to-buffer while that function is running. --- emacs/notmuch-draft.el | 3 ++- emacs/notmuch-hello.el | 2 +- emacs/notmuch-show.el | 8 emacs/notmuch-tree.el | 13 + emacs/notmuch.el | 4 ++-- 5 files changed, 18 insertions(+), 12 deletions(-) diff --git a/emacs/notmuch-draft.el b/emacs/notmuch-draft.el index 27abc7d9..3a9750e1 100644 --- a/emacs/notmuch-draft.el +++ b/emacs/notmuch-draft.el @@ -228,7 +228,8 @@ applied to newly inserted messages)." (draft (equal tags (notmuch-update-tags tags notmuch-draft-tags (when (or draft (yes-or-no-p "Message does not appear to be a draft: edit as new? ")) - (switch-to-buffer (get-buffer-create (concat "*notmuch-draft-" id "*"))) + (pop-to-buffer-same-window + (get-buffer-create (concat "*notmuch-draft-" id "*"))) (setq buffer-read-only nil) (erase-buffer) (let ((coding-system-for-read 'no-conversion)) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 0ff5aaff..3b4ed2b7 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -967,7 +967,7 @@ following: (let ((notmuch-hello-auto-refresh nil)) (if no-display (set-buffer "*notmuch-hello*") - (switch-to-buffer "*notmuch-hello*"))) + (pop-to-buffer-same-window "*notmuch-hello*"))) ;; Install auto-refresh hook (when notmuch-hello-auto-refresh diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index c9170466..4ee34f8e 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1270,7 +1270,7 @@ matched." (eval (car (get 'mm-inline-override-types 'standard-value (cons "application/*" mm-inline-override-types) mm-inline-override-types))) -(switch-to-buffer (get-buffer-create buffer-name)) +(pop-to-buffer-same-window (get-buffer-create buffer-name)) ;; No need to track undo information for this buffer. (setq buffer-undo-list t) @@ -2039,7 +2039,7 @@ to show, nil otherwise." (let* ((id (notmuch-show-get-message-id)) (buf (get-buffer-create (concat "*notmuch-raw-" id "*"))) (inhibit-read-only t)) -(switch-to-buffer buf) +(pop-to-buffer-same-window buf) (erase-buffer) (let ((coding-system-for-read 'no-conversion)) (call-process notmuch-command nil t nil "show" "--format=raw" id)) @@ -2095,7 +2095,7 @@ message." (set-buffer-modified-p nil) (setq buffer-read-only t) (unless (zerop exit-code) - (switch-to-buffer-other-window buf) + (pop-to-buffer buf) (message (format "Command '%s' exited abnormally with code %d" shell-command exit-code @@ -2503,7 +2503,7 @@ If the part is displayed in an external application then close the new buffer." (let ((buf (get-buffer-create (generate-new-buffer-name (concat " *notmuch-internal-part*") -(switch-to-buffer buf) +(pop-to-buffer-same-window buf) (if (eq (mm-display-part handle) 'external) (kill-buffer buf) (goto-char (point-min)) diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el index ab90f652..7ed06ffd 100644 --- a/emacs/notmuch-tree.el +++ b/emacs/notmuch-tree.el @@ -527,9 +527,14 @@ NOT change the database." (setq notmuch-tree-message-window (split-window-vertically (/ (window-height) 4))) (with-selected-window notmuch-tree-message-window - ;; Since we are only displaying one message do not indent. - (let ((notmuch-show-indent-messages-width 0) - (notmuch-show-only-matching-messages t)) + (let (;; Since we are only displaying one message do not indent. + (notmuch-show-indent-messages-width 0) + (notmuch-show-only-matching-messages t) + ;; Ensure that `pop-to-buffer-same-window' uses the + ;; window we want it to use. + (display-buffer-overriding-action +'((display-buffer-same-window) + (inhibit-same-window . nil (setq buffer (notmuch-show id ;; We need the `let' as notmuch-tree-message-window is buffer local. (let ((window notmuch-tree-message-window)) @@ -1061,7 +1066,7 @@ The arguments are: query "*") (inhibit-read-only t)) -
Re: [PATCH 07/23] emacs: Use 'and' instead of 'when' when the return value matters
Hello, On Mon 27 Jul 2020 at 12:02AM +02, Jonas Bernoulli wrote: > Sean Whitton writes: > >> On Sun 26 Jul 2020 at 06:58PM +02, Jonas Bernoulli wrote: >> >>> Also do so for some 'if' forms that lack an ELSE part. >>> Even go as far as using 'and' and 'not' instead of 'unless'. >> >> I don't follow "when the return value matters", could you explain? > > As in "when the caller consumes the returned value". The alternative > would be for the caller to not care about the value returned by the > callee and to instead call it for the side-effects only. > > By using `and' we can signal that care about the return value and by > using `when' that we care about the side-effects instead. Thank you for your reply. Just to confirm, this is just a convention, right? I hadn't come across it yet. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 07/23] emacs: Use 'and' instead of 'when' when the return value matters
Hello, On Sun 26 Jul 2020 at 06:58PM +02, Jonas Bernoulli wrote: > Also do so for some 'if' forms that lack an ELSE part. > Even go as far as using 'and' and 'not' instead of 'unless'. I don't follow "when the return value matters", could you explain? Thanks. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] emacs: notmuch-search: avoid wiping out buffer-local variables
--- emacs/notmuch.el | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index dd18f2e1..c97997fe 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -987,7 +987,11 @@ the configured default sort order." (if no-display (set-buffer buffer) (switch-to-buffer buffer)) -(notmuch-search-mode) +;; avoid wiping out third party buffer-local variables in the case +;; where we're just refreshing or changing the sort order of an +;; existing search results buffer +(unless (eq major-mode 'notmuch-search-mode) + (notmuch-search-mode)) ;; Don't track undo information for this buffer (set 'buffer-undo-list t) (set 'notmuch-search-query-string query) -- 2.27.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
notmuch.el: notmuch-search: avoid wiping out buffer-local variables
Hello, I have some code to cycle through a list of searches. The remaining searches are stored in a buffer-local variable, working something like this (simplified): (defun spw/next-unread-group () (interactive) (notmuch-search (car spw/more-unread-groups) (set (make-local-variable 'spw/more-unread-groups) (cdr spw/more-unread-groups However, my spw/more-unread-groups variable gets wiped out by notmuch-refresh-this-buffer, because the latter calls notmuch-search-mode, and major modes wipe out buffer-local variables. So far as I can tell that call doesn't actually have any effect when the mode is already notmuch-search-mode, so may I propose this patch to support my use case: diff --git a/emacs/notmuch.el b/emacs/notmuch.el index dd18f2e1..dcbc1eb2 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -987,7 +987,8 @@ the configured default sort order." (if no-display (set-buffer buffer) (switch-to-buffer buffer)) -(notmuch-search-mode) +(unless (eq major-mode 'notmuch-search-mode) + (notmuch-search-mode)) ;; Don't track undo information for this buffer (set 'buffer-undo-list t) (set 'notmuch-search-query-string query) -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
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
Lazily loading notmuch into Emacs
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. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Respect `load-prefer-newer` when loading `notmuch-init-file'
Before this change, `load-prefer-newer' was ignored.
Set NOERROR and MUST-SUFFIX arguments of `load' to t, and NOSUFFIX
argument to nil, to preserve the behaviour of the deleted `let' form.
---
I've observed that the way that the code at the end of notmuch.el
loads the user's notmuch-init-file means that the variable
load-prefer-newer is effectively ignored: notmuch.el will always load
notmuch-config.elc in preference to notmuch-config.el, even if the
latter is newer than the former. This patch should fix the problem
without changing anything else.
emacs/notmuch.el | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index a980c7a2..5a24d8a7 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1148,8 +1148,6 @@ beginning of the line."
;; After provide to avoid loops if notmuch was require'd via notmuch-init-file.
(if init-file-user ; don't load init file if the -q option was used.
-(let ((init-file (locate-file notmuch-init-file '("/")
- (get-load-suffixes
- (if init-file (load init-file nil t t
+(load notmuch-init-file t t nil t))
;;; notmuch.el ends here
--
2.26.2
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch and mailing lists
Hello Reto, On Sat 02 May 2020 at 03:13pm +02, Reto wrote: > On Fri, May 01, 2020 at 12:30:28PM -0700, Sean Whitton wrote: >> I've not yet used NNTP to read mailing lists myself, but I think there >> are limitations to the way I currently read lists > > What are you missing exactly? > If we know what your actual problems are there might be better solutions > forthcoming. Well, I would like to be able to handle a higher volume of messages faster. I think that I am typically reluctant to subscribe to new lists because I know that I'm not efficient at processing the mail. People who use NNTP to read mailing lists talk about the following sorts of things which speed things up: - efficient killfiles/filters - manually killing subthreads - expiration/catching up - browsing lists without going through the process of subscription and/or downloading archives I'd be interested to hear what techniques people have for making notmuch capable of getting through mailing list mail faster. I find that notmuch is great for practising Inbox Zero on personal mail, and for searching to find old mail, but I haven't made it especially good for dealing with discussion forums yet. I've come up with a few ideas myself in the past few days but they're fairly simple. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
notmuch and mailing lists
Hello, I was wondering whether anyone who previously read mailing lists via NNTP has stopped doing this after starting to use notmuch. I've not yet used NNTP to read mailing lists myself, but I think there are limitations to the way I currently read lists, and was wondering whether it is worth exploring the NNTP approach, or trying to come up with notmuch-based workflow improvements. Kindly CC me on replies. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: easy (?) elisp project for notmuch [it's mostly DONE]
Hello, On Wed 15 Apr 2020 at 01:41PM -07, Sean Whitton wrote: > Debian/Ubuntu/etc. you can `apt-get install mailscripts` Oh, and `apt-get install elpa-mailscripts` to get `M-x notmuch-slurp-this-debbug` and `M-x notmuch-slurp-debbug`. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: easy (?) elisp project for notmuch [it's mostly DONE]
Hello, On Wed 15 Apr 2020 at 04:28PM -03, David Bremner wrote: > Jonas Bernoulli writes: > >> >> One related use case for "notmuch insert" that I had in mind is the >> import of debbugs threads. It someone is aware of an existing solution >> then please let me know. Kyle, have you considered mirroring >> emacs-devel and the Emacs debbugs as well? > > Sean Whitton (in copy) maintains a script called notmuch-slurp-debbug > that does that. I can't remember if it is tested on the GNU instance of > debbugs. > > https://git.spwhitton.name/mailscripts Untested, but should work, and it's a bug if it doesn't. Debian/Ubuntu/etc. you can `apt-get install mailscripts` -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Hello David,
On Sun 01 Dec 2019 at 09:01PM +00, David Edmondson wrote:
> On Friday, 2019-11-29 at 13:01:00 -07, Sean Whitton wrote:
>
>> On Wed 27 Nov 2019 at 08:52PM +00, David Edmondson wrote:
>>> It's a lot to ask, I know, but if you could provide a specific set of
>>> messages with a corresponding initial query that fails for you after
>>> limiting using your function, it would be helpful.
>>
>> You should be able to download an mbox of the thread I was using for
>> testing here:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945195;mbox=yes
>>
>> The Org-mode link I was using to open the thread is
>> [[notmuch:id:20191125214551.31596-1-...@fifthhorseman.net][dkg's v2 for
>> S/MIME decryption]]
>
> This works exactly as I would expect with the patch I previously sent.
>
> I downloaded the messages, added them to my corpus and remove the inbox
> and unread tags.
>
> Then, if I execute:
>
> (notmuch-show “thread:{id:20191125214551.31596-1-...@fifthhorseman.net}”)
>
> and use your function the list of messages open is limited as I
> expected.
>
> “As I expected” means that if I pass no prefix, all of the messages that
> include patches are open. With a prefix argument of “1”, only the first
> set of patches are open. With a prefix argument of “2”, only the v2
> patches are open.
>
> Did I misunderstand the behaviour that you expect?
No, that's what's meant to happen, so I guess that my steps to reproduce
were not accurate. As I mentioned, I don't want to spend a lot of time
on this since I think the bug is in ol-notmuch.el.
Regardless, thank you for your interest.
(You may be interested in the latest version of mailscripts which
contains a rewritten notmuch-extract-patch with new features.)
--
Sean Whitton
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Forcing a sync of maildir flags?
Hello, On Thu 20 Feb 2020 at 08:06PM -04, David Bremner wrote: > Sean Whitton writes: > >> So, your hypothesis is that notmuch is opting not to add the Seen flag >> in order to avoid having to move the message from new to cur, for the >> sake of mutt, but that's a bug because I've explicitly requested adding >> Seen, so it ought to go ahead and move it from new to cur? > > Yeah, I think that's the case. This is based only vague memories of when > I wrote 0082a557. Thanks. Let me record in this thread what I will believe it will take a reproduce this in a test: 1) inbox and sent are Maildirs 1) Compose mail to a mailing list which will return copies of submissions, with `Fcc: sent -unread` 2) notmuch new, and in post-new hook, notmuch tag -unread -- folder:sent Expected result: copy of message in both inbox and sent has Seen flag Actual result: only copy of message in sent has Seen flag -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Forcing a sync of maildir flags?
Hello David, Thank you for your reply. On Thu 20 Feb 2020 at 08:22AM -04, David Bremner wrote: > Sean Whitton writes: > >> I have this in my post-new hook: >> >> notmuch tag -unread -- folder:sent >> >> The idea is that copies of my sent mail which get returned to me and >> stored in my inbox, e.g. by mailing lists, would get maildir Seen tags >> added to them. But that does not happen. > > I guess this is most likely a bug. It would be nice to have a test in > T340-maildir-sync.sh that duplicated it. I suspect the problem is > related to messages in the new/ subdirectory. Some non-notmuch clients > (prominently mutt) interpret being in new/ has having user-visible > semantics, so notmuch tries not to move files out of there > unnecessarily, On the other hand the maildir spec says that files in > new/ cannot have flags, so they cannot have their unread tag removed > without moving the file to cur/ So, your hypothesis is that notmuch is opting not to add the Seen flag in order to avoid having to move the message from new to cur, for the sake of mutt, but that's a bug because I've explicitly requested adding Seen, so it ought to go ahead and move it from new to cur? >> This works: >> >> notmuch tag +unread -- folder:sent >> notmuch tag -unread -- folder:sent >> >> Is there some more elegant way to force a sync of maildir flags? Am I >> the only one that has copies of my own mail in my inbox folder, not >> marked as read from the point of view of anything except notmuch? > > I guess my workflow doesn't expose this problem as I leave many messages > unread (relying on the inbox flag). I'm not sure about the locking > implications, but having sent messages delivered to cur/ instead of to > new/ would probably workaround the problem. In this case it's mbsync downloading messages from IMAP, and there doesn't seem to be a way to configure it to deliver to cur instead of new. On Thu 20 Feb 2020 at 09:21AM -04, David Bremner wrote: > I guess the other thing is that I have > > [new] > tags=unread;inbox;new > > in .notmuch-config, which means that "notmuch new" moves things into > cur/. Maybe you can use that effect? To be honest that doesn't seem really better than the workaround I'm currently using. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Forcing a sync of maildir flags?
Hello, I have this in my post-new hook: notmuch tag -unread -- folder:sent The idea is that copies of my sent mail which get returned to me and stored in my inbox, e.g. by mailing lists, would get maildir Seen tags added to them. But that does not happen. This works: notmuch tag +unread -- folder:sent notmuch tag -unread -- folder:sent Is there some more elegant way to force a sync of maildir flags? Am I the only one that has copies of my own mail in my inbox folder, not marked as read from the point of view of anything except notmuch? Please CC me on replies. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Dear David,
Thank you again for your interest.
On Wed 27 Nov 2019 at 08:52PM +00, David Edmondson wrote:
> If this does what I think, which is to filter the current thread to show
> only those messages that contain actual patches (with an optional
> version number), then, with the previous patch I sent, it seems to work
> just fine for me if the original `notmuch-show' query is something like
> “thread:a or thread:b”, where those threads both contain both patches
> and comments on the patches.
>
> An example call I used initially is:
>
> (notmuch-show "thread:{id:20191117222929.1064-1-j...@jb55.com} or
> thread:{id:20190419035659.28961-1-congdan...@gmail.com}")
>
> Hopefully this is a query that will work for you as well. Limiting this
> using your function behaves as I would expect.
I don't have those messages, I'm afraid.
> It's a lot to ask, I know, but if you could provide a specific set of
> messages with a corresponding initial query that fails for you after
> limiting using your function, it would be helpful.
You should be able to download an mbox of the thread I was using for
testing here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945195;mbox=yes
The Org-mode link I was using to open the thread is
[[notmuch:id:20191125214551.31596-1-...@fifthhorseman.net][dkg's v2 for S/MIME
decryption]]
Please excuse me for not preparing more formal steps to reproduce --
since I consider the bug to be in ol-notmuch.el and my fix to that file
prevents this bug from showing up, I am not really willing to invest a
lot of time in preparing a different sort of fix.
>>>> The purpose of `notmuch-extract-thread-patches' is to extract a whole
>>>> git-send-email(1) patch series at a time, because that is usually what
>>>> one wants to do. There are `notmuch-extract-message-patches' and
>>>> `notmuch-show-pipe-message' for single patches.
>>>
>>> Then I think the approach that you have (wrapping the query in
>>> thread:{}) makes perfect sense.
>>
>> To my mind, it makes sense only to the extent that committing hacky
>> workarounds is something which makes sense :)
>
> Well, if we stick to the idea that the first argument to `notmuch-show'
> can only be a thread ID, then yes.
>
> Given that thread IDs have some annoying properties, it would be
> convenient to allow the caller to pass an arbitrary query.
Yes, I certainly agree that it would be a more useful API.
--
Sean Whitton
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
[dropping Org-mode list per David's suggestion]
Hello,
On Wed 27 Nov 2019 at 01:08PM +00, David Edmondson wrote:
> On Tuesday, 2019-11-26 at 16:25:29 -07, Sean Whitton wrote:
>
>> On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote:
>>
>>> The poor behaviour is just a side effect of the way that queries are
>>> composed to implement the filter functionality. Does the attached patch
>>> help?
>>
>> Unfortunately, it is still broken in my test case.
>
> Could you describe your test case please? (We could remove emacs-orgmode
> for that conversation if you think it appropriate.)
I have this function which calls notmuch-show-filter-thread:
(defun spw--notmuch-show-filter-thread-patches ( reroll-count)
(interactive "P")
(let ((subject-filter
(if reroll-count
(let ((n (prefix-numeric-value reroll-count)))
(if (= n 1)
"(subject:/\\[.*PATCH[^v]*\\]/ or
subject:/\\[.*PATCH.*v1.*\\]/)"
(concat "subject:/\\[.*PATCH.*v" (number-to-string n)
".*\\]/")))
"subject:/\\[.*PATCH.*\\]/ ")))
(notmuch-show-filter-thread
(concat "tag:unread or tag:flagged or ("
subject-filter
" and not subject:'Re:' and not subject:'Info received')"
Copy-pasting the whole function since you mentioned you were interested
in the notmuch patch review functionality I'm working on, but let me
know if you want a narrower test case.
>> The purpose of `notmuch-extract-thread-patches' is to extract a whole
>> git-send-email(1) patch series at a time, because that is usually what
>> one wants to do. There are `notmuch-extract-message-patches' and
>> `notmuch-show-pipe-message' for single patches.
>
> Then I think the approach that you have (wrapping the query in
> thread:{}) makes perfect sense.
To my mind, it makes sense only to the extent that committing hacky
workarounds is something which makes sense :)
> Presumably this all arises because thread IDs are neither stable nor
> portable, so they are inappropriate to store in an external document (as
> an org-mode link in this case)?
Indeed.
--
Sean Whitton
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Hello David, Thank you for the investigation. On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote: > The poor behaviour is just a side effect of the way that queries are > composed to implement the filter functionality. Does the attached patch > help? Unfortunately, it is still broken in my test case. >> Further, my package 'mailscripts' tries to pass the current value of >> `notmuch-show-thread-id' to notmuch-extract-patch(1). >> >> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72 >> >> https://manpages.debian.org/notmuch-extract-patch >> >> If `notmuch-show-thread-id' contains a query which returns a single >> message, the wrong value is passed to notmuch-extract-patch(1), such >> that it may not extract all of the patches in the thread. > > It's not clear to me that this is broken. > > notmuch-extract-patch seems to be properly extracting patches from the > messages that match the query. > > If the current `notmuch-show' buffer query doesn't match the entire > thread, why should `notmuch-extract-thread-patches' be expected to apply > patches from the whole thread? The purpose of `notmuch-extract-thread-patches' is to extract a whole git-send-email(1) patch series at a time, because that is usually what one wants to do. There are `notmuch-extract-message-patches' and `notmuch-show-pipe-message' for single patches. (I note that this is a mailscripts design question, not strictly relevant to the issue of ol-notmuch.el causing the notmuch-show-thread-id variable to be mispopulated. Thank you for your engagement with mailscripts, regardless!) -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Hello David, On Tue 26 Nov 2019 at 08:05PM +00, David Edmondson wrote: > Could you explain how you were using `notmuch-show-thread-id' in a way > that was broken by the presence of an arbitrary query? I've observed that the standard notmuch command `notmuch-show-filter-thread' doesn't work in a buffer opened by `org-notmuch-follow-link'. Further, my package 'mailscripts' tries to pass the current value of `notmuch-show-thread-id' to notmuch-extract-patch(1). https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72 https://manpages.debian.org/notmuch-extract-patch If `notmuch-show-thread-id' contains a query which returns a single message, the wrong value is passed to notmuch-extract-patch(1), such that it may not extract all of the patches in the thread. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Hello, On Tue 26 Nov 2019 at 08:17PM +01, ra...@free.fr wrote: > Your approach probably works most of the time, but I don't like the idea > of having to perform 2 queries when one should be enough. > > I think a better approach would be to change notmuch-show (or add a > new version) that would allow taking arbitrary queries (and > especially, message ids) as input. This probably used to be the case. > > Note that the command line notmuch show function does accept arbitrary > search terms as an argument > > I think updating notmuch-show to compute the thread id from the query > (instead of assuming that the input is a thread id) would be the best > way to go, but you should see that with the notmuch developers. I agree with you that it would be best if `notmuch-show' were extended to accept arbitrary notmuch queries instead of only thread IDs. However, I also believe that ol-notmuch.el should be updated in the meantime. notmuch.el presently exposes an API, `notmuch-show', which takes a thread ID. ol-notmuch.el is misusing that API by passing in a value of a different type -- a notmuch query rather than a thread ID. That's a bug: even if an API is more limited than we would like it to be, we should use it in the way that it is documented to be used by its developers. This misuse of the API causes numerous other hard-to-diagnose bugs. For example, if you use `org-notmuch-follow-link' to open an Org-mode link like "notmuch:id:f...@bar.baz", the standard notmuch command `notmuch-show-filter-thread' doesn't work. And if you use `C-u c i` to yank the thread ID for pasting into a shell, say, you will yank a value which is not a thread ID. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Dear maintainers,
On Thu 21 Nov 2019 at 02:37PM -07, Sean Whitton wrote:
> The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls
> `notmuch-show' with an arbitrary notmuch search query. However, the
> docstring for `notmuch-show' specifies that a notmuch thread ID, rather
> than an arbitrary notmuch query, should be supplied to `notmuch-show'.
>
> The effect of this is that the variable `notmuch-show-thread-id' may
> contain an arbitrary search query rather than a thread ID. That broke
> some code of mine which uses that variable.
>
> `org-notmuch-follow-link' needs to continue to accept an arbitrary query
> (as notmuch thread IDs are not stable), but it should convert it to a
> thread ID before passing it to `notmuch-show'.
Here is my workaround. If this approach seems sensible I can prepare a
patch to `org-notmuch-follow-link` in ol-notmuch.el.
(use-package org-notmuch
:init
;; the default value for `org-notmuch-open-function' is
;; `org-notmuch-follow-link', but that function is broken: it calls
;; `notmuch-show' with a search query rather than a thread ID. This
;; causes `notmuch-show-thread-id' to be populated with a value
;; which is not a thread ID, which breaks various other things
;;
;; so use a custom function instead
(defun spw--org-notmuch-follow-link (search)
(let ((thread-id
(substring
(shell-command-to-string
(combine-and-quote-strings (list "notmuch" "search"
"--output=threads" "--limit=1"
"--format=text"
"--format-version=4" search)))
0 -1)))
(notmuch-show thread-id nil nil search search)))
(setq org-notmuch-open-function 'spw--org-notmuch-follow-link))
--
Sean Whitton
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query
Dear maintainers,
The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls
`notmuch-show' with an arbitrary notmuch search query. However, the
docstring for `notmuch-show' specifies that a notmuch thread ID, rather
than an arbitrary notmuch query, should be supplied to `notmuch-show'.
The effect of this is that the variable `notmuch-show-thread-id' may
contain an arbitrary search query rather than a thread ID. That broke
some code of mine which uses that variable.
`org-notmuch-follow-link' needs to continue to accept an arbitrary query
(as notmuch thread IDs are not stable), but it should convert it to a
thread ID before passing it to `notmuch-show'.
--
Sean Whitton
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Removing notmuch-wash-excerpt-citations from hook breaks fontlocking
Hello, On Wed 25 Jul 2018 at 04:33PM +0800, David Bremner wrote: > The issue is that the notmuch-wash-cited-text is applied in > notmuch-was-excerpt-citations. A simple solution would be to make > another wash function that did less (only did the overlay application) > and use that. Thank you for your reply. Here is how to get what I wanted when I ran into this bug: ;; don't collapse cited text ;; We ought to be able to just remove ;; `notmuch-wash-excerpt-citations' from ;; `notmuch-show-insert-text/plain-hook', but that function is also ;; responsible for colouring cited text (this is an upstream bug: ;; that function does the colouring for performance reasons but the ;; right answer is to use fontlocking, not overlays, for the colouring) (setq notmuch-wash-citation-lines-prefix 1 notmuch-wash-citation-lines-suffix 10000) -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Removing notmuch-wash-excerpt-citations from hook breaks fontlocking
Hello, Steps to reproduce: 1. emacs -q 2. M-x load-library notmuch RET 3. M-x customize-variable notmuch-show-insert-text/plain-hook RET 4. Untick notmuch-wash-excerpt-citations 5. Open notmuch-show on a message Expected result: Quoted text is fontlocked, i.e. a different colour to body text. Actual result: Quoted text is not fontlocked. Thanks. -- Sean Whitton signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Generalising applying tag changes & resolving
Hello, The a, A, x and X bindings in show mode, and similar in tree mode, are very convenient ways to apply whatever you have in notmuch-archive-tags, and move on in your mail reading. I find all four of the bindings useful. It would be good to generalise these so that they could be used for other sets of tags. For example, to apply a 'killed' or 'spam' tag, and move on in the same way that the existing keys do. I've hacked something up, and I can now hit 'K' to modify my next use of a, A, x or X such that the killed tag is also added to the message. Ideally So for example I can use 'KX' to add killed, mark as read and then get out of show mode and return to my list of search results. Ideally this wouldn't be a hack. -- Sean Whitton signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Maildir sync of seen flag confusing with multiple copies
Hello, If I have multiple copies of a message (e.g. in different subdirectories of my mail store), notmuch conveniently only shows me one of them. Once I've read that, though, it seems that only one of the messages in my Maildir gets marked as read. This seems to defeat syncing Maildir flags, because then the message will keep showing as unread in other clients. -- Sean Whitton signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
