Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

g:vimwiki_list not respected when using native package management #935

Closed
4 tasks done
ChrisDavison opened this issue Jul 9, 2020 · 2 comments
Closed
4 tasks done
Labels
question For usage and configuration questions, user support, etc.

Comments

@ChrisDavison
Copy link

Using Vim8's native package management.

  • When g:vimwiki_list is after packloadall, the configuration is not used. All commands default to ~/vimwiki as the wiki, rather than user's specified path and syntax.
  • When g:vimwiki_list is before packloadall, configuration works as expected.

Previously used both pathogen and vim-plug, so had my infect/plug#begin calls near the top of my .vimrc, and all configuration following this.

Not determined yet if having packloadall further down your .vimrc causes any issues with other plugins, so querying if there is a way of forcing a vimwiki_wikilocals update (calling vars#init manually didn't work).


  • Checkout the dev branch and confirm the issue is present there as well.
    The dev branch contains fixes that may not have been merged to master yet.
  • Post the syntax you are using (default/mediawiki/markdown) and your vimwiki settings from your .vimrc
  • Provide a detailed description of the problem including steps to reproduce the issue.
  • Include the output of :VimwikiShowVersion.

VimwikiShowVersion

:Vimwiki
VimwikiDiaryGenerateLinks      VimwikiIndex                   VimwikiMakeTomorrowDiaryNote   VimwikiShowVersion             VimwikiTabMakeDiaryNote
VimwikiDiaryIndex              VimwikiMakeDiaryNote           VimwikiMakeYesterdayDiaryNote  VimwikiTabIndex                VimwikiUISelect
Os: Linux
Vim: 800
Branch: dev
Revision: da9ef92
Date: 2020-06-16 23:21:41 -0400

Syntax, markdown

let g:vimwiki_list = [{'path': '~/code/knowledge/', 'syntax': 'markdown', 'ext': '.md'}]
@tinmarino
Copy link
Member

packloadall@vim calls
packadd@vim that loads
vimwiki_dir/plugin/vimwiki.vim that calls
autoload/vimwiki/vars.vim#init that calls
populate_wikilocal_options that reads your
g:vimwiki_list to set
g:vimwiki_wikilocal_vars
But also some other global vars like
g:vimwiki_syntax_variables or
g:vimwiki_global_vars

Uderstand that for developpers it is easyer to keep vars consistent is user configuration is loaded only onces. Note also that there are 100 devs and each one (like me) came with its own var and disregarded the consistence with others.

So g:vimwiki_list is read at packloadall and that cannot be changed (in less than 80h)

So user has 2 options:
1/ (Recomended) configure before load
2/ change those other variables you can get with :let g:vimwiki_<Tab>

I hope that answer your question and I hope you understand that hot changing some vars could lead to much more bug at the end: for example you change the wikipath at any time and then pressing Enter get unexpected results. So generally it is better for the user to set conf before starting the process (even when process permit some hot changes).

Feel free (of course) to comment, I am closing just to clear the dev priorities (and to feel I did something today ;-)

@tinmarino tinmarino added the question For usage and configuration questions, user support, etc. label Jul 21, 2020
@tinmarino
Copy link
Member

From :h vimwiki-options

note for Vim power users:
If you have an elaborated Vim setup, where you  e.g. load plugins conditionally,
make sure the settings are set before Vimwiki loads (that is,before plugin/vimwiki.vim is sourced).
If this is not possible, try this command after the Vimwiki settings are (re-)set:
  :call vimwiki#vars#init()

But it is above the vimwiki_list section so hard to find. Now that you created the issue, its gona be easyer to find in the github searcher.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question For usage and configuration questions, user support, etc.
Projects
None yet
Development

No branches or pull requests

2 participants