Support Wikilink syntax

[daniel-vera-g]

I was planning to use this Plugin as lightweight Vimwiki (Actually wiki.vim) alternative because I actually only used the file/link navigation.

Nevertheless, I saw that Wiklinks( [[wikilink]]) are not supported or I did not find the configuration. As I mainly use Obsidian and telekasten support for this would be great.

I could think of this as a config like in wiki.vim.

[jakewvincent]

Seeing as this is an existing extension to Markdown, I think wiki syntax-style links is within the scope of this plugin, so I hope to implement this at some point. I'll post here when I have this ready for testing @daniel-vera-g.

[jakewvincent]

@daniel-vera-g I just pushed this to the dev branch if you'd like to test it. If you're using packer, you can do a :PackerSync after specifying the dev branch and changing the link_style config option to wiki (example below). There is some documentation in the dev branch's readme. Most pertinent is probably the title-after-pipe format, which I am guessing is more common than title-before-pipe. That might need to be an additional config option.

use({
    'jakewvincent/mkdnflow.nvim',
    branch = 'dev',
    config = function()
        require('mkdnflow').setup({
            -- ...
            link_style = 'wiki',
            -- ...
        })
    end
})

[gregdezeeuw]

I've been testing out the wiki style links, no issues so far. Thanks for adding it.

It'd be nice if there was syntax to highlight the wiki links. I went back to using treesitter for markdown to give the wiki links some highlighting, but I'd ditch it again if it had some without it. No worries if you don't intend to add syntax for it, just a thought.

[jakewvincent]

That's good news @gregdezeeuw, thanks for trying it out! I don't currently have plans to add syntax highlighting, but I'll consider it. Does highlighting without treesitter otherwise seem acceptable?

[gregdezeeuw]

Aside from wiki links, there isn't any highlighting I'm lacking. Well, I would appreciate some highlighting for the ToDo status symbols, but that is super minor.

Thanks again for the plugin.

[jakewvincent]

Aha, after adding the to-do status commands was when I first had the urge to add some special highlighting for to-do statuses, but I haven't looked into it yet. I'll comment here if I end up adding it.

Glad you find the plug-in useful!

[jmbuhr]

Sorry to reopen this, would it be possible to have a wikilink syntax without the additional name part ( | ...)? This would make it work with logseq, which I believe is a perfect match! https://logseq.com/

[jakewvincent]

Hi @jmbuhr, the syntax without the name actually does already work (as in the links are followed), but do you mean that you'd like to have an option where links created from the word under the cursor and such are created without the additional name part of the link?

[jmbuhr]

Yes, this is what I had in mind. It wouldn't be a good default option because it breaks the reversibility of "plain text" -> "link" for links whose name has more than one word and capitalization, but it would be a very helpful option.
I played around a bit more and I think in order for these links and the links from the logseq tool I mentioned to be interoperable I would need and additional option, like a hidden_prefix such that all pages are created in a folder called pages and links automatically reference to that folder wihout saying so. Or a user-defined function that processes links.

Would you be open to a PR if I added this as an option?

Example link behaviour in logseq, which has two folders, journals and pages:

• [[Hello World]] points to a document pages/Hello World.md from anywhere
• [[May 7th, 2022]] points to journals/2022_05_07.md from anywhere.

[jakewvincent]

I see... interesting! I'm definitely open to a PR if you wanted to try to implement this. I like the idea of a user-defined function for processing links. A similar idea would be to allow the user to arbitrarily specify rules of interpretation, where if some pattern is matched in a link, a certain string modification is made (implicitly) before the link is interpreted. I sort of like the former for its flexibility. I'm imagining that the pathHandler function (in paths.lua and paths_windows.lua) would see if an interpretation function is provided in the config, and if one is, it would use it to implicitly modify a link in any arbitrary way before interpretation. I guess if something like this were implemented, a config option like the following might work for your use case?

local format_date = function(string)
    -- Change date string to formatted date
end
require('mkdnflow').setup({
    links = {
        interpret = function(input)
            if input:match('%u%a+ %d+%a%a, %d%d%d%d') then
                return('journals/'..format_date(input))
            else
                return('pages/'..input)
            end
        end
    }
})

[jmbuhr]

Sounds great, thanks for the implementation hints already!