|
From: | Dmitry Gutov |
Subject: | bug#63949: 30.0.50; `vc-print-log´ does not erase buffer when called from *vc-change-log* buffer, at least for CVS logs |
Date: | Sun, 18 Jun 2023 05:42:44 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 |
On 16/06/2023 22:33, Jens Schmidt wrote:
On 2023-06-10 19:23, Eli Zaretskii wrote:I'd also like to hear Dmitry's views on these issues. He was until now silent in this discussion, AFAICT.@Dmitry: What's your view on these issues? Just making the handling of VC parent buffer more documented and "more consistent", whatever that means, or do you prefer some particular direction?
I think the appropriate thing here is to back out of the change that caused the regression (d494833d47968fcd97ba549654a259d6fb6c2eee, as we've found out) and then try to re-fix it some other way (in master?).
Or maybe adjust the current code such as when vc-deduce-fileset-1 does change the current buffer, vc-deduce-fileset retains that change.
For example, using this ugly-ish (100% untested) patch: diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index 91d3f6f70d3..91aae40a677 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -1121,10 +1121,13 @@ vc-deduce-fileset the returned list. BEWARE: this function may change the current buffer." - (with-current-buffer (or (buffer-base-buffer) (current-buffer)) - (vc-deduce-fileset-1 not-state-changing - allow-unregistered - state-model-only-files))) + (let (new-buf) + (with-current-buffer (or (buffer-base-buffer) (current-buffer)) + (vc-deduce-fileset-1 not-state-changing + allow-unregistered + state-model-only-files) + (setq new-buf (current-buffer))) + (set-buffer new-buf))) (defun vc-deduce-fileset-1 (not-state-changing allow-unregisteredThe fact that some backends do call vc-setup-buffer inside vc-xx-print-log and some dont', also bears investigation. But the question I would like to have answered is, can we drop this call from all of them? Rather than trying to add it everywhere.
[Prev in Thread] | Current Thread | [Next in Thread] |