Skip to content

feature: wiki style media links for obsidian.nvim #410

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

Closed
neo451 opened this issue Apr 24, 2025 · 5 comments
Closed

feature: wiki style media links for obsidian.nvim #410

neo451 opened this issue Apr 24, 2025 · 5 comments
Labels
enhancement New feature or request

Comments

@neo451
Copy link

neo451 commented Apr 24, 2025

Is your feature request related to a problem? Please describe.

Before:

Image

After:

Image

Describe the solution you'd like

Image Links

Should be what ![hi]() will render into

Image

Obsidian app supports this syntax, in the past we have been only using markdown syntax for obsidian.nvim's image pasting capability, but in order to be more consistent, I want to resolve this issue: epwalsh/obsidian.nvim#582, but I do need renderers to work with us here and resolve this rendering issue.

Media Links

obsidian app supports these formats for attachments, and obsidian.nvim is intending to support them all: obsidian-nvim/obsidian.nvim#77

So it would be nicer if the ![[name.ext]] can get conceal based on the ext, i.e. videos have a tv icon and audios have a headphone icon etc.

Describe alternatives you've considered

I can also work with is you can point me to some API to register these capability ourselves :)

Additional information

No response

@MeanderingProgrammer
Copy link
Owner

Your after looks rather strange, the !, [, and ] characters should all be hidden after rendering as is. Is something modifying the conceal level or are you using custom (not shipped by nvim-treesitter) highlights?

MeanderingProgrammer added a commit that referenced this issue Apr 25, 2025
## Details

Request: #410

Avoids rendering links if they contain a nested `shortcut_link`. This
avoid the double placement of icons and instead only uses the
`shortcut_link` based rendering. A link in a link will have the same
structure as a `wikilink` so really that is the rendering logic that
will ultimately get used.

To then allow a larger variety of icons to be configured have also
expanded custom link functionality. They now have 2 additional optional
properties, `kind` & `priority`.

- kind: changes how the pattern is matched against link destinations
  - pattern: uses the existing lua pattern mechanism, is also the
    default behavior if no value is set to avoid any breaking changes
  - suffix: when set does a simple `vim.endswith` check, can be used to
    easier support file extension matching
  - because of how this is setup adding more kinds should be trivial
- priority: used when multiple patterns match a destination to decide
  which to use, highest value wins, allows users more control rather
  than being stuck with current behavior, uses the length of the pattern
  if no value is set to avoid any changes to behavior out of the box
@MeanderingProgrammer
Copy link
Owner

I've done a couple things to improve the behavior here: 6910fe1

First was removing the extra image icon before the wiki link icon, instead the rendering only does the wiki link step now.

Second is adding the ability to add suffix based icons, I can add more defaults out of the box but would like you to provide the extensions & icons we should use.

The config will look something like:

require('render-markdown').setup({
    link = {
        custom = {
            pdf = { kind = 'suffix', pattern = '. pdf', icon = '' },
        },
    },
})

Currently we provide values for various urls: https://github.com/MeanderingProgrammer/render-markdown.nvim?tab=readme-ov-file#links

LMK the full list of extensions and icons you would like and I can add them!

@neo451
Copy link
Author

neo451 commented Apr 26, 2025

Ok I know the issue now, I have been using the minimal.lua in our repo to test, and I did not setup nvim-treesitter in it.

Then it is the issue with non-ts functionalities, I am actually surprise it works without tree-sitter, so maybe look into it if you want?

@neo451
Copy link
Author

neo451 commented Apr 26, 2025

@MeanderingProgrammer
Copy link
Owner

Then it is the issue with non-ts functionalities, I am actually surprise it works without tree-sitter, so maybe look into it if you want?

This plugin doesn't need nvim-treesitter as a dependency exactly, it just needs the markdown treesitter parser to be on your runtime path to work. Since 0.10.0 (I believe but maybe earlier) neovim ships with the markdown parser builtin so nvim-treesitter isn't really necessary at all for basic functionality.

But to have decent rendering you should enable highlights, which is where various concealing behavior comes from, and that either requires you to write an autocommand or use nvim-treesitter with the highlights module enabled.

I would add the following to your minimal.lua:

local plugins = {
    {
        'nvim-treesitter/nvim-treesitter',
        build = ':TSUpdate',
        config = function()
            require('nvim-treesitter.configs').setup({
                ensure_installed = { 'markdown', 'markdown_inline' },
                highlight = { enable = true },
            })
        end,
    },
    {
        'MeanderingProgrammer/render-markdown.nvim',
        dependencies = {
            'nvim-treesitter/nvim-treesitter',
            'echasnovski/mini.nvim',
        },
        opts = {},
    },
}

the full list of extensions is here: https://github.com/obsidian-nvim/obsidian.nvim/pull/77/files#diff-7e9c3a063e52368102db4dac1a30553ce690c09d879bee7b6d7940eaadaf21a7

Please provide the extensions & icons as a table in a comment. Something like:

Extension Icon
pdf
... ...

Marking as complete, will add the icons if provided.

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

No branches or pull requests

2 participants