-
-
Notifications
You must be signed in to change notification settings - Fork 90
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
Comments
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.
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 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>')
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. |
Please confirm
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.
The text was updated successfully, but these errors were encountered: