lambdalisue / vim-fern

🌿 General purpose asynchronous tree viewer written in Pure Vim script
MIT License
1.29k stars 49 forks source link

Feature request: option to display full path on FernRootText #178

Closed joenye closed 4 years ago

joenye commented 4 years ago

It would be useful to have the option to display the full/absolute path (with text overflow ellipsis prefix) on FernRootText, rather than only the current directory name. Full path is the default behavior of NERDTree.

Is there any way to configure this at the moment? It feels to me that this is something a renderer plugin should be able to override.

lambdalisue commented 4 years ago

Unfortunately no. As you said, if someone made a render plugin, it's possible.

Additionally, I'm not going to provide such an option or render plugin officially while it would be a bit difficult for the non-file schemes (e.g. What is the full/absolute path of dict:// scheme?)

joenye commented 4 years ago

Thanks for the quick response.

I have a minimal working solution that you may wish to consider extending inside the render_node function. This example is based on the nerdfont.vim renderer:

function! s:render_node(node, base, options) abort
  let level = len(a:node.__key) - a:base
  if level is# 0
    let suffix = a:node.label =~# '/$' ? '' : '/'
>   " Show full path if in file:// scheme
>   let path = stridx(a:node.bufname, 'fern:\/\/\/file:\/\/\/') ? a:node.bufname[15:-2] : a:node.label
>   return path . suffix . '' . a:node.badge
  endif
  let leading = repeat(a:options.leading, level - 1)
  let symbol = s:get_node_symbol(a:node)
  let suffix = a:node.status ? '/' : ''
  return leading . symbol . a:node.label . suffix . '' . a:node.badge
endfunction

I hope you agree that this isn't introducing a lot of complexity to support showing full path on file:// scheme. All that seems to be missing is some extra logic to check the buffer width and overflow text accordingly, and a new user configuration setting.

Here's how it looks:

image

For me, this is a big improvement, as I have more context where I am in the filesystem. I expect others would find this feature useful too, as it's been the default behavior in NERDTree for many years. Looking at your screenshots, I suspect you may under-appreciate this feature, as I see you're relying on Vim's tabline to display the path to the current buffer. As far as I know, the majority of Vim users don't do this, and so showing the path in a tree view is likely important for them.

Would you accept PRs adding this feature to the base renderer and adding support in fern-renderer-nerdfont.vim and fern-renderer-devicons.vim?

lambdalisue commented 4 years ago

I'm sorry but fern is not only for file:// scheme thus I don't want to add file:// specific code in any renderer.

I'll think of an acceptable way to get a similar result.

lambdalisue commented 4 years ago

@joenye is #181 satisfied your request?

joenye commented 4 years ago

This looks really great! Two comments I have:

  1. You could make the custom function signature more generic by not requiring a special flag for is_root if it's possible to deduce whether a node is a root node by looking at the node itself (e.g. it has no parent, or depth/layer is 0).
  2. Would this work with existing custom renderers? Ideally it would be something that custom renderers don't need to manually support, and inherit automatically.
lambdalisue commented 4 years ago

You could make the custom function signature more generic by not requiring a special flag for is_root if it's possible to deduce whether a node is a root node by looking at the node itself (e.g. it has no parent, or depth/layer is 0).

Correct. We can remove is_root.

Would this work with existing custom renderers? Ideally it would be something that custom renderers don't need to manually support, and inherit automatically.

Unfortunately no. That's kind a reason why I'm not satisfied the API yet.

lambdalisue commented 4 years ago

@joenye I've changed the way completely. Please try #190 instead.

joenye commented 4 years ago

Thanks @lambdalisue. I think this is sufficient for now.

I have left a comment with suggestions for improvement on #190.

lambdalisue commented 4 years ago

Sorry for bothering you. Please try #195 @joenye

joenye commented 4 years ago

Sorry for the late reply, @lambdalisue. I've now tested this change and can confirm it works well and addresses #178.