Open files with relative paths

[willeccles]

Is your feature request related to a problem? Please describe.
Opening files uses their absolute paths which makes them very difficult to read. Example: the file I am currently editing has a path that is nearly 160 characters long, which is a little much for the statusline of an 80-column terminal.

Describe the solution you'd like
(An option to?) open files by their relative paths when possible, falling back to the absolute path of files which are not descendants of the current working directory (relative paths technically also work here, but IMO, ../../../../x/y/z is probably not ideal...).

Additional context
This was originally added in #487 and reverted in #524 after it caused a number of bugs. I unfortunately do not have the time to dedicate to this right now, but I suspect these bugs are likely relatively trivial to fix.

[gegoune]

Is your feature request related to a problem? Please describe. Opening files uses their absolute paths which makes them very difficult to read. Example: the file I am currently editing has a path that is nearly 160 characters long, which is a little much for the statusline of an 80-column terminal.

Is that the only motivation behind this feature request? Honestly it seems like something you can easily fix on your end (how your statusline shows paths) rather than reintroducing solution that have proven problematic in the past.

[willeccles]

Making it the statusline's job to compute a relative path (a relatively complex operation) every time it updates has, in my opinion, more downsides than it's worth, particularly on slower machines or slower terminals. In comparison, computing this path once and then allowing the statusline to simply copy the path like it normally does promises to be significantly more efficient. Adding the overhead to rendering the statusline on every window (even when nvim-tree is not being used, which is probably 95% of the time) has a bit of a smell to me.

If this is not something you guys are interested in implementing, I can live without. I may eventually get around to working on this in my (unfortunately rare) spare time. In theory, most of the work has already been done in #487, so it should really just be a matter of debugging the issues it caused and addressing them. I must admit I was a little surprised that the solution to the problem was to revert a whole feature instead of fixing the bugs themselves, but I digress.

[willeccles]

One other thing to note is that it's not just the statusline that's affected. Anything which does expand('%') or similar is also affected, as well as things like :w.

[alex-courtis]

There is little consistency in how vim buffers are named; sometimes they are absolute, sometimes they are relative. Each plugin or vim native command does it their own way. A change just to nvim-tree won't solve your requirements and will likely break or interrupt existing nvim-tree users.

Making it the statusline's job to compute a relative path (a relatively complex operation) every time it updates has, in my opinion, more downsides than it's worth, particularly on slower machines or slower terminals. In comparison, computing this path once and then allowing the statusline to simply copy the path like it normally does promises to be significantly more efficient. Adding the overhead to rendering the statusline on every window (even when nvim-tree is not being used, which is probably 95% of the time) has a bit of a smell to me.

Please provide benchmarks / performance tests to support this.

[steve21168]

I came here for this feature as well. My use case is that I frequently copy the file name to my clipboard using: expand('%') and use that to share with others. The absolute path is always a pain and is inconsistent with telescope which opens files with a relative path.

However I've found a workaround that may help others you can use expand("%:~:.") to calculate the relative path.
Source

[alex-courtis]

However I've found a workaround that may help others you can use expand("%:~:.") to calculate the relative path. Source

Thank you. That will work reliably for all buffers, no matter how they were created.

[alex-courtis]

I came here for this feature as well. My use case is that I frequently copy the file name to my clipboard using: expand('%') and use that to share with others. The absolute path is always a pain and is inconsistent with telescope which opens files with a relative path.

Please note that you can use nvim-tree:
Y Copy Relative Path
gy Copy Absolute Path
y Copy Name

Closing this one. There are multiple ways to achieve this functionality.

[elamaranae]

Opening files in their relative paths should be default as most people work on projects where absolute path doesn't really make sense. And this is how many popular plugins such as telescope and fzf-lua opens files as well.

Another place is the root folder name which is also by default starts from home directory, instead of showing just the folder name which is how other editors such as VSCode behaves and in my opinion correctly.

Please consider reopening this.

[alex-courtis]

Another place is the root folder name which is also by default starts from home directory, instead of showing just the folder name which is how other editors such as VSCode behaves and in my opinion correctly.

Please seek first to understand: :help nvim-tree.renderer.root_folder_label
You might wish to use ":t"

Please consider reopening this.

This change was attempted however reverted: #487

Pull Requests are gratefully accepted.

[alex-courtis]

This change has a large blast radius and should be done behind a experimental feature flag e.g. experimental.open.relative_path default false.

e.g.

if M.config.experimental.open.relative_path then
  return lib.open_file('preview', node.relative_path)
else
  return lib.open_file('preview', node.absolute_path)
end