Variable request: {{selected_link}} (containing link/path in the current line)

[neongreen]

description

It would be cool to have a variable, eg. {{selected_link}}, that would give me the link/path in the current line.

If there are several — it should return the one under caret, or maybe the one closest to the caret.

If it's an internal link (eg. to a file in the vault), it should be resolved.

usecase

I want to create a command like "open in a specific app". For example:

In this situation, {{selected_link}} would be the path to IMG_0704.jpg, and I could pass it to open -a path/to/app {{selected_link}}.

Since there is only one link, the caret could be anywhere on the line and {{selected_link}} would be the same.

misc thoughts

Maybe there should be {{selected_link:title}} and {{selected_link:url}}, although I only need the latter.

Maybe there should also be a distinction between external links / internal links / embeds, but again for my usecase just the url/path is enough.

[neongreen]

In the meantime, I wrote a simpler script that assumes there's only one file:

file=$(echo {{caret_paragraph}} | rg -o '!\[\[(.+)]]' -r '$1')
open -a /System/Volumes/Data/Applications/Shottr.app "$file"

Update: this actually doesn't work b/c the file can be in a folder.

[Taitava]

Hi! Thank you for your suggestion! 🙂

I can't promise to implement this, but I can take it into consideration.

I'd need to think about the following things:

• If it would only pick a link at the cursor, the variable's name could be e.g. {{caret_link}}?
• But if it needs to pick a link even if there is no link directly under the caret, maybe it could be {{caret_nearest_link}}? I'd need to consider should it traverse to other lines, too, if the current line contains no links? But perhaps not, as staying on a single line would make it simpler and easier to understand.
• If it needs to pick multiple links on the caret's line, maybe it could be {{caret_line_links}}?
• Perhaps multiple variables could be created, but I need to consider the usefullness of each one. Maybe start with one and implement others if needed?