You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there! I wanted to share some thoughts on the hyperlink system after using it more extensively in my personal notes. I've been really impressed with how the hyperlink functionality has evolved recently, especially since I last contributed to this part of the codebase some time ago. The recent improvements to the system are a big step forward, but I've encountered some limitations when I tried to implement more advanced workflows in my personal setup. I believe that with a few small extensions to the API, these limitations could be overcome, allowing users and plugin creators to implement their own extensions to enrich link handling.
My Use Case
I'd like to customize how different types of links are handled in specific contexts. For example:
Opening directory links like [[some/folder/]] in different file explorers based on context:
I've explored the existing hyperlinks.sources configuration, which is great for adding custom link types. However, I've found some limitations:
Single action per link type: The current API is focused on "following" links, but doesn't support alternative actions like "preview"
Built-in handlers are fixed: Can't easily extend built-in handlers (like file:) without replacing them entirely
No way to access link data: No method to get the current link's data without following it
Proposed Enhancements
I've thought about some minimal API additions that would enable these workflows without major changes:
1. Link Context Access Function
-- Get link at cursor without following itrequire('orgmode').api.get_link_at_cursor()
This would return parsed link information, enabling custom keymaps like:
vim.keymap.set('n', 'K', function()
locallink=require('orgmode').api.get_link_at_cursor()
ifnotlinkthenreturnend-- Preview based on link typeiflink.path:match('%.png$') orlink.path:match('%.jpg$') thenrequire('image_preview').show(link.path)
elseiflink.type=='headline' thenrequire('headline_preview').show(link.path, link.target)
endend)
2. Link Follow Options
Add a minimal API method to follow links with options:
-- Follow a link with options (useful for custom keymaps)require('orgmode').api.follow_link(link_string, {
split="vertical", -- or "horizontal", nil for current windowbackground=false, -- true to return to current position after opening
})
-- Example custom keymap using thisvim.keymap.set('n', '<leader>ov', function()
locallink=require('orgmode').api.get_link_at_cursor()
iflinkthenrequire('orgmode').api.follow_link(link.raw, {split="vertical"})
endend)
3. Extended File Link Handler Configuration
Enhance the existing configuration to support conditional handling:
require('orgmode').setup({
hyperlinks= {
file_handlers= {
-- Pattern-based directory handlingdirectories= {
['~/projects/.*/$'] =function(path)
require('neo-tree').open(path)
returntrueend,
['~/documents/.*/$'] =function(path)
vim.fn.jobstart('dolphin ' ..path, {detach=true})
returntrueend
},
-- Handle specific file types differentlyfiles= {
['%.pdf$'] =function(path)
vim.fn.jobstart('okular ' ..path, {detach=true})
returntrueend,
['%.org$'] =function(path, target)
-- Custom org file handler with window selectionrequire('window_picker').pick(function(win)
vim.api.nvim_set_current_win(win)
-- Use the original handler to navigate to targetrequire('orgmode').api.follow_file_link(path, target)
end)
returntrueend
}
}
}
})
Benefits
These minimal changes would:
Enable completely custom link workflows through regular Neovim keymaps
Keep the core API simple (only 2-3 new functions)
Maintain backward compatibility
Allow plugins to build advanced link handling while leveraging orgmode's link parsing
@kristijanhusak What do you think of this approach? Would you be open to these types of enhancements? If so, I would be happy to contribute a PR.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Does this feature exist in Emacs orgmode core?
N/A
Orgmode link
No response
Feature value
Hi there! I wanted to share some thoughts on the hyperlink system after using it more extensively in my personal notes. I've been really impressed with how the hyperlink functionality has evolved recently, especially since I last contributed to this part of the codebase some time ago. The recent improvements to the system are a big step forward, but I've encountered some limitations when I tried to implement more advanced workflows in my personal setup. I believe that with a few small extensions to the API, these limitations could be overcome, allowing users and plugin creators to implement their own extensions to enrich link handling.
My Use Case
I'd like to customize how different types of links are handled in specific contexts. For example:
Opening directory links like
[[some/folder/]]
in different file explorers based on context:Adding preview capabilities to links:
Controlling where links open:
Current Limitations
I've explored the existing
hyperlinks.sources
configuration, which is great for adding custom link types. However, I've found some limitations:Single action per link type: The current API is focused on "following" links, but doesn't support alternative actions like "preview"
Built-in handlers are fixed: Can't easily extend built-in handlers (like
file:
) without replacing them entirelyNo way to access link data: No method to get the current link's data without following it
Proposed Enhancements
I've thought about some minimal API additions that would enable these workflows without major changes:
1. Link Context Access Function
This would return parsed link information, enabling custom keymaps like:
2. Link Follow Options
Add a minimal API method to follow links with options:
3. Extended File Link Handler Configuration
Enhance the existing configuration to support conditional handling:
Benefits
These minimal changes would:
@kristijanhusak What do you think of this approach? Would you be open to these types of enhancements? If so, I would be happy to contribute a PR.
Additional context
No response
The text was updated successfully, but these errors were encountered: