Since kakoune does one thing and does it well, it is natural to use it with auxiliary tools.
I would like to start a discussion on what stack do you use with kakoune? what stack your tried and didn’t work, why you use this one and not another one etc…
Feel free to join your dotfiles 
For the moment I don’t use kak as my main editor, so I just have a vanilla kak with one plugin : kak-lsp who work fine for me. Next step: a multiplexer and a way integrate a REPL !
Here’s the list of (terminal) tools I’m using regularly, often in coordination with Kakoune: https://github.com/Delapouite/dot-in-the-sky
Holy crap… so much I didn’t know about! Things I started using as soon as I went through your list… so many new toys!
My stack:
Distro: KUbuntu/Arch
Window Manager: Bspwm, Sxhkd, looking for a bar. I also use tmux when I ssh.
Terminal Emulator: Kitty/Alacritty
Shell: I liked xonsh but I decided to stick to POSIX shell.
Typical programs:
), and once in a few months vscodeTypical terminal commands:
For documentation:
I do all my editing in kak-shell from connect.kak to manage sessions. It is inspired by nix-shell from NixOS and the first menu (when you choose a session) by 3mux.
Sway or Wayfire, and terminal-mode.kak to choose the terminal (tmux, graphical or same terminal window).
I use tmux as a workspace, where each session is a window.
[0] ⇒ Console[1] ⇒ Editor[2] ⇒ ScratchFor example in [0], I have a window for the Rails server and console (two panes in a window), in [1] the editor for Rails, and [2] a lf instance connected to the editor in [1].
When I switch to another project, I keep [0], [1] and [2] for the same tasks, but switch the view to the appropriate window in each session (what you can see as tabs in a tmux session).
For searching files, :e, :e <directory> or :e <a-.> (to expand to the buffer directory) to search with fzf in the same terminal window (see connect.kak and explore.kak).
map global prompt -docstring 'Expand to the buffer directory' <a-.> '%sh(dirname "$kak_buffile")<a-!>'
For searching buffers, :b to search with fzf (same plugins).
For exploring files, either lf or Dolphin with :lf and :dolphin (from connect.kak); when I click a file, it opens in the client from which :lf and :dolphin were run.
I mainly use Dolphin on foreign code for discovering and clicking around.
About the TUI file explorer, I use lf for its client-server architecture and simple interaction with external programs. You don’t have tabs, but you can copy or cut a file from one lf to another lf. lf initializes the server on first launch – all lf are just clients connected to a server. It’s like Kakoune, but automated, and you have a single server. As far as I know, it is the only terminal file manager offering a client-server architecture.
Like Kakoune, it interacts well with external tools, such as fzf.
Example – Jump to location:
cmd fzf-jump ${{ # [path...]
# Select a file under the given or current directory:
path=$(fd . "$@" | fzf --header='Jump to location')
# Assign the command:
if test -f "$path"; then
command=select
elif test -d "$path"; then
command=cd
else
exit 1
fi
# Send the command to the client:
lf -remote "
send $id $command $path
"
}}
map <c-f> fzf-jump
There is some oddities ($f, $fs and $fx could be unified and support different formats for perfect escaping, instead of relying on a filesep option); block strings are not as robust (multiple levels do not work) and flexible than in Kakoune (you don’t have %arg{n} to pass values, but typically just do \"$1\" of the shell inside double quotes (where inside it’s the lf speak), which is not a perfect forwarding).
I tried other file managers too.
One of the most different is Broot. It is like a project drawer (for its tree-style view) with a fzf interface. I see it more like a file selector rather than a file explorer.
The author of lf said on reddit:
The way I see it, terminal managers are like a normal mode for shell. You can assign keys to your commands and execute them easily instead of typing (as in hitting i to open a file in your pager rather than typing
less <tab>).
Broot makes fuzzy searching very easy at the expense of making spatial navigation (therefore exploring) not easy.
While lf has —hjkl— spatial navigation, it can extend its functionalities with fzf or another program to open a file or navigate into deep structures.
I wish I could make a better use of Broot in my workflow, but I didn’t.
See also the last paragraphs of Why Kakoune – What is modal text editing; I think @mawww better captured what I try to express.
I have read a lot about these “accelerated terminals”, can you actually feel a difference?
Well, the experience is not that much different. I used to use gnome-terminal, but it wouldn’t even resize to arbitrary sizes. I like kitty’s wide range of features more than anything else.
Regarding speed, a friend of mine recently switched from his default terminal emulator in MacOS to alacritty and he told me he noticed it was much faster. Personally, even if they really are quite faster, I don’t think it is going to impact your workflow that much. I prefer them over gnome-terminal or konsole though.
At one point in the recent past, didn’t Alacritty has rather poor meta/alt support?
I don’t know anything about that. I haven’t experienced any issues.
EDIT: my friend told me he had to hardcode some keys in macOS, but he said it was as easy as copying them from a blog. He told me that alacritty is the best option he know for macOS, and that he notices the speed a lot.
Check this issue.
My understanding is that for things like input delay, start up time etc… they aren’t necessarily any better than the competition but they do have excellent throughput.
alacritty has awful input latency because all the developers care about is synthetic throughput benchmarks.
My experience on macOS is that Alacritty was noticeably faster than iTerm2. I still switched back to iTerm2 for two reasons:
I started investigating kitty (ratherthan gnome terminal) to try and reduce memory use, and eventually switched over fully because of other features (the flexible startup scripts and the nice windowing support, along with better keyboard usability). I don’t know if it’s been noticeably faster or more responsive, but it certainly hasn’t been /less/ responsive.
have you tried kitty? I much prefer it over alacritty, plus built in pane creation <ctrl+enter> and pane reorganization <ctrl+L> tall, stack, horizontal,vertical,fat.
I am starting to explore kitty – hard transition from tmux. Probably not going to survive it, but interesting.
oh I still very much use tmux, particularly for commands that take a few hours/days to complete. Though it’s usually on my server, on my DD just kitty.
Hey, yeah I gave it another shot and I think I will switch to kitty for good. While sticking with tmux. Kitty supports everything I need on macOS (e.g one option-key; one alt-key). Plus I now get to share a single, version controlled kitty config across my macOS/Linux systems.
I think I finally may have found my terminal 