Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 28A7C431FB6 for ; Thu, 3 May 2012 22:45:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5ZzuiGrHjxU for ; Thu, 3 May 2012 22:45:57 -0700 (PDT) Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 4A36A431FAE for ; Thu, 3 May 2012 22:45:57 -0700 (PDT) Received: from smtp.qmul.ac.uk ([138.37.6.40]) by mail2.qmul.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1SQBKw-0005gj-7U; Fri, 04 May 2012 06:45:50 +0100 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223] helo=localhost) by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SQBKv-0006Ck-TZ; Fri, 04 May 2012 06:45:50 +0100 From: Mark Walters To: Jameson Graef Rollins , Austin Clements Subject: Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags In-Reply-To: <87397jwhjp.fsf@servo.finestructure.net> References: <1335739697-8501-1-git-send-email-markwalters1009@gmail.com> <20120429230220.GO2704@mit.edu> <87397jwhjp.fsf@servo.finestructure.net> User-Agent: Notmuch/0.12+128~g0f26d91 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Fri, 04 May 2012 06:46:08 +0100 Message-ID: <87txzw1otb.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-Host-Address: 94.192.233.223 X-QM-SPAM-Info: Sender has good ham record. :) X-QM-Body-MD5: 754000c4db4c4d91eec510d39f110fa2 (of first 20000 bytes) X-SpamAssassin-Score: -1.8 X-SpamAssassin-SpamBar: - X-SpamAssassin-Report: The QM spam filters have analysed this message to determine if it is spam. We require at least 5.0 points to mark a message as spam. This message scored -1.8 points. Summary of the scoring: * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, * medium trust * [138.37.6.40 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (markwalters1009[at]gmail.com) * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay * domain * 0.5 AWL AWL: From: address is in the auto white-list X-QM-Scan-Virus: ClamAV says the message is clean Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 05:45:58 -0000 On Wed, 02 May 2012, Jameson Graef Rollins wrote: > On Sun, Apr 29 2012, Austin Clements 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. > >> 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. Best wishes Mark