search

nvim-telekasten / telekasten.nvim

A Neovim (lua) plugin for working with a markdown zettelkasten / wiki and mixing it with a journal, based on telescope.nvim
MIT License
1.29k stars 83 forks source link

[FR] Support for classic markdown links #126

Open dmytrodubinin opened 2 years ago

dmytrodubinin commented 2 years ago

It would be nice to add support for standard markdown links for files: [text](link). I did not find similar requests, perhaps my proposal has already sounded before.

Main reason: classic formatting is supported by all markdown editors and in this case there are no difficulties in portability of notes

Rom1deTroyes commented 2 years ago

I also feel that, sometimes, writing a description instead of just a link is a good way to keep in mind the « how and why is this link related to the note ? », but I'm not a long time zetel guru, so I don't know if it's a good practice :-)

lambtho12 commented 2 years ago

Yes, this is definitely something we should support.

This was already discussed here: https://github.com/renerocksai/telekasten.nvim/discussions/56#discussioncomment-1977177

This reminds me that the 'discussions' are really hard to follow. I should create separate issues with all the various ideas that were thrown in there so it easier to skim.

ghost commented 2 years ago

Is someone working on this right now?

ahillio commented 2 years ago

Having the option to use standard markdown links [link name](filename) feels essential. I'm looking stop using Vimwiki and Telekasten looks like a great solution, but being required to use a non-markdown link format might be a dealbreaker.

A couple considerations regarding links...

dmytrodubinin commented 2 years ago

Right now I'm using another note-taking plugin that supports both kinds of links + some other features (wiki.vim). Together with the telescope, the functionality is more than satisfied

lambtho12 commented 2 years ago

Is someone working on this right now?

Unfortunately, I have very little time to work on TK at the moment. Same for renerocksai. This FR is a massive task I beleive, so I'd rather focus the few hours I have for fixing urgent bugs instead. It will have to wait a bit more or have someone else step in.

lambtho12 commented 2 years ago 
* One trouble with Vimwiki is in its linking and filepath recognition. There's no support for `~/dir` (relative to home) style links, so if you're in a deep subdirectory you've got to count: should this be `../../../../dir` or `../../../../../dir`? for example.

IMO normal markdown links should either work with relative paths (to zettelkasten home) or with absolute ones.

* path-based autocompletion when typing the link (completing the paths and filenames) would be so excellent :)

Path autocompletion can be acheived with other plugins (nvim-cmp for instance). However, telekasten has a very cool insert_link function that makes it even much simpler to insert a link to a note (as long as it is in you ZK home or a subdir of it). With that function, you do not even need to bother with its actual path.

ahillio commented 2 years ago

Path autocompletion can be acheived with other plugins (nvim-cmp for instance).

Agreed! The appropriate way to solve.

IMO normal markdown links should either work with relative paths (to zettelkasten home) or with absolute ones.

I'm not clear on your thoughts here...

This FR is a massive task I beleive,

Do you have much of an idea about how it should be done, like if someone shows up here eager to implement this... can you suggest the way forward with it?

Thank you!

ahillio commented 2 years ago

I just noticed this https://github.com/renerocksai/telekasten.nvim/pull/120 and so I suppose my last question of "how to proceed" might vary a bit based on before/after refactoring.

lambtho12 commented 2 years ago 
* do you mean telekasten should be able to work with _both_ of those?
* how about recognizing `~/Docs` as `/home/user/Docs`? (does that wall within 'absolute ones'?)

Yes it should work on both. This should not be that difficult with Plenary. We already use Plenary for lots of stuff so eventually it is just a matter of manipulating paths properly. This is the "easy" part :smile: .

Do you have much of an idea about how it should be done, like if someone shows up here eager to implement this... can you suggest the way forward with it?

