telekasten.nvim
telekasten.nvim copied to clipboard
[BUG] Line-wrapped links do not work
First, thanks for an awesome plugin! 🔥
Please confirm
- [X] I am running the latest version of this plugin
Describe the bug
Following [[note links that include newlines]]
does not work, whereas it works as expected for [external links]()
. Similarly, syntax highlighting does not work for such note links, while external links work just fine.
To Reproduce
Enter the following in a markdown file and make sure telekasten.nvim
is loaded.
[[example link on one line]]
[[example link with a
newline]]
[example external link with a
newline](https://www.google.com)
Try to follow the links with the follow_link()
Telekasten function; the first and third will work, but not the second (the Telescope picker won't even appear). This yields the following error message:
E5108: Error executing lua ...share/nvim/lazy/telescope.nvim/lua/telescope/pickers.lua:899: 'replacement string' item contains newlines
stack traceback:
[C]: in function 'nvim_buf_set_lines'
...share/nvim/lazy/telescope.nvim/lua/telescope/pickers.lua:899: in function 'reset_prompt'
...share/nvim/lazy/telescope.nvim/lua/telescope/pickers.lua:741: in function 'set_prompt'
...share/nvim/lazy/telescope.nvim/lua/telescope/pickers.lua:433: in function 'find'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:1007: in function 'find_files_sorted'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:2167: in function 'picker'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:2210: in function 'callback'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:490: in function 'callback'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:218: in function 'check_dir_and_ask'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:469: in function 'create_note_from_template'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:2201: in function 'callback'
...
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:237: in function 'callback'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:218: in function 'check'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:236: in function 'callback'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:218: in function 'check'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:235: in function 'callback'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:218: in function 'check'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:234: in function 'global_dir_check'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:2085: in function 'selection'
...local/share/nvim/lazy/telekasten.nvim/lua/telekasten.lua:3082: in function 'panel'
[string ":lua"]:1: in main chunk
Expected behavior
The example link should be followed when using the follow_link()
Telekasten function, and should also be correctly syntax highlighted.
Screenshots
Operating system (please complete the following information):
- OS: MacOS
Additional context
This is important to me because I always format all of my files to have a maximum width of 80 characters, which helps with readability and other stuff. The current functionality forces me into one of two solutions: (1) write my notes such that any internal link happens to land one of continuous line within the maximum line width, or (2) have links exceed the maximum line width. Alternative one adds additional overhead to writing links, since I now have to word the note such that links become formatted on a single line. Both alternatives makes automatic formatting with e.g. gq
impossible.
I'm assuming it's something wrong with the [[internal links]]
, since [external links]()
work fine?
Can you try adding
title = title:gsub("%s*\n", " ")
between lines 2122 and 2123 ?
https://github.com/renerocksai/telekasten.nvim/blob/d2b7c2c4d4727f31bb0676ed90e7ecdc8f67ae12/lua/telekasten.lua#L2118-L2124
just to make sure it works as expected before I push the fix ?
Thanks for the quick response! That works when I'm on the starting line of the link, but not the second (and syntax highlighting still does not work).
cursor here works
|
[[example link with a
newline]]
|
cursor here does not work
Mmmm indeed.
- I really do not have time to go deeper on that and solve the syntax highlighting stuff. So this will be for a separate issue.
- Making the function work on the second line requires fixing the
taglincks.is_tag_or_link_at
function which is significantly more complicated than simply replacing any end of line character by a space. We first need to go up any number of lines and detect if we are indeed in a link or not. I am not sure why we need such a complex function to do that tbh, so we must proceed with caution here.
Unfortunately I do not think I have much more time to work on this in the foreseeable future. If you are up to it, you can try fixing this yourself and I will happily review the PR.
- Okay, shall I add a separate issue for that?
- Alright, but why is the internal link not working while the external ones do? I assume that they share some kind of functionality between them? I'm not a plugin developer myself, so my intuition here can easily be wrong.
- Not yet, we will do when the other part is fixed (maybe both will be fixed together, I am not familiar with the highlighting stuff)
- External link is the
else
condition (-> default behavior). As the stuff under the cursor is not recognized as a link or a tag (taglinks.is_tag_or_link_at
returnsnil
), then we end up here and directly go for what is inside parenthesis. You can see this behavior yourself in the following example:
Lorem ipsum
[word1] word2 (should get yanked) lorem ipsum
Put the cursor anywhere before the ( ... ) and try follow_link
. It should yank what is inside the parentheses in the default register (now that I think of it, it should reset the register afterward before trying to open the url)
Just fixed the overwriting of the register :wink: https://github.com/renerocksai/telekasten.nvim/commit/872b83f619ddfe4312acdc658d129b6828e1f418
Okay, turns out that the syntax highlighting issue was a very simple fix: the oneline
setting had been used, and removing that from the link-related syntax fixed it; see #308.
I'll see if I can get something going for the link following-problem.
Awesome! Thank you very much for your contribution.