[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010, Carl Worth wrote: > That would highlight the current 'a' as out of place since it's > currently archiving every message in the thread. So I'd then fix it to > be 'a' for the current message and "M-a" for every (open) message in the > thread. > > What do people think of that? M-a is bound to (backward-sentence) by default. I personally do not use this shortcut, but I use M-f and M-b frequently. If these shortcuts will be replaced by some notmuch commands following the same logic, I'd not be happy. -Michal
[PATCH 0/4] Maildir synchronization
On Wed, 09 Jun 2010 19:52:42 +0100, Matt Fleming wrote: > On Tue, 11 May 2010 14:14:17 +0200, Michal Sojka > wrote: > > Hi, > > > > these patches implement synchronization between maildir flags and > > notmuch tags. The synchronization can be configured to not happen at > > all (default), to set/unset tags when importing new (or new and > > renamed) messages and to happen in both directions - set/unset tags > > during importing and change maildir flags during tagging. > > I finally got around to testing these patches and I think they're great! > It would be fantastic if these could be merged into the main notmuch > tree. I've been using them for a while as well and love the feature, but I keep running into situations where notmuch seems to get out of sync regarding file names on disk. I haven't done a lot of searching on what exactly causes this - but the symptom is that you'll open a message, read it and then try to do something on it (like, save an attachment) and suddenly are told that the message file on disk can't be found. Or that you reply to a message and just as you are trying to send the reply things fail for the same reason. Next time this happens I'll take a closer look at the filenames displayed to see what's going on. /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH 0/4] Maildir synchronization
On Tue, 11 May 2010 14:14:17 +0200, Michal Sojka wrote: > Hi, > > these patches implement synchronization between maildir flags and > notmuch tags. The synchronization can be configured to not happen at > all (default), to set/unset tags when importing new (or new and > renamed) messages and to happen in both directions - set/unset tags > during importing and change maildir flags during tagging. I finally got around to testing these patches and I think they're great! It would be fantastic if these could be merged into the main notmuch tree. FWIW, I've been using some elisp to emulate the behaviour of these patches ever since I started using notmuch - it's a necessity for my workflow. Your patches provide a much more complete solution than the bit of elisp I hacked up so I'll be using these from now on.
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 13:29:46 -0400, Jameson Rollins wrote: > I'm advocating that *only* the "unread" tag ever be automatically > removed in the emacs UI when doing anything other than explicitly > removing tags (eg. like just opening a message for viewing, or browsing > through a thread, etc.). All other tags should only ever be explicitly > modified by the user. Understood. Presumably the automatic tag addition would also remain. > If users want to have special tag manipulation procedures to match their > needs, then they can easily build the needed functions and bind them to > whichever keys they wish. In general I'd agree. The 'advance-and-archive' case is different, because it's behaviour is bound up in the logic of the function. It's not easy to just add that in on top with a simple key binding. In any case, I don't care enough to argue more. Go for it. dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/0ef69d9c/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins wrote: > I would like to push it back the other way. Having specific tags > modified by specific commands is something particular to individual > users. If a user wants to do something special, they can make their own > function to do that. You're advocating that no tags are automatically added or removed? dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/d87c9d2d/attachment-0001.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins wrote: > The function to advance through threads with the space bar is useful. > However, the current implementation also archives messages. The idea > of archiving a message should not be intertwined with the processes of > advancing through messages to read them. Archiving in general should > be a separate operation that one does explicitly. This patch just > renames the advance function "notmuch-show-advance", and removes the > archiving of a thread when the end of the thread is reached. This is great, but what if I want the current behaviour? dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/bc9e4738/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:20:47 -0700, Dirk Hohndel wrote: > On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth wrote: > > That would highlight the current 'a' as out of place since it's > > currently archiving every message in the thread. So I'd then fix it to > > be 'a' for the current message and "M-a" for every (open) message in the > > thread. > > I really like this. It's consistent and I'm sure I'll get used to it > quickly. The only question now is "all messages in a thread" or "all > open messages in a thread". I'd vote for all. I actually vote for the behavior Carl suggests. The behavior of archiving the entire thread can be done by popping out to the search and applying notmuch-search-archive-thread to the thread with: (define-key notmuch-search-mode-map "a" 'notmuch-search-archive-thread) jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/284a41ca/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth wrote:
> Meanwhile, I'm currently working on support for piping a whole thread of
> messages as an mbox to a process, (mostly getting bogged down in trying
> to fix mbox support in git).
>
> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
>
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
>
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.
>
> What do people think of that?
I think it's definitely the right way to go. I actually rebound my keys
to do that long ago.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100609/d3866f39/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On 9 June 2010 14:20, Dirk Hohndel wrote: [...] > Oh - and I really want a way to do surgery on threads. Merge threads to > fix Blackberry users breaking threads. And split threads for > hijackers... I remember this being mentioned by Carl in the list some time ago, it would be a great feature to have. Servilio
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:54:57 -0700, Carl Worth wrote: > On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins finestructure.net> wrote: > > I actually submitted this patch because there was noise on #notmuch > > about people (including from cworth) not liking the default behavior > > where the "inbox" tag is removed by the advance function. > > For the record, I wrote the current behavior for my own use, so I've > been pretty happy with it. I'm still not understanding the usage pattern here. Do you really want to archive all threads after you've read them? If so, what's the difference between the "unread" and "inbox" tags in your work flow? dme's response was "if I don't want the message archived, then I hit 'q' instead of ' '". But it seems to make more sense to me to say "if I want the message archived, I just hit 'a'". > I suppose one option here would be a customizable variable that controls > what happens when trying to advance "past" the last message, (do > nothing, advance to next thread, archive current thread and advance to > next thread)? We could, but I think it adds a lot of unnecessary complication. I wonder if there's not a better way to handle the flow that you guys are advocating, rather than using notmuch-show-advance-and-archive. But I have a stop-gap solution. What if we provide both notmuch-show-advance and notmuch-show-advance-and-archive, with the default being notmuch-show-advance? That way, if folks want to use the old behavior, they can just set (define-key notmuch-show-mode-map " " 'notmuch-show-advance-and-archive) in their emacs config file. If people agree on that solution, then I can submit a revamped patch. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/ecd9472d/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On 9 June 2010 13:54, Carl Worth wrote: [...] > But I have seen enough people complain about it that I've been convinced > that something is wrong about it. I'm not yet sure what the right answer > is. But if we at least have separate commands for separate actions, then > hopefully it wouldn't be too difficult for users to combine those > actions. > > When we have one command that does several different things, then it's > much harder for users to tweak. > > I suppose one option here would be a customizable variable that controls > what happens when trying to advance "past" the last message, (do > nothing, advance to next thread, archive current thread and advance to > next thread)? Or hooks. If that is not possible, I prefer small functions I can combine when personalizing the key bindings. Servilio
[PATCH] remove message archiving from show-advance-and-archive
On 9 June 2010 13:50, Carl Worth wrote: [...] > Which makes me think that other operations should work similarly. '+' > and '-' should change tags on the current message (as they do currently) > and then new "M-+" and "M--" could change tags on all (open) messages in > the thread. > > That would highlight the current 'a' as out of place since it's > currently archiving every message in the thread. So I'd then fix it to > be 'a' for the current message and "M-a" for every (open) message in the > thread. > > What do people think of that? +2 I think this would be awesome. I am using "-" a lot to remove the "inbox" tag to individual messages. Servilio
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 18:18:42 +0100, David Edmondson wrote: > On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins finestructure.net> wrote: > > I would like to push it back the other way. Having specific tags > > modified by specific commands is something particular to individual > > users. If a user wants to do something special, they can make their own > > function to do that. > > You're advocating that no tags are automatically added or removed? I'm advocating that *only* the "unread" tag ever be automatically removed in the emacs UI when doing anything other than explicitly removing tags (eg. like just opening a message for viewing, or browsing through a thread, etc.). All other tags should only ever be explicitly modified by the user. I don't have any problem keys being bound to specific tag modification operations, though, like having the 'd' key add the "delete" tag to a message or thread, or the 'a' key remove the "inbox" tag, etc. If users want to have special tag manipulation procedures to match their needs, then they can easily build the needed functions and bind them to whichever keys they wish. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/da07a529/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 15:20:21 -0400, Jameson Rollins wrote:
> On Wed, 09 Jun 2010 11:20:47 -0700, Dirk Hohndel
> wrote:
> > On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth wrote:
> > I really like this. It's consistent and I'm sure I'll get used to it
> > quickly. The only question now is "all messages in a thread" or "all
> > open messages in a thread". I'd vote for all.
I have situations in which I want either one. The advantage of doing
"all open messages" is that it's easy to get the "all messages" behavior
by way of an existing command that's already useful in its own right,
("open all messages").
And I think "all open messages" is actually the right default as
well. If I do a focused search and end up reading one message that
matched the search, then archiving away that message and not others that
just happen to be in the same thread.
> I actually vote for the behavior Carl suggests. The behavior of
> archiving the entire thread can be done by popping out to the search and
> applying notmuch-search-archive-thread to the thread with:
>
> (define-key notmuch-search-mode-map "a" 'notmuch-search-archive-thread)
Or not. ;-)
I actually want to also fix the search mode commands like this to only
operate on messages that matched the (original search).
We had behavior that limited these commands to matching messages once,
but that was broken because it re-ran the search to find the list. So
that led to behavior like:
-inbox # archive all messages in the thread
Then if the user realized that was a mistake, trying:
+inbox # new search now matches nothing, so no effect
Our stop-gap solution here was to re-run a search with fewer
restrictions if the first search returned an empty list.
The correct solution is to remember the list of messages that matched
the first time and always operate on those. That will fix the above
problem and also avoid the race condition that can currently happen if
notmuch new is being run asynchronously from emacs. (The race is that
the user can thing he's archiving a thread with a single message but can
actually archive many messages that arrived since the original search
because the 'a' command is re-running the search.)
-Carl
--
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100609/dda84d44/attachment-0001.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 16:36:53 +0100, David Edmondson wrote:
> They are clearly different. If I read a thread with 'space' the 'unread'
> tag is removed from the messages as I pass them by. I can then 'q' from
> the thread and the messages are not archived ('inbox' is not removed),
> but they are no longer 'unread'.
But it's not necessarily clear that you've reached the end of a thread,
which means it's somewhat indeterministic if the "inbox" tag is removed
or not. If users have to explicitly remove all tags other than
"unread", then this gets rid of this problem all together.
> Maybe you could submit a patch which allows a user to choose the
> behaviour with a customisation variable? (Though I'd expect the value of
> that variable to preserve backward compatible behaviour until Carl says
> otherwise.)
I actually submitted this patch because there was noise on #notmuch
about people (including from cworth) not liking the default behavior
where the "inbox" tag is removed by the advance function.
I would like to push it back the other way. Having specific tags
modified by specific commands is something particular to individual
users. If a user wants to do something special, they can make their own
function to do that.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100609/64417a32/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson wrote: > On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins finestructure.net> wrote: > > The function to advance through threads with the space bar is useful. > > However, the current implementation also archives messages. The idea > > of archiving a message should not be intertwined with the processes of > > advancing through messages to read them. Archiving in general should > > be a separate operation that one does explicitly. This patch just > > renames the advance function "notmuch-show-advance", and removes the > > archiving of a thread when the end of the thread is reached. > > This is great, but what if I want the current behaviour? Well, you could do like I do now, and write a function that does what you want and bind it to whatever key you want. But I really don't think the current behavior should be the default. The current behavior completely mixes the meaning of "unread" and "inbox". If there is no difference between the meaning of those tags, then why have separate tags for them? I think we've done some good work in making the "unread" tag correspond reasonably well to actually viewing a message. We have lots of good automatic removal of that tag when messages are viewed. But I really feel strongly that "unread" is the *only* tag that we should be handling in an automated way like that. We should really leave it to the user to handle all other tags explicitly how they see fit. I certainly don't want every message I read automatically removed from my inbox. If you feel really strongly about this in the other direction, I would like to understand why. If we can't resolve, then maybe a vote? jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/ed7801f3/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth wrote:
> On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins finestructure.net> wrote:
> > The function to advance through threads with the space bar is useful.
> > However, the current implementation also archives messages. The idea
> > of archiving a message should not be intertwined with the processes of
> > advancing through messages to read them. Archiving in general should
> > be a separate operation that one does explicitly. This patch just
> > renames the advance function "notmuch-show-advance", and removes the
> > archiving of a thread when the end of the thread is reached.
>
> The other piece of the magic space bar that people have complained about
> is that it intertwines advancing among messages within one thread with
> advancing from one thread to the next. (And only the first operation is
> reversible by backspace.)
This has always confused me - I think I've complained about it before as
well :)
> I think we'll probably want to change that at the same time.
>
> Meanwhile, I'm currently working on support for piping a whole thread of
> messages as an mbox to a process, (mostly getting bogged down in trying
> to fix mbox support in git).
>
> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
>
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
>
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.
I really like this. It's consistent and I'm sure I'll get used to it
quickly. The only question now is "all messages in a thread" or "all
open messages in a thread". I'd vote for all.
Oh - and I really want a way to do surgery on threads. Merge threads to
fix Blackberry users breaking threads. And split threads for
hijackers...
/D
--
Dirk Hohndel
Intel Open Source Technology Center
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins wrote: > I actually submitted this patch because there was noise on #notmuch > about people (including from cworth) not liking the default behavior > where the "inbox" tag is removed by the advance function. For the record, I wrote the current behavior for my own use, so I've been pretty happy with it. But I have seen enough people complain about it that I've been convinced that something is wrong about it. I'm not yet sure what the right answer is. But if we at least have separate commands for separate actions, then hopefully it wouldn't be too difficult for users to combine those actions. When we have one command that does several different things, then it's much harder for users to tweak. I suppose one option here would be a customizable variable that controls what happens when trying to advance "past" the last message, (do nothing, advance to next thread, archive current thread and advance to next thread)? -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/c829b424/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins wrote:
> The function to advance through threads with the space bar is useful.
> However, the current implementation also archives messages. The idea
> of archiving a message should not be intertwined with the processes of
> advancing through messages to read them. Archiving in general should
> be a separate operation that one does explicitly. This patch just
> renames the advance function "notmuch-show-advance", and removes the
> archiving of a thread when the end of the thread is reached.
The other piece of the magic space bar that people have complained about
is that it intertwines advancing among messages within one thread with
advancing from one thread to the next. (And only the first operation is
reversible by backspace.)
I think we'll probably want to change that at the same time.
Meanwhile, I'm currently working on support for piping a whole thread of
messages as an mbox to a process, (mostly getting bogged down in trying
to fix mbox support in git).
For that, I think I want the current '|' binding to pipe the current
message and then a new binding ("M-|" ?) to pipe every (open) message in
the thread.
Which makes me think that other operations should work similarly. '+'
and '-' should change tags on the current message (as they do currently)
and then new "M-+" and "M--" could change tags on all (open) messages in
the thread.
That would highlight the current 'a' as out of place since it's
currently archiving every message in the thread. So I'd then fix it to
be 'a' for the current message and "M-a" for every (open) message in the
thread.
What do people think of that?
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100609/2e73b693/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function "notmuch-show-advance", and removes the archiving of a thread when the end of the thread is reached. --- emacs/notmuch-show.el | 27 +++ 1 files changed, 11 insertions(+), 16 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index f872cdf..b0c1f63 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -579,7 +579,7 @@ function is used. " (define-key map "n" 'notmuch-show-next-open-message) (define-key map "p" 'notmuch-show-previous-open-message) (define-key map (kbd "DEL") 'notmuch-show-rewind) - (define-key map " " 'notmuch-show-advance-and-archive) + (define-key map " " 'notmuch-show-advance) (define-key map (kbd "M-RET") 'notmuch-show-open-or-close-all) (define-key map (kbd "RET") 'notmuch-show-toggle-message) map) @@ -601,7 +601,7 @@ which \\[notmuch-show-next-button] and \\[notmuch-show-previous-button] are helpful). Reading the thread sequentially is well-supported by pressing -\\[notmuch-show-advance-and-archive]. This will scroll the +\\[notmuch-show-advance]. This will scroll the current message (if necessary), advance to the next message, or advance to the next thread (if already on the last message of a thread). @@ -611,7 +611,7 @@ more selectively, (such as '\\[notmuch-show-next-message]' and '\\[notmuch-show-previous-message]' to advance to messages without removing any tags, and '\\[notmuch-show-archive-thread]' to archive an entire thread without scrolling through with -\\[notmuch-show-advance-and-archive]). +\\[notmuch-show-advance]). You can add or remove arbitary tags from the current message with '\\[notmuch-show-add-tag]' or '\\[notmuch-show-remove-tag]'. @@ -780,8 +780,8 @@ All currently available key bindings: ;; Commands typically bound to keys. -(defun notmuch-show-advance-and-archive () - "Advance through thread and archive. +(defun notmuch-show-advance () + "Advance through threads. This command is intended to be one of the simplest ways to process a thread of email. It does the following: @@ -793,10 +793,9 @@ Otherwise, (the end of the current message is already within the current window), advance to the next open message. Finally, if there is no further message to advance to, and this -last message is already read, then archive the entire current -thread, (remove the \"inbox\" tag from each message). Also kill -this buffer, and display the next thread from the search from -which this thread was originally shown." +last message is already read. Also kill this buffer, and display +the next thread from the search from which this thread was +originally shown." (interactive) (let ((end-of-this-message (notmuch-show-message-bottom))) (cond @@ -814,14 +813,10 @@ which this thread was originally shown." ((not (= end-of-this-message (point-max))) ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - archive the thread. - (notmuch-show-archive-thread) + (notmuch-show-next-open-message) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance]). Specifically, if the beginning of the previous email is fewer than `window-height' lines from the current point, move to it @@ -831,7 +826,7 @@ Otherwise, just scroll down a screenful of the current message. This command does not modify any message tags, (it does not undo any effects from previous calls to -`notmuch-show-advance-and-archive'." +`notmuch-show-advance'." (interactive) (let ((start-of-message (notmuch-show-message-top)) (start-of-window (window-start))) -- 1.7.1 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100609/f91e1322/attachment.pgp>
fix problem with notmuch-hello-nice-number
Without this little patch notmuch fails with current git if there's a saved search that has zero results diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index f5d061b..7c32f7c 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -112,6 +112,8 @@ Typically \",\" in the US and UK and \".\" in Europe." (defun notmuch-hello-nice-number (n) (let (result) +(if (= n 0) + (push 0 result)) (while (> n 0) (push (% n 1000) result) (setq n (/ n 1000))) -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] remove message archiving from show-advance-and-archive
The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function notmuch-show-advance, and removes the archiving of a thread when the end of the thread is reached. --- emacs/notmuch-show.el | 27 +++ 1 files changed, 11 insertions(+), 16 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index f872cdf..b0c1f63 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -579,7 +579,7 @@ function is used. (define-key map n 'notmuch-show-next-open-message) (define-key map p 'notmuch-show-previous-open-message) (define-key map (kbd DEL) 'notmuch-show-rewind) - (define-key map 'notmuch-show-advance-and-archive) + (define-key map 'notmuch-show-advance) (define-key map (kbd M-RET) 'notmuch-show-open-or-close-all) (define-key map (kbd RET) 'notmuch-show-toggle-message) map) @@ -601,7 +601,7 @@ which \\[notmuch-show-next-button] and \\[notmuch-show-previous-button] are helpful). Reading the thread sequentially is well-supported by pressing -\\[notmuch-show-advance-and-archive]. This will scroll the +\\[notmuch-show-advance]. This will scroll the current message (if necessary), advance to the next message, or advance to the next thread (if already on the last message of a thread). @@ -611,7 +611,7 @@ more selectively, (such as '\\[notmuch-show-next-message]' and '\\[notmuch-show-previous-message]' to advance to messages without removing any tags, and '\\[notmuch-show-archive-thread]' to archive an entire thread without scrolling through with -\\[notmuch-show-advance-and-archive]). +\\[notmuch-show-advance]). You can add or remove arbitary tags from the current message with '\\[notmuch-show-add-tag]' or '\\[notmuch-show-remove-tag]'. @@ -780,8 +780,8 @@ All currently available key bindings: ;; Commands typically bound to keys. -(defun notmuch-show-advance-and-archive () - Advance through thread and archive. +(defun notmuch-show-advance () + Advance through threads. This command is intended to be one of the simplest ways to process a thread of email. It does the following: @@ -793,10 +793,9 @@ Otherwise, (the end of the current message is already within the current window), advance to the next open message. Finally, if there is no further message to advance to, and this -last message is already read, then archive the entire current -thread, (remove the \inbox\ tag from each message). Also kill -this buffer, and display the next thread from the search from -which this thread was originally shown. +last message is already read. Also kill this buffer, and display +the next thread from the search from which this thread was +originally shown. (interactive) (let ((end-of-this-message (notmuch-show-message-bottom))) (cond @@ -814,14 +813,10 @@ which this thread was originally shown. ((not (= end-of-this-message (point-max))) ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - archive the thread. - (notmuch-show-archive-thread) + (notmuch-show-next-open-message) (defun notmuch-show-rewind () - Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance]). Specifically, if the beginning of the previous email is fewer than `window-height' lines from the current point, move to it @@ -831,7 +826,7 @@ Otherwise, just scroll down a screenful of the current message. This command does not modify any message tags, (it does not undo any effects from previous calls to -`notmuch-show-advance-and-archive'. +`notmuch-show-advance'. (interactive) (let ((start-of-message (notmuch-show-message-top)) (start-of-window (window-start))) -- 1.7.1 pgpvqKzAi4ykF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins jroll...@finestructure.net wrote: The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function notmuch-show-advance, and removes the archiving of a thread when the end of the thread is reached. This is great, but what if I want the current behaviour? dme. -- David Edmondson, http://dme.org pgpQgK6cUKSLR.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson d...@dme.org wrote: On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins jroll...@finestructure.net wrote: The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function notmuch-show-advance, and removes the archiving of a thread when the end of the thread is reached. This is great, but what if I want the current behaviour? Well, you could do like I do now, and write a function that does what you want and bind it to whatever key you want. But I really don't think the current behavior should be the default. The current behavior completely mixes the meaning of unread and inbox. If there is no difference between the meaning of those tags, then why have separate tags for them? I think we've done some good work in making the unread tag correspond reasonably well to actually viewing a message. We have lots of good automatic removal of that tag when messages are viewed. But I really feel strongly that unread is the *only* tag that we should be handling in an automated way like that. We should really leave it to the user to handle all other tags explicitly how they see fit. I certainly don't want every message I read automatically removed from my inbox. If you feel really strongly about this in the other direction, I would like to understand why. If we can't resolve, then maybe a vote? jamie. pgpzR6BG6vnFV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:25:04 -0400, Jameson Rollins
jroll...@finestructure.net wrote:
On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson d...@dme.org wrote:
On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins
jroll...@finestructure.net wrote:
The function to advance through threads with the space bar is useful.
However, the current implementation also archives messages. The idea
of archiving a message should not be intertwined with the processes of
advancing through messages to read them. Archiving in general should
be a separate operation that one does explicitly. This patch just
renames the advance function notmuch-show-advance, and removes the
archiving of a thread when the end of the thread is reached.
This is great, but what if I want the current behaviour?
Well, you could do like I do now, and write a function that does what
you want and bind it to whatever key you want. But I really don't think
the current behavior should be the default.
I'm not overly worried about the default behaviour, just with what
behaviour is easily available.
The current behavior completely mixes the meaning of unread and
inbox. If there is no difference between the meaning of those tags,
then why have separate tags for them?
They are clearly different. If I read a thread with 'space' the 'unread'
tag is removed from the messages as I pass them by. I can then 'q' from
the thread and the messages are not archived ('inbox' is not removed),
but they are no longer 'unread'.
I think we've done some good work in making the unread tag correspond
reasonably well to actually viewing a message. We have lots of good
automatic removal of that tag when messages are viewed. But I really
feel strongly that unread is the *only* tag that we should be handling
in an automated way like that. We should really leave it to the user to
handle all other tags explicitly how they see fit. I certainly don't
want every message I read automatically removed from my inbox.
If you feel really strongly about this in the other direction, I would
like to understand why. If we can't resolve, then maybe a vote?
Maybe you could submit a patch which allows a user to choose the
behaviour with a customisation variable? (Though I'd expect the value of
that variable to preserve backward compatible behaviour until Carl says
otherwise.)
dme.
--
David Edmondson, http://dme.org
pgp1O5bBtekxb.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 16:36:53 +0100, David Edmondson d...@dme.org wrote:
They are clearly different. If I read a thread with 'space' the 'unread'
tag is removed from the messages as I pass them by. I can then 'q' from
the thread and the messages are not archived ('inbox' is not removed),
but they are no longer 'unread'.
But it's not necessarily clear that you've reached the end of a thread,
which means it's somewhat indeterministic if the inbox tag is removed
or not. If users have to explicitly remove all tags other than
unread, then this gets rid of this problem all together.
Maybe you could submit a patch which allows a user to choose the
behaviour with a customisation variable? (Though I'd expect the value of
that variable to preserve backward compatible behaviour until Carl says
otherwise.)
I actually submitted this patch because there was noise on #notmuch
about people (including from cworth) not liking the default behavior
where the inbox tag is removed by the advance function.
I would like to push it back the other way. Having specific tags
modified by specific commands is something particular to individual
users. If a user wants to do something special, they can make their own
function to do that.
jamie.
pgpiNreturwG2.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins jroll...@finestructure.net wrote: I would like to push it back the other way. Having specific tags modified by specific commands is something particular to individual users. If a user wants to do something special, they can make their own function to do that. You're advocating that no tags are automatically added or removed? dme. -- David Edmondson, http://dme.org pgpknjhzYkeEB.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 18:18:42 +0100, David Edmondson d...@dme.org wrote: On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins jroll...@finestructure.net wrote: I would like to push it back the other way. Having specific tags modified by specific commands is something particular to individual users. If a user wants to do something special, they can make their own function to do that. You're advocating that no tags are automatically added or removed? I'm advocating that *only* the unread tag ever be automatically removed in the emacs UI when doing anything other than explicitly removing tags (eg. like just opening a message for viewing, or browsing through a thread, etc.). All other tags should only ever be explicitly modified by the user. I don't have any problem keys being bound to specific tag modification operations, though, like having the 'd' key add the delete tag to a message or thread, or the 'a' key remove the inbox tag, etc. If users want to have special tag manipulation procedures to match their needs, then they can easily build the needed functions and bind them to whichever keys they wish. jamie. pgp24bEykqrYu.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins jroll...@finestructure.net wrote: The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function notmuch-show-advance, and removes the archiving of a thread when the end of the thread is reached. The other piece of the magic space bar that people have complained about is that it intertwines advancing among messages within one thread with advancing from one thread to the next. (And only the first operation is reversible by backspace.) I think we'll probably want to change that at the same time. Meanwhile, I'm currently working on support for piping a whole thread of messages as an mbox to a process, (mostly getting bogged down in trying to fix mbox support in git). For that, I think I want the current '|' binding to pipe the current message and then a new binding (M-| ?) to pipe every (open) message in the thread. Which makes me think that other operations should work similarly. '+' and '-' should change tags on the current message (as they do currently) and then new M-+ and M-- could change tags on all (open) messages in the thread. That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. What do people think of that? -Carl pgp1w4e8esEDs.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins jroll...@finestructure.net wrote: I actually submitted this patch because there was noise on #notmuch about people (including from cworth) not liking the default behavior where the inbox tag is removed by the advance function. For the record, I wrote the current behavior for my own use, so I've been pretty happy with it. But I have seen enough people complain about it that I've been convinced that something is wrong about it. I'm not yet sure what the right answer is. But if we at least have separate commands for separate actions, then hopefully it wouldn't be too difficult for users to combine those actions. When we have one command that does several different things, then it's much harder for users to tweak. I suppose one option here would be a customizable variable that controls what happens when trying to advance past the last message, (do nothing, advance to next thread, archive current thread and advance to next thread)? -Carl -- carl.d.wo...@intel.com pgpn8bjB6qMwY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth cwo...@cworth.org wrote: On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins jroll...@finestructure.net wrote: The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function notmuch-show-advance, and removes the archiving of a thread when the end of the thread is reached. The other piece of the magic space bar that people have complained about is that it intertwines advancing among messages within one thread with advancing from one thread to the next. (And only the first operation is reversible by backspace.) This has always confused me - I think I've complained about it before as well :) I think we'll probably want to change that at the same time. Meanwhile, I'm currently working on support for piping a whole thread of messages as an mbox to a process, (mostly getting bogged down in trying to fix mbox support in git). For that, I think I want the current '|' binding to pipe the current message and then a new binding (M-| ?) to pipe every (open) message in the thread. Which makes me think that other operations should work similarly. '+' and '-' should change tags on the current message (as they do currently) and then new M-+ and M-- could change tags on all (open) messages in the thread. That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. I really like this. It's consistent and I'm sure I'll get used to it quickly. The only question now is all messages in a thread or all open messages in a thread. I'd vote for all. Oh - and I really want a way to do surgery on threads. Merge threads to fix Blackberry users breaking threads. And split threads for hijackers... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Maildir synchronization
On Tue, 11 May 2010 14:14:17 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: Hi, these patches implement synchronization between maildir flags and notmuch tags. The synchronization can be configured to not happen at all (default), to set/unset tags when importing new (or new and renamed) messages and to happen in both directions - set/unset tags during importing and change maildir flags during tagging. I finally got around to testing these patches and I think they're great! It would be fantastic if these could be merged into the main notmuch tree. FWIW, I've been using some elisp to emulate the behaviour of these patches ever since I started using notmuch - it's a necessity for my workflow. Your patches provide a much more complete solution than the bit of elisp I hacked up so I'll be using these from now on. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On 9 June 2010 13:50, Carl Worth cwo...@cworth.org wrote: [...] Which makes me think that other operations should work similarly. '+' and '-' should change tags on the current message (as they do currently) and then new M-+ and M-- could change tags on all (open) messages in the thread. That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. What do people think of that? +2 I think this would be awesome. I am using - a lot to remove the inbox tag to individual messages. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On 9 June 2010 13:54, Carl Worth cwo...@cworth.org wrote: [...] But I have seen enough people complain about it that I've been convinced that something is wrong about it. I'm not yet sure what the right answer is. But if we at least have separate commands for separate actions, then hopefully it wouldn't be too difficult for users to combine those actions. When we have one command that does several different things, then it's much harder for users to tweak. I suppose one option here would be a customizable variable that controls what happens when trying to advance past the last message, (do nothing, advance to next thread, archive current thread and advance to next thread)? Or hooks. If that is not possible, I prefer small functions I can combine when personalizing the key bindings. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:54:57 -0700, Carl Worth cwo...@cworth.org wrote: On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins jroll...@finestructure.net wrote: I actually submitted this patch because there was noise on #notmuch about people (including from cworth) not liking the default behavior where the inbox tag is removed by the advance function. For the record, I wrote the current behavior for my own use, so I've been pretty happy with it. I'm still not understanding the usage pattern here. Do you really want to archive all threads after you've read them? If so, what's the difference between the unread and inbox tags in your work flow? dme's response was if I don't want the message archived, then I hit 'q' instead of ' '. But it seems to make more sense to me to say if I want the message archived, I just hit 'a'. I suppose one option here would be a customizable variable that controls what happens when trying to advance past the last message, (do nothing, advance to next thread, archive current thread and advance to next thread)? We could, but I think it adds a lot of unnecessary complication. I wonder if there's not a better way to handle the flow that you guys are advocating, rather than using notmuch-show-advance-and-archive. But I have a stop-gap solution. What if we provide both notmuch-show-advance and notmuch-show-advance-and-archive, with the default being notmuch-show-advance? That way, if folks want to use the old behavior, they can just set (define-key notmuch-show-mode-map 'notmuch-show-advance-and-archive) in their emacs config file. If people agree on that solution, then I can submit a revamped patch. jamie. pgpeCXEBQGKAF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On 9 June 2010 14:20, Dirk Hohndel hohn...@infradead.org wrote: [...] Oh - and I really want a way to do surgery on threads. Merge threads to fix Blackberry users breaking threads. And split threads for hijackers... I remember this being mentioned by Carl in the list some time ago, it would be a great feature to have. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth cwo...@cworth.org wrote: Meanwhile, I'm currently working on support for piping a whole thread of messages as an mbox to a process, (mostly getting bogged down in trying to fix mbox support in git). For that, I think I want the current '|' binding to pipe the current message and then a new binding (M-| ?) to pipe every (open) message in the thread. Which makes me think that other operations should work similarly. '+' and '-' should change tags on the current message (as they do currently) and then new M-+ and M-- could change tags on all (open) messages in the thread. That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. What do people think of that? I think it's definitely the right way to go. I actually rebound my keys to do that long ago. jamie. pgpsltAnbPctE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 11:20:47 -0700, Dirk Hohndel hohn...@infradead.org wrote: On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth cwo...@cworth.org wrote: That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. I really like this. It's consistent and I'm sure I'll get used to it quickly. The only question now is all messages in a thread or all open messages in a thread. I'd vote for all. I actually vote for the behavior Carl suggests. The behavior of archiving the entire thread can be done by popping out to the search and applying notmuch-search-archive-thread to the thread with: (define-key notmuch-search-mode-map a 'notmuch-search-archive-thread) jamie. pgpZfuU8XsqB5.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 15:20:21 -0400, Jameson Rollins jroll...@finestructure.net wrote: On Wed, 09 Jun 2010 11:20:47 -0700, Dirk Hohndel hohn...@infradead.org wrote: On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth cwo...@cworth.org wrote: I really like this. It's consistent and I'm sure I'll get used to it quickly. The only question now is all messages in a thread or all open messages in a thread. I'd vote for all. I have situations in which I want either one. The advantage of doing all open messages is that it's easy to get the all messages behavior by way of an existing command that's already useful in its own right, (open all messages). And I think all open messages is actually the right default as well. If I do a focused search and end up reading one message that matched the search, then archiving away that message and not others that just happen to be in the same thread. I actually vote for the behavior Carl suggests. The behavior of archiving the entire thread can be done by popping out to the search and applying notmuch-search-archive-thread to the thread with: (define-key notmuch-search-mode-map a 'notmuch-search-archive-thread) Or not. ;-) I actually want to also fix the search mode commands like this to only operate on messages that matched the (original search). We had behavior that limited these commands to matching messages once, but that was broken because it re-ran the search to find the list. So that led to behavior like: -inbox # archive all messages in the thread Then if the user realized that was a mistake, trying: +inbox # new search now matches nothing, so no effect Our stop-gap solution here was to re-run a search with fewer restrictions if the first search returned an empty list. The correct solution is to remember the list of messages that matched the first time and always operate on those. That will fix the above problem and also avoid the race condition that can currently happen if notmuch new is being run asynchronously from emacs. (The race is that the user can thing he's archiving a thread with a single message but can actually archive many messages that arrived since the original search because the 'a' command is re-running the search.) -Carl -- carl.d.wo...@intel.com pgpfUHVKjY9E9.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
