A modern editor with a backend written in Rust.

Overview

Xi Editor
Xi Editor

(pronounced "Zigh")

A modern editor with a backend written in Rust.

Maintenance status: The xi-editor project is not currently under active development. Although we will happily accept bug fixes, no new features are currently planned. We would like to revisit writing a text editor again at some point in the future, but for the time being our attention is elsewhere. — The Editors

Note: This repo contains only the editor core, which is not usable on its own. For editors based on it, check out the list in Frontends.

The xi-editor project is an attempt to build a high quality text editor, using modern software engineering techniques. It is initially built for macOS, using Cocoa for the user interface. There are also frontends for other operating systems available from third-party developers.

Goals include:

  • Incredibly high performance. All editing operations should commit and paint in under 16ms. The editor should never make you wait for anything.

  • Beauty. The editor should fit well on a modern desktop, and not look like a throwback from the ’80s or ’90s. Text drawing should be done with the best technology available (Core Text on Mac, DirectWrite on Windows, etc.), and support Unicode fully.

  • Reliability. Crashing, hanging, or losing work should never happen.

  • Developer friendliness. It should be easy to customize xi editor, whether by adding plug-ins or hacking on the core.

Learn more with the creator of Xi, Raph Levien, in this Recurse Center Localhost talk.

Screenshot:

xi-mac screenshot

Getting started

This repository is the core only. You'll also need a front-end, from the list below.

Building the core

Xi-editor targets 'recent stable Rust'. We recommend installing via rustup. The current minimum supported version is 1.40.

To build the xi-editor core from the root directory of this repo:

> cd rust
> cargo build

Frontends

Here are some front-ends in various stages of development:

  • xi-mac, the official macOS front-end.

  • xi-gtk, a GTK+ front-end.

  • xi-term, a text UI.

  • xi-electron, a cross-platform front-end based on web-technologies.

  • Tau, a GTK+ front-end written in Rust. Forked from https://github.com/bvinc/gxi, which was abandoned.

  • xi-win, an experimental Windows front-end written in Rust.

  • kod, a terminal frontend written in Golang.

  • xi-qt, a Qt front-end.

  • vixi, a Vim like front-end in Rust.

The following are currently inactive, based on earlier versions of the front-end protocol, but perhaps could be revitalized:

There are notes (I wouldn’t call it documentation at this point) on the protocol at frontend.md. If you're working on a front-end, feel free to send a PR to add it to the above list.

Design decisions

Here are some of the design decisions, and motivation why they should contribute to the above goals:

  • Separation into front-end and back-end modules. The front-end is responsible for presenting the user interface and drawing a screen full of text. The back-end (also known as “core”) holds the file buffers and is responsible for all potentially expensive editing operations.

  • Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa.

  • Rust. The back-end needs to be extremely performant. In particular, it should use little more memory than the buffers being edited. That level of performance is possible in C++, but Rust offers a much more reliable, and in many ways, higher level programming platform.

  • A persistent rope data structure. Persistent ropes are efficient even for very large files. In addition, they present a simple interface to their clients - conceptually, they're a sequence of characters just like a string, and the client need not be aware of any internal structure.

  • Asynchronous operations. The editor should never, ever block and prevent the user from getting their work done. For example, autosave will spawn a thread with a snapshot of the current editor buffer (the persistent rope data structure is copy-on-write so this operation is nearly free), which can then proceed to write out to disk at its leisure, while the buffer is still fully editable.

  • Plug-ins over scripting. Most text editors have an associated scripting language for extending functionality. However, these languages are usually both more arcane and less powerful than “real” languages. The xi editor will communicate with plugins through pipes, letting them be written in any language, and making it easier to integrate with other systems such as version control, deeper static analyzers of code, etc.

  • JSON. The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern languages, and there are plenty of the libraries available for the other ones.

Current status

This is still a project in its early stages. The Mac build has basic editing functionality (it was used to write this README), but looks very spare and is still missing essentials such as auto-indent. At the moment, it’s expected that its main community will be developers interested in hacking on a text editor.

Authors

The xi-editor project was started by Raph Levien but has since received contributions from a number of other people. See the AUTHORS file for details.

