andreyorst
commented
6 years ago I've never worked with Kakoune's fifo, and doesn't quite know how to do all that fancy stuff with interactive buffers, however I like the idea, and It was on my mind too, but in context of #10.
We can even go further: plug-list remote, would display the list of available plugins on a provider like Github. Using the same API call that on this page: http://kakoune.org/plugins.html
I know that vim-plug does this, but when I've tried to use it, I've found that this isn't that usable feature, because it doesn't find all plugins, and the interface is really awkward.
therefore my next point about this:
This way the user can discover all the available plugins created by the community and decide to install them by pressing
<ret>. This would add the corresponding plug 'username/repo' to their kakrc and a plug-install of this specific plugin.
I don't think that this is a good idea. One thing that I don't like about Emacs, is that if you do package-install RET some_plugin RET it will automatically add this to custom variable, and thus change your config. I think that editor, or plugin should never, never touch any file in user configuration, unless editor claims that it will build config for you. Because it is error prone, hard to maintain, and involves bad feeling when you don't like how it was added, but you can't do much, because any moment plugin can re-do this, and you will fight plugin over and over, until it's too much. Sure, you can move custom to it's own file, but it is just hiding the problem away, and not solving it.
Also many plugins, are requiring a quite of a configuration, and sometimes outside of Kakoune, like kak-lsp. Some plugins are just bunch of scripts, like kakoune-extra, and user should load them carefully, by adding only needed files. Some plugins should not be loaded at all. We can't support every plugin with some kind of a configuration snippet, and can't ask every plugin maintainer to add some snippet for plug.kak to their repo. Not every maintainer likes the idea beyond plug.kak, and not every plugin can be updated, because it is abandoned, but it works and is used by people.
Adding simple plug "repo/plugin" entry to user's config can break kakoune entirely, and user will complain: "why is it there, I didn't add this by myself".
We can open plugin repo on <ret> key by using $BROWSER or something like that, so user could easily browse plugin repo and find instructions for plug.kak if there are any.
So in my opinion:
- Command to list of installed plugins and some info like last update dates, and interactive ability to update them - yes, I like it.
- Show plugins, using github API - maybe.
- Change user configuration to install plugins from list - should never happen.
Pressing Ret on the line with
Hi
A
plug-listcommand would be handy to have a quick view of all the local plugins. It could open a*plugins*buffer with the list a plugin names and some extra info like the date of the last update.Also, by pressing
<ret>on one of the line, it can try to update only this specific plugin.We can even go further:
plug-list remote, would display the list of available plugins on a provider like Github. Using the same API call that on this page: http://kakoune.org/plugins.htmlThis way the user can discover all the available plugins created by the community and decide to install them by pressing
<ret>. This would add the correspondingplug 'username/repo'to their kakrc and aplug-installof this specific plugin.