GNU bug report logs - #78890
31.0.50; Messy vc-annotate buffer names

Previous Next

Package: emacs;

Reported by: Kristoffer Balintona <krisbalintona <at> gmail.com>

Date: Tue, 24 Jun 2025 10:43:02 UTC

Severity: normal

Found in version 31.0.50

Fixed in version 31.1

Done: Sean Whitton <spwhitton <at> spwhitton.name>

Bug is archived. No further changes may be made.

Full log


Message #53 received at 78890 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>,
 Kristoffer Balintona <krisbalintona <at> gmail.com>, 78890 <at> debbugs.gnu.org
Subject: Re: bug#78890: 31.0.50; Messy vc-annotate buffer names
Date: Wed, 25 Jun 2025 17:25:40 +0100
Hello,

On Wed 25 Jun 2025 at 08:35am -07, Jim Porter wrote:

> On 6/25/2025 2:48 AM, Sean Whitton wrote:
>> On Tue 24 Jun 2025 at 11:02pm -07, Jim Porter wrote:
>>
>>> Here's another possible patch for this. It uses 'vc-parent-buffer', which
>>> might be nil when first annotating a file, but that works out nicely, since
>>> '(buffer-name nil)' gets the buffer name of the current buffer (i.e. the
>>> original source file). I think this should be safe, though I'm not an expert
>>> on the VC internals.
>> Thanks.  We could use vc-parent-buffer somehow, but not unconditionally
>> -- it's not always set, but only in certain interactive calls.
>
> I *think* it should always get set buffer-locally by 'vc-setup-buffer' once we
> actually run a command, since 'vc-do-command' calls that function. So it
> should be safe to use 'vc-parent-buffer', though we could add another call to
> 'vc-setup-buffer' if it's not guaranteed to be called by all backends or in
> all corner cases.

Sorry, what I meant was: it should indeed always be set, but it won't
always be the buffer whose name it makes sense to put in the name of the
*Annotated* buffer.

-- 
Sean Whitton




This bug report was last modified 20 days ago.

Previous Next


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