Re: [PATCH] v2 emacs: colorize buttonized 'id:' links depending on the target message's state

Subject: Re: [PATCH] v2 emacs: colorize buttonized 'id:' links depending on the target message's state

Date: Wed, 18 Jan 2012 11:08:54 +0100

To: Aaron Ecay, David Edmondson, Jameson Graef Rollins

Cc: Notmuch Mail

From: Pieter Praet


On Mon, 16 Jan 2012 16:43:06 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:
> On Mon, 16 Jan 2012 17:57:33 +0100, Pieter Praet <pieter@praet.org> wrote:
> > * emacs/notmuch-show.el (notmuch-show-buttonized-link-colors):
> >   new defcustom, allows toggling colorization of buttonized links.
> > 
> > * emacs/notmuch-show.el (notmuch-show-buttonized-link-present),
> > * emacs/notmuch-show.el (notmuch-show-buttonized-link-present-and-unread),
> > * emacs/notmuch-show.el (notmuch-show-buttonized-link-missing):
> >   new faces for buttonized id: links.
> > 
> > * emacs/notmuch-show.el (notmuch-show-found-target-p): add optional arg
> >   VERIFY-UNREAD which causes results to be filtered by "tag:unread".
> > 
> > * emacs/notmuch-show.el (notmuch-show-buttonize-links): use different
> >   face property depending on the result of `notmuch-show-found-target-p',
> >   causing buttons to available, available-and-unread and missing messages
> >   to be displayed in a different color.
> 
> I really like the idea behind this patch, but it has the very small
> problem that it colorizes too much.  So in reading this thread, there
> are things like “id:’s” and “id:?” that get colored the missing-message
> color (a very angry red, by default).  Though this isn’t likely to be a
> very frequent problem with email messages that are not on this listserv
> :), it would be nice to fix it.  [...]

Excellent suggestion!

Amended patch follows.

> [...] Maybe you could change the regex that
> matches id:’s to require a little more structure – an at-sign, perhaps.
> Or even requiring more than (say) 5 non-space characters after the
> message id would cut down sharply on the false positive rate.
> 

Not sure how that would pan out.  It's fairly common behaviour to put
one or more spaces after a inline Message-Id, so I don't think such a
limitation would be warmly recepted.

> -- 
> Aaron Ecay


Peace

-- 
Pieter

Thread: