Fascinating idea!

To summarize for those who know [Kakoune](https://github.com/mawww/kakoune) or [Helix](https://github.com/helix-editor/helix), the idea is that every command has the form ["selection mode" -> "movement" -> "action"](https://ki-editor.github.io/ki-editor/comparisons/modal-edit...) instead of Kakoune's movement->action.

So, instead of having separate commands for "next character", "next word", "next structural element", there is one command for "next" (as well as [a few additional motions](https://ki-editor.github.io/ki-editor/normal-mode/core-movem...)). Every command starts with a ["selection mode"](https://ki-editor.github.io/ki-editor/normal-mode/selection-...) like "column", "line", or "structural element".

It's hard to know without some practice and experience how much I'd enjoy it, but it is a good idea, and perhaps it'd be easier for a newcomer to learn than Kakoune/Helix.

Is this significantly better than the typical `nvim-treesitter-textobjects`[0] / `nvim-various-textobjs`[1] workflow?

[0]: https://github.com/nvim-treesitter/nvim-treesitter-textobjec... [0]: https://github.com/chrisgrieser/nvim-various-textobjs

I think it's significantly better, because you don't need to know the specific type of node you want to select.

In Ki, you only need to use `s` for any syntax node, while in nvim-treesitter-textobject, you need to use `vaf` for functions, `vac` for classes, and so on. Additionally, this also depends on how well the Tree-sitter queries are written, or if they're written at all.

To be frank it takes time to get used to, especially if you are already a Vim amateur.

However, once you get the hang of it you will find that most common operations can be achieved within 3 keypresses.

For example, to delete the current line, press `e` (Line selection mode) and then `d` (Delete).

To delete the current word, press `w` (Word selection mode) and then `d`.

To insert new text at the end of the current line, press `e`, then `a` (enter insert mode at the end of the selection).

To insert new text at the beginning of the current line, press `e`, then `i` (enter insert mode at the beginning of selection).

To go to the first line, press `e`, then `,` (Move to the first selection).

To go to the last line, press `e`, then `.` (Move to the last selection).

There are too many of such examples that I cannot fit in one comment, but I think you get the idea. It's all about creative combinations between selection modes and movements.

In Vim:

- dd

- diw

- A

- I

- 1G

- G

Code golfing, I count 12 keystrokes in your example, and 10 in stock Vim.

This is the problem which kak/helix/Ki have with drawing in experienced Vim users: a language is a language, once you know it, you know it, and switching is mostly a drag. It does seem like the "it's better to do it this way" pitch works well enough for those who haven't used a modal editor and are curious.

I disagree with the premise (from the Fine Article) that vi/vim is in some way less coherent as a language. Languages don't really do 'coherent', they do 'expressive'. To get expressive, you need some complexity, and all you can do is hide it in different places.

The argument for Vim's coherence can be found here: https://stackoverflow.com/questions/1218390/what-is-your-mos...

The basic premise of Kakoune, which Ki seems to share, is that it's more natural to move first and then command. That's not how my brain works: I know what I want to do immediately, and it takes more time to express the region I want to do it to (simple things like a line or lines are instant, but would be either way). If I found the opposite more natural, I would use `v` more heavily than I do, and then I might wish to switch. The variety of human minds and personalities virtually guarantees that different people will find one or the other to be more natural.

That all said, I think structural editing is a fine thing, and encourage any and all experiments in modal editing: vim is just a language, not a law of nature, and totalizing attitudes towards language smack of cultural imperialism. Perhaps Vim is stuck in a local optimum, although I don't happen to think so.

So, personally, I might try a structural editor which speaks fluent Vim, but won't otherwise. It's like Dvorak: I see the point in the abstract, but I type around 100WPM without any RSI, I know that switching will make me slower, potentially for a long time, and I'm pessimistic that the final state would be faster: the world record holders use QWERTY.

So I'll just limp along with treesitter objects extensions and hope for the best.

I ended up switching to Kakoune and Dance mainly for the multiple cursor support. I treat it like `sed`, but interactive. It feels miles ahead of other editors I know, with the exception of Helix, Vis, and maybe Ki (haven't played with it enough to tell).

> The basic premise of Kakoune, which Ki seems to share, is that it's more natural to move first and then command. That's not how my brain works:

I also didn't find this as a huge benefit, though some people do. That's why I'm sorry Vis (link in another comment of mine) is not more popular; I could far more easily recommend it to other people if it was as polished as Kakoune and maybe had a VS Code plugin.

---------

Now, for some things I don't fully agree with.

> I disagree with the premise (from the Fine Article) that vi/vim is in some way less coherent as a language. Languages don't really do 'coherent', they do 'expressive'.

I think Vim is definitely less coherent. The first example that comes to mind: it's easy to get to the first line with `:1<enter>` or `gg`, while getting to the last line is `G` for some reason (Update: TIL that `:$<enter>` also works, which makes a little more sense. But `:|<enter>` does not take you to the first line). Getting to the first column is `|` I think? I can never remember it, fortunately `<Home>` works.

Now, where I do agree is that, IMO, it's an open question whether making a modal editor's language more coherent than Vim's would make it more expressive or easier to learn. Vim's language is pretty good. My personal feeling is that Kakoune maybe gets close to Vim's bar, and maybe even exceeds it, but not by enough to make it a fundamentally better language (except for its multiple selection support, where it is fundamentally better).

My hope is that Ki might be better, or that its ideas might lead to a better language. I am not certain this is the case, but it should make the situation I described two paragraphs ago better, at least.

> Code golfing, I count 12 keystrokes in your example, and 10 in stock Vim.

To me, the number of actual keystrokes matters less than how much space they take up in my mind and how easy they are to think of (or, better, perform reflexively). If I typed faster than I thought (e.g. if I was transcribing a voice recording or translating), I might feel differently.

Honestly I used to feel this way, but ended up using Helix for a few months mostly as an experiment. Now the selection-action version feels just as natural as action-selection used to. I’m sure I could flip it back if I wanted to.

I’m pretty sure it’s not a natural wiring of your brain, but rather long ingrained familiarity.

That said, incredibly marginal value to switching so I wouldn’t bother.

Bookmarking

what's the keystroke sequence to move forward five words, one word at a time (so you don't have to count them first)? in vim it's wwwww, and in emacs it's alt-f f f f f

the asciinema demos are super cool! btw asciinema has an option to record input keystrokes as well as screen output, but i don't know if there's a way to display them in the standard js web player for it

I tried but couldn't figure it out from the docs. It's unclear if the selection mode is sticky or is required before each command. e.g. wl would be "next word". I don't know if the command is "wl wl wl wl wl" or "wl l l l l" or if there's a "repeat movement" command.

Update: I installed it and the selection mode is sticky. The command is "wl l l l l"

so sometimes it's just l l l l l, but other times that does a different movement, depending on what mode you're in? how many different things can l l l l l do? are there situations where two of them look the same so you might continue to believe you are in a different mode than you are?

this kind of thing might be a good ux tradeoff but I think you'd have to validate it empirically to see how much the extra cognitive load slows user task completion

Yes, but there’s a visual indicator what the selection mode is, which helped in my brief experimentation.

Selection modes are sticky, so it would be “w l l l l l”

> in vim it's wwwww

You may also want to try out <num><action> methods while in normal mode.

    # Move forward 5 words
    5w

    # Move 20 lines up
    20k

The latter paired with relative line numbering can be really handy.

yeah, that's why i said 'so i don't have to count them first' (the reason i have a computer is so it can count things for me) and used words rather than lines. i agree that relative line numbering is a big plus here

I am a vim user and I wonder what is the use of going five words forward when you can just search for the beginning of the word you want to go to and press enter (even works across lines).

After using vim for a while now I do most of my navigation and editing by searching/replacing

yes, usually it's better to do a search in both vim and emacs, unless you're recording a keyboard macro or using multiple cursors. commonly in the macro or multicursor case, the search string would be different on every line you're trying to make the edit on

I wouldn't say either is better "usually", it really depends on the situation.

If the next five words begin with the same prefix (happens to me), searching will be wasteful. Just spamming "w" is easier.

But when there's something really distinctive (often, punctuation) near the position I'm aiming for, I'll definitely use search.

That's one of the reasons I prefer BRE over ERE/PCRE when editing text interactively - I can search for punctuation in code without having to backslash-escape it.

you have some good points

'bre vs. ere' is terminology i wasn't familiar with, though i've often tripped over the differences: https://www.gnu.org/software/sed/manual/html_node/BRE-vs-ERE...

iirc mit teco used control characters for its regexp metacharacters to diminish this particular problem

From a theory/implementation point of view, maybe this is relevant: https://groups.csail.mit.edu/graphics/lapis/doc/papers.html

Another editor that people might be interested in (and I think more people should know about) is https://github.com/martanne/vis. It is, in some ways, the opposite of Ki; instead of straying further from vim, Vis is just Vim + good multiple cursor support + sam-styled structural regexes (I didn't know what those are before using Vis, I consider it a detail of how the multiple cursor interface works).

Thus, Vis is easier to learn than Helix/Kakoune and gives you (IMO) the most useful feature of Helix/Kakoune.

Unfortunately, Vis is also a bit bare-bones, I don't think it has LSP support for instance.

Re. LSP support, there's this:

https://gitlab.com/muhq/vis-lspc

https://github.com/fischerling/vis-lspc

I've linked both because it seems like the github repo has a pull-request with a bunch of updates but the gitlab repo seems to be more up to date?

I've not tried getting it working yet, but I've seen people on Reddit (or lobste.rs, I don't remember) saying they got it working.

You know it's going to be a good day when there is a new modal editor in town. Thanks for sharing.

About the editor : I love what I see. I must admit that for me now the ultimate vim-fu I settled upon for navigating/editing is searching/replacing ( with something like traces.vim and `set incsearch on` so it feels nicer ) so this new paradigm makes a lot sense I believe.

Very nice project, i think the way you navigate is implemented spot on!

Although i have some questions / concerns: - "Command mode" (`:`) seems a bit more different compared to Helix / Kakoune and maybe even VIM. I would have also expected to be able to change the theme like so.

- I couldn't find (after just a bit of skimming around the docs) how to adjust the sizes of e.g. the file-tree. Or well, even change to a different window. I like the concept of having multiple windows within the browser, but couldn't really figure it out.

Also, layouts may be a neat idea to implement, so that e.g. the file browser will always spawn on the exact same location of a defined layout (may as well be pre-defined) - Theme browsing is a little bit slow i feel like, not big of a deal, just something i noticed.

- The docs may also need a way to change from selection based movement (e.g. via Token / ts node) back to character based.

- The gui may need some improvements, maybe it's just subjective perception, but having a small window with all the options there is good, but i couldn't intuitively tell whether or not those were all the options (e.g. in <SPC> mode). Also i am fairly certain there were more options.

- A builtin tutor is also a neat idea, considering that your editor looks very young, i am sure you thought of that, but it's a really easy way to get new users comfortable with using it.

Anyway, very neat project! I will keep an eye out and eventually try and daily it, at least for a week. The structured editing you implemented is REALLY GREAT, like better than i could have done it (or even thought about).

Thank you for trying!

For character-based movement, simply press 'z' to enter the column mode.

Regarding the built-in tutor, yes I really have to put in the effort, because it's so much harder than authoring documentation.

And yes, a lot more has to be improved, Ki needs a lot of polishing around the edges.

> For character-based movement, simply press 'z' to enter the column mode.

I did eventually find this in the documentation, under the "regexp selections" section. I think it should be more prominently displayed in other sections, since it's a natural thing to want (at first).

I am enjoying the editor (as a current helix user), and looking forward to trying it more.

I wish this were a mode for https://github.com/71/dance or a plugin like it. Technically, this seems entirely possible, though I'm not sure anybody would have the time to actually implement it unless Ki's author wants to do it.

As is, Dance with Kakoune bindings is good enough and supports all of VS Code plugins, so I'm not sure I'll get enough use of Ki to actually get used to its bindings. Or maybe I'll play with it anyway...

P.S. I linked this in [Dance's forum](https://github.com/71/dance/discussions/347), perhaps it'll turn into an actual discussion.

This looks really interesting. I will try it out sometime, but since there's no Windows builds (does it even support Windows?) that will wait a bit. I don't think it's good idea to have compile-time configuration (needing a toolchain to change config). What happened to MERC[1]? I suppose it was written for this editor?

[1] https://ki-editor.github.io/merc/

I will need help unfortunately because I don't have an accessible Windows machine.

For the configuration I'm planning something crazier, I might use my programming language that I built earlier (https://github.com/wongjiahau/kk).

I personally don't think Lua is a good choice for an embedded language in 2024, the bare minimum should be indentation-based scopes and zero-indexed arrays. Of course, Tthis is your project, but perhaps taking an existing and mature language would ease the adoption?

I'm working on something similar (not as far along), a vscode extension that has ideas like functions, parameters, etc as first class ideas (so press f to select a function) and also does things like adding a newline and a space where appropriate during insert actions.

Here's a short video demo if anyone is interested: https://youtu.be/owuuFxDBQh4

"Ki" also means "who" in Persian-Farsi ("کی"). Looks neat, just wanted to add some random related trivia.

"Qui" (pronounced ki) also means "who" in French. I wonder if they're related.

French and Farsi (Persian) are both IndoEuropean languages. So yes, they are related. If I'm reading it right, the Proto-IndoEuropean word for "who?" is /kwis/.

KI means AI in German, I was already searching for some fancy GPT implementations

Künstliche Intelligenz. Sounds super cool, not gonna lie.

Oddly enough, same in Hungarian.

“Ki” means “what” in Punjabi.

This is so well presented. I love the demonstrations of real life editing tasks. Looks like it can actually do the kinds of complex editing tasks Vim users claim they can (but never provide realistic evidence for like this).

Case agnostic search and replace is such a nice feature too. I have no idea why it isn't standard in IDEs.

This looks awesome.

It was a bit hard to see on mobile - what are the hotkeys in the first demo to select the full function call?

Just `s` if your cursor is already placed on the first token of the function call node.

Structured editors are so cool. I’ll give this a try at some point, because I really wanted to like Helix and others, but the actual UX felt too strange and difficult.

I’m building my own semi-structured editor but it’s specifically for UI design. Love seeing more examples for inspiration!

Would be cool if it was client-server architectured. If I can't open the editor in 2 terminals and edit the same file, that's a real blocker.

Good keybinds though, I like it a lot.

cool demos, but i feel they would be easier to follow slowed down a touch

going to try this out: the idea of breaking motion -> action into something like topic -> adjective -> action has been kicking around in my head for a while

Aren't multiple cursors and structural selection kinda standard fare these days? Even VSCode has "Expand Selection".

Multi-cursor, yes; structural selection, not so much, they are more like an afterthought for most editors, there’s a big difference between being treated as first-class and second-class.

Can you describe what you think is the difference between Ki and the syntax tree based selection expanding that's been available in emacs for probably a decade or more?

Do you mind sharing the Emacs package that does "tree based selection expanding" so I can better highlight their differences?

I haven't been active in Emacs world for a couple of years, but https://github.com/magnars/expand-region.el has been there for a while. I think the new code is right in lsp-mode and called lsp-extend-selection.

VSCode has "Expand Selection".

Mathematica has ctrl-. (http://xahlee.info/emacs/emacs/syntax_tree_walk.html)

Zed has "select enclosing symbol" but that seems to jump to function level expansion immediately, I didn't see anything more gradual there.

It really needs a tutorial. I'd like to get a feel of how it works before having to study the documentation.

Aside from that congrats!

Love the idea! I too am exploring structured editing, i hope to learn something from Ki :)

How does this compare to Kakoune and Helix?

Ki is much inspired by Helix and Kakoune, however, it introduces an extra layer called the Selection Mode, with this, every movement is standardized to the same set of keybindings.

Also, most importantly, syntactical selection/navigation/modification is first class, although it is somehow supported in Helix, the default keybindings are not very accessible.

Another big difference from Helix is its internal architecture, most Helix components were rebuilt from scratch, while in Ki every components uses the core editor as the base, which means all components shares the same set of keybindings, you don't need to learn different set of keybindings for different components.

That's true for some users certainly, but I guess most users will not know which 4 easy-to-access keybindings to downgrade in exchange for the 4 syntax navigation keys, if it were you which 4 default keybindings are you willing to sacrifice?

The 4 movements are parent, first child, previous sibling, and next sibling.

I find alt-npoi intuitive and easy to reach. But my point was not that default key bindings don't matter, just that there is no one shoe fits all, and that different choices are not so relevant in comparing editor features when they are fully customizable.

As an old-timer, I don't quite understand why Emacs still is kind of a niche app after all these years even within dev circles. Most of the functionality that other editors offer is available in Emacs too, and when it isn't, then there are usually acceptable alternatives.

Over the years, I've heard many arguments against Emacs but found none of them convincing, especially if you take the point of view that learning a powerful tool can be an essential asset in any profession. Emacs certainly is such a tool.

The same question could be asked about vi(m), although that one at least received some hipster love in recent years. That seems to have cooled down somewhat too, though.

Any emacs set up as a 'modern IDE' with neat features runs like an absolute dog. It's only fast because it was written long ago.

Does it?

I've set it (emacs 29.4) up like that (LSP mode (including rust), DAP mode, 160 emacs packages, daemon mode) and it works very fast for me. It can do project tree, intellisense, refactoring, macro-expansion and auto-implementation that way.

Opening a new document takes about 75ms for me.

Modern emacs has native compilation via gccjit.

package specification: https://github.com/daym/guix-config/

emacs config: https://github.com/daym/emacs-config/

The most productive programmer I know would launch Epsilon (a Windows version of emacs) at the beginning of his workday and never leave it (even to browse the web at lunchtime).

My problem has always been that I prefer to use styluses, and to hand-write things out at times and to use a stylus for editing/annotation and to have a graphical environment for displaying markup and so forth (which reminds me, I need to see how the new LyX 2.4 works w/ a stylus).

As a long time Vim/Kakoune/Helix user, i've never really understood the difference tbh. Clearly i've never tried, but getting comfortable enough in a new editor, especially one that deviates so much from your norm, is quite the chore.

From the outside Emacs never drew me in. It didn't do anything "bad", but the premise behind vim (motion actions, etc) just sounded logical, like building blocks , and as a result drew me in for being easier to understand the basics of.

I could never grasp what Emacs even "was", as a pre-vim beginner. To this day i still don't know, but my general assumption is it's more built around commands rather than little primitives like Vim does. Which, seems fine - just never was enough to hook me.

These days i'm mulling on my own editor and i should probably better understand Emacs. I've watched some guides on Org Mode, which is a big area of focus for me, but even that just seems like Markdown with an LSP (link jumping/etc), so i still must be missing something heh.

Well, for one, org-mode predates Markdown (not by much, but anyway), and it is not just the syntax but also a lot of usage functionality. However, while a lot of people use Emacs especially because of org-mode, I almost never use it, although Emacs has been my daily driver for over 25 years.

For me, the concept of modal editing has never been appealing, so even though I know some basic vi, I never got into it. Perhaps I was influenced to some degree from taking some HMI classes in college (see Larry Tesler), I don't know.

Emacs is really just an editor, but it was built from the get-go to be super-hackable and has a very solid modular architecture, based on well thought-out concepts. That allows it to offer specialized functionality for different file types in the form of add-ons ("modes"), and it allows every end-user to fine-tune the editor to their own liking.

If you want to get a grasp of its capabilities, check out the "Emacs rocks!" series [0] - it's a bunch of short videos demonstrating some interesting things you can do with Emacs.

[0] https://emacsrocks.com/

Emacs is a text processing environment. Everything is a command: even hitting the down arrow is calling a specific command in Emacs Lisp. This means you can modify almost any behaviour or Emacs. Want to add some new action to the down arrow? You can easily do that with Emacs.

(I'm not trying to convert you, I'm just trying to get across what Emacs is)

Emacs exposes lots of rich functionality to the user.

A lot of people have been told that they don't need to learn "difficult" or "esoteric" tools. The same thinking is behind the use of npm modules for basic functions that programmers should be able to make themselves.

That would be a prime example of what I called "unconvincing argument" above.

Almost every part of your comment is wrong, too, so that certainly cannot be the reason.

Why it is wrong? I don't want to learn (((complex))) and (((((((useless (((language)))))))) just to adjust some config. Sorry to trigger you. But that's a fact and I am not wrong about it

Obviously you are wrong, since it has been already demonstrated that it's not useless, as already the GNU Emacs example shows. It comes with a lot useful and well written software -> in Emacs Lisp -> roughly 1.5 million lines of code.

and not even a "full" Lisp, last I checked it was a special emacs version of Lisp, with a lot of ways to end up with unstructured code (freedom) hence leading to "emacs bankruptcy". I think the concepts are nice though, just needs to be refined - difficult given the legacy and following emacs has..

I don't think that Emacs Lisp needs to be a "full Lisp", whatever that would be, but it would need, for example, some improvements in the structuring of large programs, since there is now a lot, and still growing, amount of code written in it. Namespaces/modules and threading would be examples for improvements.

Emacs Lisp's language design was originally designed on Maclisp. Maclisp is long dead, but other descendants of Maclisp have been standardized (like Common Lisp and ISLisp). Emacs Lisp has been improved over the years (just two examples: lexical binding and native compilation), but there would be more to do at the base language. It's the task of the users and maintainers to do so and they have their own preferences.