Re: Forcing a sync of maildir flags?

2022-05-03 Thread Sean Whitton
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?

2022-05-02 Thread Sean Whitton
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

2022-04-30 Thread Sean Whitton
[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?

2022-04-04 Thread Sean Whitton
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?

2022-03-22 Thread Sean Whitton
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

2022-03-20 Thread Sean Whitton
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

2022-02-23 Thread Sean Whitton
Hello,

I have this subquery:

subject:("Cron 

Re: [PATCH v2] nmbug: write tags out to a temporary file, not 'nmbug.index'

2022-02-13 Thread Sean Whitton
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'

2022-02-13 Thread Sean Whitton
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'

2022-02-12 Thread Sean Whitton
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"

2020-11-08 Thread Sean Whitton
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

2020-08-22 Thread Sean Whitton
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

2020-08-11 Thread Sean Whitton
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

2020-08-07 Thread Sean Whitton
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

2020-07-27 Thread Sean Whitton
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

2020-07-26 Thread Sean Whitton
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

2020-07-22 Thread Sean Whitton
---
 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

2020-07-21 Thread Sean Whitton
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

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
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Lazily loading notmuch into Emacs

2020-06-01 Thread Sean Whitton
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'

2020-06-01 Thread Sean Whitton
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

2020-05-03 Thread Sean Whitton
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

2020-05-01 Thread Sean Whitton
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]

2020-04-15 Thread Sean Whitton
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]

2020-04-15 Thread Sean Whitton
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

2020-02-29 Thread Sean Whitton
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?

2020-02-21 Thread Sean Whitton
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?

2020-02-20 Thread Sean Whitton
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?

2020-02-19 Thread Sean Whitton
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

2019-11-29 Thread Sean Whitton
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

2019-11-27 Thread Sean Whitton
[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

2019-11-26 Thread Sean Whitton
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

2019-11-26 Thread Sean Whitton
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

2019-11-26 Thread Sean Whitton
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

2019-11-26 Thread Sean Whitton
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

2019-11-21 Thread Sean Whitton
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

2018-07-25 Thread Sean Whitton
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

2018-07-24 Thread Sean Whitton
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

2017-08-10 Thread Sean Whitton
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

2017-08-10 Thread Sean Whitton
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