[PATCH] emacs: Re-work the implementation of highlighting in notmuch-search-mode.
Re-write `notmuch-search-color-line', with the following improvements: - create overlays only if they will be needed, - merge the properties specified for a tag on top of any matching a previous tag. --- emacs/notmuch.el | 37 + 1 files changed, 21 insertions(+), 16 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 10babe4..ac1da34 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -585,28 +585,33 @@ This function advances the next thread when finished." Here is an example of how to color search results based on tags. (the following text would be placed in your ~/.emacs file): - (setq notmuch-search-line-faces '((\"delete\" . '(:foreground \"red\")) + (setq notmuch-search-line-faces '((\"delete\" . '(:foreground \"red\" + :background \"blue\")) (\"unread\" . '(:foreground \"green\" -Order matters: for lines with multiple tags, the the first -matching will be applied." +The attributes defined for matching tags are merged, with later +attributes overriding earlier. A message having both \"delete\" +and \"unread\" tags with the above settings would have a green +foreground and blue background." :type '(alist :key-type (string) :value-type (list)) :group 'notmuch) (defun notmuch-search-color-line (start end line-tag-list) - "Colorize lines in notmuch-show based on tags" - (if notmuch-search-line-faces - (let ((overlay (make-overlay start end)) - (tags-faces (copy-alist notmuch-search-line-faces))) - (while tags-faces - (let* ((tag-face (car tags-faces)) -(tag (car tag-face)) -(face (cdr tag-face))) - (cond ((member tag line-tag-list) - (overlay-put overlay 'face face) - (setq tags-faces nil)) - (t - (setq tags-faces (cdr tags-faces) + "Colorize lines in `notmuch-show' based on tags." + ;; Create the overlay only if the message has tags which match one + ;; of those specified in `notmuch-search-line-faces'. + (let (overlay) +(mapc '(lambda (elem) +(let ((tag (car elem)) + (attributes (cdr elem))) + (when (member tag line-tag-list) +(when (not overlay) + (setq overlay (make-overlay start end))) +;; Merge the specified properties with any already +;; applied from an earlier match. +(overlay-put overlay 'face + (append (overlay-get overlay 'face) attributes) + notmuch-search-line-faces))) (defun notmuch-search-isearch-authors-show (overlay) (remove-from-invisibility-spec (cons (overlay-get overlay 'invisible) t))) -- 1.7.1
[PATCH] Customize saved search order separately from regular search order
On Mon, 07 Jun 2010 14:49:23 +0100, David Edmondson wrote: > Writing code to manipulate and use a structure like this would obviously > be some effort, but it doesn't seem overly difficult. More challenging > would be the interface to allow the user to customise the structure to > express their intentions. Do you have any thoughts on that? Moreover, what happens if the user types in a search by hand and then wishes to make it a saved search? Determining the best/right way to insert it into the considerably more complex `notmuch-saved-searches' structure sounds hard. If this data structure were only ever manipulated by editing .emacs then I'd have no problem. Currently that's not the case. dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100607/ecc9c970/attachment.pgp>
patches for 0.4
On Thu, 03 Jun 2010 19:20:54 -0700, Carl Worth wrote: > > [PATCH 09/13] emacs: Avoid runtime use of `cl'. > > Perhaps it's just fine now that you've been testing it a while, but at > least in your original email you said you wanted some additional review, > so I planned to do that. I have not noticed any oddities when using the changes. It would still make sense for there to be careful review. dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100607/b73b16ed/attachment.pgp>
[PATCH] Customize saved search order separately from regular search order
On Thu, 03 Jun 2010 17:45:20 -0700, Carl Worth wrote:
> So I think what we actually want here is an additional member for our
> saved-search tuple which indicates the desired search order for that
> particular search. That's the only way I see to support a single user
> who wants to take advantage of both kinds of searches.
That seems straightforward to implement in the code and only slightly
complicated in the customisation interface (though I haven't done it
yet).
> A separated, but perhaps related idea would be to explicitly support the
> notion of one search being a subset of another. I have an "inbox" search
> (tag:inbox) and several searches that are subsets, ("notmuch" is
> "tag:notmuch and tag:inbox"). If this were setup as an actual hierarchy
> it might have two advantages:
>
> 1. It would be a bit simpler to specify all of theses searches,
> I wouldn't have to keep repeating "and tag:inbox" in each.
> This would be particularly important if I changed the
> criteria for the top-level search.
>
> 2. If the various levels of the hierarchy were displayed
> separately it would be easier for me to focus on processing
> all of my inbox folders (which happen to be
> oldest-first)--archiving each down to 0 messages, without
> being distracted by several (newest-first) saved searches
> that will only ever grow and don't have any
> processing/archiving associated with them.
Writing code to manipulate and use a structure like this would obviously
be some effort, but it doesn't seem overly difficult. More challenging
would be the interface to allow the user to customise the structure to
express their intentions. Do you have any thoughts on that?
dme.
--
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100607/d0c9e1e3/attachment.pgp>
My repository is moving once again...
On Sat, 05 Jun 2010, Carl Worth wrote: > new tests in the test suite to handle 512-character message IDs). Hi Carl, I see some changes in the test suite in your repo. Do you want me to update the modularization patches I sent in id:1273510084-19896-1-git-send-email-sojkam1 at fel.cvut.cz? Michal
My repository is moving once again...
On Mon, 07 Jun 2010 09:47:54 +0200, Michal Sojka wrote: > On Sat, 05 Jun 2010, Carl Worth wrote: > > new tests in the test suite to handle 512-character message IDs). > > Hi Carl, > > I see some changes in the test suite in your repo. Do you want me to > update the modularization patches I sent in > id:1273510084-19896-1-git-send-email-sojkam1 at fel.cvut.cz? Either you or me. I am planning to review/merge your changes very soon. And I was aware that this patch series was outstanding when I recently changed the test suite. So I made those test-suite changes with the assumption that I would take any merge pain upon myself, rather than putting it on you. If you'd like to help with the merge, that would be great, but you're under no obligation. I prmoise not to augment the test suite anymore before looking at that patch series at least. So hopefully this is the very last time you'll have to update it! Thanks for your patience, -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100607/a093c057/attachment.pgp>
Re: [PATCH] Customize saved search order separately from regular search order
On Thu, 03 Jun 2010 17:45:20 -0700, Carl Worth cwo...@cworth.org wrote: So I think what we actually want here is an additional member for our saved-search tuple which indicates the desired search order for that particular search. That's the only way I see to support a single user who wants to take advantage of both kinds of searches. That seems straightforward to implement in the code and only slightly complicated in the customisation interface (though I haven't done it yet). A separated, but perhaps related idea would be to explicitly support the notion of one search being a subset of another. I have an inbox search (tag:inbox) and several searches that are subsets, (notmuch is tag:notmuch and tag:inbox). If this were setup as an actual hierarchy it might have two advantages: 1. It would be a bit simpler to specify all of theses searches, I wouldn't have to keep repeating and tag:inbox in each. This would be particularly important if I changed the criteria for the top-level search. 2. If the various levels of the hierarchy were displayed separately it would be easier for me to focus on processing all of my inbox folders (which happen to be oldest-first)--archiving each down to 0 messages, without being distracted by several (newest-first) saved searches that will only ever grow and don't have any processing/archiving associated with them. Writing code to manipulate and use a structure like this would obviously be some effort, but it doesn't seem overly difficult. More challenging would be the interface to allow the user to customise the structure to express their intentions. Do you have any thoughts on that? dme. -- David Edmondson, http://dme.org pgpabviM1QVWk.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Customize saved search order separately from regular search order
On Mon, 07 Jun 2010 14:49:23 +0100, David Edmondson d...@dme.org wrote: Writing code to manipulate and use a structure like this would obviously be some effort, but it doesn't seem overly difficult. More challenging would be the interface to allow the user to customise the structure to express their intentions. Do you have any thoughts on that? Moreover, what happens if the user types in a search by hand and then wishes to make it a saved search? Determining the best/right way to insert it into the considerably more complex `notmuch-saved-searches' structure sounds hard. If this data structure were only ever manipulated by editing .emacs then I'd have no problem. Currently that's not the case. dme. -- David Edmondson, http://dme.org pgpah38Y8vokw.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: patches for 0.4
On Thu, 03 Jun 2010 19:20:54 -0700, Carl Worth cwo...@cworth.org wrote: [PATCH 09/13] emacs: Avoid runtime use of `cl'. Perhaps it's just fine now that you've been testing it a while, but at least in your original email you said you wanted some additional review, so I planned to do that. I have not noticed any oddities when using the changes. It would still make sense for there to be careful review. dme. -- David Edmondson, http://dme.org pgpmzSIVVnPGp.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Re-work the implementation of highlighting in notmuch-search-mode.
Re-write `notmuch-search-color-line', with the following improvements: - create overlays only if they will be needed, - merge the properties specified for a tag on top of any matching a previous tag. --- emacs/notmuch.el | 37 + 1 files changed, 21 insertions(+), 16 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 10babe4..ac1da34 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -585,28 +585,33 @@ This function advances the next thread when finished. Here is an example of how to color search results based on tags. (the following text would be placed in your ~/.emacs file): - (setq notmuch-search-line-faces '((\delete\ . '(:foreground \red\)) + (setq notmuch-search-line-faces '((\delete\ . '(:foreground \red\ + :background \blue\)) (\unread\ . '(:foreground \green\ -Order matters: for lines with multiple tags, the the first -matching will be applied. +The attributes defined for matching tags are merged, with later +attributes overriding earlier. A message having both \delete\ +and \unread\ tags with the above settings would have a green +foreground and blue background. :type '(alist :key-type (string) :value-type (list)) :group 'notmuch) (defun notmuch-search-color-line (start end line-tag-list) - Colorize lines in notmuch-show based on tags - (if notmuch-search-line-faces - (let ((overlay (make-overlay start end)) - (tags-faces (copy-alist notmuch-search-line-faces))) - (while tags-faces - (let* ((tag-face (car tags-faces)) -(tag (car tag-face)) -(face (cdr tag-face))) - (cond ((member tag line-tag-list) - (overlay-put overlay 'face face) - (setq tags-faces nil)) - (t - (setq tags-faces (cdr tags-faces) + Colorize lines in `notmuch-show' based on tags. + ;; Create the overlay only if the message has tags which match one + ;; of those specified in `notmuch-search-line-faces'. + (let (overlay) +(mapc '(lambda (elem) +(let ((tag (car elem)) + (attributes (cdr elem))) + (when (member tag line-tag-list) +(when (not overlay) + (setq overlay (make-overlay start end))) +;; Merge the specified properties with any already +;; applied from an earlier match. +(overlay-put overlay 'face + (append (overlay-get overlay 'face) attributes) + notmuch-search-line-faces))) (defun notmuch-search-isearch-authors-show (overlay) (remove-from-invisibility-spec (cons (overlay-get overlay 'invisible) t))) -- 1.7.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: My repository is moving once again...
On Mon, 07 Jun 2010 09:47:54 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: On Sat, 05 Jun 2010, Carl Worth wrote: new tests in the test suite to handle 512-character message IDs). Hi Carl, I see some changes in the test suite in your repo. Do you want me to update the modularization patches I sent in id:1273510084-19896-1-git-send-email-sojk...@fel.cvut.cz? Either you or me. I am planning to review/merge your changes very soon. And I was aware that this patch series was outstanding when I recently changed the test suite. So I made those test-suite changes with the assumption that I would take any merge pain upon myself, rather than putting it on you. If you'd like to help with the merge, that would be great, but you're under no obligation. I prmoise not to augment the test suite anymore before looking at that patch series at least. So hopefully this is the very last time you'll have to update it! Thanks for your patience, -Carl -- carl.d.wo...@intel.com pgp0CqBPYgplg.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
