feat: allow gx to function for markdown links

[dundargoc]

In other words, gx works regardless of where it was used in
[...](https://...). This only works on markdown buffers.

[ribru17]

Since the markdown parser is bundled could we use Tree-sitter for this? The downside is that maybe the grammar changes (affecting the node names) but it seems like this could be easier:

  local current_node = get_node { ignore_injections = false }
  while current_node do
    local type = current_node:type()
    if type == 'link_destination' then
      return do_open(vim.treesitter.get_node_text(current_node, 0))
    elseif type == 'inline_link' or type == 'image' then
      return do_open(vim.treesitter.get_node_text(current_node:named_child(1), 0))
    elseif type == 'link_text' or type == 'image_description' then
      return do_open(vim.treesitter.get_node_text(current_node:next_named_sibling(), 0))
    end
    current_node = current_node:parent()
  end

[dundargoc]

Since the markdown parser is bundled could we use Tree-sitter for this?

I dunno if there's any problems with that, I'll need to ask the ts squad: @neovim/treesitter

[dundargoc]

Yes, if the language name is not equal to the filetype (or registered as an alias), you need to specify it explicitly.

Syntax aside, is relying on the markdown parser acceptable in this case?

[lewis6991]

What is the benefit in using the Markdown parser? This seems easy enough to parse manually.

[ribru17]

@lewis6991 No real reason if it is easy enough to parse manually; that said I do think the code looks a bit simpler (and using the parser would handle cases with escaped \) or \] that I think needs to be handled specially and might not work with the current manual code (not 100% sure about this))

[ribru17]

Also the inline parser is pretty flat so traversing up nodes like that (only needed when there is e.g. an emphasis node inside the link text node) won't be too expensive

[dundargoc]

I tried the treesitter suggestion (with some adjustments to get rid of type warnings). It works as expected. I suspect this might be more robust than my initial PR. Thanks for the suggestion.

I will leave this up for a bit to see if there are more input on this.

[dundargoc]

Edit: Also should this code check first if the user is in a markdown buffer? I think if this is run on another filetype it will still try to parse it and then potentially return back some nonsense nodes (if there happens to be text that the inline parser can process). E.g. I tried running this on CMakeLists.txt and it sometimes thought I was in a shortcut link, if there was a string like [[ ... ]]

I see what you mean. The parser thinks the text inside [[ ]] is a link_text. This did cause a problem before when we explicitly matched for link_text, but if we only look for inline_link like we do now the problem seems to go away.

[ribru17]

Ah I see; but couldn't it be the case that there happens to be some language using some weird [...](...) syntax that will still affect the current version?

[dundargoc]

Theoretically, yes. But I still wonder if the benefit of always enabling this isn't greater than the potential clash with a language that may or may not exist. I certainly can't come up with any. I don't think this decision is irreversible, if we notice it causes any problems for some filetype we can further evaluate and iterate on this. I'm not dead set on either approach though, so input welcome. @justinmk any thoughts?

[justinmk]

Tested locally. It works, but it seems that the parse tree gets "stale". If I use gx on [foo bar baz](https://example.com/?a=1&b=2) then make random edits and try gx again, then undo and try again, ... the results are just random.

Possibly #28715 is needed, or just need to re-parse. Or maybe we should use vim.treesitter.get_string_parser() instead?

[icholy]

Would it be possible to export this as a callable function? Or add a way to hook into it?

I maintain a plugin which adds support for LSP document links. It has a gx function which opens the link under the cursor or falls back to the default <cfile> behaviour if one doesn't exist.

If this change goes in as-is, I no longer have a simple way to fallback to the default.

[dundargoc]

I've created module vim.url and added the function _get_url(). Underscore to mark it private. I don't particularly care where this is added, I just chose something. If someone wants this somewhere else that's fine by me.

[dundargoc]

Future improvements:

• Allow links without "https", e.g. using gx on "github.com" doesn't work.
• (Optional) upstream https://github.com/icholy/lsplinks.nvim or a variation of it. Unsure if it's useful enough to upstream in core though, seemed kinda niche.

[icholy]

@dundargoc FYI vscode is using LSP document links to implement this functionality for markdown files https://github.com/microsoft/vscode/tree/main/extensions/markdown-language-features/server