lervag / wiki.vim

A wiki plugin for Vim

Introduction

This is a Vim and neovim plugin for writing and maintaining a personal wiki. The plugin was initially based on vimwiki, but it is written mostly from scratch and is based on a more "do one thing and do it well" philosophy.

This README file contains basic information on how to get started, as well as a list of available features. For more details, please read the full documentation.

Note: wiki.vim is not a filetype plugin. It is designed to be used with filetype plugins, e.g. dedicated Markdown plugins. Users are adviced to read :help wiki-intro-plugins for a list of plugins that work well with wiki.vim.

Note: wiki.vim requires Vim 9.1 or Neovim 0.9.5.

Table of contents

• Quick Start
• Features
• Acknowledgements
• Alternatives

Quick Start

Installation

If you use vim-plug, then add the following line to your vimrc file:

Plug 'lervag/wiki.vim'

Or use some other plugin manager:

• vundle
• neobundle
• pathogen

Usage

This outlines the basic steps to get started:

1. Create a wiki directory where the wiki files should be stored, for instance ~/wiki.

2. Add the following to your vimrc file:

   let g:wiki_root = '~/wiki'

3. Now you can open the index file (by default index.wiki) with <leader>ww and start to add your notes as desired.

Please also read the Guide section in the documentation.

Features

• Wiki functionality
  • Global
    • Commands (and mappings) to access a pre-specified wiki (g:wiki_root)
      • WikiIndex to open the index
      • WikiJournal to open the journal
      • WikiPages to select from list of all pages
      • WikiTags to select from list of tags
  • Local commands and mappings for
    • Navigation (follow links, go back, etc)
    • Renaming pages (will also update links in other pages)
    • Navigate through a table of contents (WikiToc)
    • Creating a table of contents (WikiTocGenerate)
    • Transforming links (from text to link or between link types)
    • Viewing wiki link graphs
    • Displaying incoming links (see WikiLinkIncomingToggle)
  • Completion of wiki links and link anchors
  • Text objects
    • iu au Link URL
    • it at Link text
  • New page templates
• Support for journal entries
  • Navigating the journal back and forth with <c-p> and <c-n>
  • Support for parsing journal entries in order to make weekly and monthly summaries. The parsed result needs manual editing for good results.
• Utility functionality
  • :WikiExport command for exporting to e.g. pdf with pandoc
• Third-party support
  • ncm2: SubscopeDetector for nested completion

Acknowledgements

Without vimwiki, this plugin would never have existed. So my thanks go to the smart people that developed and maintains vimwiki, both for the inspiration and for the ideas.

Alternatives

Feel free to consider any of the many available alternatives. There are likely many more, but these are the ones I'm aware of:

• Vimwiki
• neorg
• tdo.nvim
• notes.nvim

wiki.vim's Issues

WikiExport and Relative Paths

Currently, I think the WikiExport runs on a temporary version of the file, or does so at least in neovim. That is, it runs on something in /tmp/nvim_____/.

This in turn causes issues if I have some images linked in my markdown files, since ![My Image](./images/001.png) is no longer a valid link. Running pandoc directly on the file in the original location produces the expected pdf with images.

Using relative links lets me convert all my notes via MkDocs and host it online, but since that is private I would love an export feature so I can send some of the pages as PDF etc when I occasionally need to do that.

Perhaps this could be solved by using resource-path in pandoc? I attempted to get this working with the current config options, but I couldn't see a way to define a relative path in the current form of the arguments.

Weekly/monthly journal support

Similar to vimwiki/vimwiki#265, I'd like to express my interest in a tweak to the journal functionality to allow it to use weekly journal files.

To provide some flexibility here, do you think it is feasible to allow specifying a custom date format string with which to create the journal file? For example, if the default is %Y-%m-%d which would be 2017-11-27 today and 2017-11-28 tomorrow, and you wanted to reduce the frequency of journal entries to weekly, you could specify %Y-%U which would be 2017-48 this week and 2017-49 next week, or %Y-%m for monthly for example.

Please let me know your thoughts!

request: fzf tags binding

It would be great if there was a key binding for fzf searching wiki tags!

Pandoc/Vimtex Integration

This is more of an open discussion/feature request than any sort of bug or issue so I did not follow the issue template.

I was thinking it would be nice to support integration with Vimtex and Pandoc, and to support the Pandoc flavor of markdown.

Supporting Vimtex integration would give users access to all the convenient text objects, insert mode mappings, and other typesetting features of Vimtex when taking notes in their wiki. Pandoc's flavor of markdown supports inline Latex, making access to Vimtex's mappings extremely valuable. Conforming to Pandoc's flavor of markdown allows users to render their wiki files to a multitude of output formats.

