load subset of files from repository

[TeddyDD]

I'm opening this issue as you asked.

Basically I'd like option that would allow to load subset of files from repo (single file/files matching pattern. This was show stopper for me.

I realized two things:

• most common use case is loading single file from repo
• it's possible in plug.kak using noload and config block

plug "https://github.com/lenormf/kakoune-extra" "noload" %{
    source "%val{config}/plugins/kakoune-extra/hatch_terminal.kak"
    source "%val{config}/plugins/kakoune-extra/lineindent.kak"
    alias global t hatch-terminal-x11
}

It's not perfect pretty but it does the job.

Rationale

1. IIRC my plugin manager still lacks a feature of loading single script, because I think that this is plugin maintainer responsibility.

You can't except that every plugin autor will comply with single repo - single plugin rule. I think managing kakoune-extra as separate repos would be insane.

Manual management of those few plugins that don't comply is a hassle.

2. It would allow you to load single script from repo that is not formally a plugin (dotfiles repo).

3. It doesn't bring too much complexity. At first look - replacing find param: -name with -path and using optional parameter there would be enough. I haven't tested it yet.

   for file in $(find -L $(eval echo $kak_opt_plug_install_dir/"${plugin##*/}") -type f -name '*.kak'); do

[andreyorst]

You can't except that every plugin autor will comply with single repo - single plugin rule.

I actually expect it to be so, since it is natural for plugin to be standalone and packed to a repository, or group of repositories if plugin is complex and have sub-modules. Check any of VSCode, Atom, Emacs or Vim plugins - 95% of them are single repo - single plugin. Those 5% who're not are ~20 years old.

I think managing kakoune-extra as separate repos would be insane.

As I've mentioned at r/kakoune I don't think that kakoune-extra can be treated as plugin. It is user-script-collection shared with community. I also think that if you like some script from that repo, you should contact @lenormf and discuss if this script could be externalized to separate repo, and removed from extra so it could grew as a standalone plugin, and users were not misguided that there's also another version in kakoune-extra. For example I'm thinking about contacting him because I've found that there's a fzf.kak script that is not as powerful as my fzf plugin.

It would allow you to load single script from repo that is not formally a plugin (dotfiles repo).

Again, plug.kak isn't supposed to load regular scripts. You can do it by using source. I understand that this seems a fancy ability to do so, but, tool should be used where it's really needed. plug.kak is a manager in the first place. It downloads, updates. builds, configures, and only then loads. You should not use it with dotfiles. If it is small kak script, I think it should be just copied to your dotfiles. If you think that something is too big to be copied from anothers person dotfiles into yours, then I think it means that this should be a plugin with it's own repo then.

I do load scripts not from autoload directory, because I don't want to mess with it. I use shell. If I want to add some piece of configuration from someones dotfiles I'll just externalize it to separate file, and include it in my kakrc. This is my entire kakrc file contents:

evaluate-commands %sh{
    config_files="
        plugins/plug.kak/rc/plug.kak
        tmux.kak
        commands.kak
        plugins.kak
        common.kak
        languages.kak
    "

    for file in $config_files; do
        echo "try %{ source '$HOME/.config/kak/$file' } catch %{ echo -debug 'Error sourcing $file' }"
    done
}

I understand the point of loading separate files, and I understand that there are some repos who provide bundles of scripts, but I hope that plugins will become more organized, and plugin itself will care about other files associated with it.

However until then, I'll add a fallback feature called "load: pattern". If it is specified it acts like noload and only files that match the pattern will be loaded, and it can be repeated if necessary. What do you think?

[TeddyDD]

You are going for long play here and that's fine. I think single repo - single plugin is right approach, I use this structure as well, but I'm playing devil's advocate here.

---

kakoune-extra has plenty of useful scripts and they are updated more or less frequently, that's why I like to have them handled by plugin manager. Sure, I could use submodule in dotfiles repo but I'm lazy :wink:

Kakoune scripts tend to be short and sometimes it doesn't feel right to make new repo for 10 LOC script. It can lead to more repositories being structured as bundle of scripts in the future. I can copy them to my dotfiles repo but then I'v got no updates.

Again, plug.kak isn't supposed to load regular scripts. You can do it by using source. plug.kak is a manager in the first place. It downloads, updates. builds, configures, and only then loads

