GNU bug report logs - #53626
28.0.91; project-find-regexp (C-x p g) twice results in searching different projects

Previous Next

Package: emacs;

Reported by: sbaugh <at> catern.com

Date: Sat, 29 Jan 2022 19:12:01 UTC

Severity: normal

Found in version 28.0.91

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Sean Whitton <spwhitton <at> spwhitton.name>, sbaugh <at> catern.com, 53626 <at> debbugs.gnu.org
Subject: bug#53626: 28.0.91; project-find-regexp (C-x p g) twice results in searching different projects
Date: Mon, 7 Feb 2022 05:12:04 +0200
On 04.02.2022 07:32, Sean Whitton wrote:
> Hello,
> 
> On Fri 04 Feb 2022 at 04:32am +02, Dmitry Gutov wrote:
> 
>> On 30.01.2022 08:28, Sean Whitton wrote:
>>> These bindings hide the
>>> buffer-local value for default-directory in*xref*, such that
>>> xref--show-xref-buffer is only able to set the binding's value, not the
>>> real buffer-local value, and so when the let forms unwind*xref*'s old
>>> default-directory is restored.
>>
>> I have to say I'm surprised by this mechanic: not even setq-local helps.
> 
> I guess that's dynamic binding for you :)
> 
>> Guess we could kill the xref buffer every time, instead of erasing and
>> re-filling it, though.
>> [...]
>> It has the unfortunate side-effect of having that buffer displayed in a
>> different window, though. Or at least the possibility (though it happens
>> every time here).
>>
>> Maybe some kill-but-recreate-and-show-in-the-same-window-first kind of
>> hack would do the trick.
> 
> Maybe we could rename the old buffer to a temp name, then create and
> fill the new one, then set the old buffer's window's buffer to the new
> one, and finally kill the old one.  But this is not nice at all.

Right.

> How necessary is it that project.el set up this binding?  Is there
> something else it could do to achieve the same effect?
> 
> At worst, it seems better to special-case *xref* over in project.el than
> in xref.el, but you have a better overall perspective of the two
> libraries than me.

I suppose which is the better fix depends on whether we consider it to 
be important for third-party or simply new/future code to be able add a 
let-binding for default-directory to affect xref's behavior without 
having to worry about using a temp buffer. Until now, I've considered it 
to be a reasonable approach that shouldn't cause problems requiring the 
code author to travel down the call chain for investigation.

But maybe that was a bad assumption, and the added complexity of the 
approach described above it too much. I like your first suggested fix 
well enough, FWIW.

I wonder if we hit this problem in Emacs in some packages in the past, 
and how we chose to solve it. After all, default-directory is always 
buffer-local, and modifying its value is a common thing to do.




This bug report was last modified 3 years and 92 days ago.

Previous Next


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