No colors since cd18ffb

betseg commented 5 years ago

What happened

Vim doesn't render the color scheme since the commit cd18ffb. Log of related parts: http://ix.io/1Kiq

What I expected to happen

Vim to render the color scheme correctly I guess?

Screenshot

Grim-Screenshot-2019-05-28_16:06:27

Machine Info

$ uname -a
Linux betseg 5.1.4-arch1-1-ARCH #1 SMP PREEMPT Wed May 22 08:06:56 UTC 2019 x86_64 GNU/Linux

Vim type (vim/gvim/neovim): vim
Vim version: 8.1.1186
OS: Arch Linux
Terminal/Terminal Emulator/VTE: kitty
TERM environment variable: xterm-kitty

dsifford commented 5 years ago

What's the output of :scriptnames... Looks like your vim implementation isn't loading autoloads? What version of vim are you using?

betseg commented 5 years ago

Vim version is 8.1.1186 and the output is here: http://ix.io/1Kio and the extension works if I manually revert it to the commit bfbc3ca (the one immediately before the last one).

dsifford commented 5 years ago

Yep, I have no idea...

That's being loaded and g:dracula#palette is clearly defined here...

https://github.com/dracula/vim/blob/cd18ffb1fb2f796fd769c7c00d775500f4fdac31/autoload/dracula.vim#L1-L6

Ping: @benknoble -- thoughts?

dsifford commented 5 years ago

One thing I will mention though that seems odd is how your runtime paths are set up...

You've got nested directories that aren't standard at the root level of your package paths.

I'm not a native package manager user so maybe that's normal, but that looks strange to me.

dsifford commented 5 years ago

Aha... I think I see the issue.

Rename the directory that contains this repo from vim to dracula and see if that works.