This feature request is not about loading regular dotfiles (I use kakrc and source for that) it's about downloading, updating and loading files from remote repositories in flexible way, without making assumptions how that repository is structured.

---

Honestly my only real world use case for this feature is kakoune-extra repo and scripts mentioned in my example. It's handled well enough with noload + source hack (I'v got downloading and updating handled by plug.kak, I need to source manually). It's not elegant but good enough for me to abandon my custom solution. Therefore this issue is not a priority, at least not for me.

I'm not sure if it's worth to add special feature to handle single use case, especially if it will make code more complex. This issue can be reopen later when/if other users request this feature.

On the other hand your proposed solution seems solid, quite simple to implement and it makes plug.kak much more flexible. In the end it's your call

[andreyorst]

Sure, I could use submodule in dotfiles repo but I'm lazy wink

That's exactly why I've made plug.kak as my first kakoune plugin. I hate submodules since I've tried to use them with Vim for plugin management.

This issue can be reopen later when/if other users request this feature.

I'm not going to close this issue until we really could came to a conclusion. TBH I'm not against this anymore since it allows to cover more usecases and increase plugin support.

I'm not sure if it's worth to add special feature to handle single use case, especially if it will make code more complex.

Actually.. It is. Because there's are some plugins like ul/kak-lsp, which forced me to add noload keyword since it uses executable to load main kak script. We have a discussion there: https://github.com/ul/kak-lsp/issues/117 and if I'll get to do that separate main kak script that will take care of launching executable, I'll be forced again to load only one file which is actually good, because it allows plugin to build it's own hierarchy of scripts and dependencies. But If it happens all plugins that consist from several files (I don't know any) will be not. That's why https://github.com/mawww/kakoune/issues/2402 is so important, since we need to develop a mostly uniform structure for kakoune plugin.

On the other hand your proposed solution seems solid, quite simple to implement and it makes plug.kak much more flexible. In the end it's your call

I'm not rejecting pull requests at all :smiling_imp:

[andreyorst]

@TeddyDD I'm starting to work on a feature. Do you have a better name for the keyword?

I'm thinking that syntax will be like this:

plug "lenormf/kakoune-extra" load %{
    hatch_terminal.kak
    lineindent.kak # direct names
    *.kak # wildcard matching also supported
} config %{
    alias global t hatch-terminal-x11
}

But I don't kinda like load keyword. I'm afraid that We can't use source as it will be treated as part of Kakoune configuration. I'm also going to add optional config keyword, that will not be required, but can be used to make configuration more readable like in this case.

[Delapouite]

The keyword could be "pick"

[andreyorst]

Somehow I like load more than pick. I understand what brings this name, but it doesn't genereally mean what to do with those picked files. Maybe it's just me

[TeddyDD]

Load looks fine IMO

śr., 7 lis 2018, 09:19: Andrey Orst notifications@github.com napisał(a):

Somehow I like load more than pick. I understand what brings this name, but it doesn't genereally mean what to do with those picked files. Maybe it's just me

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/andreyorst/plug.kak/issues/15#issuecomment-436541259, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMZ3aJa-Wqn_wONVS6wzIrGlOD2FM3hks5uspeMgaJpZM4X33gg .

[andreyorst]

I don't like load because generally this word can be treated as command opposite to noload. User may be misguided by the name. I'm thinking about only:

plug "lenormf/kakoune-extra" only %{
    hatch_terminal.kak
}

However only keyword doesn't correspond well if we use it with wildcards in names:

plug "lenormf/kakoune-extra" only %{
    *.kak # which doesn't make any sense but whatever
}

subset could be fine keyword, but it doesn't actually say what plug should do with this subset.

[andreyorst]

Working prototype can be found at load branch

Edit: Not so working prototype. I don't understand why it is working for single line single file situation, but doesn't work for single file/ single line multiple files situation, e.g.:

Works:

plug "lenormf/kakoune-extra" only %{ hatch_terminal.kak }

Doesn't work:

plug "lenormf/kakoune-extra" only %{
    hatch_terminal.kak
}

Yet the very same code works for post-update hooks

[andreyorst]

Fixed. Now this works and need testing. I've tried loading some files from kakoune-extra and it works fine.

[TeddyDD]

I tried load branch with my setup and it works perfectly well :+1:

[andreyorst]

ok, Ill merge it to kakoune-git branch and backport it to stable branches

[andreyorst]

I've added this to kakoune-git branch and backported this feature to all stable releases.