Thoughts and Wishlist

[K1DV5]

I accidentally found this when I got curious if someone built an editor in zig. And this is a great project! Like many before me, I was impressed by what it can already do and how cleanly it does it. I specifically like how agnostic it is about editing models and provides bindings similar to many editors, and I think that's powerful. And that it has full mouse support for people who like that. I am Neovim (non power) user so I will focus on the vim-like parts. And I'm on 0.6 so some points may be outdated, but this is the latest released version.

Verbs: I like the vim mode, works most of the time, but I noticed that it's not that complete, like ce doesn't work and vec doesn't include the last character. And surround motions (provided by plugins in Neovim) like ci" are not implemented yet. But these are small things I use daily but I assume they will be ironed out.

Splits: I think I saw something mentioning these, but I didn't get a clear idea, and I could not find it mentioned in the help. This is an important editor feature and would make it much more efficient to work with in some cases.

Plugin system and config: I think the vim way of doing this is the best (IMO): a scripting language used as both a config format and a plugin language, and I propose Lua. I see flow uses JSON in the current version and I think it changed to another easier format in main and that makes it easy to configure. BUT, having a scripting language for configuration gives the user a lot of power for those who need it; and for those who don't, Lua is very simple for config, can be even simpler than JSON. And it's very fast to write plugins in. It also avoids having a DSL inside a config language, and I assume generally reduces development effort too.

Terminal buffers: I know you mentioned somewhere that you're looking into libghostty and I just wanted to say this is great! And I hope to be able to use it soon.

Binary size: (just to have it in one place) I understand that it's mainly because of treesitter, but two things: First, I use just a handful of languages and the rest of the 70 supported languages, I never use. So most of the big binary is useless baggage to me. Second, in the event where someone needs to edit a language not already included, they either have to wait for it to be included in the next release or build it from source. So I propose just including the minimum number of languages, and have the rest as additional downloads that can be dynamically loaded (like Neovim). I know I am going against the batteries-included thinking, but this is different from having for e.g. a fuzzy searchable command line pallete built-in, which I like. And I don't think the simplicity of downloading one binary is that different from downloading an archive and unpacking it.

In general thank you for the cool editor, and I hope it will grow soon to be a good daily driver for many more people and me :-).

[neurocyte]

Verbs: I like the vim mode, works most of the time, but I noticed that it's not that complete, like ce doesn't work and vec doesn't include the last character. And surround motions (provided by plugins in Neovim) like ci" are not implemented yet. But these are small things I use daily but I assume they will be ironed out.

There are a few open requests for vim mode related features. Feel free to upvote or add whatever you need for your daily workflow. This really helps us prioritize which of the many vim features might actually be useful in flow.

[K1DV5]

Great, I will!

[neurocyte]

Splits: I think I saw something mentioning these, but I didn't get a clear idea, and I could not find it mentioned in the help. This is an important editor feature and would make it much more efficient to work with in some cases.

Vertical splits are going to be available from v0.7.0, which will be released when I get around to fixing a few splits related bugs. Horizontal splits will likely follow shortly.

[K1DV5]

Cool!

[neurocyte]

Plugin system and config: I think the vim way of doing this is the best (IMO): a scripting language used as both a config format and a plugin language, and I propose Lua. I see flow uses JSON in the current version and I think it changed to another easier format in main and that makes it easy to configure. BUT, having a scripting language for configuration gives the user a lot of power for those who need it; and for those who don't, Lua is very simple for config, can be even simpler than JSON. And it's very fast to write plugins in. It also avoids having a DSL inside a config language, and I assume generally reduces development effort too.

I hope to make flow's plugin API very language agnostic. Lua will likely be a very popular option though.

As for config, I'm not certain that a built-in config language is really needed. The plugin API will likely be able to manipulate all available configuration options anyway, so you could just load a Lua plugin if you want to configure flow via Lua. That way it would still be possible to use flow with no startup scripts at all, which I find very appealing.

[K1DV5]

Interesting. Looking forward to this!

[neurocyte]

Terminal buffers: I know you mentioned somewhere that you're looking into libghostty and I just wanted to say this is great! And I hope to be able to use it soon.

"soon" depends on a lot of things, but yes, that is kind of the plan.

[K1DV5]

Haha yes I understand

[neurocyte]

Binary size: (just to have it in one place) I understand that it's mainly because of treesitter, but two things: First, I use just a handful of languages and the rest of the 70 supported languages, I never use. So most of the big binary is useless baggage to me. Second, in the event where someone needs to edit a language not already included, they either have to wait for it to be included in the next release or build it from source. So I propose just including the minimum number of languages, and have the rest as additional downloads that can be dynamically loaded (like Neovim). I know I am going against the batteries-included thinking, but this is different from having for e.g. a fuzzy searchable command line pallete built-in, which I like. And I don't think the simplicity of downloading one binary is that different from downloading an archive and unpacking it.

There is plenty of extra baggage, yes. But it also "just works" when you need it. I am not sure the extra complexity is actually useful to anyone.

That beings said, I would like to maybe move tree-sitter parsers to external executables at some point. That would prevent tree-sitter from being able to crash flow (which, although rare, can happen at the moment). Moving tree-sitter out-of-process would also mean that each parser could be downloaded separately too.

[neurocyte]

Btw, you can also build flow now with no tree-sitter parsers at all with -Duse_tree_sitter=false.

[K1DV5]

I think that's the best approach. And maybe have a command to download the binary, or even automatically downloading it when the first file is opened.

The thing is, for it to "just work" and to support a lot of languages, you have to include a lot of parsers which can make the binary huge. Or include some text-file-with-regex based highlighting for the languages that don't have binary parsers as fallback (Neovim does this, the binary/appimage can be small because text files are small). But obviously tree sitter based highlighting is preferred, necessitating downloading additional content anyway.