(might not be the issue, but it figured it's worth a try)

betseg commented 5 years ago

Nope, doesn't fix the issue.

dsifford commented 5 years ago

Darn. No idea then. I'll wait to hear back from someone else on this. I use neovim and I can't reproduce this.

betseg commented 5 years ago

Oh, I think the problem is that Vim is trying to load ~/.vim/pack/syntax/start/vim/colors/dracula.vim (which has references to g:dracula#palette etc) before ~/.vim/pack/syntax/start/vim/autoload/dracula.vim (which has the definitions). I have no idea how to fix it though.

dsifford commented 5 years ago

That shouldn't matter (and it's actually expected) since g:dracula#palette is an autoloaded variable.

betseg commented 5 years ago

I think it does matter, because I changed my .vimrc to a different color scheme and then when I'm in Vim i did :colorscheme dracula and it loaded without a problem.

dsifford commented 5 years ago

That's an error with your vim implementation then. The purpose of autoloads are to load on demand when needed.

See :h autoload

betseg commented 5 years ago

OK, I got the latest version of Vim (8.1.1413) and compiled it from the source, and I still have the same problem. I don't think it's a problem with Vim tho, because the issue doesn't happen with any other plugins.

benknoble commented 5 years ago

Here's what I've been able to identify so far as a user of vim's native packages:

Prior to packages loading (?? maybe... certainly prior to colorscheme dracula), my runtime path is

/Users/Knoble/.vim
/usr/local/share/vim/vimfiles
/usr/local/share/vim/vim81
/usr/local/share/vim/vim81/pack/dist/opt/matchit
/usr/local/share/vim/vimfiles/after
/Users/Knoble/.vim/after

Once packages have loaded:

/Users/Knoble/.vim
/Users/Knoble/.vim/pack/utility/start/vader
/Users/Knoble/.vim/pack/utility/start/unimpaired
/Users/Knoble/.vim/pack/utility/start/undotree
/Users/Knoble/.vim/pack/utility/start/tbone
/Users/Knoble/.vim/pack/utility/start/surround
/Users/Knoble/.vim/pack/utility/start/splitjoin
/Users/Knoble/.vim/pack/utility/start/rhubarb
/Users/Knoble/.vim/pack/utility/start/repeat
/Users/Knoble/.vim/pack/utility/start/projectionist
/Users/Knoble/.vim/pack/utility/start/presenting
/Users/Knoble/.vim/pack/utility/start/obsession
/Users/Knoble/.vim/pack/utility/start/indent-object
/Users/Knoble/.vim/pack/utility/start/heroku
/Users/Knoble/.vim/pack/utility/start/fugitive
/Users/Knoble/.vim/pack/utility/start/eunuch
/Users/Knoble/.vim/pack/utility/start/endwise
/Users/Knoble/.vim/pack/utility/start/dispatch
/Users/Knoble/.vim/pack/utility/start/commentary
/Users/Knoble/.vim/pack/utility/start/clam
/Users/Knoble/.vim/pack/utility/start/apathy
/Users/Knoble/.vim/pack/utility/start/ale
/Users/Knoble/.vim/pack/utility/start/ack
/Users/Knoble/.vim/pack/languages/start/tmux
/Users/Knoble/.vim/pack/languages/start/scala
/Users/Knoble/.vim/pack/languages/start/pydoc
/Users/Knoble/.vim/pack/languages/start/puppet
/Users/Knoble/.vim/pack/languages/start/liquid
/Users/Knoble/.vim/pack/languages/start/js
/Users/Knoble/.vim/pack/languages/start/go
/Users/Knoble/.vim/pack/languages/start/docker
/Users/Knoble/.vim/pack/interface/start/winresizer
/Users/Knoble/.vim/pack/interface/start/startify
/Users/Knoble/.vim/pack/interface/start/colorizer
/Users/Knoble/.vim/pack/games/start/code-break
/Users/Knoble/.vim/pack/colors/start/dracula
/Users/Knoble/.vim/pack/benknoble/start/synstax
/Users/Knoble/.vim/pack/benknoble/start/invader
/Users/Knoble/.vim/pack/benknoble/start/auto-origami
/usr/local/share/vim/vimfiles
/usr/local/share/vim/vim81
/usr/local/share/vim/vim81/pack/dist/opt/matchit
/Users/Knoble/.vim/pack/utility/start/apathy/after
/Users/Knoble/.vim/pack/languages/start/js/after
/Users/Knoble/.vim/pack/colors/start/dracula/after
/usr/local/share/vim/vimfiles/after
/Users/Knoble/.vim/after

So clearly, the autoload can't be found because of the package. The relevant help entry states:

When Vim starts up, after processing your .vimrc, it scans all directories in 'packpath' for plugins under the "pack/*/start" directory. First all those directories are added to 'runtimepath'. Then all the plugins are loaded. See |packload-two-steps| for how these two steps can be useful.

So, solutions would be (to me)

Tell users to packadd! dracula before they colorscheme dracula
Tell users to au VimEnter * colorscheme dracula (since then the colorscheme call happens after runtimepath has been manipulated).
Revert the autoload commit (a simpler, and less breaking, change—necessitates re-opening the closed issue and investigating a way around it)

dsifford commented 5 years ago

Tell users to packadd! dracula before they colorscheme dracula

Isn't this what we have been telling people? That same sentiment is true for all other package managers.

betseg commented 5 years ago

Isn't this what we have been telling people?

No? It works if I add it, btw.

dsifford commented 5 years ago

Would you or other users expect the dracula theme and functionality to be available and working prior to loading the dracula theme? That's what I'm not quite wrapping my head around.

How and where do you both recommend this be stated?

benknoble commented 5 years ago

I don’t mind going with solution number 1 above, but we need to announce it

in the docs
in the ReadMe
on the website
in a version number/release?? @dsifford

And be prepared to close issues as people upgrade.

The problem is, we haven’t been telling folks this, and by some miracle that I still don’t understand, it was working fine before even without packload!-ing it.

lsrdg commented 5 years ago

Just passing by to say thanks for the great colorscheme and reporting that the same problem just happened on Neovim, right after updating the plugin. It loads smoothly after running :colorscheme dracula though. Out of curiosity, just opened vim and the same problem and the same solution can be found there as well. (:

dsifford commented 5 years ago

Do you have a link to your init.vim that I can take a look at?

benknoble commented 5 years ago

@dsifford with some digging: https://github.com/lsrdg/dotfiles/tree/a66fd9c8f3a3e4bcd19ef66a8573c001d00eec8d

Didn't see anything re: dracula

I'm happy to put together the necessary PRs for https://github.com/dracula/vim/issues/140#issuecomment-497147203

dsifford commented 5 years ago

Yep, same issue.... Red should come after blue.

@benknoble Sounds good to me. Thanks!

lsrdg commented 5 years ago

@dsifford and @benknoble ,

Sorry, have moved away from github. The init.vim file which produces the error is here: https://gitlab.com/lsrdg/dotfiles/blob/master/.config/nvim/init.vim with red after blue. (:

Nvim v0.3.7. Let me know if I can help, and thank you both for maintaining the project. o/

dsifford commented 5 years ago

Not sure what to tell ya then. Can't begin to debug something I can't reproduce.

Some might suggest to just revert back to the old commit, however that commit, too, is broken. If you don't load dracula initially as your first color scheme, running :colorscheme dracula will result in errors for all vim users.

benknoble commented 5 years ago

@lsrdg based on my understanding of minpac, it just clones plugins and places them in the packpath. It doesn't actually add them (this is left to happen after .vimrc is loaded).

So, the solution is still

packadd! dracula
colorscheme dracula

dmhenry commented 5 years ago

@benknoble Proposed solution 1 from https://github.com/dracula/vim/issues/140#issuecomment-496707448 has no effect:

packadd! dracula
colorscheme dracula

Proposed solution 2 from https://github.com/dracula/vim/issues/140#issuecomment-496707448 does apply the theme, but the very verbose errors are still outputted upon starting Neovim:

au VimEnter * colorscheme dracula

Manually sourcing the autoload file works:

source $HOME/.config/nvim/pack/minpac/start/vim-dracula/autoload/dracula.vim
colorscheme dracula

Alternatively, users of minpac can check out the prior commit by adding the following to your init.vim or .vimrc:

call minpac#add('dracula/vim', {'name': 'vim-dracula', 'rev': 'bfbc3cadbd142e74d3b92e63f1de8711261015a4', 'frozen': 1})

The 'rev' entry chooses the commit and the 'frozen' entry will prevent minpac from automatically updating the plugin upon calling minpac#update() Obviously this isn't a great long-term solution, but it's the solution I have chosen for now.

dmhenry commented 5 years ago

Also, https://github.com/dracula/vim/issues/143#issuecomment-500546548.

digitallyelite commented 5 years ago

I realize this issue is closed, but I have this issue...

I've tried with pathogen (although my .vim isn't a git repository so the instructions are somewhat off there)

cd ~/.vim
git submodule add git@github.com:dracula/vim.git bundle/dracula-theme

Because I'm not using git for my .vim directory, I tried doing git clone https://github.com/dracula/vim.git bundle/dracula-theme instead

This throws an error of

Error detected while processing /user/.vimrc:
line 12:
E185: Cannot find color scheme 'dracula'
Press ENTER or type command to continue

Line 11 and 12 of my .vimrc are

syntax on
color dracula

Which actually coincides with the manual instructions on the website...

If you aren't so clever just move the dracula.vim file into ~/.vim/colors and add the following lines into your vimrc file:

syntax on
color dracula

But, if I just move the dracula.vim file to ~/.vim/colors.... then I get the same output of the first screenshot in the original bug as output....

benknoble commented 5 years ago

@digitallyelite it looks like the site instructions have not yet been updated. Can you try the recommendations in the README?

digitallyelite commented 5 years ago

@benknoble thanks for that - set runtimepath^=~/.vim/bundle/dracula-theme seems to do the trick. does this mean it's no longer possible to simply copy the .vim file into colors?

benknoble commented 5 years ago

@digitallyelite there is now more than one .vim file, as there has been for a while. But yes, we need dracula on the runtime path for the autoload functionality to work. Pathogen users may need to set the runtimepath, or try the autocmd VimEnter * colorscheme dracula approach from this thread.

benknoble commented 4 years ago

Just an update for anyone that cares: if you place colorscheme dracula in ~/.vim/plugin/somefile.vim, by the time it runs, packages have already been added to the runtime path. Things will work just fine.

dracula / vim