On Fri, 04 May 2012, Mark Walters <markwalters1009@gmail.com> wrote: > On Wed, 02 May 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote: >> On Sun, Apr 29 2012, Austin Clements <amdragon@MIT.EDU> wrote: >>> I haven't really looked at this series yet, but I do have a quick >>> high-level question. Why use separate customization variables for the >>> colors in search and show mode? Wouldn't it make more sense to set >>> the colors just once and use them in both modes? >> >> I thought about this myself as soon as I read the patch. I think I >> would always want the colors to match, so it would make sense to me to >> set them in one place. > > Hi > > I think both are useful (see my reply to Austin) but having show apply > the faces from notmuch-search first seems a good idea. > > There are a couple of extra reasons why I like the show ones > separate. One is that I like to colour headerlines of matching messages to > highlight them, but in search mode that would highlight every > line. Secondly, I colour some things "negatively" in show mode: for > example I show excluded messages in grey. This negative colouring does > not make sense for search mode because I would only want to grey out > results where all messages were excluded not results where at least one > message is excluded. Of course we don't show entirely excluded threads > in search, but similar comments apply to say the "replied" tag: I could > show those in green (on the basis they are "dealt with") but I would not > want a thread coloured green just because I have replied to one message > in it. I completely agree with having separate faces for search and show. >>> BTW, I like how this clearly distinguishes tags and flags. I wonder >>> if we could transition to flags for some information that's current >>> shoe-horned into tags but actually represents immutable information >>> about a message (attachment, signed, and encrypted or so). >> >> Yes! As Austin probably remembers, we've discussed this before. I >> definitely agree that it makes sense to somehow distinguish "immutable" >> information that is a fundamental, unchanging/able property of the >> message, and it might be nice to look ahead to that here. > > In essence I agree: my only concern is can the user search for these > immutable things, and what syntax is used there. Making a separation between immutable properties (like "attachment" or "signed") and tags is a good goal, but AFAICS doing that right requires changes all the way down to the library. I wouldn't worry about it at all here. From emacs UI perspective they're all just tags. This is here now, and works; there's no need to complicate matters when there's nobody doing anything about the plumbing. Fixing this later is a trivial matter compared to the plumbing work in cli and lib. BR, Jani. > > Best wishes > > Mark > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch