From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63949: 30.0.50; =?UTF-8?Q?`vc-print-log=C2=B4?= 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 Message-ID: References: <8c62dd9a-3cad-b992-bfc4-64b2f1db4485@vodafonemail.de> <87fs729jxu.fsf@ledu-giraud.fr> <7bc0c78e-e4b5-0edc-0e9f-2f8fbafc352f@vodafonemail.de> <83y1kt180v.fsf@gnu.org> <8477db3b-b237-aa4b-b4aa-41d31cb77ac1@vodafonemail.de> <834jnf26v2.fsf@gnu.org> Reply-To: Jens Schmidt Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32487"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cc: 63949@debbugs.gnu.org, manuel@ledu-giraud.fr To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 17:45:28 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q80mO-0008HN-22 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 17:45:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q80m0-0002z7-UK; Sat, 10 Jun 2023 11:45:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q80ly-0002xh-Uf for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 11:45:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q80ly-0001o8-Ky for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 11:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q80ly-00084U-4I for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 11:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jens Schmidt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 15:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63949 X-GNU-PR-Package: emacs Original-Received: via spool by 63949-submit@debbugs.gnu.org id=B63949.168641189630995 (code B ref 63949); Sat, 10 Jun 2023 15:45:02 +0000 Original-Received: (at 63949) by debbugs.gnu.org; 10 Jun 2023 15:44:56 +0000 Original-Received: from localhost ([127.0.0.1]:36124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q80ls-00083p-2g for submit@debbugs.gnu.org; Sat, 10 Jun 2023 11:44:56 -0400 Original-Received: from mr3.vodafonemail.de ([145.253.228.163]:48786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q80ln-00083Y-0n for 63949@debbugs.gnu.org; Sat, 10 Jun 2023 11:44:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-21dec; t=1686411885; bh=BFyj3E2wmMiLgSUUJzs19OT3ley6CyeE2PBZmBk/f9Y=; h=Message-ID:Date:User-Agent:Subject:To:References:Content-Language: From:In-Reply-To:Content-Type:From; b=QXLLH7dGGH1hQwvME+z1AWgSQQA6rqlsHbIEX7RIGrGbrxfxUOQzPklNG+5AYbRjJ vvJZUN1+Deg/iAuBoDk9vO0G88SgLI0qFibRoHI6MSFLIEO3xmuV2vbCuKFBD9W3uI JhqNL5iq7iMVvN8y8MRbDkQJxGWsUZ2vbephfDLE= Original-Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr3.vodafonemail.de (Postfix) with ESMTPS id 4Qdj1n0Zszz210y; Sat, 10 Jun 2023 15:44:44 +0000 (UTC) Original-Received: from [192.168.178.41] (port-92-194-236-191.dynamic.as20676.net [92.194.236.191]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4Qdj1Z2tk0z9sbZ; Sat, 10 Jun 2023 15:44:31 +0000 (UTC) Content-Language: de-DE-frami, en-US In-Reply-To: <834jnf26v2.fsf@gnu.org> X-purgate-type: clean X-purgate: clean X-purgate-size: 3010 X-purgate-ID: 155817::1686411880-28FF84F8-170957F0/0/0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263221 Archived-At: 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...