I am perhaps the ideal example use case for this integration. As a physics graduate student, having access to inline math via Latex is indispensable. I use Pandoc to convert my weekly journal summaries to PDF and send them along to my advisor to keep him updated about my progress. I have enabled this integration using the following snippet in my vimrc

augroup wiki_setup
    autocmd!
    " Enable pandoc for all wiki files
    autocmd BufNewFile,BufFilePre,BufRead *.wiki set filetype=wiki.pandoc.tex
    " Now enable vimtex plugin to get vimtex keybindings and such
    autocmd BufNewFile,BufFilePre,BufRead *.wiki call vimtex#init()
augroup END

Perhaps this is a vimtex issue and not a wiki issue, but I can't get vimtex to initialize using multiple filetypes like I have above. I need to explicitly call vimtex#init().

From a development perspective, one could offload the syntax highlighting to the vim-pandoc-syntax plugin, and only add syntax extensions onto that. It provides nice highlighting for math, lists, etc. Currently there is some weirdness with how the syntax from wiki.vim and vim-pandoc interact.

Anyway, I opened this issue to get people's thoughts and see if anyone else would find this useful. Also fishing for some cool ideas :)

Feel free to close if this seems too vague or not particularly useful.

Extend supported alphabets for creating wiki links

Creating links on the following does not work:

ウィキ
土壇場

Entering visual mode to highlight these entries produces garbage next to the new link and looks even worse pasted here:

孛苣ꎂ苣嶭艝ભ
孛鳥螣ꃥ嶴ꁝ઴

I would assume this is undefined behavior (as CJK text cannot be used to create links in normal mode) and could be (hopefully) easily implemented.

Additionally, the following text may not be made into a link unless highlighted in visual mode:

être
Pokémon
ça
miałyście

Though it does not produce garbage text like with CJK characters.

.md file extension support

It is possible to add the .md file extension support so i don't have to rename all my files? I am accessing my .md files from other applications and i want them to recognise these are markdown files.

Support .md postfix

With this it would be possible to edit github/gitlab wikis locally and in markdown.

Opening wiki changes the working directory.

When I open the wiki from a session I'm currently working on, edit a wiki file, and quit the buffer, the working directory is changed. E.g.:

• open ~/test.py in neovim, edit, so current directory is ~/;
• open wiki (located in ~/documents/diary) with <leader>ww, edit wiki, exit buffer;
• return to ~/test.py. The working directory is now ~/documents/diary (i.e., it never changed back to ~/, which I would have thought would be the more intuitive behaviour).

[refactor] This is not a filetype plugin - remove syntax highlighting

As already discussed before in #8, #9, and #12, it makes a lot of sense to decouple the wiki part of this plugin from the syntax highlighting. Syntax highlighting is already provided by other plugins, such as:

• https://github.com/plasticboy/vim-markdown
• https://github.com/gabrielelana/vim-markdown
• https://github.com/vim-pandoc/vim-pandoc-syntax

We should therefore remove this from wiki.vim and focus on link actions and similar. There is a lot of obvious potential, e.g. to support different styles of links in a natural and dynamic manner, but the first step is to make clear what the plugin should provide.

In this regard, here is a short list of actions:

• Remove syntax highlighting from wiki.vim
• Allow to load wiki.vim for other filetypes, e.g. markdown files (perhaps with g:wiki_extensions variable)
• Add section on various Markdown syntax plugins in wiki.vim docs, preferably with a recommendation on the most mature syntax highlighting plugin

E37: Can't open link before you've saved the current buffer.

Thank you for creating and supporting this plugin.

I have a question about the way that the plugin works to create a new link, navigate to the link target, and return to the original page. New user of n/vim.

Environment: macos catalina 10.15.3, nvim 0.4.3, wiki.vim, wiki-ft.vim; plugins loaded by nvim default package manager.

Description

1. I expected this process to work in the same way as vimwiki, without having to manually save files before traversing new links. Namely, [cr] on text in normal mode to create link, [cr] to follow link to new page, enter text, [bs] in normal mode to return to the original page.

2. In my wiki.vim installation, however, it seems that the files must be manually saved before traversing links. On creating a link using [cr] and trying to navigate to the target with a second [cr], an error is thrown:

Error detected while processing function wiki#link#open:
line    8:
E37: Can't open link before you've saved the current buffer.
Press ENTER or type command to continue

Similarly, choosing backspace from the target page before the page is saved throws:

E37: No write since last change (add ! to override)

Therefore, my process in wiki.vim is more like [cr], :w, [cr], insert text, :w, [bs].

My question is whether this is the correct behavior (and usage) or not.

Minimal working example

Directory structure:

~/wiki
├── index.wiki
└── test.wiki

Tested with a minimal init.vim:

