|
From: | Dmitry Gutov |
Subject: | Re: [Emacs-diffs] master 108ce84 2/2: xref--next-error-function: Move xref's window point |
Date: | Wed, 28 Feb 2018 17:58:59 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 |
On 2/28/18 5:28 PM, Eli Zaretskii wrote:
branch: master commit 108ce84432d597f92637ea74bd0a094224d157de Author: Dmitry Gutov <address@hidden> Commit: Dmitry Gutov <address@hidden> xref--next-error-function: Move xref's window point* lisp/progmodes/xref.el (xref--next-error-function): Movexref's window point if it's visible. When we don't do that, navigation can start looping after a while.Sorry, this doesn't tell which problem(s) it attempts to fix, and there are no references to discussions or bug reports that could help me figure that out. Without that, I cannot make up my mind about the importance of this fix.
next-error can misbehave (resume from an earlier position) after several invocations when next-error-last-buffer is an xref buffer, and that buffer is visible.
Try: 1. cd .../emacs/source/dir 2. emacs -Q 3. M-x project-find-regexp RET It is not necessary to RET (The searches for "It is not necessary to", which only occurs in .el files).4. M-x next-error, do that a few times. Make sure *xref* is still visible (otherwise, you need to tweak the split-threshold variables). 5. Select the window showing the xref buffer, then go back to where you were (by typing 'C-x o' a couple of times). 6. M-x next-error will return to the beginning. Or, if the window point of the xref window is not at the first line, start over from there.
The reason I figured it's urgent, is step 5 is not necessary with my work configuration (not 'emacs -Q'). It's hard for me to tell now which package/setting/timer has this effect, but it seems reasonable to believe that some other users will see this too. Essentially, the code in emacs-26 currently relies on "undefined behavior", in C terms.
[Prev in Thread] | Current Thread | [Next in Thread] |