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

Support Wikilinks #15

Open
Rubiginosa opened this issue Dec 4, 2024 · 3 comments
Open

Support Wikilinks #15

Rubiginosa opened this issue Dec 4, 2024 · 3 comments

Comments

@Rubiginosa
Copy link

I see in #14:

I have never used the Wikilink syntax, so I'm not really inclined to integrate it, unless there is significant demand or someone creates a PR.

Like others I use this plugin to mitigate vim's conceal problems, and I happen to have a lot of files with aliased links, like [[path/to/file|arbitrary text]]. I think the capability to handle these links directly in link.vim without a search-and-replace would be a neat improvement.

@qadzek
Copy link
Owner

qadzek commented Dec 5, 2024

I use this plugin to mitigate vim's conceal problems

Good to hear that this plugin has been helpful.

I happen to have a lot of files with aliased links, like [[path/to/file|arbitrary text]]

In which filetype do you use these links? Markdown?

I think the capability to handle these links directly in link.vim without a search-and-replace would be a neat improvement.

I'm not familiar with Wikilink syntax. Does it offer any advantages over Markdown syntax?

Wiki.vim provides the WikiLinkTransform command to convert a single link such as [[foo|bar]] to [bar](foo) and vice versa. I'm sure we can come up with a sed one-liner to convert all your Wikilinks in one go.

Wouldn't converting all your existing links and using Markdown syntax for future links be a better solution?

Supporting an additional syntax in link.vim might be tricky, especially since Wikilinks can take different forms, like your example [[path/to/file|arbitrary text]] or without the pipe, such as [[Three laws of motion]]. The latter apparently converts to [Three laws of motion](Three%20laws%20of%20motion.md).

I'll ping @einarpersson as he first mentioned this syntax in #14.

@Rubiginosa
Copy link
Author

In which filetype do you use these links? Markdown?

Yes, I am using wiki.vim with markdown files.

I'm not familiar with Wikilink syntax. Does it offer any advantages over Markdown syntax?

I'd say it does—for links without an alias, it's a little more ergonomic to type and easier to parse in plaintext.

Wouldn't converting all your existing links and using Markdown syntax for future links be a better solution?

possibly! Assuming vim's conceal never gets improved, I'll probably migrate over everything eventually.

I'm sure we can come up with a sed one-liner to convert all your Wikilinks in one go.

For sure—%s/\[\[\(.\{-}\)|\(.\{-}\)\]\]/[\1](\2)/g works well enough for my use. If you think it's out of scope then this issue should probably be closed. Thanks for responding!

@qadzek
Copy link
Owner

qadzek commented Dec 13, 2024

I'd say it does—for links without an alias, it's a little more ergonomic to type and easier to parse in plaintext.

For this limited use case, I agree that there are some small benefits.
For URLs (the main focus of this plugin), I assume you would always want to add a label: [GitHub](https://github.com) or [[https://github.com|GitHub]].
For files, [[recipes]] is indeed easier to type than [recipes](recipes.md). If you use wiki.vim however, you only need to type recipes, press Enter while the cursor is on that word, and it will be automatically converted to [recipes](recipes.md).

Assuming vim's conceal never gets improved

I wouldn't count on it, as it's a very old bug: vim/vim#260 😄

If you think it's out of scope then this issue should probably be closed.

I will leave it open for now so others can chime in as well. I might add this in the future. The benefits seems rather small in my opinion, but it could help onboard new users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants