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

Previous Next

Full log

Message #83 received at 55016-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Peter Povinec <spepo.42 <at> gmail.com>
Cc: 55016-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#55016: 28.1; xref-find-references finds no matches if project
 dir contains a space
Date: Mon, 31 Oct 2022 03:00:06 +0200

Hi again,

On 27.04.2022 06:00, Peter Povinec wrote:
> On Tue, Apr 26, 2022 at 5:30 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>>
>> On 26.04.2022 14:18, Eli Zaretskii wrote:
>>> I'm curious what does Dmitry think about this consequence of the
>>> change.
>>
>> I think Peter is saying that the patch made the file names displayed in
>> the abbreviated form, not vice versa.
>>
>> Which seems like a good change (more compact display).
> 
> That's right, with the patch, the filenames start with "~/".
> 
> I actually like that change too, but I am curious if there is an
> Emacs wide design guideline on such a thing.
> It seems that the behavior varies from place to place.
> E.g. when I
> 'C-x C-f' /Users/spepo42/test.txt
> it shows up as  "~/test.txt" in the buffer list.
> On the other hand, when I
> 'C-x C-f' ~/
> dired tells me in the header line it is looking at
> /Users/spepo42, but shows "~/" in the buffer list...

Sorry about the wait. I've pushed the patch now in commit a691e811e2, to 
get it in time for the next release.

Regarding a guideline, not sure if we had one (though it sounds good), 
but I think the only times where it would matter, is when a directory 
name is repeated multiple times (e.g. Compilation buffer).

And in places line a header line where it's only printed once, it 
doesn't matter as much, but can can show the expanded version, to make 
it doubly clear.

Previous Next

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