An experimental next-generation Electron-based text editor

Related tags

Text editors xray

Attention: GitHub has decided not to move forward with any aspect of this project. We'll archive the repository in case anybody finds value here, but we don't expect to actively work on this in the foreseeable future. Thanks to everyone for their interest and support.


Build Status

Xray is an experimental Electron-based text editor informed by what we've learned in the four years since the launch of Atom. In the short term, this project is a testbed for rapidly iterating on several radical ideas without risking the stability of Atom. The longer term future of the code in this repository will become clearer after a few months of progress. For now, our primary goal is to iterate rapidly and learn as much as possible.

Q3 2018 Focus

We're currently focused on a sub-project of Xray called Memo, which will serve as the foundation of Xray but also be available as a standalone tool. Memo is an operation-based version control system that tracks changes at the level of individual keystrokes and synchronizes branches in real time.


Foundational priorities

Our goal is to build a cross-platform text editor that is designed from the beginning around the following foundational priorities:


Xray makes it as easy to code together as it is to code alone.

We design features for collaborative use from the beginning. Editors and other relevant UI elements are designed to be occupied by multiple users. Interactions with the file system and other resources such as subprocesses are abstracted to work over network connections.

High performance

Xray feels lightweight and responsive.

We design our features to be responsive from the beginning. We reliably provide visual feedback within the latency windows suggested by the RAIL performance model. For all interactions, we shoot for the following targets on the hardware of our median user:

Duration Action
8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement.
50ms Coarse-grained interactions such as opening a file or initiating a search. If we can't complete the action within this window, we should show a progress bar.
150ms Opening an application window.

We are careful to maximize throughput of batch operations such as project-wide search. Memory consumption is kept within a low constant factor of the size of the project and open buffer set, but we trade memory for speed and extensibility so long as memory requirements are reasonable.


Xray gives developers control over their own tools.

We expose convenient and powerful APIs to enable users to add non-trivial functionality to the application. We balance the power of our APIs with the ability to ensure the responsiveness, stability, and security of the application as a whole. We avoid leaking implementation details and use versioning where possible to enable a sustained rapid development without destabilizing the package ecosystem.

Web compatibility

Editing on GitHub feels like editing in Xray.

We want to provide a full-featured editor experience that can be used from within a browser. This will ultimately help us provide a more unified experience between and Xray and give us a stronger base of stakeholders in the core editing technology.


Martin Fowler defines software architecture as those decisions which are both important and hard to change. Since these decisions are hard to change, we need to be sure that our foundational priorities are well-served by these decisions.


The UI is built with web technology

Web tech adds a lot of overhead, which detracts from our top priority of high-performance. However, web standards are also the best approach that we know of to deliver a cross-platform, extensible user interface. Atom proved that developers want to add non-trivial UI elements to their editor, and we still see web technologies as the most viable way to offer them that ability.

The fundamental question is whether we can gain the web's benefits for extensibility while still meeting our desired performance goals. Our hypothesis is that it's possible–with the right architecture.

Core application logic is written in Rust

While the UI will be web-based, the core of the application is implemented in a server process written in Rust. We place as much logic as possible in a library crate located in /xray_core, then expose this logic as a server when running Xray on the desktop (/xray_server) and a web-assembly library running on a worker thread when running Xray in the browser (/xray_wasm). We communicate between the UI and the back end process via JSON RPC.

All of the core application code other than the view logic should be written in Rust. This will ensure that it has a minimal footprint to load and execute, and Rust's robust type system will help us maintain it more efficiently than dynamically typed code. A language that is fundamentally designed for multi-threading will also make it easier to exploit parallelism whenever the need arises, whereas JavaScript's single-threaded nature makes parallelism awkward and challenging.

Fundamentally, we want to spend our time writing in a language that is fast by default. It's true that it's possible to write slow Rust, and also possible to write fast JavaScript. It's also true that it's much harder to write slow Rust than it is to write slow JavaScript. By spending fewer resources on the implementation of the platform itself, we'll make more resources available to run package code.

I/O will be centralized in the server

