GNU bug report logs - #63949
30.0.50; `vc-print-log´ does not erase buffer when called from *vc-change-log* buffer, at least for CVS logs

Previous Next

Full log

View this message in rfc822 format

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63949 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
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: Sat, 10 Jun 2023 17:44:26 +0200

On 2023-06-10  08:01, Eli Zaretskii wrote:

> Why do you think it's a problem?  I can justify this behavior, at 
> least in some use cases.

Let's distinguish "VC-controlled buffers" like the buffer of a
VC-controlled file or a *vc-dir* buffer or a dired buffer of
VC-controlled directory.  And "VC working buffers", like
*vc-change-log*, *vc-log*, *vc-diff*.

It is my understanding that `vc-parent-buffer' in a VC working buffer
points to the VC-controlled buffer from which it originates.  The
rationale of that variable is to allow VC operations from a VC working
buffer as if executed on the original VC-controlled buffer.  So I can do
C-x v l, pick a commit, do a C-x v ~ on that commit, then a C-x v =, and
all these operations would automagically relate to the original
VC-controlled buffer.  At least I use that concept frequently.

The documentation on `vc-parent-buffer', unfortunately, is out of date 
and does not necessarily support my understanding:

  ;; In a log entry buffer, this is a local variable
  ;; that points to the buffer for which it was made
  ;; (either a file, or a directory buffer).

However, this has been working as described by me up to and including
Emacs 27.  So at least we can say that the fix fur bug#40967 has changed
established behavior.

And also the following code snippet from function `vc-deduce-fileset-1'
seems to prove my point:

  ((and (buffer-live-p vc-parent-buffer)
        ;; FIXME: Why this test?  --Stef
        (or (buffer-file-name vc-parent-buffer)
            (with-current-buffer vc-parent-buffer
              (or (derived-mode-p 'vc-dir-mode)
                  (derived-mode-p 'dired-mode)
                  (derived-mode-p 'diff-mode)))))
   (progn          ;FIXME: Why not `with-current-buffer'? --Stef.
     (set-buffer vc-parent-buffer)
     (vc-deduce-fileset-1 not-state-changing
                          allow-unregistered
                          state-model-only-files)))

Meaning: If the current buffer has a live vc-parent-buffer, this
function switches to it and deduces the fileset from that.  Plus it
leaves the VC parent buffer current, which is important for follow-up
code to keep the VC parent buffer unchanged.

That logic used to work as intended (by me) up to Nathan's commit, which
put a `with-current-buffer' around the whole function and rendered the
`set-buffer' side effect pointless.

Let's put it that way: The pre-28 logic of handling the VC parent buffer
was not necessarily clean, as also pointed out by Stefan.  But I think
the concept of having a stable VC parent buffer across multiple VC
operations is nice, and changing it midway according to rather unclear
rules undesirable.

Ideally, we would have a fix that handled indirect buffers and VC parent
buffers (which are somewhat similar by concept) all consistently and
nicely and in a stable way, at the same time fixing both issues that I 
have.  I'll mediate about that...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.