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

Previous Next

Package: emacs;

Reported by: Peter Povinec <spepo.42 <at> gmail.com>

Date: Tue, 19 Apr 2022 04:59:02 UTC

Severity: normal

Found in version 28.1

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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Peter Povinec <spepo.42 <at> gmail.com>
Subject: bug#55016: closed (Re: bug#55016: 28.1; xref-find-references
 finds no matches if project dir contains a space)
Date: Mon, 31 Oct 2022 01:01:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#55016: 28.1; xref-find-references finds no matches if project dir contains a space

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 55016 <at> debbugs.gnu.org.

-- 
55016: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55016
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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.

[Message part 3 (message/rfc822, inline)]
From: Peter Povinec <spepo.42 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1;
 xref-find-references finds no matches if project dir contains a space
Date: Mon, 18 Apr 2022 21:52:49 -0700
I despise spaces in directory names like the next guy, but sometimes it
is unavoidable. In my case, I had some elisp files in apple
icloud shared folder, and those are mounted by the system
under a nasty path like
~/Library/Mobile\ Documents/com~apple~CloudDocs.
If I loaded one of those files and tried xref-find-references,
it would never find anything, not even references within the same file.

Here is a contrived scenario to reproduce the issue:
1. create two symlinks like
ln -s ~/Applications/Emacs.app/Contents/Resources/lisp/progmodes
~/space\ dir
ln -s ~/Applications/Emacs.app/Contents/Resources/lisp/progmodes
~/nospacedir
2. C-x C-f ~/space dir/xref.el
3. M-? on xref-location-marker, specify default project and default
directory ~/space dir
4. Observe "No references found for: xref-location-marker"
5. Close the xref.el buffer with C-x k
6. Repeat steps 2-3, but using  ~/nospacedir instead
7. Observe that references are shown correctly

We should be able to handle directories with spaces. If for some reason
we couldn't do that, we'd need to inform the user explicitly.

Workaround to the original problem where the elisp files are
stored under a directory with spaces in it:
1. Create a symlink pointing to a subdir under the directory that
contains the space so you have a pathname to the files without any space.
2. Configure the mapping from the full pathname to the symlink using
directory-abbrev-alist to tell emacs to use the symlink directory name
whenever creating buffers of files under the space-containing directory.



In GNU Emacs 28.1 (build 1, aarch64-apple-darwin21.1.0, NS
appkit-2113.00 Version 12.0.1 (Build 21A559))
 of 2022-04-04 built on armbob.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.2.1

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 50996 6609)
 (symbols 48 6552 1)
 (strings 32 17843 2090)
 (string-bytes 1 596645)
 (vectors 16 13825)
 (vector-slots 8 184230 11069)
 (floats 8 21 39)
 (intervals 56 301 0)
 (buffers 992 11))



This bug report was last modified 2 years and 263 days ago.

Previous Next


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