Adding the show symlink option to finder

[aadi58002]

Addresses the issue #300

[aadi58002]

I actually wanted to implement something similar to ls -al to also show the path of the symlink ex below.

But i have faced a roadblock and wanted ways of implementing it.
I tried to get the path of the symlink in the make_entry around here. But getting the link requires the call of realpath on entry.path with either vim.loop or plenary.async ( atleast on linux / not sure about windows ) or there might be some other way directly without invoking a command.

Ps i am new to neovim and lua. So any advice would be greatly helpful.

.local/share/nvim/lazy/telescope.nvim/lua/telescope/pickers.lua:642: Finder failed with msg: ...im/lua/telescope/_extensions/file_browser/m │ ake_entry.lua:201: E5560: nvim_buf_is_valid must not be called in a lua loop callback

Above is the error which i was getting when i tried to use a vim.loop or plenary.async function in the make_entry function

[jamestrew]

Sorry for the late response.

We can get the path of the symlink using a libuv function fs_readlink https://github.com/luvit/luv/blob/master/docs.md#uvfs_readlinkpath-callback
We can access these libuv function through the vim.loop namespace.

We can make the call to it similar to how we call vim.loop.fs_stat here:

telescope-file-browser.nvim/lua/telescope/_extensions/file_browser/make_entry.lua

Lines 226 to 232 in 6e51d0c

	if k == "stat" then
	t.stat = vim.F.if_nil(vim.loop.fs_stat(t.value), false)
	if not t.stat then
	return t.lstat
	end
	return t.stat
	end

Then we should be able to just modify path_display if opts.show_symlink is true and concatenate entry.link_path (or whatever you call the k == "stat" equivalent).

[aadi58002]

I inspected the entry element in the make_entry file and saw that lstat and the stat values on the entry is always same despite the file being a link or not. I don't think this is a desired behavior (maybe).

diff --git a/lua/telescope/_extensions/file_browser/make_entry.lua b/lua/telescope/_extensions/file_browser/make_entry.lua
index b8cf898..f99203f 100644
--- a/lua/telescope/_extensions/file_browser/make_entry.lua
+++ b/lua/telescope/_extensions/file_browser/make_entry.lua
@@ -124,6 +124,8 @@ local make_entry = function(opts)
     local display_array = {}
     local icon, icon_hl
     local is_dir = entry.Path:is_dir()
+    
+    print(vim.inspect(entry.lstat))
     -- entry.ordinal is path excl. cwd
     local tail = fb_utils.trim_right_os_sep(entry.ordinal)
     -- path_display plays better with relative paths

This line and :messages to inspect the element ( i don't know if there is a better way 😄 )

I would like to make it so that lstat and stat are properly set but i don't know where there values get

[jamestrew]

I tried putting this in the same line

    vim.print { path = entry.path, _type = entry.lstat.type }

and it's showing directory/file/link for the lstat.type accordingly. (I'm also just using :message as well).
Do you see this? Make sure you have the show_symlinks option enabled.

[aadi58002]

It does not seem to work for me

These directories are most symlinks but it still shows them as directories

[jamestrew]

maybe verify the flags being passed to fd
All I'm doing is hardcoding this to fd_file_args

  table.insert(args, "--type")
  table.insert(args, "symlink")

We actually already have builtin support for showing directory vs link vs files in the fs stats so with the code above I get this

Notice the d vs l in the fs mode/permissions column.

[aadi58002]

It seems the --follow options from the #312 PR makes the symlinks appear as directories.

--follow treats symlinks as directories

Any suggestion of how we can approach this problem ?

[jamestrew]

I see two ways the follow_symlinks affects file_browser:

1. showing symlinks (traversed) in the result
2. the way the links are opened/cd'ed (as a result of fd returning traversed link path)

I think with the show_symlinks option can be mutually exclusive with follow_symlinks in terms of fd args. So if show_symlinks=true then don't pass --follow to fd. I think this makes sense because in terms of showing results, they have a similar purpose. With show_symlinks we can have the additional benefit of showing both the link path and true path (x -> y).

In terms of cd'ing and opening files, follow_symlinks should continue to follow the symlink regardless of show_symlinks.

Does that make sense?
Basically if a user have show_symlinks=true but follow_symlinks=false and they hit <CR> on dir_path/ -> /true/path/to/dir/, file_browser will cd into dir_path/ but if follow_symlinks=true than it should cd into /true/path/to/dir/.

So you'll have to adjust which path entry.path points to based on follow_symlinks here

telescope-file-browser.nvim/lua/telescope/_extensions/file_browser/make_entry.lua

Lines 222 to 224 in 3044ff9

	if k == "path" then
	return t.value
	end

^ t.value here is the absolute_path from index 1 of this metatable

telescope-file-browser.nvim/lua/telescope/_extensions/file_browser/make_entry.lua

Lines 248 to 253 in 3044ff9

	return function(absolute_path)
	local e = setmetatable({
	absolute_path,
	ordinal = (absolute_path == opts.cwd and ".")
	or (absolute_path == parent_dir and ".." or absolute_path:sub(cwd_substr, -1)),
	}, mt)

[aadi58002]

Sorry about this made a little mistake with git and deleted the remote branch i reopened a new PR #334 i also made a pseudo working example which shows the link.

It behaves the same way as --follow even without the flag of fd. So that flag could be removed from the config ( maybe not sure about it ).

I am not confident in the implementation there might be some bug which i can't see immediately. I would like your opinion on how to further refine the implementation.

Also I am very thankful for the time and advice you (@jamestrew) have given me over this issue.Thanks for pointing to the exact file location where changes would be made for the implementation.it has been a great experience to work on this issue thank.