search

mhinz / vim-startify

:link: The fancy start screen for Vim.
MIT License
5.31k stars 187 forks source link

$VIMRUNTIME resolution of docs fails for GUI vims #296

Closed ELLIOTTCABLE closed 6 years ago

ELLIOTTCABLE commented 6 years ago

So, GUI vim implementations have different $VIMRUNTIME paths than their embedded vim instances actually use:

MacVim uses …

escape(fnamemodify(resolve($VIMRUNTIME), ':p'), '\') .'doc' ==#
\ '/Applications/MacVim.app/Contents/Resources/vim/runtime/doc'

… whereas VimR (on NeoVim) uses …

escape(fnamemodify(resolve($VIMRUNTIME), ':p'), '\') .'doc' ==#
\ '/Applications/VimR.app/Contents/Frameworks/SwiftNeoVim.framework/'
\ . 'Versions/A/Resources/vim/runtime/doc'

This, unfortunately, breaks the g:startify_skiplist resolution of "docs" implemented after #78:

screen shot 2017-11-29 at 11 44 20

I can add an additional entry for my own setup; but I'm thinking that maybe “ignore Vim's docs” needs to be a little more robust implementation, with a separate option, instead of using the skip-list?

mhinz commented 6 years ago

Hmm, yeah, that feature certainly predates embedded Vims. :]

But I wonder how much I can really do about it. The approach could be slightly different for each single GUI and I'm somehow reluctant to do RPC (to get the correct runtime directory) in something that most people use as a start screen.

I need to think about this a bit more.

ELLIOTTCABLE commented 6 years ago

@mhinz I think an interactive “add this directory to the ignore-list” feature might be the most user-friendly solution?

Example: mapped to i by default …

  1. hitting i with the cursor over line [d] above adds /usr/local/.../nvim/runtime/doc/eval.txt to the ignore-list, prints a message to that effect, and re-renders
  2. moving down to the next one and hitting i again replaces that ignore with one for /usr/local/.../nvim/runtime/doc/*.txt … etceteras.

That's substantial implementation-work, though, and probably not worth your effort. Seems perfectly reasonable to WONTFIX this, to me, as the (centralized, user-friendly) solution(s) are all out-of-porportion to the difficulty of fixing it on the user's end … maybe just drop a note in the README? (=

mhinz commented 6 years ago

The implementation itself would probably be easier than the decision on where to save all that. So, yeah, that's a tad too much. :]

I added a new FAQ to the help, though.

Thanks for bringing this up anyway! ✨