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

[Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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...