[Patch v2 0/3] emacs: allow show to colour based on tags and flags

Jani Nikula jani at nikula.org
Sat May 5 04:57:29 PDT 2012


On Fri, 04 May 2012, Mark Walters <markwalters1009 at gmail.com> wrote:
> On Wed, 02 May 2012, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
>> On Sun, Apr 29 2012, Austin Clements <amdragon at 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 at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


More information about the notmuch mailing list