{"id":13338333,"url":"https://github.com/romgrk/xedel","last_synced_at":"2025-08-22T03:13:19.896Z","repository":{"id":145089544,"uuid":"247380020","full_name":"romgrk/xedel","owner":"romgrk","description":"Keyboard-centric modal code editor, built with nodejs and GTK","archived":false,"fork":false,"pushed_at":"2023-08-03T06:18:29.000Z","size":9947,"stargazers_count":26,"open_issues_count":3,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-07-19T21:04:52.829Z","etag":null,"topics":["code-editor","editor","gtk","text-editor","tree-sitter","vim"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/romgrk.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-03-15T01:16:08.000Z","updated_at":"2024-03-29T21:29:21.000Z","dependencies_parsed_at":null,"dependency_job_id":"56c4ab86-c7f5-48e9-ba20-3562c7542498","html_url":"https://github.com/romgrk/xedel","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/romgrk/xedel","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/romgrk%2Fxedel","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/romgrk%2Fxedel/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/romgrk%2Fxedel/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/romgrk%2Fxedel/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/romgrk","download_url":"https://codeload.github.com/romgrk/xedel/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/romgrk%2Fxedel/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":271578520,"owners_count":24784052,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-22T02:00:08.480Z","response_time":65,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["code-editor","editor","gtk","text-editor","tree-sitter","vim"],"created_at":"2024-07-29T19:16:17.888Z","updated_at":"2025-08-22T03:13:19.847Z","avatar_url":"https://github.com/romgrk.png","language":"JavaScript","readme":"# xedel\n\nThe goal of xedel is to be a modern text editor, that would be a spiritual GUI successor to neovim.\nI should note that this is currently very hypothetical, the core part of the editor is mostly\nworking but there is still a lot of work to do to get it to a competitive point.\n\n### Goals\n - Keyboard-centric, inspired from vim, kakoune, spacemacs\n - GUI, using native technologies (not electron)\n - Batteries-included, as in VSCode-equivalent\n - Extendable, using a decent scripting language\n\n\u003cp align=\"center\"\u003e\n  \u003cimg\n    src=\"./static/demo.png\"\n    style=\"width: 500px; height: auto\"\n  /\u003e\n\u003c/p\u003e\n\n### Current technological choices\n - Node.js\n - GTK+ via node-gtk\n - tree-sitter via node-tree-sitter\n - Atom core\n\nWhile both Gtk+ and tree-sitter are usable from Rust, which could be an interesting language choice, I've chosen to\nstart with javascript because Javascript offers a faster feedback loop. Besides, critical parts of the editor can be\nimplemented in C/C++ or Rust with native modules.\n\nUsing node.js also provides a non-blocking model by default, being based on an event-loop at its\ncore. It also makes it easy to create a plugin system where authors can use Javascript, which is\nthe closest thing we have to a programming *lingua franca* (and I hate python a lot).\n\nFinally, to save time, I've decided to use as a base the now deprecated Atom editor.\n\n### Features\n\n - [x] Editor: rendering\n - [x] Editor: marks \u0026 decorations\n - [x] Editor: multi-cursor\n - [x] Editor: API\n - [x] Syntax (tree-sitter) (in progress)\n - [x] Core: keyboard-mapping system (in progress)\n - [x] Plugin system\n - [ ] Autocomplete \u0026 LSP\n - [ ] UI (side panels, grid view, tabs)\n - [ ] Fuzzy-finder\n - [ ] File searching/replacing\n - [ ] Language Server Protocol\n - [ ] Debug Adapter Protocol\n\n### Current thoughts\n\n#### The good parts\n\nI got stuff working much more easily than I thought. Replacing the DOM with Gtk was quite pleasant. Re-using Atom also\nmeans we got a lot of features for free, such as the package system, the editor component, the modal editing, syntax\nhighlighting.\n\n#### The bad parts\n\nI'm not sure if it will cause any problems, but `node-gtk` is my toy project. It's not bad, but it has received much\nless love than `gjs`.\n\nThe editor component scrolling feels slow because it's not performant enough. Ideally the core components such as that\none would be written in a native language, but I really just did a 1-1 replacement of the DOM implementation, so it uses\na tiling system that doesn't work really well. This isn't a permanent blocker though, it can be optimized or replaced by\nnative code where/when appropriate.\n\nRe-using Atom code means we get javascript (meh) code and coffeescript (even more meh) code. Ideally we should migrate\neverything to typescript.\n\n### Why did X fail.../Why not...\n\n#### onivim\n\nVery talented developer, but the lack of resources combined with the technological choices made this project unlikely\nto succeed. Trying to develop a UI framework from scratch for a language with low adoption is a big task. The choice\nto preserve vim as the underlying engine also meant that the project was preserving vim's limitations, such as\nthe impossible multi-cursors or the terrible plugin language.\n\n#### lapce\n\nSimilar to the above, trying to use an experimental \u0026 still WIP UI framework means the editor doesn't have a polished\nlook. It also diverts resources from implementing the core editor logic, which is modal editing.\n\n#### xi\n\nVery cool in theory, but in practice the model doesn't work. It has the same limitations as neovim GUIs: keypress\nlatency is higher than it needs to, and the required IPC between the core \u0026 the frontend makes it hard to have a good\nexecution/implementation of the features. A code editor isn't just an abstract backend model; it's a very tangible\ninterface that users need to intuitively understand very deeply. Loose coupling is a good principle in general, but in\nthis particular case it doesn't work.\n\n#### atom\n\nEven early in the vscode vs atom war, it was very clear that vscode was going to win (and I say this as an early atom\nfanboy). They got a lot of stuff right (this project is based on atom!), but they left too many details to external\nplugins. Why was it necessary to install `autocomplete-plus`? The code editor should have the best possible autocomplete\nimplementation to start with. A strong core \u0026 an unified vision is necessary. Plugins should be there for edge cases.\n\n#### vscode\n\nI love vscode so much, if I could I would be using it. They have a great execution, great vision, they understand\nprecisely what developers need. The only missing detail is that they haven't made modal editing a central tennet of the\neditor. And they have decided that all plugins must run in separated processes, which although good in theory, means\nthat plugins with high latency requirements (aka vim mode, which runs on each keypress) have an unacceptable feel.\n\n#### gnome-builder\n\nAlso a very talented developper, fantastic editor with a fantastic look. The main issue is that it's written in C with\nGnome conventions, which means it's not very well documented and it's hard to extend. I know they have GJS plugins\ncoming up soon, but I'm not sure how easy it will be to work with. Also the vim mode sucks. Also they re-use (or extend?)\nthe GtkSourceView component, which although good, is not great. And a code editor's editor component is one of its\nmake-or-break features. I've been shamelessly copying their theme/style though.\n\n### License\n\nMIT\n\nThe editing code (in `src/editor`) has been mostly extracted from\n[Atom](https://github.com/atom/atom), also licensed under MIT.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fromgrk%2Fxedel","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fromgrk%2Fxedel","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fromgrk%2Fxedel/lists"}