GNU bug report logs - #64131
make resolving symlinks in compilation-find-file optional

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64131 in the body.
You can then email your comments to 64131 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Qiang Fang <qiang.fang <at> zoho.com.cn>
To: "bug-gnu-emacs" <bug-gnu-emacs <at> gnu.org>
Subject: make resolving symlinks in compilation-find-file optional
Date: Sat, 17 Jun 2023 21:18:49 +0800

I use rg for searching in a git-annex repo, rg use compilation-find-file to jump to the file from the search result, symlinks are resolved with file-truename. But it should not resolve the symlink in the above case. See this issue for more details.

https://github.com/dajva/rg.el/issues/156#issuecomment-1595654224

Message #8 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Qiang Fang <qiang.fang <at> zoho.com.cn>, 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Mon, 11 Sep 2023 11:06:28 -0700

tags 64131 + moreinfo
thanks

Qiang Fang via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> I use rg for searching in a git-annex repo, rg use compilation-find-file to jump to the file from the search result, symlinks are resolved with file-truename. But it should not resolve the symlink in the above case. See this issue for more details.
>
> https://github.com/dajva/rg.el/issues/156#issuecomment-1595654224

Could you please give a complete recipe to reproduce this, what the
result is and what you expect?  Or is this a feature request?

It's preferable if your recipe doesn't include rg.el, because otherwise
it'll be hard for us to test it.

Message #13 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Qiang <qiang.fang <at> zoho.com.cn>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Qiang Fang <qiang.fang <at> zoho.com.cn>, 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Tue, 12 Sep 2023 07:56:40 +0800

