andreyorst / plug.kak Goto Github PK

*.kak is default $file contents if no load were specified. It becomes anything named alike to any .kak file or dir if you launch kakoune in the same dir.

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

Currently when installing, I see a print: "Installing plugins in background". However I get no message when it is done installing.

So, currently I do not know when it is done.

Plug started failing to load after an update with a highlighter error, one commit earlier works fine.

It seems like the highlighter group has not been defined?

Sometimes there's a need to disable a plugin (during kakrc debugging, testing or because it misbehaves). It would be nice to have a keyword that would just make plug.kak skip a given plugin, and options associated with it.

If unsuspecting users leave a final / in the URL, really, really nasty things happen in plug_load. plugin_name becomes empty, path_to_plugin becomes the entire plugins folder, and all plugins get loaded (including double-loading of plug.kak itself).

I suggest something like 904e9b1 ...

Perhaps there should be a section for plugin authors in the README.

For example, suppose that, as a plugin author, I recommend that users install my plugin via plug. Normally, my module can be loaded optionally via require-module mymod. This translates to (AFAICT)

plug me/mymod demand mymod

But plug already has a mechanism to noload. Should the module autoload itself (e.g. add a KakBegin hook that require-module's), so that users can just add to their kakrc this and avoid two layers of optional loading?

plug me/mymod

From *debug* buffer, after running plug-install:

awk: illegal field $(), name "F"
 input record number 1, file 
 source line number 1

I never get the Done installing plugins message, it just hangs on Installing plugins in background.

It seems the problem appeared in the latest commit (b3801d2). I can run plug-install with no problems on the previous commit (98defec).

My guess is that my version of awk on macOS is different from whatever version you're using on Linux (I have version 20070501 of awk installed on macOS 10.14 Mojave).

It seems that latest changes to plug_chain command broke something.

The variable plug_always_ensure doesn't work.

Installation of plugins seems broken as well. I get a lot of errors that username could not be read for https://gitlab.com for plugins that don't have domain set

@mralusw can you confirm?

Hello

Almost all plugins that I know of have a README.md file at their root.

So what about a plug-doc command, that would have the all the installed plugins as auto-completion and would automatically opens the associated README.md ?

Example:

:plug-doc<space>

I select ul/kak-lsp for instance, then press Enter, Kakoune opens kak-lsp's README.md

Bonus:

When the list of plugins is displayed in the *plug* buffer after a :plug-list, pressing a key like d would automatically call plug-doc for the plugin on the line.

Had this issue for weeks until I just fixed it. Over this time I thought this thought it was many things before I realised that I had pasted the repo name into the "plug" command wrong. To recreate put the following line into your kakrc:

plug "alexherbo2/auto-pairs"
(it should be auto-pairs.kak, yes this is the exact thing I have left in my kakrc for weeks it is really dumb for me to not have noticed this)

This also works with any git repo that doesnt exist, I've tested it. Would it at all possible for the fifo buffer to display an error instead? Because of a mistake which is reletively easy to make this issue has plagued me for ages and I couldnt work out why. Just thought I'd point out this bug. Otherwise I love this, keep up the good work !

The pattern in rc/plug.sh line 167 ((http*|git*))is confusing. Is it designed to allow [email protected]:..., as a plugin developer might use, or is that just coincidental to the fact that there's no check for a URL scheme (://)?

Anyway, I've opened #84 to allow file:// URL schemes. Thanks for this very useful plugin!

It seems that when a plugin gets installed via ensure, it won't be immediately loaded before subsequent kakrc commands, but rather at an unspecified time, when the install finishes.

This will obviously not work if the rest of kakrc uses commands defined by the plugin (e.g. my k9s0ke-dbg.kak defines meta-programming commands which are subsequently used in my kakrc; but there could be other cases).

On the one hand, this behavior should be documented (and possibly configurable); on the other hand, though, I wonder if it's really useful to speed up kak startup for the one-time case of missing plugins?

Edit: never mind, blocking kak startup would be unacceptable. I guess only the documentation remains to be enhanced.

Just installed Kakoune and trying to set up plug.kak. My kakrc is empty. I've ran

mkdir -p ~/.config/kak/plugins/
git clone https://github.com/andreyorst/plug.kak.git ~/.config/kak/plugins/plug.kak

successfully, but when I try to run

source "~/.config/kak/plugins/plug.kak/rc/plug.kak"

I get the error:

plug.kak: line 56: syntax error near unexpected token `newline'
plug.kak: line 56: `try %<'

Fish is my default shell, and I tried running it in a bash shell as well. Not sure if that matters.

I've copied my kak setup (same config files, same kakoune version) to Ubuntu 18.10, and I get an error on startup.

*** This is the debug buffer, where debug info will be written ***                                                                                                                                                           
Dependency unmet: jq, please install it to use go-tools                                                                                                                                                                      
/home/dpc/.config/kak/kakrc:41:2140: 'plug' 3:57: 'evaluate-commands' 5:1388: 'plug-configure' 1:2: 'evaluate-commands' parse error: unterminated string '...'                                                               
/usr/local/share/kak/kakrc:5:853: 'evaluate-commands' 97:15217: 'source' 41:2140: 'plug' 3:57: 'evaluate-commands' 5:1388: 'plug-configure' 1:2: 'evaluate-commands' parse error: unterminated string '...'                  
error while parsing kakrc:                                                                                                                                                                                                   
    1:1: 'source' 5:853: 'evaluate-commands' 97:15217: 'source' 41:2140: 'plug' 3:57: 'evaluate-commands' 5:1388: 'plug-configure' 1:2: 'evaluate-commands' parse error: unterminated string '...'

Kakoune v2019.07.01
2691c61

As in description: calling :plug-list and using U, I, , D, L has no effect.

There is no logs/errors in *debug*

Hi

A plug-list command 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.html

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.

To allow automatically loading plugins without using require-mode in config block:

plug "author/plugin" defer module %{
     set-option global option value
} demand

instead of:

plug "author/plugin" defer module %{
    set-option global option value
} config %{
    require-module module
}

I'm thinking about supporting loading order. It's not quite the same as defer since it will allow to source plugins in different order. For example

We have plugins that provide powerline modules, for example langmap.kak and therefore rely on powerline.kak. So if we're going to load plugins we should load powerline before langmap. We can do it like so:

plug "andreyorst/powerline.kak"
plug "andreyorst/langmap.kak"

But if there are many plugins in kakrc it gets harder every time to figure out the order and move plugins around is a tedious task. So instead of keeping an order, it could be set with after keyword:

plug "andreyorst/langmap.kak" after "powerline.kak"
plug "andreyorst/powerline.kak"

This way the order load will be as follows:

source powerline.kak
source powerline-modules
source langmap.kak

Not sure how useful this feature will be, but there are some other plugins already that depend on other plugins, for example: kakoune-emmet depends on kakoune-snippets

Basically plug starts before any window is created, and plug-update-fifo breaks

Continuing from alexherbo2/auto-pairs.kak#16 (comment):

plug alexherbo2/auto-pairs.kak %{
  hook global WinCreate .* auto-pairs-enable
  map global user s -docstring 'Surround' ':<space>auto-pairs-surround<ret>'
}

Support some setting that will ensure that every plugin is installed on Kakoune startup.

kakoune-lsp/kakoune-lsp#153

The load %{plugin.kak} does not seem to work anymore, and I'm getting weird errors, suggesting that I'm sourcing some files many times?

I am pretty new to kakoune editor but im a regular vim user. I am trying to source plug.kak in my kakrc file but i get the error message saying

I've been trying to get Plug to work with private Github repositories, but it doesn't really seem to work.

Authenticated HTTP checkout:
A regular plug "crote/kakoune-my-private-plugin" hangs on installation because it requires a username and password, which you can't provide. The only way to get out of this is by kill -9.

SSH checkout:
A plug "[email protected]:Crote/kakoune-my-private-plugin.git" does a proper checkout (but it probably only works for me because my machine prompts for a SSH passphrase using a GUI popup).
Afterwards, it never loads the plugin. Subsequent plug-install and plug-list invocations seem to indicate that it doesn't recognize that the cloned directory belongs to this url, so it's never recognised as properly installed. Renaming it to plug "crote/kakoune-my-private-plugin" after installation does make it work, including future updates.

I'm not sure if this is even worth fixing, but it would probably be nice to have the desired behaviour in this situation documented.

My kakrc previously contained this exact line:

set-option global plug_install_dir '$HOME/.cache/kakoune_plugins'

I spent a couple hours trying to figure out why my plugins weren't installing, and what I found is that the above no longer works.
Instead, something like this, with a full path works:

set global plug_install_dir %sh{ echo "$HOME/.cache/kakoune_plugins" }

The documentation clearly states, that the former is functional, so that should be changed.

The following hook adds hl to the plug keyword

hook global WinSetOption filetype=kak %{
	try %{ add-highlighter window/plug regex ^(\h+)?\bplug\b\h 0:keyword }
}

I think a hook to remove the hl is missing. Something like:

hook  global WinSetOption filetype=(?!kak).* %{ remove-highlighter window/plug }

Hi, it's a bit hard to tell if this an issue with kakoune.cr or here but I think there is at least something strange going with plug.kak. I think there are actually two problems but they both appeared today after nothing for a few months. The *debug* buffer says this everytime I open kakoune:

Error: plug.kak: can't require 'kak' module to declare highlighters for plug.kak. Check if kakrc.kak is available in your autoload.
shell stderr: <<<
find: File system loop detected; ‘/home/uver/.config/kak/plugins/plug.kak/..//kakoune.cr/lib/fifo/lib’ is part of the same file system loop as ‘/home/uver/.config/kak/plugins/plug.kak/..//kakoune.cr/lib’.
find: File system loop detected; ‘/home/uver/.config/kak/plugins/plug.kak/..//kakoune.cr/lib/rsub/lib’ is part of the same file system loop as ‘/home/uver/.config/kak/plugins/plug.kak/..//kakoune.cr/lib’.
>>>

Like I mentioned, I think the first thing seems separate. Why would you need a kakrc in the autoload directory? As for the second and third messages, I popped open nnn on those directories and they keep opening infinitely. Maybe not a plug.kak issue but I'm not sure so was curious if anyone could offer some ideas.

Thank you so much.

New error message in the debug buffer as of Kakoune commit 92972bed and plug.kak commit 6076e4c:

plug.kak: Can't declare highlighters for kakrc.
          Detailed error: 2:6: 'add-highlighter' no such id: 'kakrc'

Can you please add fd support?
When I set set-option global fzf_file_command 'fd --type f --follow', I got following:

I suppose there should be info box message, instead of that line.

The current default path is '$HOME/.config/kak/plugins'.

Should the plugin use something like %val{config}/plugins for better flexibility and cross-platform compatibility?

I'd like to set up automated updates for my kakoune plugins, and I do this for all my other apps, such as vim, by running a script. For vim, I can just do vim +PlugUpdate +qa, and it works, but if I do something similar with plug.kak like kak -e 'plug-update; quit', it simply quits right away before it does any updating.

I am unsure what the cause is, but I can only assume it is because the actual update process is asynchronous and happens in the background, while the user is free to do whatever else in kakoune while the update process is going. While this may be desirable in an interactive setting, it makes it impossible to do updates in an automated way.

In plug.sh / plug_list, the code checks for @{0}, which causes git to fail if the reflog is empty (can be triggered manually with git reflog expire, but probably can also happen automatically). Furthermore, plug_list interprets this failure as "Updates available".

Is there any reason to use @{0} instead of @ (the actual HEAD)? If yes, the code could still be fixed by changing to

LOCAL=$(git rev-parse '@{0}') || LOCAL=$(git rev-parse '@')

(and similarly for BASE=)

My use case is that I compact all kak (and vim) plugins by deleting tags, reflogs, inactive remote branches, setting git remote set-branches to only the current branch, and running git fsck to repack only reachable objects. Some people put images (or even videos!) in their repository, so the space savings can be quite substantial, as long as only a minimal set of objects are reachable.

When I commit changes to a color theme repo in $XDG_CONFIG_HOME/kak/plugins, plug.kak identifies these changes with plug-list, but there doesn't seem to be a way of automatically replacing the .kak files in $XDG_CONFIG_HOME/kak/colors.

With such structure of the plugin:

some_plugin.kak
└── rc
    ├── submodules
    │   └── module.kak
    └──  plugin.kak

find -type f -name "*.kak" will either print:

./rc/plugin.kak
./rc/submodules/module.kak

or:

./rc/submodules/module.kak
./rc/plugin.kak

Which is critical, since if module depends on some thing that is being declared in the main plugin, it will throw an error on source. Therefore plugin must be sourced first, then all subdirectories must be sourced after it. So I think something like breadth-first search is needed here, however GNU Find isn't capable to do such search.

Installing plug.kak as described in the README gets me this error on start-up:

/home/<sanitized>/.config/kak/plugins/plug.kak/rc/plug.kak:70:4171: 'define-command' unknown option '-shell-script-candidates'
/home/<sanitized>/.config/kak/kakrc:2:48: 'source' 70:4171: 'define-command' unknown option '-shell-script-candidates'
/home/<sanitized>/.local/share/kak/kakrc:5:846: 'evaluate-commands' 99:16501: 'source' 2:48: 'source' 70:4171: 'define-command' unknown option '-shell-script-candidates'
error while parsing kakrc:
    1:1: 'source' 5:846: 'evaluate-commands' 99:16501: 'source' 2:48: 'source' 70:4171: 'define-command' unknown option '-shell-script-candidates'

Kakoune version (master) 983a8f759a3a959c7712891e2180ab5357c139d2
plug.kak version 7a41cdf

My kakrc contains only one line:

source "%val{config}/plugins/plug.kak/rc/plug.kak"

There are two things which strike me as odd. Line 70 of plug.kak does not contain define-command. And second the -shell-script-candidates isn't new. It was added late 2018.

I'm thinking of adding a colors-cheme attribute, so instead of installing colorschemes like so:

plug "andreyorst/base16-gruvbox.kak" noload do %{
    find -type f -name "*.kak" -print0 | xargs -0 cp -t $HOME/.config/kak/colors
} config %{
    colorscheme base16-gruvbox-dark-soft
}

It will look like so:

plug "andreyorst/base16-gruvbox.kak" colors-cheme %{
    colorscheme base16-gruvbox-dark-soft
}

Where color-scheme switch will make plug copy schemes to colors folder on update for specific packages.

I have been having a blast tinkering with Kakoune, with no small thanks to you for this awesome plugin manager. However, at some point yesterday, something went wrong, because I can no longer install, clean, or update plugins:

This message appears every time, and never disappears. I have tried re-installing plug.kak from scratch twice, but that didn't help anything. This happens even if I reduce my kakrc to just the plug invocations.

Grepping over the source code led me to believe that it places this lock file in the plugins directory, but no such file exists there.

Have a nice colored FIFO could be helpful to keep log.

Moreover, we could imagine some nice interactions on this buffer, like Re-update or Re-try by pressing Return on a given message.

It’s easy to implement and asynchronous by nature, so it could even simplify your implementation.

Implementation examples

• grep.kak
• make.kak
• edit-directory.kak
• filetree.kak (Waiting merge #2)

Currently plugins with load-path are shown as Not installed and invoking I on those results in download error. Instead we should show their load path, and prevent mappings from doing things not meant to be done on load-path loaded plugins, like updating and installing.

This issue will track features, announce updates, changelogs, etc.

Subscribe if you interested.

Spring is coming, so I've decided to show some love to the code. I'm going to do bit of refactoring, some optimizations for performance hungry places, and simplify overall structure a bit. The plugin will act the same as before, but hopefully will be a bit faster on loading plugins and their configurations, and easier to maintain.

This works without any errors:

plug 'andreyorst/plug.kak' noload

However, this gives me an error:

plug 'andreyorst/plug.kak' 'branch: v2018.10.27' noload

~/.config/kak/plugins.kak:3:54: 'plug' 3:57: 'evaluate-commands' 2:66: 'plug-configure' 1:2: 'evaluate-commands' no such command: 'noload'
/Users/evanrelf/.config/kak/kakrc:1:1: 'source' 3:54: 'plug' 3:57: 'evaluate-commands' 2:66: 'plug-configure' 1:2: 'evaluate-commands' no such command: 'noload'
/usr/local/Cellar/kakoune/2018.10.27/share/kak/kakrc:5:853: 'evaluate-commands' 97:20157: 'source' 1:1: 'source' 3:54: 'plug' 3:57: 'evaluate-commands' 2:66: 'plug-configure' 1:2: 'evaluate-commands' no such command: 'noload'
error while parsing kakrc:
    1:1: 'source' 5:853: 'evaluate-commands' 97:20157: 'source' 1:1: 'source' 3:54: 'plug' 3:57: 'evaluate-commands' 2:66: 'plug-configure' 1:2: 'evaluate-commands' no such command: 'noload'

I'm using kak-lsp with a noload parameter and it works fine; it's only when I try to combine noload and a (branch|tag|commit) parameter that it gives that error.

Tested on the latest commit (b3801d2) and one before that (98defec); both had this problem.

Currently plugins directory is quite messy, I propose that plug should install plugins to
author/repo or even hosting/author/repo subdirectories.

Not sure if this make things much more complex, maybe it's not worth it. WDYT?

On OSX Catalina, with Kakoune brewed from source and suggested kakrc, plug returns an error on :plug-install or :plug-update, but loads normally when updated from the list manually.

Debug buffer:

plug.kak: Can't declare highlighters for 'kak' filetype.
          Detailed error: 2:10: 'add-highlighter' duplicate id: 'plug_keywords'
plug.kak: Can't declare highlighters for *plug* buffer.
          Detailed error: 2:6: 'add-highlighter' duplicate id: 'plug_buffer'
error running hook WinSetOption(filetype=plug)/plug-syntax: 2:6: 'add-highlighter' duplicate id: 'plug_buffer'

i have configuration for fzf.kak(Kakoune v2020.09.01)

plug "andreyorst/fzf.kak" %{
    map global normal \' ': fzf-mode<ret>'  # works
} defer fzf %{
    set-option global fzf_file_command fd # not works
}

expected:

option fzf_file_command have value fd

actual:

option fzf_file_command not setted and have default value find

also if set option after kakoune loaded it works.
am i doing something wrong?

The find command here is what's failing:

Changing find -type f ... to find . -type f ... seems to fix this on macOS.

plug plugin demand mod %{}

works, but if the final %{} is removed, the plugin is silently ignored. It is listed as up-to-date, but its code is not sourced. For example any options declared in the plugin are unavailable, and any module declared in the plugin cannot be require-module'd.

Hey,

I noticed this case where defer does not hook correctly.

hook global ModuleLoaded auto-pairs %{
        echo -debug 'this works'
}
plug 'alexherbo2/auto-pairs.kak' defer "auto-pairs" %{
	echo -debug 'this does not'
}

Maybe because it's required so soon? The module is declared and required in the same file.