Modern text editor features checklist

Complaints & Improvements
1

Recently I read the blog post „What is in a modern code editor?”. I noted features that are required according to the author and (subjectively) marked what we already have in Kakoune and what are still missing.

  • [x] syntax highlighting
    • tree sitter / PEG based parser might be more accurate but regexp based highlighting is good enough
    • syntect integration could be a cool project to take advantage of Sublime syntax definitions and color schemes but again - not needed, what we have is good enough
  • [ ] file browser
  • [x] Searching through the codebase
    • great grep integration, fzf plugin (also archived but works in latest stable)
  • [x] Language intelligence
    • kak-lsp folks are doing a great job :smiling_face_with_three_hearts:
  • [ ] Debugging capabilities
  • [x] linters / show errors
  • [ ] snippets
  • [x] formatting code
  • [x] terminal emulator
    • not needed with tmux/i3
  • [ ] Git/VCS integration
    • mediocre integration with git
    • could be so much better
    • sky (Magit) is the limit
    • we can use external tools, but some tasks are better performed from the editor (staging, line/file history, reverting, conflict resolution)
  • [ ] Configuration language and plugin system
    • IMO needs better IPC
      - %sh{} annoying for complex stuff
      - spawning shell is slow
      - see pykak
  • [x] test runners
    - I think LSP supports it
  • [x] window management
    • use tmux
  • [x] undo system
  • [ ] code folding
    • :poop:
  • Understanding indentation
    • :poop::poop:
  • [x] docs lookup
  • [x] works on remote systems
  • [x] modeline
  • [x] good font rendering
    • delegated to terminal
  • Vim mode
    • NO
5 Likes
2

But connect.kak exists, and kakoune.cr and some others I’ve forgotten at the moment. It’s not exactly the same thing as kak-tree, but with i3/tmux integration you can pop open the file-browser of your choice to edit new files in your existing Kakoune session.

3

it’s quite simple; enable snippets in your kak-lsp.toml (it’s the default again) and add the recommended mapping for insert <tab>. Then, in a C file with #include <stdio.h> type fprin<c-n>stderr<tab>"hello\n"<tab>.

Git/VCS integration

True although I’m fairly happy with Tig where I can just hit e to open Kakoune at the current line. I agree that Magit is the best but it was a bit slow last time I used it.

1 Like
4

Yeah, I use kkga/kks + lf and this stopgap solution:

declare-option -docstring "Choose where to display kks_lf panel.
    Possible values: left, right
    Default value: left
When kks_lf_split is set to 'horizontal', 'left' and 'right' will make split above or below current pane respectively." \
str kks_lf_side "left"

declare-option -docstring "The size of kks_lf pane. Can be either a number of columns or size in percentage." \
str kks_lf_size '36'

define-command kks-lf %{
	nop %sh{
    	kks_lf_cmd="kks-lf"
        export EDITOR="kks edit"
        export KKS_SESSION="$kak_session"
        export KKS_CLIENT="$kak_client"
        if [ -n "$TMUX" ]
        then
            [ "${kak_opt_kks_lf_split}" = "vertical" ] && split="-v" || split="-h"
            [ "${kak_opt_kks_lf_side}" = "left" ] && side="-b" || side=
            [ -n "${kak_opt_kks_lf_size%%*%}" ] && measure="-l" || measure="-p"
            tmux split-window -f ${split} ${side} ${measure} ${kak_opt_kks_lf_size%%%*} env EDITOR="kks edit" KKS_SESSION="$kak_session" KKS_CLIENT="$kak_client" ${kks_lf_cmd}
        elif [ -n "${kak_opt_termcmd}" ]; then
            ( ${kak_opt_termcmd} "sh -c '${kks_lf_cmd}'" ) > /dev/null 2>&1 < /dev/null &
        fi
	}
}

Not as good as tree view of files, though.

Thanks for the instruction @krobelus, I’ll give it a try!

5

I’m currently working on the “Debugging Capabilities” item with kak-dap, but progress has been kind of slow as of late due to other hobbies and activities taking up my free time. This project’s not dead, I promise :grinning:.

Currently, although it is quite limited, kak-dap is capable of debugging any language that works with gdb, and also has been tested with ruby, python, and PHP. It’s undergoing a complete rewrite at the moment, though, which will greatly change how it works. Debugging will come; just give me some time :grinning:.

4 Likes
6

kak-dap looks promising. I was on your codeberg page just yesterday, and the one thing that stopped me from diving right in was the installation of associated tools.

One of the amazing features of VSCode’s flagship plugins (I’m thinking specifically of the Go plugin) is that they often install tools for you. This is - of course - both error prone and fraught with peril, and perhaps not what you should focus on right now as the sole developer.

But do you have any thoughts on it? Could you perhaps provide hooks or a framework for others to contribute code that 1) downloads plugins, 2) runs diagnostics, 3) keeps them updated, etc.

7

Yeah, that’s one of the reasons my rewrite is moving away from Rust, since it’s not installed by default on any Linux or Unix distro I know of. I’m trying to switch over to Python (with a small performance hit), since that’s far more widespread and doesn’t require compiling a kak-dap binary.

