emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master 108ce84 2/2: xref--next-error-function: Move xr


From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master 108ce84 2/2: xref--next-error-function: Move xref's window point
Date: Fri, 2 Mar 2018 16:10:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0

On 3/2/18 3:39 PM, Eli Zaretskii wrote:

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.

Is this due to switch-to-buffer-preserve-window-point being t by
default now?

I want to say yes because that fits my understanding of the problem. But (setq switch-to-buffer-preserve-window-point nil) doesn't change neither the scenario above, nor its behavior in my work configuration.
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.

I'm not sure I see where does "undefined behavior" come from.

"Behavior I don't understand" might be closer to the truth. :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]