-
Notifications
You must be signed in to change notification settings - Fork 43
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
Cannot follow links to internal headers #193
Comments
I can confirm this happens for me too. My initial thought is whether we even support go to definition for headings. But regardless, we shouldn't return anything if we don't. |
I think it's important to support this. Markdown links are supported, but apparently only partially. This means that for internal note navigation a user has to prepare an alternative (find it or create it, install, configure, ...). This is complicated by the fact that you need to either:
Thus, pushing it on the user would be an inconvenience for everyone. Furthermore, links are already being handled somewhere. Also, following the behavior of other LSP implementations, for example for programming languages, the user would expect the cursor to move to the definition of a function, even if it were in the same document, instead of doing nothing or opening an unrelated document. All in all, I agree that in the worst case nothing should happen, maybe log a warning that it is unsupported. |
Our lsp was designed to offer extra functionality that was either zk specific, or that other lsps don't. But not to implement regular markdown lsp functionality. See here. It's expected that users are using another lsp for markdown, as zk lsp only launches when editing markdown documents within a zk notebook anyway. So it would never be an lsp to rely on for markdown editing in general. So it's more a case that we should negate this behavior, rather than support it. |
I see, thanks for the explanation. I think what I have most issue with is that zk's LSP implementation covers following links, but not quite all of the supported links of the underlying document format (in this case, markdown). If that's the chosen direction, so be it. I'll update my configuration to use a full markdown LSP implementation to fulfill that functionality instead. That the Thank you for your time! |
Yeah, it's a tricky balance to strike. As the lsp should be usable for the base requirements of writing a markdown wiki. But we're also not out to build and maintain a fully fledged LSP. I mean it was one person, Mickael who was building and managing zk and the lsp himself for quite a while. Which still blows my mind how much he got done... Now it's mainly me holding fort, and the reason I say that is that I'm still fairly new to the code bases, and I've been wrong about calling out features as not existing before when they actually do! So keep an eye on your notifications, because as I get around to looking into the lsp side of things (for which there are some other open issues) I'll double check on this. Maybe it is implemented, but it's buggy. |
Check if applicable
Describe the bug
When following a markdown link to an internal header, such as
[my link](#some-existing-link)
, by using<CR>
or:lua vim.lsp.buf.definition()
, the cursor and the view should move to the header.Instead, a new buffer is opened with a different note. It seems that it is always the same note, regardless of the link. It also seems that it is the first note ever created.
Requirements.
nvim
.telescope
.zk
.zk-nvim
.Additional details.
Contents of
LspLog
after:lua vim.lsp.set_log_level("debug")
:How to reproduce?
zk init
. Configure links for markdown.nvim .
.faulty link
.<CR>
or execute the command:lua vim.lsp.buf.definition()
.## Some header
, but instead a buffer is opened with the file that contains# First note
.zk configuration
Neovim configuration
Environment
The text was updated successfully, but these errors were encountered: