No colors since cd18ffb #140

betseg · 2019-05-28T13:10:53Z

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

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

The text was updated successfully, but these errors were encountered:

dsifford · 2019-05-28T15:31:26Z

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

betseg · 2019-05-28T16:18:41Z

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 · 2019-05-28T16:32:54Z

Yep, I have no idea...

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

vim/autoload/dracula.vim

Lines 1 to 6 in cd18ffb

    
           " Palette: {{{ 
        
           let g:dracula#palette           = {} 
        
           let g:dracula#palette.fg        = ['#F8F8F2', 253] 
        
           let g:dracula#palette.bglighter = ['#424450', 238]

Ping: @benknoble -- thoughts?

dsifford · 2019-05-28T16:39:36Z

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 · 2019-05-28T16:43:35Z

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 · 2019-05-28T16:45:05Z

Nope, doesn't fix the issue.

dsifford · 2019-05-28T16:46:39Z

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 · 2019-05-28T16:46:57Z

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 · 2019-05-28T16:47:44Z

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

betseg · 2019-05-28T16:50:32Z

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 · 2019-05-28T16:54:56Z

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

See :h autoload

betseg · 2019-05-28T17:20:23Z

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 · 2019-05-28T22:05:06Z

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 · 2019-05-28T23:03:51Z

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 · 2019-05-29T04:01:59Z

Isn't this what we have been telling people?

No? It works if I add it, btw.

dsifford · 2019-05-29T18:14:21Z

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 · 2019-05-29T23:41:47Z

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 · 2019-05-31T09:13:41Z

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 · 2019-05-31T22:33:44Z

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

benknoble · 2019-05-31T22:38:12Z

@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 #140 (comment)

dsifford · 2019-05-31T22:56:27Z

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

@benknoble Sounds good to me. Thanks!

Reset dracula-vim to bfbc3cadbd142e74d3b92e63f1de8711261015a4 as the master branch has some errors that have not yet been fixed. dracula/vim#140

lsrdg · 2019-06-02T08:36:02Z

@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 · 2019-06-02T16:29:41Z

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 · 2019-06-02T19:59:26Z

@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 · 2019-06-10T14:44:03Z

@benknoble
Proposed solution 1 from #140 (comment) has no effect:

packadd! dracula
colorscheme dracula

Proposed solution 2 from #140 (comment) 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 · 2019-06-10T19:00:39Z

Also, #143 (comment).

digitallyelite · 2019-06-17T20:39:56Z

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 [email protected]: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 · 2019-06-17T23:34:51Z

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

digitallyelite · 2019-06-18T00:09:40Z

@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 · 2019-06-18T19:54:08Z

@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 · 2019-11-18T17:06:31Z

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.

noisysocks added a commit to noisysocks/dotfiles that referenced this issue Jun 1, 2019

Move dracula-vim back to older version

51cf091

Reset dracula-vim to bfbc3cadbd142e74d3b92e63f1de8711261015a4 as the master branch has some errors that have not yet been fixed. dracula/vim#140

benknoble mentioned this issue Jun 2, 2019

Document solutions to errors caused by 'rtp' #142

Merged

dsifford closed this as completed in #142 Jun 2, 2019

benknoble mentioned this issue Jun 10, 2019

Doesn't source properly under minpac or using manual package management #143

Closed

benknoble mentioned this issue Dec 9, 2019

dracula does not work on .vimrc but works with :colorscheme dracula #161

Closed

benknoble mentioned this issue Apr 11, 2021

Need better installation instructions for Windows #244

Closed

roosta mentioned this issue Oct 14, 2021

getting error when setting colerscheme srcery-colors/srcery-vim#72

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No colors since cd18ffb #140

No colors since cd18ffb #140

betseg commented May 28, 2019 •

edited

Loading

dsifford commented May 28, 2019

betseg commented May 28, 2019 •

edited

Loading

dsifford commented May 28, 2019

dsifford commented May 28, 2019

dsifford commented May 28, 2019 •

edited

Loading

betseg commented May 28, 2019

dsifford commented May 28, 2019

betseg commented May 28, 2019 •

edited

Loading

dsifford commented May 28, 2019

betseg commented May 28, 2019

dsifford commented May 28, 2019 •

edited

Loading

betseg commented May 28, 2019 •

edited

Loading

benknoble commented May 28, 2019

dsifford commented May 28, 2019

betseg commented May 29, 2019

dsifford commented May 29, 2019

benknoble commented May 29, 2019

lsrdg commented May 31, 2019

dsifford commented May 31, 2019

benknoble commented May 31, 2019

dsifford commented May 31, 2019

lsrdg commented Jun 2, 2019

dsifford commented Jun 2, 2019

benknoble commented Jun 2, 2019

dmhenry commented Jun 10, 2019 •

edited

Loading

dmhenry commented Jun 10, 2019

digitallyelite commented Jun 17, 2019

benknoble commented Jun 17, 2019

digitallyelite commented Jun 18, 2019

benknoble commented Jun 18, 2019

benknoble commented Nov 18, 2019

No colors since cd18ffb #140

No colors since cd18ffb #140

Comments

betseg commented May 28, 2019 • edited Loading

What happened

What I expected to happen

Screenshot

Machine Info

dsifford commented May 28, 2019

betseg commented May 28, 2019 • edited Loading

dsifford commented May 28, 2019

dsifford commented May 28, 2019

dsifford commented May 28, 2019 • edited Loading

betseg commented May 28, 2019

dsifford commented May 28, 2019

betseg commented May 28, 2019 • edited Loading

dsifford commented May 28, 2019

betseg commented May 28, 2019

dsifford commented May 28, 2019 • edited Loading

betseg commented May 28, 2019 • edited Loading

benknoble commented May 28, 2019

dsifford commented May 28, 2019

betseg commented May 29, 2019

dsifford commented May 29, 2019

benknoble commented May 29, 2019

lsrdg commented May 31, 2019

dsifford commented May 31, 2019

benknoble commented May 31, 2019

dsifford commented May 31, 2019

lsrdg commented Jun 2, 2019

dsifford commented Jun 2, 2019

benknoble commented Jun 2, 2019

dmhenry commented Jun 10, 2019 • edited Loading

dmhenry commented Jun 10, 2019

digitallyelite commented Jun 17, 2019

benknoble commented Jun 17, 2019

digitallyelite commented Jun 18, 2019

benknoble commented Jun 18, 2019

benknoble commented Nov 18, 2019

betseg commented May 28, 2019 •

edited

Loading

betseg commented May 28, 2019 •

edited

Loading

dsifford commented May 28, 2019 •

edited

Loading

betseg commented May 28, 2019 •

edited

Loading

dsifford commented May 28, 2019 •

edited

Loading

betseg commented May 28, 2019 •

edited

Loading

dmhenry commented Jun 10, 2019 •

edited

Loading