Plug.kak

Plugins
21

What about import.kak?

import 'alexherbo2/prelude.kak'
import 'connect' 'connect-nnn' 'connect-fzf' from 'alexherbo2/connect.kak'

The implementation being something like

define-command -override -params 1.. import %{
    edit -scratch *import.kak*
    buffer *import.kak*
    exec "i%arg{@}"
    try %{
        # test if command was something like import x from y
        exec "s from <ret>"
        # split into requires and imports and choose RHS (source)
        exec "<a-x>S from <ret><space>"
        git-clone-and-source %val{selection}
        # split into requires and imports and choose LHS (modules)
        exec "<a-x>S from <ret><a-space>"
        exec "S <ret>"
        eval -itersel %{ require-module %val{selection} }
    } catch %{
        exec <a-x>
        git-clone-and-source %val{selection}
    } catch %{
         delete-buffer *import.kak*
    }
    delete-buffer *import.kak*
}
2 Likes
22

For something initialized in the kakrc, it does a bit too much work for my taste.

23

Itā€™s simpler if you switch the syntax to something more consistent

import 'alexherbo2/prelude.kak'
import 'alexherbo2/connect.kak' 'connect' 'connect-nnn' 'connect-fzf'

but you miss out on aesthetics & readability. Might as well just have the require-module as itā€™s own step at that point.

24

Hi, @alexherbo2!

You do have some interesting ideas here. Leveraging already available Kakoune features (the module system and the autoload directory infrastructure) to do the job seems the right path to take on the plugins story for Kakoune.

Nevertheless, open source projects are always a balance between innovation and agreement: itā€™s much easier and faster to go alone, but together we go stronger.

Thinking a bit about your proposal, I see a problem on it: for it to work the way itā€™s meant to, you must convince every plugin developer to wrap her plugins inside modules. You could convince some, others would prefer to stay the way it currently is, and suddenly our small community would be divided between the modulers and the andreyorsters.

I think that, since Andrey left the project, we have a unique opportunity to design the future of plugins machinery for Kakoune together. For that Iā€™d kindly ask you and @robertmeta to, together, start a discussion about it, inviting all stakeholders to take part on it and give their thoughts, from plugin developers to end users, including also Kakoune developers.

What I would really like to see is an agreement on best practices for developing plugins and, with hope, a unifying approach materialised on a single plugin manager implementation with (why not?) a dedicated Github organisation which everyone interested could join, in the lines of what we already have for kak-lsp.

8 Likes
25

@gustavo-hms indeed, it is a unique time. I guess we start from the user experience and work our way back.

26

What about gulp?
Reversed name intuitively indicates itā€™s a revised thing it refers to.

3 Likes
27

really like it ! glup would work too !

1 Like
28

Has there been any discussion since the last on this thread?

As an end user I donā€™t mind it having the same name as andreyā€™s plugin. Iā€™m much more interested in figuring out a good standard for how plugins should work.

One thing Iā€™d like to see is becoming more agnostic to which remote (github vs gitlab vs ā€¦) plugins are cloned from. I think Iā€™ve seen at least one person preferring pijul, so it might be nice to support other VCS systems, within reason. One possibility is to have a sort of thin package repository containing only a unique registry of names and where they point. Then we could still have nice short names of packages in rc files while still having flexibility. Actually the plugins section on the website suffers from the issue of only searching key tags on github, so this sort of thing could replace that interface as well.

29

To play devilā€™s advocate to myself, one bad thing about a central repository is figuring out who gets to act as maintainer. Recently I came across a federated version of nodeā€™s package ecosystem called entropic. I think it neatly solves that particular problem at the cost of a bit of complexity. It even purports not to be js specific in that one need only contribute the logic for a kakoune package installer, then it could be used as is.

31

seems that @alexherbo2 deleted a bunch of their plugins.

Luckily for me I still have the word-select.kak, surround.kak, and replace.kak installed on one of my machine.

@alexherbo2 if you donā€™t want to maintain these plugins, can I add those three to the kakounedotcom org?

32

The plugins moved to kakoune.cr.

1 Like
33

I see, thanks for letting me know.

So can I add your old repos to kakounedotcom, as Iā€™m pretty sure some people would like to use what was already working for them without external tools?

34

I think it would divide the community, a simple source /path/to/script.kak does the job.

35

it doesnā€™t seem to uncleā€™s replace mode or word move

36

How so? Not having separate repos for plugins would be really inconvenient for people that use plugin managers like plug.kak. And it seems like some of the plugins that are bundled with kakoune.cr donā€™t actually need kakoune.cr to be installed. For example, I was able to manually download auto-pairs.kak from the kakoune.cr repo, soruce it, and have it work fine without needing to install kakoune.cr.

4 Likes
37

Agreed, one of the strong aspect of kakoune is the modularity. I am afraid this new monolithic structure might be less flexible. Maybe git submodule may help get the best of the two world ?
I already hesitated to recreate repo for these files so I could keep my old conf, I finally I dropped some of these plugins to avoid using kakoune.cr for unrelated stuff. I think the community might also get divided by this mechanism.

2 Likes
38

Yeah, instead of just deleting the repos, those could have been made read-only with a note on the top of readme at least pointing to the direction where are maintained versions are. Removal just broke a lot of user configs.

7 Likes
39

I agree, lumping the plugins into kakoune.cr was incohesive given the intended use-case. The new functions break configurations that shouldnā€™t have any logical overlap with kakoune.cr and make it harder to integrate within existing configs.

At the very least the extra functions should be separate in a ā€œlibraryā€ repo:

  • still less repos to maintain
  • understood that users copy/clone/source from the library however they see fit
  • kakoune.cr stays cohesive and predictable
  • kakoune.cr remains interoperable with existing configs and separate plugins
  • kakoune.cr remains easy to install/update within plug.kak
4 Likes
40

I think that the library repo approach could still be a bit inconvenient for some that use plugin managers like plug.kak, which to my knowledge does not support selectively sourcing scripts. But I certainly agree that it would be a significant improvement over the current approach.

41

Previously it could but Iā€™ve removed this feature in the 2.0.0 release, because it was initially added as a hack, before module system was a thing. Nowadays scripts should be in modules, so you could load everything and selectively enable things you need.

2 Likes