emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55016: closed (28.1; xref-find-references finds no matches if projec


From: GNU bug Tracking System
Subject: bug#55016: closed (28.1; xref-find-references finds no matches if project dir contains a space)
Date: Mon, 31 Oct 2022 01:01:02 +0000

Your message dated Mon, 31 Oct 2022 03:00:06 +0200
with message-id <6a49d4ff-6f29-0a45-8acf-329cc121ac97@yandex.ru>
and subject line Re: bug#55016: 28.1; xref-find-references finds no matches if 
project dir contains a space
has caused the debbugs.gnu.org bug report #55016,
regarding 28.1; xref-find-references finds no matches if project dir contains a 
space
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
55016: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55016
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- 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))



--- End Message ---
--- Begin Message --- 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 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Hi again,

On 27.04.2022 06:00, Peter Povinec wrote:
On Tue, Apr 26, 2022 at 5:30 AM Dmitry Gutov <dgutov@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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]