bug#64131: make resolving symlinks in compilation-find-file optional

bug#64131: make resolving symlinks in compilation-find-file optional

[Qiang Fang via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#64131: make resolving symlinks in compilation-find-file optional

[Stefan Kangas]

tags 64131 + moreinfo
thanks

Qiang Fang via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@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.

bug#64131: make resolving symlinks in compilation-find-file optional

[Qiang via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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)))
    

bug#64131: make resolving symlinks in compilation-find-file optional

[Stefan Kangas]

Qiang <qiang.fang@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?

bug#64131: make resolving symlinks in compilation-find-file optional

[Qiang via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#64131: make resolving symlinks in compilation-find-file optional

[Qiang via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

bug#64131: make resolving symlinks in compilation-find-file optional

[Stefan Kangas]

Qiang <qiang.fang@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?

bug#64131: make resolving symlinks in compilation-find-file optional

[Eli Zaretskii]

> Cc: 64131@debbugs.gnu.org
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 10 Jan 2024 02:39:33 -0800
> 
> Qiang <qiang.fang@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.