David Bremner <david@tethera.net> writes: > David Bremner <david@tethera.net> writes: > >> >> This reproduces the problem for me. Indeed it looks a bit like a similar >> "cursor jumping" problem I have seen (and someone else has reported on >> IRC). I will see if I can figure anything more out now that I have a >> reproducer. > > I think the following is a (simpler) reproducer of the same problem. > > 1) Do a search with at least 10 results > > 2) goto line 10 > > 3) hit 'g' > > For me this consistently leaves the point on line 10 but the hl-line bar > on line 1. I have not debugged it yet, but the proximate cause is that > when notmuch-hl-line-mode is called, (point) is 1, so the bar ends up on > the first line. The whys and wherefores I don't know yet. I have been slowly trying to debug this. It is a kind of heisenbug because the position of the hl-line-mode bar is affected by using the debugger (because hl-line-mode uses post-command-hook). My current understanding is 0) the refresh calls notmuch-search to rebuild the buffer contents. 1) hl-line-highlight is being called via notmuch-search-hook 2) notmuch-search-hook is being invoked asynchronously from notmuch-search-process-filter. 3) There is a buffer local variable notmuch--search-hook-run used to make sure this happens only once per call to notmuch-search. 4) Unfortunately when the hook is invoked, (point) is 1, and that is how the hl-line-mode bar ends up on the first line, rather than where the (point) is after the refresh completes. A) one question is why notmuch-search-hook is being run so early. I vaguely remember some discussion / reason for this but I have not dug it up. B) I have some hope this can be fixed by use of the existing variable notmuch-search-target-line, but it's a bit tricky because at the point where the hook is invoked, the buffer does not have that many lines yet. _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org