Closed lervag closed 5 years ago
I've taken the liberty of asking Reddit for help on this matter: https://www.reddit.com/r/vim/comments/9ilrr5/help_wanted_a_better_wiki_experience_within_vim/
For me, the showstopper with vimwiki is the use of Vimscript for too complicated stuff. Lua should be much faster. :hushed:
For me, there are no speed related issues at all with this plugin. That is, I have a quite large personal wiki, and the only thing that could probably be optimized is the part that generates graphs (e.g. backlinks and stuff like that). But this is not a day-to-day feature, and so I don't mind that it takes ~1-2 seconds the few times I do it.
Note also that although vimscript is slow, well written vimscript code is usually not so slow. It may become slow e.g. when we want to parse thousands of files or when you operate on very large arrays, especially if you don't use array operations (i.e. if you use for
loops).
Not quite finished, but I've started. There are still parts that should probably be delegated to other plugins.
I suggest that the code snippet text object moves to the wiki syntax plugin. Although for markdown, such things already exist: https://github.com/pocke/vim-textobj-markdown This could be combined with something like https://github.com/kassio/neoterm & it's <Plug>(neoterm-repl-send)
.
There's no harm I can see from having the useful text objects carefully grouped though. But full code evaluation might become a maintenance burden that's already taken care of elsewhere.
Folding is handled quite nicely by plasticboy/vim-markdown, even offering multiple styles. It might be that some this is best served by the existing markdown/vim ecosystem.
Thanks for the input. I generally agree and will attempt to make some progress in not too long!
I suggest that the code snippet text object moves to the wiki syntax plugin.
Done.
Folding is already moved to wiki-ft.vim
. I think things are quite barebones right now, but I would appreciate new issues/updates if there are more suggestions to things that should be separated due to filetype plugin conflicts.
This is OK for now, I'll rather focus on other parts. I would not mind to decouple more parts later if it makes sense.
In liue of #14, I came to realize that there might be some features that are now part of wiki.vim that are already (better) provided by other, dedicated plugins. I'm specifically thinking of:
If not, then I should also consider to separate these features from wiki.vim, as they are not necessarily related to a wiki in themselves.
While doing this, we should also write and improve a section in the docs on how to combine tools/plugins in order to get a good personal wiki setup.