The server will serialize buffer loads and saves on a per-path basis, and maintains a persistent database of CRDT operations for each file. As edits are performed in windows, they will be streamed to the host process to be stored and echoed out to any other windows with the same open buffer. This will enable unsaved changes to always be incrementally preserved in case of a crash or power failure and preserves the history associated with a file indefinitely.

Early on, we should design the application process to be capable of connecting to multiple workspace servers to facilitate real-time collaboration or editing files on a remote server by running a headless host process. To support these use cases, all code paths that touch the file system or spawn subprocesses will occur in the server process. The UI will not make use of the I/O facilities provided by Electron, and instead interact with the server via RPC.

Packages will run in a JavaScript VM in the server process

A misbehaving package should not be able to impact the responsiveness of the application. The best way to guarantee this while preserving ease of development is to activate packages on their own threads. We can run a worker thread per package or run packages in their own contexts across a pool of threads.

Packages can run code on the render thread by specifying versioned components in their package.json.

"components": {
  "TodoList": "./components/todo-list.js"

If a package called my-todos had the above entry in its package.json, it could request that the workspace attach that component by referring to myTodos.TodoList when adding an item. During package installation on the desktop, we can automatically update the V8 snapshot of the UI to include the components of every installed package. Components will only be dynamically loaded from the provided paths in development mode.

Custom views will only have access to the DOM and an asynchronous channel to communicate with the package's back end running on the server. APIs for interacting with the core application state and the underlying operating system will only be available within the server process, discouraging package authors from putting too much logic into their views. We'll use a combination of asynchronous channels and CRDTs to present convenient APIs to package authors within worker threads.

Text is stored in a copy-on-write CRDT

To fully exploit Rust's unique advantage of parallelism, we need to store text in a concurrency-friendly way. We use a variant of RGA called RGASplit, which is described in this research paper.

CRDT diagram

In RGA split, the document is stored as a sequence of insertion fragments. In the example above, the document starts as just a single insertion containing hello world. We then introduce , there and ! as additional insertions, splitting the original insertion into two fragments. To delete the ld at the end of world in the third step, we create another fragment containing just the ld and mark it as deleted with a tombstone.

Structuring the document in this way has a number of advantages.

  • Real-time collaboration works out of the box
  • Concurrent edits: Any thread can read or write its own replica of the document without diverging in the presence of concurrent edits.
  • Integrated non-linear history: To undo any group of operations, we increment an undo counter associated with any insertions and deletions that controls their visibility. This means we only need to store operation ids in the history rather than operations themselves, and we can undo any operation at any time rather than adhering to historical order.
  • Stable logical positions: Instead of tracking the location of markers on every edit, we can refer to stable positions that are guaranteed to be valid for any future buffer state. For example, we can mark the positions of all search results in a background thread and continue to interpret them in a foreground thread if edits are performed in the meantime.

Our use of a CRDT is similar to the Xi editor, but the approach we're exploring is somewhat different. Our current understanding is that in Xi, the buffer is stored in a rope data structure, then a secondary layer is used to incorporate edits. In Xray, the fundamental storage structure of all text is itself a CRDT. It's similar to Xi's rope in that it uses a copy-on-write B-tree to index all inserted fragments, but it does not require any secondary system for incorporating edits.

Derived state will be computed asynchronously

We should avoid implementing synchronous APIs that depend on open-ended computations of derived state. For example, when soft wrapping is enabled in Atom, we synchronously update a display index that maps display coordinates to buffer coordinates, which can block the UI.

In Xray, we want to avoid making these kinds of promises in our API. For example, we will allow the display index to be accessed synchronously after a buffer edit, but only provide an interpolated version of its state that can be produced in logarithmic time. This means it will be spatially consistent with the underlying buffer, but may contain lines that have not yet been soft-wrapped.

We can expose an asynchronous API that allows a package author to wait until the display layer is up to date with a specific version of the buffer. In the user interface, we can display a progress bar for any derived state updates that exceed 50ms, which may occur when the user pastes multiple megabytes of text into the editor.

React will be used for presentation

By using React, we completely eliminate the view framework as a concern that we need to deal with and give package authors access to a tool they're likely to be familiar with. We also raise the level of abstraction above basic DOM APIs. The risk of using React is of course that it is not standardized and could have breaking API changes. To mitigate this risk, we will require packages to declare which version of React they depend on. We will attempt using this version information to provide shims to older versions of React when we upgrade the bundled version. When it's not possible to shim breaking changes, we'll use the version information to present a warning.

Styling will be specified in JS

CSS is a widely-known and well-supported tool for styling user interfaces, which is why we embraced it in Atom. Unfortunately, the performance and maintainability of CSS degrade as the number of selectors increases. CSS also lacks good tools for exposing a versioned theming API and applying programmatic logic such as altering colors. Finally, the browser does not expose APIs for being notified when computed styles change, making it difficult to use CSS as a source of truth for complex components. For a theming system that performs well and scales, we need more direct control. We plan to use a CSS-in-JS approach that automatically generates atomic selectors so as to keep our total number of selectors minimal.

Text is rendered via WebGL

In Atom, the vast majority of computation of any given frame is spent manipulating the DOM, recalculating styles, and performing layout. To achieve good text rendering performance, it is critical that we bypass this overhead and take direct control over rendering. Like Alacritty and Xi, we plan to employ OpenGL to position quads that are mapped to glyph bitmaps in a texture atlas.

There isn't always a 1:1 relationship between code units inside a JavaScript string and glyphs on screen. Characters (code points) can be expressed as two 16-bit units, but this situation is simple to detect by examining the numeric ranges of the code units. In other cases, the correspondence between code units and glyphs is less straightforward to determine. If the current font and/or locale depends on ligatures or contextual alternates to render correctly, determining the correspondence between code points and glyphs requires support for complex text shaping that references metadata embedded in the font. Bi-directional text complicates the situation further.

For now, our plan is to detect the presence of characters that may require such complex text shaping and fall back to rendering with HTML on the specific lines that require these features. This will enable us to support scripts such as Arabic and Devanagari. For fonts like FiraCode, which include ligatures for common character sequences used in programming, we'll need a different approach. One idea would be to perform a limited subset of text-shaping that just handles ligatures, so as to keep performance high. Another approach that would only work on the desktop would be to use the platform text-shaping and rasterization APIs in this environment.

Bypassing the DOM means that we'll need to implement styling and text layout ourselves. That is a high price to pay, but we think it will be worth it to bypass the performance overhead imposed by the DOM.

Development process


At this phase, this code is focused on learning. Whatever code we write should be production-quality, but we don't need to support everything at this phase. We can defer features that don't contribute substantially to learning.

Documentation-driven development

Before coding, we ask ourselves whether the code we're writing can be motivated by something that's written in the guide. The right approach here will always be a judgment call, but let's err on the side of transparency and see what happens.

Disciplined monorepo

All code related to Xray should live in this repository, but intra-repository dependencies should be expressed in a disciplined way to ensure that a one-line docs change doesn't require us to rebuild the world. Builds should be finger-printed on a per-component basis and we should aim to keep components granular.


Interested in helping out? Welcome! Check out the CONTRIBUTING guide to get started.

  • Unable to build on macOS

    Unable to build on macOS

    When I execute npm install then npm start I get the following error:

    Compiling xray_node v0.1.0 (file:///Users/jrothberg/Repositories/xray/xray_node) error[E0463]: can't find crate for napi --> src/ | 1 | extern crate napi; | ^^^^^^^^^^^^^^^^^^ can't find crate

    error: aborting due to previous error

    If you want more information on this error, try using "rustc --explain E0463" error: Could not compile xray_node.

    To learn more, run the command again with --verbose. child_process.js:614 throw err; ^

    Error: Command failed: cargo rustc --release -- -Clink-args="-undefined dynamic_lookup -export_dynamic" at checkExecSyncError (child_process.js:574:11) at Object.execSync (child_process.js:611:13) at Object. (/Users/jrothberg/Repositories/xray/napi/scripts/napi.js:31:8) at Module._compile (module.js:660:30) at Object.Module._extensions..js (module.js:671:10) at Module.load (module.js:573:32) at tryModuleLoad (module.js:513:12) at Function.Module._load (module.js:505:3) at Function.Module.runMain (module.js:701:10) at startup (bootstrap_node.js:190:16)

    I am building with Rust 1.24.1 (I have also tried building with nightly and get the same result).

    opened by JonnyWalker81 25
  • new logo/icon proposal

    new logo/icon proposal

    Good day Sir I am a graphic designer and i am interested in designing a logo for your good project. I will be doing it as a gift for free. I just need your permission first before i begin my design. Hoping for your positive feedback. Thanks

    opened by mansya 16
  • Linux Build Compatibility

    Linux Build Compatibility

    I changed the napi build script to work on Linux platforms in addition to MacOS. I am using the built-in Node.js os module to detect the user's system type in order to copy the correct dynamic library file. I also included <string.h> as I was having issues with memcpy not working on Ubuntu 16.04 LTS.

    This address comments in #15

    opened by apcragg 16
  • App launches without UI

    App launches without UI

    After app launched, I see window with menu and blank area: screenshot from 2018-03-08 15-37-23

    From console of xray electron app:

    Uncaught Error: Cannot find module 'xray'
        at Module._resolveFilename (module.js:543:15)
        at Function.Module._resolveFilename ($HOME/path/xray/xray_electron/node_modules/electron/dist/resources/electron.asar/common/reset-search-paths.js:35:12)
        at Function.Module._load (module.js:473:25)
        at Module.require (module.js:586:17)
        at require (internal/module.js:11:18)
        at Object.<anonymous> ($HOME/path/xray/xray_electron/lib/render_process/main.js:5:14)
        at Object.<anonymous> ($HOME/path/xray/xray_electron/lib/render_process/main.js:37:3)
        at Module._compile (module.js:642:30)
        at Object.Module._extensions..js (module.js:653:10)
        at Module.load (module.js:561:32)
    $ npm install
    > [email protected] postinstall $HOME/path/xray/xray_electron/node_modules/electron
    > node install.js
    npm WARN [email protected] No repository field.
    added 1 package from 1 contributor in 9.842s
    $ rustup -V
    rustup 1.11.0 (e751ff9f8 2018-02-13)
    $ node -v
    $ uname -a
    Linux catsys 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    opened by twerq 15
  • Windows 10 build error xray_electron\node_modules\napi\Cargo.toml can't be found

    Windows 10 build error xray_electron\node_modules\napi\Cargo.toml can't be found

    Following the instructions in the contribution guide:

    1. Install Node 8.9.3
    2. Install Rust
    3. git clone this repository
    4. cd into xray_electron
    5. run npm install

    npm install exits saying that I:\xray\xray\xray_electron\node_modules\napi\Cargo.toml does not exist. I've checked inside that folder and it does not exist.

    No rush for me to get anything up and running just mostly curious 🙂


    I:\xray\xray\xray_electron>node --version
    I:\xray\xray\xray_electron>rustc --version
    rustc 1.24.1 (d3ae9a9e0 2018-02-27)
    Full output
    I:\xray\xray\xray_electron>npm install
    > [email protected] install I:\xray\xray\xray_electron\node_modules\xray
    > npm run build-release
    > [email protected] build-release I:\xray\xray\xray_electron\node_modules\xray
    > napi build --release
    error: failed to load source for a dependency on `napi`
    Caused by:
      Unable to update file:///I:/xray/xray/xray_electron/node_modules/napi
    Caused by:
      failed to read `I:\xray\xray\xray_electron\node_modules\napi\Cargo.toml`
    Caused by:
      The system cannot find the path specified. (os error 3)
        throw err;
    Error: Command failed: cargo rustc --release -- -Clink-args="-undefined dynamic_lookup -export_dynamic"
        at checkExecSyncError (child_process.js:601:13)
        at Object.execSync (child_process.js:641:13)
        at Object.<anonymous> (I:\xray\xray\napi\scripts\napi.js:31:8)
        at Module._compile (module.js:635:30)
        at Object.Module._extensions..js (module.js:646:10)
        at Module.load (module.js:554:32)
        at tryModuleLoad (module.js:497:12)
        at Function.Module._load (module.js:489:3)
        at Function.Module.runMain (module.js:676:10)
        at startup (bootstrap_node.js:187:16)
    npm ERR! code ELIFECYCLE
    npm ERR! errno 1
    npm ERR! [email protected] build-release: `napi build --release`
    npm ERR! Exit status 1
    npm ERR!
    npm ERR! Failed at the [email protected] build-release script.
    npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
    npm ERR! A complete log of this run can be found in:
    npm ERR!     C:\Users\bene\AppData\Roaming\npm-cache\_logs\2018-03-06T22_08_16_150Z-debug.log
    npm WARN [email protected] No repository field.
    npm ERR! code ELIFECYCLE
    npm ERR! errno 1
    npm ERR! [email protected] install: `npm run build-release`
    npm ERR! Exit status 1
    npm ERR!
    npm ERR! Failed at the [email protected] install script.
    npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
    npm ERR! A complete log of this run can be found in:
    npm ERR!     C:\Users\bene\AppData\Roaming\npm-cache\_logs\2018-03-06T22_08_16_320Z-debug.log
    opened by Ben3eeE 13
  • Contributing


    Exciting project - thanks for sharing at such an early stage.

    Are there areas you'd like PRs? Are there good first issues? Is there CI (and if not would you take a PR for one)?

    opened by max-sixty 13
  • Initial Travis Config

    Initial Travis Config

    Initial config for Ubuntu on Travis. At the moment this is fairly bare bones as it only builds xray and does not run tests. See log. There were some issues with clang and rustup that required some fiddling and the commit history reflects that.


    opened by chgibb 11
  • Consider using Svelte instead of React

    Consider using Svelte instead of React

    Svelte has some advantages over react:

    • It's compiled, self-contained, & has no runtime library [smaller transpiled payloads]. This also makes it's components compatible with any other component library & will not cause conflicts.
    • It follows standards (html, css, javascript, & web components)
    • It's significantly faster & uses less memory. It's also produces isomorphic javascript out of the box.
    • It's a better development experience. Superior & more cohesive Idioms followed by the community.
    • It's api is stable yet there's plenty of development. See the sapper project ( & compare it to next.js

    Here's the repl:

    If this seems interesting, I encourage you to have a conversation with Rich Harris on gittr ( He introduced Tree-Shaking with his RollupJS package. He also wrote bublejs (, which will yield faster & memory-efficient JS compared to babel.

    opened by btakita 10
  • Ci test script

    Ci test script

    This script differs(via git) the files changed from the origin's default branch and executes tests only on changed packages. Since a GIF is worth more than a thousand words, here you have a demonstration:


    The code is a little messy and not well commented, but I think it's okay for a first quick sketch. Tell me if you can find a simpler way to build these dependencies trees, I sincerely couldn't.

    Also would you mind taking a look at this comment here and give me any suggestions?

    opened by lucat1 9
  • Screenshot of the actual editor please?

    Screenshot of the actual editor please?


    It would be nice if the README contained what is currently built here. Just like... One at least to see how it looks like. People are visual beings for the greater part. :)

    opened by Skarlso 8
  • Improve compatibility with different Node.js/N-API versions

    Improve compatibility with different Node.js/N-API versions

    Noticed that the file was rustfmt'ed, but there was no mention or invocation of rustfmt in the code-base. This PR is an attempt to document that approach and automatically run rustfmt on the generated bindings code as part of the build process.

    This is by no means a finished product. I'm curious if y'all want to continue rustfmt'ing the bindings, and if so is this the approach to take for doing that? Or should the formatting step be removed and unformatted bindings committed to the repo?

    opened by dirk 8
  • Question: Can we potentially use x-ray on a thin-client while the x-ray core server could be installed remotely? (Hackable Cloud IDE?)

    Question: Can we potentially use x-ray on a thin-client while the x-ray core server could be installed remotely? (Hackable Cloud IDE?)

    Firstly, I think this project looks really promising, kudos to the team! I was wondering if we could potentially use x-ray on a thin-client while the x-ray core server could be installed remotely (x-ray packages, extensions, language servers etc... all installed remotely)? Source files and dependencies would also reside in the server. However, the UX on the client feels as if everything is running locally. This would obviously require an integrated terminal which is also fed from the one available on the machine x-ray core server is installed at. Sort of like a cloud IDE except completely hackable and configurable? I got a sense from the architecture diagram that maybe you guys already have something like this in mind (beside realtime collaboration, I mean like a "Single player mode" would be nice). I think this would eliminate so many issues teams face. Like having to stick to certain hardware for their employees, configurations and setting each one up then fixing stability issues every now and then. It would be nice to simply give everyone a cloud instance running x-ray and any decent laptop where they could use the x-ray client. This would also make learning Vim or emacs for working over ssh unnecessary and we can finally have a nice remote development experience? It will also be significantly cheaper and much easier to keep upto date. Thoughts?

    opened by Kasahs 1
  • panic at index out of bounds

    panic at index out of bounds

    How to reproduce?

    build & run RUST_BACKTRACE=1 XRAY_SRC_PATH=. script/xray ., open xray_ui/lib/app.js with the editor, then panic occurs.

    thread 'main' panicked at 'index out of bounds: the len is 29 but the index is 29', libcore/slice/
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
       1: std::sys_common::backtrace::print
       2: std::panicking::default_hook::{{closure}}
       3: std::panicking::default_hook
       4: std::panicking::rust_panic_with_hook
       5: std::panicking::continue_panic_fmt
       6: rust_begin_unwind
       7: core::panicking::panic_fmt
       8: core::panicking::panic_bounds_check
       9: <xray_core::buffer_view::BufferView as xray_core::window::View>::render
      10: <xray_core::window::WindowUpdateStream as futures::stream::Stream>::poll
      11: <futures::stream::map::Map<S, F> as futures::stream::Stream>::poll
      12: <futures::sink::send_all::SendAll<T, U> as futures::future::Future>::poll
      13: <futures::future::chain::Chain<A, B, C>>::poll
      14: futures::task_impl::std::set
      15: <futures::task_impl::Spawn<T>>::poll_future_notify
      16: tokio::executor::current_thread::CurrentRunner::set_spawn
      17: <tokio::executor::current_thread::scheduler::Scheduler<U>>::tick
      18: <scoped_tls::ScopedKey<T>>::set
      19: <std::thread::local::LocalKey<T>>::with
      20: <std::thread::local::LocalKey<T>>::with
      21: <std::thread::local::LocalKey<T>>::with
      22: tokio_core::reactor::Core::poll
      23: xray_server::main
      24: std::rt::lang_start::{{closure}}
      25: std::panicking::try::do_call
      26: __rust_maybe_catch_panic
      27: std::rt::lang_start_internal
      28: main
    opened by flappyBug 1
  • Xray panics when scrolling too fast while editing

    Xray panics when scrolling too fast while editing

    Building on macOS Mojave - 10.14 on a MacBook Pro 2016 13" with Touchbar.

    $ XRAY_SRC_PATH=. RUST_BACKTRACE=1 script/xray .
    $ thread 'main' panicked at 'index out of bounds: the len is 30 but the index is 30', /Users/travis/build/rust-lang/rust/src/libcore/slice/
    note: Run with `RUST_BACKTRACE=1` for a backtrace.
    $ node --version
    $ v8.9.3
    $ rustc --version
    $ rustc 1.30.0-nightly (33b923fd4 2018-08-18)
    $ nvm list
    $          v8.9.3
    $ ->     v10.12.0
    $          system
    $ default -> node (-> v10.12.0)
    $ node -> stable (-> v10.12.0) (default)
    $ stable -> 10.12 (-> v10.12.0) (default)
    $ iojs -> N/A (default)
    $ lts/* -> lts/carbon (-> N/A)
    $ lts/argon -> v4.9.1 (-> N/A)
    $ lts/boron -> v6.14.4 (-> N/A)
    $ lts/carbon -> v8.12.0 (-> N/A)
    opened by jasikpark 7
  • [Memo] Change notifications?

    [Memo] Change notifications?

    Maybe I'm missing something obvious, but is there an API (or plans for an API) to be notified of changes to the work tree. In particular if the work tree gets modified due to remote ops being applied how do I learn when that happens and what has changed.

    opened by jessegrosjean 2
Atom Archive
Projects that are no longer maintained by GitHub.
Atom Archive
A terminal-based text editor written in Rust

Iota Iota is a terminal-based text-editor written in Rust. Here's what it looks like right now, editing itself. Motivation Iota was born out of my fru

Greg Chapple 1.6k Jan 8, 2023
ReVi is a cross-platform terminal based Vim inspired text editor.

ReVi Table Of Contents: About Usage Install Clone && Installing Development Q&A KeyBindings Roadmap Changelog About ReVi is a cross-platform terminal

null 31 Sep 21, 2022
TIF is a terminal_image_format. (theres no TIF editor, so i made TIF images through a hex editor lol)

Colors these are the colors you can use when displaying images on the terminal BYTES: 5A = BLUE 5B = BLACK 5C = RED 5D = GREEN 5E = PURPLE 5F = WHITE

buzz 5 Dec 23, 2022
A fast and small Rust library to make Electron apps more secure.

electron-hardener A Rust library and command line tool to harden Electron binaries against runtime behavior modifications. This provides a way to hard

1Password 364 Dec 23, 2022
A text editor in ≤1024 lines of code, written in Rust

Kibi: A text editor in ≤1024 lines of code, written in Rust A configurable text editor with UTF-8 support, incremental search, syntax highlighting, li

Ilaï Deutel 881 Dec 29, 2022
Aspiring vim-like text editor

Rim Rim is an aspiring Vim-like text editor written in Rust. Current state Rim is in an early prototype stage. This means that you can load, edit and

Mathias Hällman 557 Jan 2, 2023
An independent Rust text editor that runs in your terminal!

Ox editor Ox is a code editor that runs in your terminal. About The Project Ox is a code editor. It was written in Rust using ANSI escape sequences. I

null 2.9k Jan 2, 2023
Web base text editor written in rust

Ultron Ultron is a web based monospace text-editor with syntax highlighting, completely written in rust. I wrote this code editor for my very specific

Jovansonlee Cesar 59 Aug 8, 2022
Ginkgo is a text editor built entirely in Rust

Ginkgo is a text editor built entirely in Rust. It supports cursor movements, CTRL commands, select vim commands, insert vs. normal modes, and more. Ginkgo is based on my text editor JED, which itself was based on the popular online editor Kilo.

James Asbury 12 Oct 15, 2022
Archeum - a minimalist text editor

Archeum About The Project Archeum is a minimalist text editor that is really usefull if you've been in the vim psychosis for to long. Reject plugins,

null 4 Jul 1, 2022
(An attempt to write) a modal text editor

kaka (An attempt to write) a modal text editor. NOTE: The project is very young and certainly not ready for use. Current project goals keymap and mode

Marcin Pajkowski 4 Aug 15, 2022
Rust-based traffic editor for RMF

Traffic Editor III Welcome to Traffic Editor III. install stuff Unfortunately we need a newer Rust than what comes with Ubuntu 20.04. First make sure

null 2 Oct 20, 2022
A simple terminal-based editor made in rust!

ELuna Editor The terminal-based editor for europa lang. Goals Be as minimal as possible, but retain conveniences found in other editors. Do not add fe

Junhao 3 May 25, 2022
Subtext is a text-based, block-oriented hypertext format.

Subtext: markup for note-taking Subtext is a text-based, block-oriented hypertext format. It is designed with note-taking in mind. It has a simple, pe

Gordon Brander 223 Dec 15, 2022
An opinionated modal editor to simplify code editing from the terminal

(I'm currently refactoring the platform layer. So we have to first finish this cleanup before we're able to continue adding features) An opinionated m

Matheus Lessa Rodrigues 284 Jan 5, 2023
A modern editor with a backend written in Rust.

Xi Editor (pronounced "Zigh") A modern editor with a backend written in Rust. Maintenance status: The xi-editor project is not currently under active

null 19.7k Jan 5, 2023
A save editor for Mass Effect Trilogy

Trilogy Save Editor A save editor for Mass Effect Trilogy A bit late but just in time ! This software is similar to Gibbed's save editors (and forks)

Karlitos 118 Dec 25, 2022
Rustpad is an efficient and minimal collaborative code editor, self-hosted, no database required

Rustpad is an efficient and minimal open-source collaborative text editor based on the operational transformation algorithm

Eric Zhang 2.5k Dec 31, 2022
A package manager for the Lite-XL code editor

Lite-XL Package Manager (lpm) (Under Development) lpm is an attempt to create a package manager for the Lite-XL code editor. It's primary goal is to p

Debarchito Nath 12 Dec 11, 2022