.md file extension support about wiki.vim

[lervag]

Yes, this should be possible. I am actually considering to use this plugin as my main plugin for markdown files in general, myself. Still, it should be mentioned that the markdown flavour is not really very well defined (sorry!).

In any case, in the meantime before I push a better solution, this should work:

augroup my_ftdetect
  autocmd!
  autocmd BufRead,BufNewFile *.md set filetype=wiki
augroup END

[lervag]

Just for future reference (when I get the time to consider an implementation), I am thinking something along these lines:

• By default, we only consider .wiki files in a directory structure that has some index.wiki file.
• I'll implement an option to allow one or more custom file extensions, e.g. g:wiki_extensions = ['wiki', 'md']. One would still need to detect an index.<ext> file.
• I'll add an option to specify the index.wiki behaviour; one could use a different name, or perhaps not really care about having an index file at all. In this case, one would either have to specify the root directly, or choose an way to detect the root folder (e.g. the "inner most" directory that contains a filetype with the specified extension(s)).

Note, if we use this plugin to handle markdown files, it might lead to a clash if one also has other plugins for markdown files. In the first iteration, I will assume that one does not try to combine this with other filetype plugins.

[lervag]

Ok, I've been thinking. I don't want to make this plugin be a markdown plugin in general. For that, there are multiple alternatives, where many of them are probably better.

The point of the plugin is mainly to be a good note taking plugin that builds on the wiki principal. That is, creating and using interwiki links should be very simple, and it should use simple syntax and have support for other stuff that are nice to have for note taking. In time, I might slowly adapt to support the pandoc markdown syntax, see #9.

But for now, I want to focus on smaller issues. If you still want to use this plugin for .md files, then I think my suggested autocommands above should work, and if there are problems I'll be happy to address them. But I want to keep the .wiki extension fixed for now.

[emKaroly]

In the point about clashing of .md plugins you are absolutely right. I also experienced this thing. In case of vimwiki i removed the other markdown plugins because vimwiki handled everything what i need related to markdown.

This point is the reason why i think these wiki plugins should be separated from markdown stuff as much as it is possible and do only the linking all kind of files together (not only .md but pictures, pdf whatever you want) searching, taging organizing, creating indexes etc.

For example when i do some kind of project i make a .md file where i put my notes but also link the .pdf files as sources from where my notes comes from. For example i copy the relevant stuff from API documentation but also link the .pdf so i can open it with ENTER if i need to check out other things.

That’s why i think the .wiki files should be used only for the plugins internal stuff like indexes and let people use all their .md files.

I think if someone is searching for this kind of solution they already use .md for this stuff and what they need a central place where they can effortlessly navigate between these files and force them to rename and reorganize all the stuff they.

[lervag]

Yes, I tend to agree with you, at least in a sense. I've used the .wiki extension for my own personal wiki, which currently has > 100 000 lines of various notes and journal entries. This is mostly/all written in some flavor of markdown. I think it should be possible to separate the markdown specific features from the wiki specific features in an effective manner such that wiki.vim could be used together with any good markdown plugin. But it will take some time.

As a first step, I think that it makes sense to decouple the syntax highlighting as suggested by @kwrobert in #9. I will probably look into this when I get the time.