On Sun, 15 Jul 2012, Austin Clements <amdragon@MIT.EDU> wrote: > On Sun, 15 Jul 2012, Mark Walters <markwalters1009@gmail.com> wrote: >> On Sun, 15 Jul 2012, Austin Clements <amdragon@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