James K. Lowden
не прочитано,2 янв. 2017 г., 15:48:1402.01.2017У вас нет разрешения на удаление сообщений в этой группе.
Чтобы отправить жалобу на сообщение, войдите в систему
Показать исходное сообщение
Возможно, адреса электронной почты являются анонимными для этой группы или вам требуется разрешение на просмотр адресов электронной почты ее участников, чтобы увидеть исходное сообщение.
–
With 25.1 installed, I'm happily using xref. I noticed something
slightly odd, and wonder what might be done for it.
On my system $HOME/projects is a symbolic link:
$ file ~/projects
/home/jklowden/projects: symbolic link to /usr/local/projects/
I rely exclusively on the symbolic link, and start emacs as a daemon
there. At the moment I have two daemons running (under different
names) for two different projects. When I use M-x pwd in the
*Messages* buffer, it reports the symlink path:
Directory /home/jklowden/projects/csv2bin/
When I use xref-find-definitions to load a file, though, it loads it via
the non-symbolic path. If I open the file per usual (in the project
directory, via the symlink) and then use xref-find-definitions, I see a
message like
/usr/local/projects/csv2bin/mapcols.h and
/home/jklowden/projects/csv2bin/mapcols.h
are the same file
which indeed they are.
Why is xref insisting on using the non-symbolic path? The TAGS file
doesn't mention it. The daemon's current working directory is on the
symbolic path. Files opened with emacsclient on the symbolic path
behave normally (i.e., their names reflect the symbolic path).
I suspect something somewhere is gratuitously calling realpath(3),
doubtless with good intentions. I'd like to understand why, and see if
there's a better way.
--jkl