Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for relative path for gf #1917

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

liuzhishan
Copy link

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
Copy link
Member

tomdl89 commented Jun 20, 2024

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
Copy link
Author

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

@liuzhishan
Copy link
Author

liuzhishan commented Jun 22, 2024

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.

Copy link
Member

@tomdl89 tomdl89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

evil-commands.el Outdated Show resolved Hide resolved
evil-commands.el Outdated Show resolved Hide resolved
evil-commands.el Outdated Show resolved Hide resolved
evil-commands.el Outdated
(find-file file-path)

(if (and (stringp file-path)
(string-match-p "/" file-path))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

evil-commands.el Outdated Show resolved Hide resolved
evil-commands.el Outdated Show resolved Hide resolved
evil-commands.el Outdated Show resolved Hide resolved
evil-commands.el Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

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
Copy link
Author

liuzhishan commented Jun 29, 2024

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
Copy link
Member

tomdl89 commented Jul 2, 2024

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
Copy link
Author

liuzhishan commented Jul 3, 2024

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
Copy link
Member

tomdl89 commented Jul 3, 2024

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.

@liuzhishan
Copy link
Author

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.

Ok, let me add some comment to document the limitation. As for the least surprising approach, I think changing the traverse order would be a solution, from parent of b.h to project root.

@liuzhishan
Copy link
Author

Hi, @tomdl89 already add comments of limitation and update the search order, please check the code.

@liuzhishan
Copy link
Author

Hi, @tomdl89 It's been a while since I fix the code last time. If you have time please take a look at the code.

@axelf4
Copy link
Collaborator

axelf4 commented Jul 26, 2024

Why not contribute this to ffap upstream instead? I do not see the point of adding yet another bespoke implementation to Evil that does not even attempt to be bug-for-bug compatible with Vim, when a standard, Emacs-native counterpart to gf already exists in ffap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants