Dou Vim-style Code Editor

[hyduez]

Note

This a Open-talk to discuss things about the project we are building, feel free to read, make your comments and suggest new approaches. Here are the roles we are looking for, click here.

a dedicated communication to @dousec/ace team and the public.

alr, as you may know we were doing a few tests/drafts about developing a new text editor, with a minimalist and versatile design split by a core library and an api one, which would be used to script and extend the behavior of the core. of course, there's a lot of things we can add to improve the user experience as well as the developer one, things such as adding lazy-loading native support, an api documentation, plugin manager, etc. but that's for later, we want to discuss the plan.

the initial stack to do this (although it still is) was doing the core and api with rust and embed quickjs, so the plugin files could be evaluated using our own "javascript api" and with that offers to you a very solid and minimalist text editor with the necessary extensibility available.

why to use rust? its the low-level lang with the most cross-platform gui libraries, i think its enough reason to use it.

why not embed lua with mlua? because quickjs is way more powerful and we can integrate with the javascript ecosystem very well, at some point i would like to think.

lets see, i was the one who experimented with the code, so i want to disclose some points. i was requested to just do a demo connecting a gui with quickjs. im going to abstract every method and trouble, so you can share your thoughts about them.

GUI Libraries/Frameworks

Candidate	Features	Summary
Floem	Reactivity, Performance, Flexbox & Grid Layout, Global Themes and Localization	I like its reactivity with Signals and Dependencies, it's lightweight and not so father-linked (Lapce) and designed to make code editors.
GPUI	Entity System, Application Mode, Contexts, Elements and GPU Accelerated	It's more declarative on the code written, but so linked to its father (Zed) that bring us a lot of features that maybe we wouldn't use at all. Its entity system is interesting.
Iced	Cross-platform GUI library inspired by Elm. Just a GUI library, like Iced.	I didn't test it. But its name doesn't bring me confidence.
Tauri	Frontend with whatever that compiles to HTML, CSS and JS and the Backend is done in Rust	It's way easier, but it's literally a browser, that brings up to us a few advantages like DOM and it's way more maintainable. But it's a browser though

All these libraries have their own pros and cons, but in definitively we have to make a choice. A great one, in fact.

Like said on GPUI2 and extensions and I quote:

As you can't use rust to script, you will need to embed something like mlua or rquickjs with bindings to GPUI2 (really hard with the current trait/closure based api.). or embed wasmtime with bindings which is even harder as you need to go full "C FFI" mode for this (even harder to do it in a safe way).

And the most important:

gtk is C based, which allows everyone to bind to it easily. this is why we have multiple rust crates binding to gtk.

We will need to create bindings to one of these libraries, the one we choose will be the full-time library to the entire project. In this position, we have to look very carefully what we are going to use, and how it's designed, because we have to know the architecture very well.

And here I am, thinking about studying one of these libraries or create one from scratch, some bindings to gtk or qt, wrappers (build a library over GTK), we have a lot of options and we have to agreed on just one.

I think create bindings is the most reasonable idea. Think about it, JavaScript context directly manipulate the core channel.

I had another idea when it just begun, that it was, yea, evaluate code, and the return answer will be made with some builders so the answer we would receive the API will parser it and send it to the core. It's like a traditional API connection, yea, you send your post and the API, if the body is well made, will do whatever you stipulated. But it's a workaround, not a fully feature.

Anyways, create a new library from the ground with the goal we want will take years and a lot of knowledge on GUI architecture, low-level drivers and controllers of video, cross-platform domain and a lot of things more.

Organization

Important

The next areas of this project must be covered to be fully operational

• User Interface (UI)
• Application Programmable Interface (API)
• Bridge (Concurrency between channels, contexts and API, MPSC)
• Documentation
• Research
• Typings

What do you guys think?

[shikr]

The main idea is to follow the concept of Vim and NeoVim by providing an API for a scripting language, but overcoming the limitations of a terminal-based interface. Due to its capabilities, the idea is to use GPUI as the user interface framework. Of the options we analyzed, GPUI best suits our dynamic approach of describing the UI through an API.

JavaScript

JavaScript is our primary choice for editor scripting, thanks to rquickjs. Its ecosystem makes it an excellent option for this scenario. For now, we want to keep things lightweight, so we don't plan to implement direct support for Node.js, Deno, or any other runtimes. We can integrate some dependencies through bundlers if they don't require those runtimes directly. JavaScript's strength lies in TypeScript, so we definitely plan to integrate type definitions for the editor's API.