Re: [PATCH v3 0/8] emacs: JSON-based search cleanups
On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote: This version swaps out the notmuch-search-do-results macro for a higher-order function, notmuch-search-foreach-result. This requires less squiting to understand and clearly distinguishes the arguments passed in to the function from the arguments passed to the callback. This version also updates the docstring for notmuch-search-result-format to mention that multi-line result formats work and how to enter them, and it adds a NEWS patch. Hello I am afraid I have found a minor (but reproducible) bug in the line re-drawing even with single line results. Find a search result with a partially elided author field and put the cursor after the ellipsis in that line. Then update the tags. The result gets redrawn with ellipsis written out in full. Re-redrawing with the cursor after the author field redraws the line with the keeping the ellipsis written out in full, whereas re-redrawing the line with cursor before the author field gets it written with the correct ellipsis. Best wishes Mark Diff from v2: diff --git a/NEWS b/NEWS index a1a6e93..7b33f0d 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,20 @@ Maildir tag synchronization Emacs Interface --- +Search results now get re-colored when tags are updated + +The formatting of tags in search results can now be customized + + Previously, attempting to change the format of tags in + `notmuch-search-result-format` would usually break tagging from + search-mode. We no longer make assumptions about the format. + +Multi-line search result formats are now supported + + It is now possible to embed newlines in + `notmuch-search-result-format` to make individual search results + span multiple lines. + Search now uses the JSON format internally This should address problems with unusual characters in authors and diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 7302fa7..ec760dc 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -69,7 +69,13 @@ date, count, authors, subject, tags For example: (setq notmuch-search-result-format \(\(\authors\ . \%-40s\\) - \(\subject\ . \%s\\)\)\) + \(\subject\ . \%s\\)\)\) +Line breaks are permitted in format strings. Note that a line +break at the end of an \authors\ field will get elided if the +authors list is long; place it instead at the beginning of the +following field. To enter a line break when setting this +variable with setq, use \\n. To enter a line break in customize, +press \\[quoted-insert] C-j. :type '(alist :key-type (string) :value-type (string)) :group 'notmuch-search) @@ -433,32 +439,39 @@ returns nil (next-single-property-change (or pos (point)) 'notmuch-search-result nil (point-max -(defmacro notmuch-search-do-results (beg end pos-sym rest body) - Invoke BODY for each result between BEG and END. - -POS-SYM will be bound to the point at the beginning of the -current result. - (declare (indent 3)) - (let ((end-sym (make-symbol end)) - (first-sym (make-symbol first))) -`(let ((,pos-sym (notmuch-search-result-beginning ,beg)) -;; End must be a marker in case body changes the text -(,end-sym (copy-marker ,end)) -;; Make sure we examine one result, even if (= beg end) -(,first-sym t)) - ;; We have to be careful if the region extends beyond the - ;; results. In this case, pos could be null or there could be - ;; no result at pos. - (while (and ,pos-sym (or ( ,pos-sym ,end-sym) ,first-sym)) - (when (notmuch-search-get-result ,pos-sym) -,@body) - (setq ,pos-sym (notmuch-search-result-end ,pos-sym) -,first-sym nil) +(defun notmuch-search-foreach-result (beg end function) + Invoke FUNCTION for each result between BEG and END. + +FUNCTION should take one argument. It will be applied to the +character position of the beginning of each result that overlaps +the region between points BEG and END. As a special case, if (= +BEG END), FUNCTION will be applied to the result containing point +BEG. + + (lexical-let ((pos (notmuch-search-result-beginning beg)) + ;; End must be a marker in case function changes the + ;; text. + (end (copy-marker end)) + ;; Make sure we examine at least one result, even if + ;; (= beg end). + (first t)) +;; We have to be careful if the region extends beyond the results. +;; In this case, pos could be null or there could be no result at +;; pos. +(while (and pos (or ( pos end) first)) + (when (notmuch-search-get-result pos) + (funcall function pos)) + (setq pos (notmuch-search-result-end pos) + first nil +;; Unindent the function argument of
Re: [PATCH v3 0/8] emacs: JSON-based search cleanups
On Sun, 15 Jul 2012, Mark Walters markwalters1...@gmail.com wrote: On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote: This version swaps out the notmuch-search-do-results macro for a higher-order function, notmuch-search-foreach-result. This requires less squiting to understand and clearly distinguishes the arguments passed in to the function from the arguments passed to the callback. This version also updates the docstring for notmuch-search-result-format to mention that multi-line result formats work and how to enter them, and it adds a NEWS patch. Hello I am afraid I have found a minor (but reproducible) bug in the line re-drawing even with single line results. Find a search result with a partially elided author field and put the cursor after the ellipsis in that line. Then update the tags. The result gets redrawn with ellipsis written out in full. Re-redrawing with the cursor after the author field redraws the line with the keeping the ellipsis written out in full, whereas re-redrawing the line with cursor before the author field gets it written with the correct ellipsis. Arrrg, overlays. I can think of two ways to fix this. We could generate the author elision overlays lazily (say, via jit-lock). This would have the added benefit of eliminating what I think is the last quadratic factor in building search buffers, but there are much easier ways to do that. Or, I could scrap the insert-before-markers nonsense and manipulate point directly in notmuch-search-update-result, with the caveat that the little bit of support it had for doing sane things in some situations involving save-excursions would be lost. Given that we never call notmuch-search-update-result inside a save-excursion (precisely because I couldn't reliably hit the narrow window of situations it could handle when there were save-excursions involved), I'd lean toward the latter option. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 0/8] emacs: JSON-based search cleanups
On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote: On Sun, 15 Jul 2012, Mark Walters markwalters1...@gmail.com wrote: On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote: This version swaps out the notmuch-search-do-results macro for a higher-order function, notmuch-search-foreach-result. This requires less squiting to understand and clearly distinguishes the arguments passed in to the function from the arguments passed to the callback. This version also updates the docstring for notmuch-search-result-format to mention that multi-line result formats work and how to enter them, and it adds a NEWS patch. Hello I am afraid I have found a minor (but reproducible) bug in the line re-drawing even with single line results. Find a search result with a partially elided author field and put the cursor after the ellipsis in that line. Then update the tags. The result gets redrawn with ellipsis written out in full. Re-redrawing with the cursor after the author field redraws the line with the keeping the ellipsis written out in full, whereas re-redrawing the line with cursor before the author field gets it written with the correct ellipsis. Arrrg, overlays. I can think of two ways to fix this. We could generate the author elision overlays lazily (say, via jit-lock). This would have the added benefit of eliminating what I think is the last quadratic factor in building search buffers, but there are much easier ways to do that. Or, I could scrap the insert-before-markers nonsense and manipulate point directly in notmuch-search-update-result, with the caveat that the little bit of support it had for doing sane things in some situations involving save-excursions would be lost. Given that we never call notmuch-search-update-result inside a save-excursion (precisely because I couldn't reliably hit the narrow window of situations it could handle when there were save-excursions involved), I'd lean toward the latter option. I think I don't really know enough emacs/lisp to be able to say anything sensible. I think manipulating point directly seems good because then I think we can make sure things work in the multiline case too. I haven't yet worked out whether multiline is an amusing oh look it works or genuinely useful thing. I am leaning towards the latter as do often work on laptops with quite small screens and think I would like to see more about a smaller number of results. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 0/8] emacs: JSON-based search cleanups
On Sun, Jul 15 2012, Mark Walters markwalters1...@gmail.com wrote: However, there are some problems with multiline search results (see below) so I think we should either fix these or just downplay this new functionality by, for example, removing the comments on newlines from the defcustom and saying in NEWS that the feature is experimental/not complete or similar. (NEWS could say how to enter newlines in the defcustom) With this minor comment on the documentation my criticisms should not hold up this excellent series. I agree that multi-line support needs a little bit more work before it's ready for prime time. I'll keep experimenting with it as well and see if I can uncover any other issues. But I definitely also agree that that work should *not* hold up this patch series, as it adds plenty of other benefits. Examples of incompleteness: these are rather more personal but it seems odd to me to highlight one line rather than one result in the buffer. Similarly I would expect up down to scroll up or down by one result rather than one line. Highlighting the entire entry should definitely be fixed, since otherwise it can be hard to see which of the other lines is associated with the current entry. I also notice that the author field munging causes some weird behaviors. Certain formatter strings can cause it to break. If we can get that fixed it might be nice to have a similar functionality for the subject field, which can also be really long. jamie. pgpxXf7uzPxZH.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