set nocompatible
filetype plugin indent on
syntax on
let mapleader=','
let g:wiki_root = '~/wiki'

Thanks for your help.

Suggestion: Split/Reduce WikiPrint functionality

This is just my personal taste and a very minor issue, but I'm not super happy with the behaviour of WikiPrint.

Complaints 😉

When I call :WikiPrint, I have 3 successive dialogues: View file, Print File and Export File.

I think dialogues are not the best interface in vim (very personal opinion).
My "Problem" with this is, that when I want to view the pdf and type 'y' when I'm asked "View file", It opens the pdf immediately (which is fine). But when I close the pdf viewer, I already have forgotten that I'm stil in the dialogue and wonder, why there is nothing happening in the buffer until I take a look at the bottom of the screen :-D

Suggestion

I would argue, that all the functionality could also be provided with a single command WikiGeneratePDF and an optional parameter for the export filename (if not given, use /tmp/.. as default).
Maybe the command should now open the pdf viewer, but nothing more. Printing can (and should IMHO) be done from the PDF viewer, which provides a interface for printing options. (Acutally I have never printed from vim).
(Besides that, I think that "printing" is not the primary functionality of the WikiPrint and therefore it should not be named like this.)

The command WikiGeneratePDF could then provide almost the same functionality with less interaction required.

Thanks for developing this nice plugin 👍!

Check box support

I really like the check boxes in the vimwiki plugin:

- [o] Do these things:
    - [X] This thing is done
    - [ ] Have yet to do this thing

Any plans on implementing support for them in this plugin?

V (visual mode) breaks link creation

Description

For link creation I like to hit V, so the whole line gets highlighted.
But on link creation there gets ^@ inserted at the end of the link.

The link works, but it link gets modified to a not intended string.

This does not happen with other visual selection.
ve<cr> works normal, as expected
<c-v>e works normal, as expected

Example

With the cursor on word entering V<cr> turns it into [[word^@]]

(This is somewhat important for me, to link files in folders.)

File creation based on parent folder

I am trying to learn how to use wiki.vim. Basically I want to create one folder per project and put all project-notes in its corresponding folder. But it seems like wiki.vim does not expect the folder of current wiki but create all wikis inside g:wiki_root folder.

Here is my wiki.vim settings:

let g:wiki_filetypes = ['md']
let g:wiki_link_extenstion = '.md'
let g:wiki_link_target_type = 'md'

Here is my example index.md:

1. [work](work)
2. [personal](personal)

Here is an example of work.md:

1. [project1](project1)
2. [project2](work/project2)

Right now, in work.md:

1. If I follow the project1 link, project1.md will be created in the g:wiki_root folder
2. If I follow the project2 link, project2.md will be created in the g:wiki_root/work folder

How can I specify relative path to current note when creating new files?

Here is another example: in both project1.md and project2.md:

# Meetings

1. [2020-02-05](2020-02-05)

This link will link to the same file under g:wiki_root/2020-02-05.md

Is there any way to make wiki.vim respect the folder of current wiki when creating new files? Otherwise I have to make sure to include the parent folder each time when I create a new link.

By the way, could you share some insights what is the better way to arrange notes for different projects? Do you put all of them inside the wiki root folder or create a folder to store notes for each projects?

Thanks!

Automatically generating a journal index file.

What is the recommended workflow to maintain an index file for the journal?
In vimwiki there is :VimwikiDiaryGenerateLinks (mapped to <Leader>w<Leader>i) that allows to easily generate and update an index file of the diary.

I saw that wiki.vim has :WikiJournalIndex. However, it only seems to work with the wiki and not the markdown syntax and most importantly it does not update an index file but adds the index to the current file.

So currently I would need to create an index file, open it and call :WikiJournalIndex to create the index. Then, when I write a new diary, I would have to open the file again, remove the content and call :WikiJournalIndex again. Is there a simpler way?

Escape of pandoc args causes trouble

The args parameter which is handed to pandoc is processed by escape (page.vim line 426).
This causes trouble, when for example setting the g:wiki_export struct to:

let g:wiki_export = {'from_format': 'markdown', 'args': '--template eisvogel', 'ext': 'pdf', 'view': v:false}

pandoc --template\ eisvogel -f markdown -o [...]
Shell output:
Unknown option --template eisvogel.^@Try pandoc --help for more information.^@

However, If I remove the escape() from the pandoc processing, everything works as it should do and it accepts the --template parameter

Pandoc with gfm format is not present in current Ubuntu stable

Apparently wiki.vim uses pandoc with gfm as input format.

wiki.vim/autoload/wiki/page.vim

Line 402 in 67368c9

