We have a toolsclient that allows to have various tools always at hand without much overhead of switching windows and such. Sadly, that works only with kakoune tools, while our philosophy seems to be against reimplementing everything inside the editor, so it would be nice to have a place for all kinds of tools be it kakoune internals, TUIs like lazygit/broot/whatever or even GUI tools.
What i personally encounter is i want to run git add --patch with delta diffing in the same place where my :man or :git diff reside.
For that, i see the following possible solutions:
Define an option for tools’ terminal or tools’ window-position-something. That would also require lots of logic for implementing a switch of tools in-place for various terminals/multiplexers/WMs and that sucks.
Implement such workflow entirely from outside of kakoune by means of my WM and terminals.
What do you guys think about that? Anyone has such kind of workflow ready?
Only link i know is a tooltip you would see when :set global toolsclient. Short, it is an option that specifies which kakoune client should be used for opening kakoune tools’ buffers. Tools are in %val(runtime)/rc/tools e.g. {git,man,grep,make}.kak
Thanks for the explanation. I’m also finding that I want to use Kakoune as a text IDE and am tending to route more text output to Kakoune buffers instead of terminal windows.
repo:mawww/kakoune toolsclient
yields some documentation and code samples.
It looks like the Kakoune tools are simply issuing
evaluate-commands -try-client %opt{<mark>toolsclient</mark>} followed by the command
Seems to me you can just as well use that -try-client for your own custom commands. Kakoune has been adding all sorts of function to :git lately that might already do what you want.
How would toolsclient apply to GUI tools? I not aware that Kakoune can display graphics, although my Kitty terminal emulator can so there is a graphics protocol for terminals that Kakoune could support…
How to have such a workflow that one can achieve with toolsclient but unifying kakoune, TUI and GUI tools is the actual question. I know it’s impossible with what we currently have. And i obviously can’t even use TUIs as they are not spawned inside of kakoune client. So i have a setup of kakoune + kakoune man/git on the right, then i want to spawn lazygit and have it in place of kakoune git, but what i can do is either:
spawn it in another tab
close kakoune, open lazygit, open kakoune
mess up the layout
IMO it goes against the conception of easily integrating external tools into one’s workflow.
Probably should have posted in rants and complaints section
The Kitty terminal emulator (and I assume others) has a command interface that I have used to send commands from kak script to another Kitty terminal window. Kitty has overlays that should allow you to cover an existing kak toolsclient with your own command. It’s likely possible for a kak script to access the Kakoune toolsclient name and calculate which Kitty window it is running in…
My kak script instead looked for the largest non Kakoune window in the tab and directed the output there.
You can always store the WM location for a tools window in a file if you can’t calculate it.
Kakoune is so integrated with the shell that I can’t see much difference between your original option 2 and a kak script running under Kakoune…
Kakoune already has to tangle with the varieties of shells, I can’t see any advantage in Kakoune trying to interface to all the terminal emulators out there… I support your goal though. If there is a kakoune hook, kakoune command that would make this easier that might be appropriate.
You can always store the WM location for a tools window in a file if you can’t calculate it.
Yeah, many things are possible and all are non-standard. I’m looking for anyone who already tried such kind of approach, thus has some experience (whether should it be done at all) and maybe a reference implementation.
I am not even sure my bspwm is a good fit for such kind of workflow, as i find swapping and hiding windows logic nontrivial to manage on top of that binary tree.
Kakoune is so integrated with the shell that I can’t see much difference between your original option 2 and a kak script running under Kakoune…
Well the difference is just where and how much integrated the script would be. I don’t really like the idea of baking some WM-specific code into kakoune: that
will break in different environments and is overall ugly. OTOH, if i manipulate kakoune from outside, i could avoid such problems.
Kakoune already has to tangle with the varieties of shells
does it really? as i can see, all stdlib scripts are written assuming
a user has some POSIX sh without bash extensions and standard UNIX tools: i can see them using awk but no perl/ruby/python/tcl;
also no RIIRs like fd/rg.
I can’t see any advantage in Kakoune trying to interface to all the terminal emulators out there
doesn’t it already with all the *-windowing modules? but yeah it’s
pretty thin layer of abstraction compared to what i propose in option 1.
You could replace that with :git diff, select the changes you want to add and run :git apply --cached from Kakoune.
This way there is no need to use a program like git add -p that requires a terminal.