No, I couldn't provide a recipe. But it is obvious even to a beginner like me. The solution is just removed the file-truename function from compile-find-file, or make it customisable:

    (defun compilation-find-file (marker filename directory &rest formats)
      "Find a buffer for file FILENAME.
       If FILENAME is not found at all, ask the user where to find it.
       Pop up the buffer containing MARKER and scroll to MARKER if we ask
       the user where to find the file.
       Search the directories in `compilation-search-path'.
       A nil in `compilation-search-path' means to try the
       \"current\" directory, which is passed in DIRECTORY.
       If DIRECTORY is relative, it is combined with `default-directory'.
       If DIRECTORY is nil, that means use `default-directory'.
       FORMATS, if given, is a list of formats to reformat FILENAME when
       looking for it: for each element FMT in FORMATS, this function
       attempts to find a file whose name is produced by (format FMT FILENAME)."
      (or formats (setq formats '("%s")))
      (let ((dirs compilation-search-path)
            (spec-dir (if directory
                          (expand-file-name directory)
                        default-directory))
            buffer thisdir fmts name)
        (if (and filename
                 (file-name-absolute-p filename))
            ;; The file name is absolute.  Use its explicit directory as
            ;; the first in the search path, and strip it from FILENAME.
            (setq filename (abbreviate-file-name (expand-file-name filename))
                  dirs (cons (file-name-directory filename) dirs)
                  filename (file-name-nondirectory filename)))
        ;; Now search the path.
        (while (and dirs (null buffer))
          (setq thisdir (or (car dirs) spec-dir)
                fmts formats)
          ;; For each directory, try each format string.
          (while (and fmts (null buffer))
            (setq name (file-name-concat thisdir (format (car fmts) filename))
                  buffer (and (file-exists-p name)
                              (find-file-noselect name))
                  fmts (cdr fmts)))
          (setq dirs (cdr dirs)))
        ;; If we haven't found it, this might be a parallel build.
        ;; Search the directories further up the buffer.
        (when (and (null buffer)
                   compilation-search-all-directories)
          (with-current-buffer (marker-buffer marker)
            (save-excursion
              (goto-char (marker-position marker))
              (when-let ((prev (compilation--previous-directory (point))))
                (goto-char prev))
              (setq dirs (cdr (or (get-text-property
                                   (1- (point)) 'compilation-directory)
                                  (get-text-property
                                   (point) 'compilation-directory))))))
          (while (and dirs (null buffer))
            (setq thisdir (car dirs)
                  fmts formats)
            (while (and fmts (null buffer))
              (setq name (file-name-concat thisdir (format (car fmts) filename))
                    buffer (and (file-exists-p name)
                                (find-file-noselect name))
                    fmts (cdr fmts)))
            (setq dirs (cdr dirs))))
        (while (null buffer)              ;Repeat until the user selects an existing file.
          ;; The file doesn't exist.  Ask the user where to find it.
          (save-excursion                 ;This save-excursion is probably not right.
            (let ((w (let ((pop-up-windows t))
                       (display-buffer (marker-buffer marker)
                                       '(nil (allow-no-window . t))))))
              (with-current-buffer (marker-buffer marker)
                (goto-char marker)
                (and w (progn (compilation-set-window w marker)
                              (compilation-set-overlay-arrow w))))
              (let* ((name (read-file-name
                            (format-prompt "Find this %s in"
                                           filename compilation-error)
                            spec-dir filename t nil
                            ;; The predicate below is fine when called from
                            ;; minibuffer-complete-and-exit, but it's too
                            ;; restrictive otherwise, since it also prevents the
                            ;; user from completing "fo" to "foo/" when she
                            ;; wants to enter "foo/bar".
                            ;;
                            ;; Try to make sure the user can only select
                            ;; a valid answer.  This predicate may be ignored,
                            ;; tho, so we still have to double-check afterwards.
                            ;; TODO: We should probably fix read-file-name so
                            ;; that it never ignores this predicate, even when
                            ;; using popup dialog boxes.
                            ;; (lambda (name)
                            ;;   (if (file-directory-p name)
                            ;;       (setq name (expand-file-name filename name)))
                            ;;   (file-exists-p name))
                            ))
                     (origname name))
                (cond
                  ((not (file-exists-p name))
                   (message "Cannot find file `%s'" name)
                   (ding) (sit-for 2))
                  ((and (file-directory-p name)
                        (not (file-exists-p
                              (setq name (file-name-concat name filename)))))
                   (message "No `%s' in directory %s" filename origname)
                   (ding) (sit-for 2))
                  (t
                   (setq buffer (find-file-noselect name))))))))
        ;; Make intangible overlays tangible.
        ;; This is weird: it's not even clear which is the current buffer,
        ;; so the code below can't be expected to DTRT here.  -- Stef
        (dolist (ov (overlays-in (point-min) (point-max)))
          (when (overlay-get ov 'intangible)
            (overlay-put ov 'intangible nil)))
        buffer)))
    

Message #16 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Qiang <qiang.fang <at> zoho.com.cn>
Cc: 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Mon, 11 Sep 2023 17:33:36 -0700

Qiang <qiang.fang <at> zoho.com.cn> writes:

> No, I couldn't provide a recipe. But it is obvious even to a beginner
> like me. The solution is just removed the file-truename function from
> compile-find-file, or make it customisable:

Thanks, but what is the problem that this solves?

Message #19 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Qiang <qiang.fang <at> zoho.com.cn>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Qiang <qiang.fang <at> zoho.com.cn>, 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Tue, 12 Sep 2023 08:59:03 +0800

Without that tiny modification, I have problem jump to the file in my git-annex folder. I think it should be the default.

Message #22 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Qiang <qiang.fang <at> zoho.com.cn>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Qiang <qiang.fang <at> zoho.com.cn>, 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Tue, 12 Sep 2023 09:01:09 +0800

Without that tiny modification, I have problem jump to the file in my git-annex folder, it jump to the actual database folder, what I want to the folder that have the symlink. I think it should be the default.

People use symlinks to organize text documents, a file may have links in different dirs. For example, if we use dirs as catalogues, when a file is opened following the search result in a "rg" buffer, it would be convenient to jump to the catalogue by just M-x "dired". However, the current behavior is to jump to the dir that has the symlink destination file. For people using git-annex, the symlink destination dir could be a database dir, and it is not supposed to be accessed directly.

Message #25 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Qiang <qiang.fang <at> zoho.com.cn>
Cc: 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Wed, 10 Jan 2024 02:39:33 -0800

Qiang <qiang.fang <at> zoho.com.cn> writes:

> Without that tiny modification, I have problem jump to the file in my
> git-annex folder, it jump to the actual database folder, what I want
> to the folder that have the symlink. I think it should be the default.
>
> People use symlinks to organize text documents, a file may have links
> in different dirs. For example, if we use dirs as catalogues, when a
> file is opened following the search result in a "rg" buffer, it would
> be convenient to jump to the catalogue by just M-x "dired". However,
> the current behavior is to jump to the dir that has the symlink
> destination file. For people using git-annex, the symlink destination
> dir could be a database dir, and it is not supposed to be accessed
> directly.

Could you provide a recipe for how to test this, for someone that
doesn't use git-annex but would be happy to install it?

Or even better, could you produce a recipe that doesn't rely on
git-annex?

Message #28 received at 64131 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: qiang.fang <at> zoho.com.cn, 64131 <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Wed, 10 Jan 2024 15:29:42 +0200

> Cc: 64131 <at> debbugs.gnu.org
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 10 Jan 2024 02:39:33 -0800
> 
> Qiang <qiang.fang <at> zoho.com.cn> writes:
> 
> > Without that tiny modification, I have problem jump to the file in my
> > git-annex folder, it jump to the actual database folder, what I want
> > to the folder that have the symlink. I think it should be the default.
> >
> > People use symlinks to organize text documents, a file may have links
> > in different dirs. For example, if we use dirs as catalogues, when a
> > file is opened following the search result in a "rg" buffer, it would
> > be convenient to jump to the catalogue by just M-x "dired". However,
> > the current behavior is to jump to the dir that has the symlink
> > destination file. For people using git-annex, the symlink destination
> > dir could be a database dir, and it is not supposed to be accessed
> > directly.
> 
> Could you provide a recipe for how to test this, for someone that
> doesn't use git-annex but would be happy to install it?
> 
> Or even better, could you produce a recipe that doesn't rely on
> git-annex?

It is possible that this issue was resolved while solving bug#67930,
so I suggest that the OP tries the current master branch to see if the
problem still exists.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: qiang.fang <at> zoho.com.cn, 64131-done <at> debbugs.gnu.org
Subject: Re: bug#64131: make resolving symlinks in compilation-find-file
 optional
Date: Sun, 9 Jun 2024 16:59:10 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 64131 <at> debbugs.gnu.org
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Wed, 10 Jan 2024 02:39:33 -0800
>>
>> Qiang <qiang.fang <at> zoho.com.cn> writes:
>>
>> > Without that tiny modification, I have problem jump to the file in my
>> > git-annex folder, it jump to the actual database folder, what I want
>> > to the folder that have the symlink. I think it should be the default.
>> >
>> > People use symlinks to organize text documents, a file may have links
>> > in different dirs. For example, if we use dirs as catalogues, when a
>> > file is opened following the search result in a "rg" buffer, it would
>> > be convenient to jump to the catalogue by just M-x "dired". However,
>> > the current behavior is to jump to the dir that has the symlink
>> > destination file. For people using git-annex, the symlink destination
>> > dir could be a database dir, and it is not supposed to be accessed
>> > directly.
>>
>> Could you provide a recipe for how to test this, for someone that
>> doesn't use git-annex but would be happy to install it?
>>
>> Or even better, could you produce a recipe that doesn't rely on
>> git-annex?
>
> It is possible that this issue was resolved while solving bug#67930,
> so I suggest that the OP tries the current master branch to see if the
> problem still exists.

More information was requested, but none was given within 5 months, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Previous Next

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