Quick question: how should I reference plugins managed by the system

dumb question, I’ve been working on my kak configuration on a new install where kak-lsp is installed by the system rather than manually, I’m trying to figure out the syntax for configuring a plugin without installing a copy.
noload is to , is there something similar for noinstall

I could be misunderstanding your question but there’s nothing special about the configuration part of plug.kak other than when it is run. You already have the binary so you don’t need to build it. With other plugins you might need to

hook -once global ModuleLoaded 'module name' %{ ... }

but kak-lsp is normally loaded by

eval %sh{ kak-lsp --kakoune -s $kak_session }

or

source "directory/of/lsp.kak/rc/lsp.kak"

so you just write your config below that. The kak-lsp readme implies Plug.kak does the later automatically.

you can point plug to your local installation of the plugin using load-path keyword:

plug "kak-lsp" load-path "/path/to/kak-lsp"

This way plug.kak will not attempt to install or update a plugin.

But I don’t like the idea of installing plugins for text editor with the system’s package manager in the first place, this is what plugin manager is for. If kak-lsp provides prebuild releases you can grab those in the do block with something like wget

yeah, I’m debating the merits of relying on the plugin manager vs system, especially on my system (fedora) due to me still not fully understanding how to configure selinux policies(it’s on my todo list), and the fact that it’s not quite rolling release means occasionally bugs will be fixed upstream but broken for the distribution.

I do have something I’m about to pick up again where having packaging controlled by the system make sense, because it’s editor agnostic, so I needed to figure out how to do this anyway.

skewballfox
March 11

yeah, I’m debating the merits of relying on the plugin manager vs system, especially on my system (fedora) due to me still not fully understanding how to configure selinux policies(it’s on my todo list), and the fact that it’s not quite rolling release means occasionally bugs will be fixed upstream but broken for the distribution.

I do have something I’m about to pick up again where having packaging controlled by the system make sense, because it’s editor agnostic, so I needed to figure out how to do this anyway.

did load-path worked for you? As I’m a bit unsure how exactly the plugin is installed by the system

I had an odd issue where it wasn’t generating errors but it wasn’t starting the language server(or at least, the lsp wasn’t showing any output), so I switched to sourcing it manually, which worked.

the issue may not have been the method of loading with plug.kak the way you mentioned; I’m making a ton of changes to my kakrc(mainly cleaning it up and trying to get everything configured to work on fresh installs with little manual intervention), so a few things are not working as expected in the interim

it seems to the kakrc is in /usr/share/kak-lsp/rc/lsp.kak and the actual executable is in /usr/bin, so mainly adhering to linux directory norms

honestly I might need help debugging the issues with my kakrc. Since that is irrelevant to the current topic should I open an new discussion?

yes, seems reasonable

Interesting, I might need to test this