As for installing plugins, there’s a couple of plugin managers that can help automate the process. plug.kak isn’t maintained anymore, but it works well, and kak-bundle is another option I made if you want a more streamlined experience. Both of these support running post-install tasks in case of installation of prerequisites or compiling.

Let me know if this helps, and if you need anything else :grinning:.

1 Like
8

That is a very interesting article! I agree with your checklist; most of the things that are missing are things that I have found myself wanting.

File browsing

I have a two-part solution. The first solution is a mapping in kakoune that collects file candidates from a shell script, then uses kakoune’s built-in fuzzy finder to search for the file you want:
map global goto f '<esc>:prompt -menu -shell-script-candidates %{ git ls-files -c -m -o } git-file: %{ edit %val{text} }<ret>' -docstring "git file..."
You could replace git ls-files with fd or something similar. It’s really nice, because it’s built right in to the editor and is very quick to use:

image

For browsing the filesystem, I use nnn, which is an absolutely amazing and minimal terminal file browser. I have a kakoune command that opens a floating terminal, and a small shell script to open nnn in picker mode and pipe the chosen file back to kakoune:

image

Debugging

This is indeed something that is missing, and needed. There are a few kakoune plugins for specific debuggers like GDB, but there is not yet a complete plugin implementing the debug adapter protocol.

jdugan is working on kak-dap, but at around the same time, I started working on my own project called pesticide. While kak-dap is specifically targeted at kakoune, pesticide will be usable as a completely standalone program, and will also feature kakoune integration built-in. I had a working prototype, but ended up scrapping it and switching from Rust to Go. Hopefully in the near future, both kak-dap and pesticide will be in usable states, and we’ll have two competing implementations of debugging!

Git integration

I honestly don’t use kakoune’s git integration for much more than blame. For everything else, I use the phenomenal lazygit in a popup window. It’s so good that I don’t find myself missing anything in kakoune in this department.

Plugin system

Better IPC is sorely needed. I have been saying for over a year that I wished kakoune had a proper IPC using json rpc. While %sh{} is really great for simple things, using it to create complex plugins is an absolute pain. Kakoune already uses json rpc for alternate UIs, so some of the infrastructure is already there.

TL;DR

Agreed on almost all points. Kakoune is an amazing editor, but there is no denying that it could be better! I look forward to seeing what the future has in store.

4 Likes
9

better ipc is very much needed. i would also like if kakoune was a proper gui editor, not limited by terminal grid, allowing mixed fonts/font sizes, inlined media and rich fake windows. for now i am a hostage to editing model, because feature wise pretty much every other popular editor is miles ahead.

1 Like
10

Are IPC and GUI support related concepts? My understanding is Neovim can operate as a headless server, accepting commands over (msgpack?) ipc, and maintaining buffer state.

11

There is a vscode extension called Dance that does a pretty good job of integrating Kakoune’s editing model. It does it all natively in vscode instead of using a backend Kakoune instance, and it works pretty well. It hasn’t incorporated the recent breaking changes yet though.

It’s possible to make a GUI kakoune using the JSON UI protocol, but nobody has done it yet.

12

Kakoune’s JSON UI protocol is fairly low-level: you tell it the dimensions of the character grid, it tells you what characters to draw in which cells and with what formatting. There is some leeway with info boxes and completion menus (you just get told about the contents, its up to the UI to decide where to draw it), but you don’t get enough information to (for example) draw a scrollbar or see any text above or below the viewport, and the UI’s only way to control Kakoune is by the moral equivalent of execute-keys (or, if you’re tracking the session ID, kak -p).

I’m not too fussed about JSON based IPC, though. Kakoune’s native data type (as used in Kakoune scripting, etc.) is “list of strings”, and while you could represent that as newline-delimited JSON like the JSON UI protocol, implementing Kakoune’s quoting system from scratch would be no more difficult… and that’s assuming you’re going to use a library for JSON and not for Kakoune.

1 Like
13

What are the use cases for better IPC?
kak-lsp is unusably slow on Cygwin but the pykak approach could fix that.

14

Somehow I missed this reply. Whenever I have tried to make something even moderately complex with Kakoune, it has involved a ridiculous amount of jank. Writing a plugin in a proper language is better, but you still have to write a bunch of shim shell code to make it work. Take kak-lsp for example - while the majority of it is written in Rust, you still have to write a bunch of shell scripts in the rc file to make it all talk. Shell is nice for a lot of things, and the tight integration that Kakoune has with it is truly spectacular, but doing anything complex with it is an absolute PITA.

A proper IPC protocol would solve this issue, allowing an external process to communicate directly with Kakoune and eliminate the middleman. If it was based on JSON RPC, the majority of languages already have mature libraries to handle that protocol, making complex plugins a lot easier to write. When I was (attempting to) write my location list plugin, I spent more time setting up the Kakoune comms than I did writing the business logic of my plugin. By contrast, someone made a vis plugin for quickfix lists in just 200 lines of Lua.

I feel that having proper IPC would greatly benefit the extensibility of the editor. %sh{} for simple things, IPC for complex things.

8 Likes