No particular idea. The code base is a bit of mess at the moment. As you mentioned, I started refactoring it a bit in #120, but I had lots of stuff happening at work and crazy deadlines to met for the following weeks/months, so I cannot even go further on that. Basically what is difficult is that:

  1. TK currently relies on link type (markdown vs wiki) to determine if something is a file or a media, if I recall correctly. So this logic should be changed as well.
  2. TK is relies heavily on regex for lots of stuff. These regex are much too complex IMO (#135) and would likely need to be modified to support the other types of links.
  3. Probably other stuff that I cannot think like that on the top of my head.

These make it very difficult to do the changes in all the correct spot. It will also likely considerably lengthen and complicate the code with big if/else statements for the various cases. This is why I wanted to do a proper refactoring before adding more complex features.

In my opinion, the refactoring should clearly help separate:

Once this is done, it will become much simpler to simply amend the link parsing stuff to allow different types of links.

ahillio commented 2 years ago

Nice. Thanks for explaining!!!

On 22/07/07 04:56AM, lambtho wrote:

* do you mean telekasten should be able to work with _both_ of those?
* how about recognizing `~/Docs` as `/home/user/Docs`? (does that wall within 'absolute ones'?)

Yes it should work on both. This should not be that difficult with Plenary. We already use Plenary for lots of stuff so eventually it is just a matter of manipulating paths properly. This is the "easy" part :smile: .

Do you have much of an idea about how it should be done, like if someone shows up here eager to implement this... can you suggest the way forward with it?

No particular idea. The code base is a bit of mess at the moment. As you mentioned, I started refactoring it a bit in #120, but I had lots of stuff happening at work and crazy deadlines to met for the following weeks/months, so I cannot even go further on that. Basically what is difficult is that:

  1. TK currently relies on link type (markdown vs wiki) to determine if something is a file or a media, if I recall correctly. So this logic should be changed as well.
  2. TK is relies heavily on regex for lots of stuff. These regex are much too complex IMO (#135) and would likely need to be modified to support the other types of links.
  3. Probably other stuff that I cannot think like that on the top of my head.

These make it very difficult to do the changes in all the correct spot. It will also likely considerably lengthen and complicate the code with big if/else statements for the various cases. This is why I wanted to do a proper refactoring before adding more complex features.

In my opinion, the refactoring should clearly help separate:

  • the config and initial setup of the plugin
  • the pickers
  • the link parsing and formatting logic
  • the tag parsing logic
  • the templates
  • various small utilities functions
  • (LSP stuff)

Once this is done, it will become much simpler to simply amend the link parsing stuff to allow different types of links.

-- Reply to this email directly or view it on GitHub: https://github.com/renerocksai/telekasten.nvim/issues/126#issuecomment-1177492426 You are receiving this because you commented.

Message ID: @.***>

rockneverdies55 commented 1 year ago

Waiting for this to switch to telekasten

klei22 commented 1 year ago

Would be awesome to have this supported! Navigation of notes in wiki form would be a amazing feature : D

TheTaoOfSu commented 1 month ago

I've done some work on the refact branch for the refactor, and it's definitely nowhere near complete, but as this is the only real missing critical feature for me, I think it's time I step away from that process and address this.

The current state of the refact branch is that main has been merged in, and a lot of the easier changes, like moving functions to more appropriate modules, some elucidating comments, etc., have been made. There's a lot of work to be done still, and I hope to come back to it, but I also don't super want the headache of doing this in main and then merging it back into refact when most of the functions I have to modify have been rehomed in other files. Since this is going to be an in-demand feature, it will probably necessitate some extra work to clean up the current refactoring progress. It's not quite where I'd like it to be for that, but I personally need the feature, so it's about time I address it.

I gave all the different functions a quick skim and took note of any that seemed to be directly working with links. It's possible something is missing from this initial assessment, but this to-do list should cover the vast majority of the work that needs to be done. Note that in a few places, primarily in functions dealing with images, I've marked that they appear at a glance to be already working with markdown links, but they will need a more careful analysis before they're officially considered done.

All in all, this doesn't seem that huge. Kind of significant for sure, but relatively simple to fix in most of these cases. I'm wondering if I can do this somehow so that I can make a function or small group of functions that's called in all these different situations so that if we ever need to address the link structure again, say to implement issue #295, it doesn't require digging into all these different pieces again. If not, though, this should provide a good record for the future so that I or whoever comes next knows loosely what needs to be done to get it implemented.

TheTaoOfSu commented 2 weeks ago

Looking into this more, there seem to be only a couple things being done with links. Most functions that directly interact with links, the ones duplicating code and/or effort, either generate a link or generate a pattern for a link so they can parse it. I should be able to make a function to handle each of these two tasks, probably in telekasten/utils/links.lua, and have other functions call them to handle these things. That should make things a little easier to change if they ever need to, and it should also help the refactor effort.

The rest of the relevant ones do the actual work. Identifying types of links, resolving them, etc. There's not too much here, so I think it should be pretty manageable to get this handled soon. This will be going into the refact branch first since it both depends on and contributes to the refactor, but I'm hoping we can get refact merged into main soon afterwards.

lambtho12 commented 1 week ago

That would be awesome! I cannot thank you enough for all the work you are currently doing on Telekasten. Keep it up!