On Wed, 09 Jun 2010 11:25:04 -0400, Jameson Rollins <jrollins@finestructure.net> wrote: > On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson <dme@dme.org> wrote: > > On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@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