Skip to content
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

Simplifying Telekasten's Scope #283

Open
1 task done
thw26 opened this issue Sep 13, 2023 · 1 comment
Open
1 task done

Simplifying Telekasten's Scope #283

thw26 opened this issue Sep 13, 2023 · 1 comment
Assignees

Comments

@thw26
Copy link
Contributor

thw26 commented Sep 13, 2023

Please confirm

  • I am running the latest version of this plugin

Tell us about what's bothering you...
Mostly looking to start a discussion!

I know there are some major rewrites to the code base happening or at least planned, and I've found some of Telekasten's functionality is mostly a front end for Telescope, such as some of the pickers. As I am trying to figure out a solution to #261, I have found a workaround in setting up Telescope commands instead. What is different is, for instance, searching by tag, but that could also just be executed as a Telescope live grep for the tag.

I recently managed a Telescope workaround for following links on hitting enter in normal view, for instance.

I was also thinking about the image previewing capability. I have been looking for a plugin that can execute xdg-open on a file, i.e., to open a LibreOffice document in LibreOffice. I found this plugin and this PR: nvim-telescope/telescope-media-files.nvim#39.

To make Telekasten easier to maintain, and perhaps as part of the rewrite, could not this plugin be utilized instead of Telekasten's own media handling? It might even be able to replace link insertion and the like to the point that this plugin handles journal notes, vaults, wiki links, links to headings.

@lambtho12
Copy link
Member

I know there are some major rewrites to the code base happening or at least planned, and I've found some of Telekasten's functionality is mostly a front end for Telescope, such as some of the pickers.

Yes, the best way moving forward would be to leverage telescope and the latest nvim api as much as possible and only act as a sort of interface for it. This is already what we are doing for most functions, but in a bit messy way sometimes.
It is quite hard to maintain everything currently. Partly because of a lack of time on my side, but also because telescope and nvim are adding a ton of features and it is hard to keep up to date with those.

What is different is, for instance, searching by tag, but that could also just be executed as a Telescope live grep for the tag.

Not quite. Telescope live grep does not work like our show_tags picker. If I am not mistaken, you would basically need to know beforehand what tag you are looking for and would not be able to only extract a list of tag to choose from.

I have been looking for a plugin that can execute xdg-open on a file, i.e., to open a LibreOffice document in LibreOffice. I found this plugin and this PR: nvim-telescope/telescope-media-files.nvim#39.

I was not aware of that PR. This would indeed be a fantastic solution to add as yet an other option. I personally just use the following mapping to open files/links

  vim.keymap.set("n", "gx", '<Cmd>call jobstart(["xdg-open", expand("<cfile>")], {"detach": v:true})<CR>')

To make Telekasten easier to maintain, and perhaps as part of the rewrite, could not this plugin be utilized instead of Telekasten's own media handling? It might even be able to replace link insertion and the like to the point that this plugin handles journal notes, vaults, wiki links, links to headings.

I did not follow their latest developments, so I will have to look into it more. In my opinion, as long as media-files is only a "media previewer" (like it was the last time I checked, a long time ago), there is no point in making it a requirement. I do not like to force the users into downloading a ton of external plugins for some niche features. HOWEVER, if it can do some heavy-lifting in our place and help us keep telekasten to a somewhat more reasonable size and architecture, then this would indeed be a good thing.


I think the long-awaited refactoring of the plugin will already bring major improvements already to be honest. Code is duplicated ad nausam, pickers could be simplified tremendously, everything is all over the place, the regexes can be rewritten in a cleaner more robust way, etc. The entire code base could probably be cut in half without loosing any feature. Then the user configuration flow can be completely redone as well. Instead of passing a gigantic table, we could set a table with options to pass to telescope directly to tweak telescope iteself, a table to configure the vaults, one for the general options, etc. With something more organized like that, it becomes a breeze to stay in pair with the latest development of telescope for instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants