GNU bug report logs - #55016
28.1; xref-find-references finds no matches if project dir contains a space

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Povinec <spepo.42 <at> gmail.com>
Cc: 55016 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#55016: 28.1; xref-find-references finds no matches if project dir contains a space
Date: Tue, 26 Apr 2022 14:18:20 +0300

> From: Peter Povinec <spepo.42 <at> gmail.com>
> Date: Mon, 25 Apr 2022 21:57:59 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 55016 <at> debbugs.gnu.org
> 
> On Mon, Apr 25, 2022 at 7:07 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> >
> > Anyway, here's the patch in attachment which should be much easier to
> > apply either way. It also contains a tiny renaming.
> 
> Indeed. It applied successfully, thanks for that.
> 
> I can confirm that the patch fixes the bug. However, I noticed a subtle
> change in behavior: With the patch, the xref buffer shows the file names
> with '~' in them, whereas before the patch, the '~' was resolved to
> '/Users/username'. Functionally, it doesn't seem to make a difference
> though -- at least as far as I can tell.

Thanks for testing.

We could use abbreviate-file-name, perhaps.  But I'm not sure the
change you describe is not for the better, since absolute file names
are absolutely understandable and interpreted correctly in all
situations, whereas file names that begin with "~/" need to be
interpreted either by Emacs or by a reasonably functional shell before
they can be safely passed to any other program.

I'm curious what does Dmitry think about this consequence of the
change.

Previous Next

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