add support for relative path for gf

[liuzhishan]

In evil mode, gf doest work when path under cursor has common ancstor with current buffer file. This seems to be a common situation. For example, suppose I have the following files:

project
└── src
    ├── a
    │   └── a.h
    └── b
        └── b.h

and in b.h, the file a/a.h is included:

// b/b.h
#include "a/a.h"

The gf command was mapped to find-file-at-point. If I want to open a/a.h file using gf in b.h file, it doest not work.

To solve this problem, I add a new function evil-open-file-under-cursor:

1. Find path under cursor.
2. If the path is absolute path, then try opening the file using find-file.
3. If the path is a relative path, find directory of current buffer file, then try every combination of sub directory and path under cursor. If any of them exists, then we found the target, try opening the file.
4. Otherwise, fallback to evil-find-file-at-point-with-line as the origin logic.

And also I changed the gf key mapping in evil-maps.el:

(define-key evil-normal-state-map "gf" 'evil-open-file-under-cursor)
(define-key evil-normal-state-map "]f" 'evil-open-file-under-cursor)
(define-key evil-normal-state-map "[f" 'evil-open-file-under-cursor)

---

• [ x ] I searched the issue tracker and this hasn't been PRed before.
• [ x ] My changes are not on the do-not-PR list for this project.
• [ x ] My commits conform to the git conventions.
• [ x ] Any relevant issues or PRs have been linked to.

[tomdl89]

Thanks for the PR @liuzhishan. I think there will be some work required before we can merge. A few observations:

• Functions such as evil-find-file-at-point-with-line should be backtick-quoted in docstrings
• It looks like you're using the dash library. Evil doesn't require dash, so you'll need to find a way without it
• Your indentation looks wrong on a few lines. e.g. 3738 and 3747
• if without an else clause looks better as an and or when
• My inclination would be to let this function take an argument of the filename, and put the thing-at-point code in the interactive block.
• When let-binding something to nil, it's usually more idiomatic to just write foo than (foo nil)
• let* is not necessary when you only have one binding let will do

I'll take a look at the code in more detail once these things are ironed out. I hope that helps.

[liuzhishan]

@tomdl89 thanks for the detailed reply. I'll fix the code and update the pr.

[liuzhishan]

Thanks for the PR @liuzhishan. I think there will be some work required before we can merge. A few observations:

• Functions such as evil-find-file-at-point-with-line should be backtick-quoted in docstrings
• It looks like you're using the dash library. Evil doesn't require dash, so you'll need to find a way without it
• Your indentation looks wrong on a few lines. e.g. 3738 and 3747
• if without an else clause looks better as an and or when
• My inclination would be to let this function take an argument of the filename, and put the thing-at-point code in the interactive block.
• When let-binding something to nil, it's usually more idiomatic to just write foo than (foo nil)
• let* is not necessary when you only have one binding let will do

I'll take a look at the code in more detail once these things are ironed out. I hope that helps.

Hi, I have update the code, please have a look if there are any other problem.

[tomdl89]

I've added a load more comments. If this is an enjoyable educational process, then by all means keep going. Equally though, if this is turning out to be more work than you had hoped for, feel free to drop this PR, make an issue, and I'll take a look when I get the time. Cheers

[tomdl89]

I'm not 100% sure on this, but have you checked if this check would work in windows? I believe they use backslashes over there.

[liuzhishan]

I have add a check on system-type to distinguish windows and other system.

[tomdl89]

Also, I haven't tried your function yet (because it requires functions I don't have) but your diagram of accessing a/a.h from b/b.h doesn't seem to tally with the vim's documentation on path (by default, anyway). So I'm not sure if your diagram is wrong and your functionality is right, or the other way round, but that's worth checking too.

[liuzhishan]

Can you please specify which part of vim's documentation on path ? I checked vim doc, but found several entries on path.

I have tested the function on mac and linux, it worked. I don't have a windows os, but as far as I know, the different of windows and linux path is just the '/' and '' seperator. So after I add a logic to distinguish os type, it should work on windows too.

[liuzhishan]

I've added a load more comments. If this is an enjoyable educational process, then by all means keep going. Equally though, if this is turning out to be more work than you had hoped for, feel free to drop this PR, make an issue, and I'll take a look when I get the time. Cheers

Hi, I think this is a enjoyable learning process. I use doom emacs, and got used to use some doom function. I'll rm the doom related code, and fix other problems.

[liuzhishan]

I've added a load more comments. If this is an enjoyable educational process, then by all means keep going. Equally though, if this is turning out to be more work than you had hoped for, feel free to drop this PR, make an issue, and I'll take a look when I get the time. Cheers

Hi, thanks for the detailed comments. I have fix the code. The main change are as follows:

1. Rename the function to evil-goto-file.
2. Add system-type check for path delimiter, distinguish windows and others.
3. Switch to the logic of first version, handling the path using builtin functions like string-join, take, without other packages dependent.
4. Fallback to find-file-at-point.

[tomdl89]

Hey @liuzhishan thanks for getting it to the point where I can test it. It seems to work as you want, but the same functionality doesn't work in vim for me. I don't have a C codebase to hand, so vim may behave differently there, but with a structure of text files as you laid out in your description, vim says E447: Cannot find file "a/a.txt" in path and when I do :set path? I see path=.,,,src/**,public/** (this is what I was referring to as "path" - docs are at :h path). I'd like to be sure we are implementing actual vim functionality before continuing with code-related feedback.

[liuzhishan]

Hey @liuzhishan thanks for getting it to the point where I can test it. It seems to work as you want, but the same functionality doesn't work in vim for me. I don't have a C codebase to hand, so vim may behave differently there, but with a structure of text files as you laid out in your description, vim says E447: Cannot find file "a/a.txt" in path and when I do :set path? I see path=.,,,src/**,public/** (this is what I was referring to as "path" - docs are at :h path). I'd like to be sure we are implementing actual vim functionality before continuing with code-related feedback.

Hi, @tomdl89 I known where the problem is. It's not a vim functionality of gf.

When I do :set path in vim, I see path=.,/usr/include,,, and gf does not work for relative path. If I set path using :set path=.,/usr/include,,/path/to/project, it worked for relative path under project (where /path/to/project is the actual absolute path to project root). It seems that vim is missing the same functionality gf for relative path.

So it's a a new functionality for emacs evil. Should evil be exactly the same as vim behavior ?

[tomdl89]

Should evil be exactly the same as vim behavior ?

Usually, but not always. Evil can improve upon vim in some cases. This is especially true when dealing with something on the interface between emacs and vim.

Because there is no direct equivalent of path in emacs, adding support for relative path for gf is non-trivial. Your current approach hard-codes one of many possible relative filepath searching approaches, so at a minimum I'd want to document this limitation. Even better would be to introduce an evil-path buffer-local variable which could be customized by users, but I don't think this needs adding on the first iteration of the functionality.

I'm happy to proceed with this PR, but I think the right thing to do is to implement the least surprising hard-coded approach, and then we can look at adding customizability later. For me, if I'm visiting b.h in your example, the least surprising approach for relative paths would be to search relative to b/. So if I wanted to navigate to a.h with gf, the text under the cursor would need to be ../a/a.h. I'm very open to counter-arguments, as this isn't something I've given much thought.