|
From: | Dmitry Gutov |
Subject: | bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason |
Date: | Fri, 2 Mar 2018 03:30:22 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 |
On 3/2/18 1:04 AM, Juri Linkov wrote:
In short, adapting that code is kind of difficult, but hopefully I found and fixed the problem in xref directly in 11c58c4fc495ea4f7bff52ca077fd3e4382aa900.While looking at this, I discovered more problems: 1. the same problem that you fixed for xref, also exists in occur: it doesn't set the right current-buffer for next-error.
Sounds indeed like a bug.
2. also typing RET in *Occur* doesn't set next-error-last-buffer. Maybe we need to set it in occur-mode-goto-occurrence (but not in occur-next-error)
Should it? Why? Hopefully, not just because Compilation does it (if we just want consistency, we can fix it in the other way, too).
3. typing RET in *xref* should set next-error-last-buffer as well
Same question.
4. Maybe these 2 lines needed to be added also to xref--xref-buffer-mode: (setq next-error-last-buffer buffer) (setq-default next-error-last-buffer buffer) like in next-error to set both buffer-local and global values.
I guess so (but one of them is already there). TBH, seeing these two lines together still makes me cringe a little.
[Prev in Thread] | Current Thread | [Next in Thread] |