License

This project is licensed under the Apache 2 license.

Contributions

We gladly accept contributions via GitHub pull requests. Please see CONTRIBUTING.md for more details.

If you are interested in contributing but not sure where to start, there is an active Zulip channel at #xi-editor on https://xi.zulipchat.com. There is also a #xi channel on irc.mozilla.org. Finally, there is a subreddit at /r/xi_editor.

Comments
  • Syntax highlighting via LPeg

    Syntax highlighting via LPeg

    One possible suggestion for the method of syntax highlighting is via LPeg. This is used by the Vis editor, which borrowed it from the Scintillua project as described in this README.

    You can see all the languages supported in the Vis lexers directory.

    If you wanted to embed this in xicore there seem to be multiple Rust Lua bindings, such as these two:

    https://github.com/kballard/rust-lua https://github.com/jcmoyer/rust-lua53

    Or maybe LPeg could be use from a Lua-based external tool using whatever future RPC mechanism you intend for "plugins". But this may make sense to be done inside the core.

    opened by leavengood 44
  • Update notify 5.0

    Update notify 5.0

    Closes #1158

    This PR will change based on comments but gives a good idea of what's coming.

    • [x] I have responded to reviews and made changes where appropriate.
    • [x] I have tested the code with cargo test --all / ./rust/run_all_checks.
    • [x] I have updated comments / documentation related to the changes I made.
    • [x] I have rebased my PR branch onto xi-editor/master.
    opened by sjoshid 23
  • Managing and persisting user preferences

    Managing and persisting user preferences

    Preferences and persistence

    This is a brief sketch of how I've been thinking about the preferences / config system, how the various levels of preferences fit together, and some thoughts on how we might manage client settings.

    Config levels

    There are a number of configuration 'tiers', which override one another in a set order:

    1. Defaults: the base level settings that ship with xi; these are included in assets/defaults.toml. These are always loaded first, and provide sane general-case defaults.
    2. Platform specific: these are platform-specific overrides that ship with xi, in (for instance) assets/windows.toml. These override the default settings on a particular platform.
    3. General user preferences (optional): these are persistent user preferences, which override defaults. When a user modifies preferences, they are modifying these.
    4. Syntax specific (system): these are syntax-specific settings which are bundled with xi. These override even user preferences; if a user's preferences declare a desire for tabs over spaces, the yaml syntax (assets/yaml.toml) preferences (which want spaces over tabs) will be preferred.
    5. Syntax specific (user) (optional): The user can optionally set their own syntax-specific settings, which will override all previous settings, and persist between application launches.
    6. Session overrides (system): finally, on a per-buffer basis xi-core may override some settings, for instance if we have a preference for spaces over tabs but open a file that is indented with tabs, we might override the user preference for that given file.
    7. Session overrides (user): through the RPC protocol, the client may override a given setting for the current buffer. These overrides are not persistent; they would be used to manually set a line-ending or encoding on a per-document, per-session basis.

    Of these, only the third and fifth are user-defined and persistent; they're the focus of this discussion.

    Getting and persisting user preferences

    Two of these tiers (general and syntax-specific) require us to persist user preferences. There are a few possible approaches to this:

    1. File based, core managed: the classic unix text editor approach: all preferences are saved in preference files; files are watched and preferences reloaded on change. This is the easiest approach, and has pedigree, but it can confuse and frustrate newer users, and doesn't really respect platform conventions.

    2. RPC based, client managed The opposite pole: the client manages all user settings, sending them to core at launch and then keeping core up to date about changes. This would involve RPC calls to the effect of:

      {
          "method": "set_preferences",
          "params": {
              "user": {
                  "font_size" 14
              }
              "python": {
                  "translate_tabs_to_spaces": true,
                  "tab_size": 2
              }
          }
      }
      

    This approach gives the client total control over how preferences are managed, but also requires each client to implement a settings system.

    1. File based, shared A compromise; preferences are file based, but instead of editing those files directly, the user has some platform idiomatic preferences interface, and the client writes the user's preferences to disk, where changes are picked up by core. This approach is flexible (only clients that want to do this have to) but it's also fairly inelegant.

    2. File backed, RPC modified Another compromise; core stores all preferences, and sends them to the client at launch. The client can present an idiomatic UI to the user, and preference changes are sent to core via a set_preference RPC call. Core persists the changes. This lets core handle file modification in a way that preserves document structure (https://github.com/joelself/tomllib), and is also opt-in for the client (or the user): if either wants to just edit files directly, that's no problem. It is also reasonably cross platform (a user can export their settings and have it just work), but is a bit cumbersome.

    3. Multimodal: Allow the client to select from 1. and 2., above. Configuration is file based by default, but the client can opt into managing preferences, (with a launch flag or some RPC call) in which case core defers. This adds complexity in exchange for improved client flexibility.

    Conclusion

    This is intended to sketch out some of my thoughts around persistence specifically. I would like to try and come up with some solution that accommodates various possible use cases, and I don't know what all of those are. If anything is missing or unclear, please help me clarify.

    discussion 
    opened by cmyr 23
  • Implement workspaces

    Implement workspaces

    This is a medium-sized project for somebody, which will require a design document and discussion. I am happy to mentor somebody who is interested in taking this on.

    Workspaces group a collection of open documents, and enable a variety of features:

    • auto-save and session restoration: workspaces will passively track state, including window properties (probably an opaque blob of data updated as needed by the frontend, that might include things like window position, size, and other state) and will also store unsaved changes, the undo stack, etc; a client should be able to pass a 'workspace id' to core on startup, and have be able to easily reopen all previously open documents.

    • directory tracking: a workspace should consist of one or more directories, and there should be api for adding and removing directories; these will be used for things like 'quick open'

    • (eventually) workspaces should have their own config domain, so that config options can be set on a per-workspace basis

    • (eventually) workspaces will provide a new hook into the config and plugin systems, for things like language server support

    • multiple workspaces should be possible, and there should be an initial implicit workspace

    For an initial version of this, I think it's reasonable to focus on the persistence bits.

    enhancement on hold needs design 
    opened by cmyr 22
  • Add Command Recording

    Add Command Recording

    As per the discussion in https://github.com/xi-editor/xi-editor/issues/806, there are some basic actions missing from xi that are comprised of already existing commands. Instead of implementing these manually, it'd be really convenient if we could just compose existing commands.

    The implementation was a bit different than the one originally suggested by @cmyr; instead of having and RPC that holds events, we have an RPC that toggles a recording state and an RPC that plays the recorded state. I'm open to switching to the other model if it's preferred-- I was just getting a feel for the project with this first pass.

    TODOs

    • [x] Record commands (duh)
    • [x] Add tests
    • [x] Undo / Redo entire replay in a single command
    • [x] Limit to only edit commands?
    • [ ] ~Handle requests alongside notifications?~
    • [x] Don't record Undo / Redos
    • [x] Clear recording
    • [x] Allow for multiple recordings?
    opened by mbStavola 19
  • allow opening from command line as root

    allow opening from command line as root

    Wanted to edit my /etc/sudoers file with visudo.

    I use xi as my $EDITOR for everything.

    Unfortunately, sudo xi doesn't open a file as root, it'd be nice if it just worked.

    enhancement discussion 
    opened by nhooyr 18
  • Add chrome tracing support

    Add chrome tracing support

    In xi-mac#103 we added support for tracing using the chrome trace format.

    This should be rolled out to xi-core, and eventually plugins. I would defer on the plugin work initially, and implement this in xi-core.

    So: we should be generating traces on an ongoing basis, and then in response to some new dump_trace RPC we should be either writing them to a directory passed as an argument, or else returning them as a response. (It's unclear to me which of these is better; it comes down to whether the tools for viewing traces want a single file or not, probably)

    Some questions:

    • Do we want to have some global trace repository, or do we want to use some thread-local structure and synchronize only as needed?
    • Do we want to include traces in xi-rpc? If yes, this gets a bit more complicated; we'd need to add some mechanism for collecting these.
    • Do we write to a file or return a response?
    enhancement performance 
    opened by cmyr 18
  • To anyone who installed Rust via homebrew

    To anyone who installed Rust via homebrew

    Apparently installing Rust via Homebrew installs the 1.3 version, which causes xcodebuild to return the following error.

    Compiling xi-rope v0.0.0 (file:///Users/xyz/dev-lab/xi-editor/rust/rope)
       Compiling serde v0.7.0
       Compiling winapi-build v0.1.1
       Compiling num-integer v0.1.32
    rope/src/tree.rs:445:1: 451:2 error: the associated type `<N as tree::NodeInfo>::L` may not live long enough [E0309]
                         ...
    

    The solution was to install Rust from the official website obviously.

    It's definitely my mistake, but I never really installed/used Rust before ...

    (I thought about submitting a PR to explicitly specify a minimum Rust version ... but again I don't know enough about Rust to know which version would be required)

    opened by nsbraksa 17
  • update to notify 5.0

    update to notify 5.0

    A vague tracking issue: a major update to the notify crate is in the works, and we should investigate what will be involved in migrating to use it. I haven't looked into this at all, but there are some docs here.

    enhancement help wanted 
    opened by cmyr 16
  • WIP: Added logging support with Fern

    WIP: Added logging support with Fern

    First step towards #408

    Work in progress.

    Tasks

    • [x] : add logging library
    • [ ] : convert existing calls to stderr directly via eprintln macro to log calls.
    • [ ] : log all RPC calls.

    @cmyr Please affirm if I am heading in right direction. Thanks 😄

    opened by betterclever 15
  • Selection granularity for drag gestures

    Selection granularity for drag gestures

    Like most text editors, Xi lets you select a word by double-clicking or a line by triple-clicking. However, if you then drag the cursor, it will extend the selection one character at a time. This PR assigns the appropriate granularity to drag gestures, depending on whether they started with a single, double, or triple click.

    opened by ryanbloom 14
  • Bump commonmarker from 0.23.4 to 0.23.6 in /docs

    Bump commonmarker from 0.23.4 to 0.23.6 in /docs

    Bumps commonmarker from 0.23.4 to 0.23.6.

    Release notes

    Sourced from commonmarker's releases.

    v0.23.6

    What's Changed

    This release includes two updates from the upstream cmark-gfm library, namely:

    Changelog

    Sourced from commonmarker's changelog.

    Changelog

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies ruby 
    opened by dependabot[bot] 0
  • Bump thread_local from 1.0.1 to 1.1.4 in /rust

    Bump thread_local from 1.0.1 to 1.1.4 in /rust

    Bumps thread_local from 1.0.1 to 1.1.4.

    Commits
    • 4a54e57 Bump version to 1.1.4
    • ebf8b45 Merge pull request #34 from ibraheemdev/patch-1
    • 3d69afa Fix memory ordering in RawIter::next
    • c7d8dcd Bump version to 1.1.3
    • 5e8bbf2 Merge pull request #30 from Marwes/fix_drop
    • a44b836 fix: Drop the value in the ThreadLocal on drop
    • 322cf34 Bump version to 1.1.2
    • dca4007 Merge pull request #29 from Kestrer/raw-iter
    • 33ad405 Add #[inline] to non-generic functions
    • 810c043 Implement iterator logic in RawIter
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies rust 
    opened by dependabot[bot] 0
  • Bump smallvec from 0.6.13 to 0.6.14 in /rust

    Bump smallvec from 0.6.13 to 0.6.14 in /rust

    Bumps smallvec from 0.6.13 to 0.6.14.

    Release notes

    Sourced from smallvec's releases.

    v0.6.14

    • Fix a possible buffer overflow in insert_many (#252, #254).
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies rust 
    opened by dependabot[bot] 0
  • Bump crossbeam-channel from 0.3.9 to 0.4.4 in /rust

    Bump crossbeam-channel from 0.3.9 to 0.4.4 in /rust

    Bumps crossbeam-channel from 0.3.9 to 0.4.4.

    Changelog

    Sourced from crossbeam-channel's changelog.

    Version 0.8.1

    • Support targets that do not have atomic CAS on stable Rust (#698)

    Version 0.8.0

    • Bump the minimum supported Rust version to 1.36.
    • Bump crossbeam-channel to 0.5.
    • Bump crossbeam-deque to 0.8.
    • Bump crossbeam-epoch to 0.9.
    • Bump crossbeam-queue to 0.3.
    • Bump crossbeam-utils to 0.8.

    Version 0.7.3

    • Fix breakage with nightly feature due to rust-lang/rust#65214.
    • Bump crossbeam-channel to 0.4.
    • Bump crossbeam-epoch to 0.8.
    • Bump crossbeam-queue to 0.2.
    • Bump crossbeam-utils to 0.7.

    Version 0.7.2

    • Bump crossbeam-channel to 0.3.9.
    • Bump crossbeam-epoch to 0.7.2.
    • Bump crossbeam-utils to 0.6.6.

    Version 0.7.1

    • Bump crossbeam-utils to 0.6.5.

    Version 0.7.0

    • Remove ArcCell, MsQueue, and TreiberStack.
    • Change the interface of ShardedLock to match RwLock.
    • Add SegQueue::len().
    • Rename SegQueue::try_pop() to SegQueue::pop().
    • Change the return type of SegQueue::pop() to Result.
    • Introduce ArrayQueue.
    • Update dependencies.

    Version 0.6.0

    • Update dependencies.

    Version 0.5.0

    • Update crossbeam-channel to 0.3.
    • Update crossbeam-utils to 0.6.
    • Add AtomicCell, SharedLock, and WaitGroup.

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies rust 
    opened by dependabot[bot] 0
  • Add Lapce

    Add Lapce

    Not affiliated with Lapce, the description should probably be approved by https://github.com/dzhou121

    Summary

    Add Lapce as one of the frontends to the README.

    Review Checklist

    • [ ] I have responded to reviews and made changes where appropriate.
    opened by ricklamers 1
  • `xi-unicode` allows linebreaks in emoji sequences

    `xi-unicode` allows linebreaks in emoji sequences

    The xi_unicode::LineBreakIterator allows breaks inside of a lot of the longer emoji sequences. For example:

    assert_eq!(
        vec![(10, false), (14, false)],
        LineBreakIterator::new("🏳️‍🌈").collect::<Vec<_>>()
    );
    

    Not sure whether this is an actual bug in the code or whether the Unicode data is just outdated. In any case, since this library is used by quite a few projects, it might be worth investigating!

    bug 
    opened by laurmaedje 0
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 4 Jun 21, 2022
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.5k Sep 20, 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 839 Sep 24, 2022
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
Lightning-fast and Powerful Code Editor written in Rust

Lapce Lightning-fast and Powerful Code Editor written in Rust About Lapce is written in pure Rust, with UI in Druid. It's using Xi-Editor's Rope Scien

Lapce 18k Sep 26, 2022
A collision editor for Guilty Gear -Strive-, written in Rust

ggst_collision_editor_rs A collision editor for Guilty Gear -Strive- and other Team Red Arc System Works games, written in Rust. Uses a customized ver

null 4 May 3, 2022
Helix - A kakoune / neovim inspired editor, written in Rust

A kakoune / neovim inspired editor, written in Rust. The editing model is very heavily based on kakoune; during development I found myself agree

null 13.1k Sep 28, 2022
A pathtracer written in rust - runs in the web and includes an editor

Webtracer A pathtracer written in rust - runs in the web and includes an editor Rendering is parallelized and utilizes all cpu cores You can easily ed

Shapur 2 Aug 29, 2022
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.8k Sep 27, 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 1 Nov 26, 2021
My own personal code editor built with Rust + OpenGL

Glyph This is my personal code editor that I am building for fun and to get more familiar with OpenGL. Glyph currently supports Vim keybinds, syntax h

Zack Radisic 72 Sep 26, 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
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 11 Mar 21, 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 271 Sep 24, 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 547 Sep 24, 2022
An experimental next-generation Electron-based text editor

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

Atom Archive 8.6k Sep 22, 2022
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 109 Sep 13, 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.4k Sep 25, 2022
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 30 Aug 25, 2022