call system('pandoc -f gfm -o'

Unfortunately, this input format is not present Pandoc 1.19 which is shipped with the current Ubuntu stable (18.04).
It works with a more up to date version or with the (deprecated) markdown_github format. But I don't know in which version of pandoc the gfm format was added.

Maybe a minimum required pandoc version number should be added to the help page.

WikiFzfTags and esc without selecting anything gives error

40_callback: Vim(let):E684: list index out of range 0

New name?

I'm considering a change of name, and would be happy for some feedback. /u/slugmanns commented on reddit that it could be wise, and one suggestion there was wikinotes. I've also been considering wiki.vim.

Are there other suggestions or comments on this from interested/possible users?

Configuration of `zot:` link handler

Currently, the handler for zot: links (Zotero) assumes that:

1. The search tool binary is named fd;
2. The Zotero folder is ~/.local/zotero.

The first is e.g. not the case on Ubuntu, where the binary is named fdfind to prevent name collision with a different fd tool. The second is not actually the default location of the Zotero directory (on my system it defaults to ~/Zotero if I install Zotero manually, and ~/snap/zotero-snap/common/Zotero if I install it via snap, so any other choice like ~/.local/zotero has to be configured manually.) Ideally, there should be config options for these: e.g. g:wiki_find_tool and g:wiki_zotero_root.

If these requirements are not met, trying to follow a zot: link in wiki.vim also fails silently. I think it could be useful with an error message in that case, so the user notices that e.g. fd is missing.

:CtrlPWiki errors

The command gives this error:

E117: Unknown function: ctrlp#wiki#id
E116: Invalid arguments for function ctrlp#init

I am using https://github.com/ctrlpvim/ctrlp.vim

Any ideas how I could debug this?

Disabling folding

I guess this is kind of a feature request. But here is hacky workaround:

let g:wiki_mappings_global = {
    \ '<plug>(wiki-link-open)' : '<c>tttt',
    \}
nmap <LocalLeader>w <plug>(wiki-index):set nofoldenable<cr>
au FileType wiki nmap<buffer><cr> <plug>(wiki-link-open):set nofoldenable<cr>

Cannot open URLs on macOS

The l:link.open function has xdg-open hard-coded:

wiki.vim/autoload/wiki/url/generic.vim

Lines 10 to 12 in 252f965

	function! l:parser.open(...) abort dict
	call system('xdg-open ' . shellescape(self.url) . '&')
	endfunction

For PDFs the proper program is selected based on the OS:

wiki.vim/plugin/wiki.vim

Lines 13 to 16 in 252f965

	let g:wiki_pdf_viewer = get(g:, 'wiki_pdf_viewer', get({
	\ 'linux' : 'xdg-open',
	\ 'mac' : 'open',
	\}, wiki#init#get_os(), ''))

Go back link behavior does not make sense

Description

When traversing down multiple files, pressing backspace to go back does not do what I expect it to. For instance, if I have a directory structure as follows:

/wiki/
└── index.wiki
└── folder
    └── file2
    └── folder2
        └── file3

And I traverse from index.wiki -> file2 -> file3, and then from file3 I go back, it will bring me to file2. However, upon going back once more, suddenly I am back in file3. Then another press will bring me back to file2 and then finally to index.wiki.

Expected Behavior

I expect the progress to be a stack, where pressing back brings me to the last item that I visted. Like a web browser back button. In this case, going from index.wiki -> file2 -> file3, I expect it to bring me back in the exact reverse order.

Support for creating TOCs for current chapter/section

I want to be able to create chapter/section local TOCs. Perhaps doing <leader>wt could ask to create a global or local list, or one could add <leader>wT for creating a local list.

Make folder links resolve to the index.wiki file

Description

Given the following folder structure:

~/wiki
├── index.wiki
└── subfolder
    └── index.wiki

With the top-level index.wiki:

[[subfolder/]]

Navigating through this link goes to ~/wiki/subfolder/.wiki. However, it seems like the intention is that it should navigate to ~/wiki/subfolder/index.wiki.

My current workaround is to have the link read: [[Refactoring/index|Refactoring/]].

instructions for running tests

I spent 10 minutes poking at the makefile but I can't figure out how to run the tests. I would update doc if I knew, so if you post quick instruction here i'll clean up and PR

Improvement: Customizable Pandoc Arguments

WikiGeneratePDF basically calls pandoc -f gfm -o mypage.pdf mypage.wiki. It might be interesting to change the arguments, for example to use pandoc templates.

Idea: add a variable like wiki_pandoc_arguments that defaults to -f gfm but can be changed for example to -f markdown_mediawiki --template awesometemplate.

This could be part of a solution for #24 :
Format flag defaults to -f markdown or -f gfm but can be changed via the variable.
Setting it by default to markdown should increase compatibility with old versions of pandoc.

[refactor] This is not a "do-it-all" plugin - are there more features that are provided elsewhere?

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:

• Creating table of contents from markdown syntax pages
• Creating and handling lists of todos
• Code snippets
  • Running code snippets (this does not even work as of now)
  • Text object
• Folding
• The journal part should probably be extracted as a dedicated addon to more clearly separate it from the main wiki code

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.

Top-centered view on link follow

wiki.vim/autoload/wiki/url/wiki.vim

Line 90 in 0f0556b

normal! zt

If a user has their vim setup configured to remember the previous line in a file, a top-centered view makes little sense, because it obscures information above the remembered line upon reentering a buffer.

It is very easy for a user to reinstate this feature to their liking:

au BufWinEnter *.wiki exec "normal! zt"

Though the above code does not work to override the plugin's centering unless one removes it manually from their local copy.

All considered, it seems better to leave the orientation of the window after following a link up to the user.

Using wiki.vim with MDwiki

Description

I'm looking to use the output of wiki.vim with MDwiki, but MDwiki expects the files to have a .md format, not .wiki.

I can get index.wiki to load properly, but setting up links just doesn't work :(

Is there any chance we can make the file format configurable for this?

MDwiki expects intra-content links to look like [link name](link_page.md). If I use the .wiki in the link portion, I get a page that doesn't render the markdown.

Maybe something like:

let g:wiki_file_format = '.md'

Thanks!

Warning if pandoc is not installed

Related to #24
If pandoc is not installed, WikiGeneratePDF fails without a warning.

Suggestion: Check if pandoc is installed and output an error message if not and WikiGeneratePDF is called.

Checking for a minimum required version would solve #24

Help to decide between using .md or .wiki extension

Thank you very much for this awesome plugin!

I would like to know which benefits there are for using the .wiki extension over using markdown files (.md).

I thought about using markdown files, because it is the standard that I see everywhere and I am familiar with.

Why is the default file type wiki and which advantages will I miss if I change it to markdown?

WhichKey Bindings

This is not an Issue.
I created a map with keybindings for https://github.com/liuchengxu/vim-which-key.

This is a matter of taste and not fully tested, but if somebody uses both plugins, it might be a starting point. So I'll just paste this here:

let g:which_key_map.W = {
      \ 'name' : '+Wiki',
      \ 'i' : ['<plug>(wiki-index)', 'Index'],
      \ 'o' : ['<plug>(wiki-open)', 'Open'],
      \ 'j' : ['<plug>(wiki-journal)', 'Journal'],
      \ 'd' : ['<plug>(wiki-page-delete)', 'PageDelete'],
      \ 'r' : ['<plug>(wiki-page-rename)', 'PageRename'],
      \ 'E' : ['<plug>(wiki-export)', 'Export'],
      \ '/' : ['<plug>(wiki-fzf-pages)', 'FzfPages'],
      \ 'g' : {·
      \   'name' : '+ Graph',
      \   'b' : ['<plug>(wiki-graph-find-backlinks)', 'Find Backlinks'],
      \   't' : ['<plug>(wiki-graph-in)', 'Graph to current Page'],
      \   'f' : ['<plug>(wiki-graph-out)', 'Graph from current Paget'],
      \  },
      \ 'J' : {·
      \   'name' : '+ Journal',
      \   'i' : ['<plug>(wiki-journal-index)', 'Create Index'],
      \   'I' : ['<plug>(wiki-journal-index-md)', 'Create Index md-style'],
      \   'n' : ['<plug>(wiki-journal-next)', 'Next'],
      \   'p' : ['<plug>(wiki-journal-prev)', 'Prev'],
      \   'cn' : ['<plug>(wiki-journal-copy-tonext)', 'CopyToNext'],
      \   'w' : ['<plug>(wiki-journal-toweek)', 'To Week Summary'],
      \   'm' : ['<plug>(wiki-journal-tomonth)', 'To Month Summary'],
      \  },
      \ 'l' : {·
      \   'name' : '+ List',
      \   't' : ['<plug>(wiki-list-toggle)', 'Toggle item'],
      \   'u' : ['<plug>(wiki-list-uniq)', 'Remove duplicates'],
      \   'U' : ['<plug>(wiki-list-uniq-local)', 'Rem. duplicates local'],
      \  },
      \ 'L' : {·
      \   'name' : '+ Link',
      \   'n' : ['<plug>(wiki-link-next)', 'Next'],
      \   'p' : ['<plug>(wiki-link-prev)', 'Prev'],
      \   'o' : ['<plug>(wiki-link-open)', 'Open'],
      \   's' : ['<plug>(wiki-link-open-split)', 'Open in Split'],
      \   'b' : ['<plug>(wiki-link-return)', 'Back to prev. page'],
      \  },
      \ 't' : {·
      \   'name' : '+ Tag/ToC',
      \   'l' : ['<plug>(wiki-tag-list)', 'List'],
      \   'r' : ['<plug>(wiki-tag-reload)', 'Reload'],
      \   's' : ['<plug>(wiki-tag-search)', 'Search' ],
      \   't' : ['<plug>(wiki-page-toc)', 'Page ToC'],
      \   'T' : ['<plug>(wiki-page-toc-local)', 'Page ToC Local'],
      \  },
      \ }
      " Unused:
      " \ 'r' : ['<plug>(wiki-reload)', 'Reload'],
      " \ '' : ['<plug>(wiki-code-run)', 'CodeRun'],
      " \ '' : ['<plug>(wiki-fzf-toc)', 'FzfToc'],

changing wiki file extension

Thank you for creating wiki.vim -- viable and clean alternative to vimwiki! In my setup .wiki
file extension is reserved for vimwiki with its traditional file-type and syntax.

How can I reconfigure wiki.vim to use a file extension other than .wiki?

To make this task harder, .wiki file extension is hard-coded in quite a few places throughout the code base - see files link.vim, page.vim, template.vim.

Thanks,
--Leo

Wrong link recognition

Hi,

I noticed that the regex matcher recognizes links in checkbox lists that aren't actual links when using a markdown wiki.

Example:

- [o] [Link](...)
- [o] []()
- [] [] <--- is sufficient
keywords: [ This, is, recognized, as, a, link ]

E715 and broken wiki.vim

I've been using your wiki.vim plugin, and really enjoying it - I'm excited for where it is going. However, three or so days ago, an update broke it on my end, and despite the various updates since, it still throws up errors. Specifically, when opening neovim, I get

Error detected while processing function wiki#init#option[5]..wiki#u#extend_recursive:
line    7:
E715: Dictionary required

Once neovim opens, if I try to open the index, I get the following error:

Error detected while processing function wiki#buffer#init:                                                                                                                                                 
line   12:
E121: Undefined variable: name
E116: Invalid arguments for function printf
E15: Invalid expression: printf('%s/%s', b:wiki.root, g:wiki_journal.name)

although the index then opens, but then I can't follow links from there (by pressing Enter). If I try to open the journal, I get

Error detected while processing function wiki#journal#make_note:                                                                                                                                            
line    1:
E121: Undefined variable: date_format
E116: Invalid arguments for function strftime
E15: Invalid expression: (a:0 > 0 ? a:1 : strftime(g:wiki_journal.date_format[g:wiki_journal.frequency]))

This happens when using the following minimal init.vim:

filetype off                   " required!

" Vim-Plug.
call plug#begin('~/.config/nvim/bundle')

" Github repos
Plug 'lervag/vimtex'
Plug 'lervag/wiki.vim'

call plug#end()

" wiki.vim
let g:wiki_root = '~/notes'
let g:wiki_filetypes = ['md']
let g:wiki_link_extension = ['md']
let g:wiki_journal = 'diary'
let g:wiki_pdf_viewer = 'zathura'

let g:wiki_link_target_map = 'MyFunction'

function MyFunction(text) 
  return substitute(tolower(a:text), '\s\+', '_', 'g')
endfunction

New Tags are only found after vim restart

I add a Tag to an existing wiki page and safe the file (buffer is still open). When I now do WikiTagReload and WikiTagSearch mytag, the page is not listed.

However, when I restart vim and do the same, the tag is found as expected.

In other words: I have to restart vim in order make changes to tags happen.

(Using neovim on MacOS)

Improvement: Utilize other export formats in WikiGeneratePDF

As already mentioned in #21

WikiGeneratePFD basically calls pandoc, which will generate the pdf. However, pandoc can generate much more different formats than pdf by changing the suffix of the ouput file. This already works in wiki.vim:
WikiGeneratePDF mypage.html generates a html page.

Idea: (once more) rename WikiGeneratePDF to WikiExport and adapt the description. The default for pdf is fine.

[feature] Organization of Pages with Categories or Tags

This plugin is actually quite nice!
I started a wiki and it feels like a very good system to take notes.
But now I stumbled over the problem, that I want to create some kind of overview pages.
Example: all notes about/related to ProjA. At the moment, I have to track them manually.

I don't have a final idea of how it should look like, but I think of some kind of category or tag system.
I imagine adding [[Tag:ProjA]] to a Wiki page and then inserting/updating a list of all the pages with this tag in the ProjA overview automatically or at least manually.
(Simmilar to the journal functionality)

Bonus Idea: Maybe even organizing the files in folders according to the categories? But I guess this does not work (or is at least complicated - symlinks) if a page can have more than one category...

Journal commands create Norwegian(?) date names

When I create a journal monthly page by using WikiJournalToMonth, It adds the the caption in norwegian:

Samandrag fra mars 2019

The same happens with the month names in the output of WikiJournalIndex

Apparently the date names are hardcoded in norwegian(?).

Additional Issue (maybe I have to create a new issue):
Using WikiJournalToWeek creates a buffer with the filename 2019_wdate: illegal time format.wiki

[feature] Custom function/map to translate selected text to link target/url

This was suggested by @BonaBeavis in #12.

The idea is to allow a custom map or function that is applied in order to transform the selected text when creating a new link.

Presently, if one selects Some text and creates a link with the <cr> visual mode mapping, the link becomes [[Some text]], i.e. the same text is used for the link target. The proposal is to allow a user to customize this, e.g. with:

let g:wiki_link_target_map = "MyFunction"

function MyFunction(text) abort
  return substitute(tolower(a:text), '\s\+', '-', 'g')
endfunction

With this configuration, the result of pressing <cr> on Some text would now be [[some-text|Some text]].

Fix mappings for link url text objects in readme

Awesome job on wiki.vim! I really appreciate your approach.

Line 69 in README.md

  - Text objects
    - `il al` Link url
    - `it at` Link text

... should be changed to:

  - Text objects
    - `iu au` Link url
    - `it at` Link text

il al -> iu au

Just a tiny typo, yet one that I didn't become aware of until reading through the source for the text objects ;-)

Citation links

Pandoc Markdown supports citations with the pandoc-citeproc extension, which works via the following basic syntax. For a citekey ouassou2018, the text @ouassou2018 did some stuff [@ouassou2018] would get translated to e.g. "Ouassou (2018) did some stuff (Ouassou, 2018)." Exactly how it is formatted of course depends on what options you use for the reference list (export format, reference format, etc.) The references can e.g. be provided via bibtex. As described in the link above, multiple citations can be combined using a semicolon; so [@ouassou2018a; @ouassou2018b] is interpreted as one citation of two sources.

I think it would be interesting if the same syntax was supported in wiki.vim. Basically, we now have the syntax [reference](zot:citekey) available to cite entries in a Zotero database, which is useful. However, if you want to export parts of your wiki notes to some other format via pandoc, you currently have to manually convert these citations to the pandoc format. All the information is already there - it's just in a different and incompatible format. Also, if you write some MarkDown for export with pandoc, and some private notes with wiki.vim, having to switch between two different syntaxes for MarkDown citations is perhaps not ideal.

The simplest implementation would probably be to just add the @citekey format as a synonym for [citekey](zot:citekey). But if you also add support for the bracket syntaxes [@citekey] and [@citekey1; @citekey2], I think each citekey can be handled in the same way; so if you were to add support to WikiLinkOpen for @citekey, you just have to let it work also inside brackets as well.

I don't know how the code is setup, but the latter might require adding a rule that a link matching the regexp \[@.*\] is not considered a bottom-style link. (This could probably be combined with the heuristic suggested in another issue #59 regarding recognizing MarkDown checkboxes.)

E716, this plugin is language dependent

When on a word (default mappings) an Error msg appears and no link is created

Zeile    4:
E716: Schlüssel nicht in Dictionary enthalten: open, a:000, l:link)
E116: Ungültige Argumente für die Funktion call

trying to get a translated error msg:
$ export LC_ALL=C

-> no error appears, links and pages created accordingly.

however, setting
let g:wiki_link_target_type = ['md']
breaks then again with:

_word[44]..wiki#link#template_pick_from_option:
line    6:
E730: using List as a String
E116: Invalid arguments for function call
E15: Invalid expression: call('wiki#link#template_' . g:wiki_link_target_type, a:000)

I'll provide a minimal working example if needed. But it already took me a while to figure the problem after moving from another wiki plugin.

edit/ my (updated) plugin config:

Plug 'lervag/wiki.vim'
Plug 'lervag/wiki-ft.vim'

let g:wiki_root = '~/datenspeicher/documents/wiki/vimwiki'
let g:wiki_link_target_type = 'md'
let g:wiki_filetypes = ['md']
let g:wiki_journal = {'name': 'diary'}

Is there any way to template new wiki pages?

It's very possible that this is already a feature, and I just don't realize it, but is there any way to set up the default for new pages? For example, I turn the text "Example Page Here" into a link, and open it.

Observed behavior: empty document

Expected behavior: A document starting with a level 1 heading containing the name of the link, and maybe a few new lines. Ideally, it would all be configurable beyond that, but that seems like a solid minimal default.

Refile function

I think it would be useful to have to have a function in wiki.vim similar to org-refile in Emacs' org-mode. The way it would work is as follows. If we e.g. have a MarkDown file like this:

# Inbox
## Foo
Random text here.
## Bar
More random text here. 
### Subheading
More here.

# Tasks
## Baz
Even more random text here.

# Someday
## Qux
More text.

Then having the cursor in the subsection "Bar" and activating a "refile" function should give a fuzzy-search popup similar to WikiFzfToc, that lets you pick a different heading (e.g. "Tasks"). When you do that, you should get something like this:

# Inbox
## Foo
Random text here.

# Tasks
## Baz
Even more random text here.
## Bar
More random text here. 
### Subheading
More here.

# Someday
## Qux
More text.

This is particularly useful for GTD-type workflows, for moving tasks between headings efficiently. But it can also be useful for working with structured notes in general, as it makes it easy to "refactor" notes.

Just being able to refile between same-level headings (e.g. moving "Foo" from "Inbox" to "Tasks" or "Someday" in the example above) would already be very useful. Org-mode refiling also supports refiling between multiple files (so that you can let the Inbox and Someday be different note files instead of different headings), and refiling between different levels (e.g. moving Bar inside Qux, in which case ## Bar becomes ### Bar and ### Subheading becomes #### Subheading).

Can't generate weekly journal summary with `:WikiJournalToWeek`

I want to write daily journal entries and then use :WikiJournalToWeek in order to create a weekly summary. When doing so, instead of a weekly summary markdown file (expected) my journal directory contains a folder with name 'date: invalid date ‘' (observed).

My wiki.vim configuration looks as follows:

let g:wiki_root = '~/wiki'
let g:wiki_filetypes = ['md']
let g:wiki_link_extension = '.md'
let g:wiki_link_target_type = 'md'
let g:wiki_pdf_viewer = 'zathura'
let g:wiki_list_todos = ['TODO', 'DOING', 'DONE']

[bug/feature]: overwrite <c-s> binding in insert mode

I would like to use the default key mappings that come with wiki.vim but overwrite some of them.
I've used g:wiki_mappings_global to customize global mappings.
Specifically, I want to overwrite the standard <c-s> binding.

" WIKI.VIM
let g:wiki_mappings_global = {
      \ '<plug>(wiki-list-toggle)' : '<c-w>',
      \}

Expected behavior:
Wiki.vim respects the customization in insert mode and normal mode.
Expected output of :imap <c-w> (within a wiki file with above customization options):

i <C-W>   @<Plug>(wiki-list-toggle)

Observed behavior:
Wiki.vim accepts the customized key binding in normal mode, but using <c-s> within a wiki file still triggers the wiki-list-toggle plug in insert mode.
Output of :imap <c-w> (within a wiki file):

No mapping found

Output of :imap <c-s>:

i <C-S>   @<Plug>(wiki-list-toggle)

Minimal working example

let g:wiki_root                  = '~/wiki'
let g:wiki_filetypes             = ['md']
let g:wiki_link_target_type      = 'md'
let g:wiki_mappings_global = {
      \ '<plug>(wiki-list-toggle)' : '<c-w>',
      \}

/~wiki
├── index.md
├── log
│   └── 2017-11-24.md
└── test.md

NeoVim:

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5

Thank you for creating this plugin, it's very useful!

calling <plug>(wiki-journal-next)

I have set up wiki.vim to use weekly journals with

let g:wiki_root = '/home/myname/Notes'
let g:wiki_filetypes = ['md', 'markdown', 'markdown.pandoc']
let g:wiki_list_todos = ['TODO', 'DOING', 'DONE']
let g:wiki_link_extension = '.md'
let g:wiki_link_target_type = 'md'
let g:wiki_template_title_week = '# Uke %(week) - %(year)'
let g:wiki_journal = {
    \ 'name': 'journal',
    \ 'frequency': 'weekly',
    \ 'date_format': {
    \   'daily' : '%Y-%m-%d',
    \   'weekly' : '%Y_w%V',
    \   'monthly' : '%Y_m%m',
    \ },
    \}

While inside vim,<leader>w<leader>w (<plug>wiki-journal) opens the current weeks journal, and <C-k> (<plug>(wiki-journal-next)) opens the next journal entry and <C-j> (<plug>(wiki-journal-prev)) opens the previous journal entry as expected. But, if I open the current weeks journal directly from the terminal, e.g. vim /home/username/Notes/journal/2019_w16.md and enter <C-k> (<plug> (wiki-journal-next) or <C-j> (<plug>(wiki-journal-prev)), either nothing happens or a new buffer is created with the path /home/username/Notes/journal/journal/2019_w16.md. Have I configured something wrong or is this a bug?

Anyways, thank you for wiki.vim. I previously used vimwiki, but this plugin suits all my needs and nothing more.