bazed-editor / bazed Goto Github PK

Currently we're creating a .swp file in the files directory temporarily whilst saving. This should probably happen somewhere else, in a standardized place (i.e. /tmp/, or, probably preferrably, the cache directory). To identify that sort of dir in a cross-plattform manner, I propose using https://crates.io/crates/dirs

See #1.

The communication with the backend implemented in #60 is very basic. We still need to implement viewport logic:

• Line numbers need to be offset by the first_line value we get from core
• viewport width and height need to be properly sent to the backend
• We should set the required framework for scrolling to work

At the moment we have a Theme object that we pass around to our components. Its properties are then used as inline styles in the DOM elements. This clearly does not scale as the number of config options grows over time.

 <div
    style:position="absolute"
    style:height="{height}px"
    style:top="0"
    style:background={theme.editor_background}
    style:width="{theme.text_offset}px"
    style:left="{gutter_width}px"
  />

I think we could instead have a global styles.css file that is either exposed to the user or generated from its user settings, which would clean up the component code a lot.

Right now, the movement and edit operations aren't tested properly. We should have a solid test suite here.

• basic "insert & delete" api on top of ropey
• reading & saving files

• plugin version negotiation (plugin API changes)
• plugin dependencies (DAG of deps? pain)

We need to do further evaluation if our current choice of tauri + Svelte is feasible, especially w.r.t. the performance and rendering issues we noticed in tauri.

I'd think we want to have a vim-style concept of different registers, maybe a killring of deleted text. However, especially w.r.t. a kill-ring, I'd think that may already be the concern of a vim plugin rather than of core, although I'm not sure.
Having some concept of registers should most likely be part of core, however. The details of this need to be discussed

We should implement word boundary detection and allow movement in terms of these boundaries

The frontend should actually use the backend!

Translate raw key inputs into MVP actions supported by MVP editor core

Edit actions should be grouped into undo-groups in a sensible manner, and redo should be possible.
It may be worth thinking about approaches to have some sort of undo-tree or emacs-style undo, although for an initial POC regular undo/redo will do

input chains are command mappings like gg, dw, etc that are composed of several, chained inputs. Some of these will have timeouts, i.e. mappings in insert mode (kj for escape is a typical example), whereas others are basically leader binds that shouldn't have a timeout. We should check if we can unify those or if they are conceptually different, and then implement both.

The naming for the frontend should be descriptive and consistent with the one used in the backend

Undo history should be preserved across restarts of the editor, similar to how it works in vim. This requires specifying the location of the undo history file, specifying a format for that history, and loading the history from that file when opening a file.

Currently, rekuho does not carets with length > 0 into account, and still displays them as regular carets. These should be taken into account and displayed as selections.

We should set up CI to run the typical checks on PRs, mostly so @buffet doesn't have to pull and run them manually every time :P
Optimally we should set up some caching thing for this, so it doesn't have to build from scratch every time. Maybe reference what https://github.com/unixporn/robbb does for this?

Plugins will need to react to events such as insertion, deletion, cursor movement, etc.
Similarly, things like a jumplist would need to remember cursor position after any jump and/or text insert action.
There are definitely a lot more of those things.
We should discuss a general event-system for these things, allowing us to modularize out any non-core components by having them simply register event-listeners and work in the background. Most, if not all things that rely on this can probably be expressed as plugins!

While the datastructure in BufferRegions is currently already able to represent multiple carets, edits will frequently crash the editor as the carets will result in deltas being applied out of order.

We need to have some way to guarantee that carets are dealt with in order, and that caret regions never overlap. Once that abstraction exists, we need to have tests and actually a BufferOp to add and remove cursors

We should generate type definitions for the RPC messages between the frontend and backend so that they remain consistent with each other.

It should be possible to store selections in BufferMarks, and it should be possible to change selections by moving the cursor whilst a selection is active. We will probably need to distinguish between any region and user-initiated selections again, those details and plans for other uses of regions should be discussed prior to implementation.

This is a problem xi-editor had too (xi-editor/xi-editor#458): Undo is done as part of the CRDT engine, which does not know about cursors.
I see two viable implementation strategies:

• wrap around the CRDT undo API and memorize cursor positions outside (this may need to interact with more of the CRDT for cursor offsets, idk)
• Fork xi-rope
• Don't do this (deliberately not counted towards the viable implementation strategies, as this would be garbage UX)

Additionally, any other marks also need to be aware of undo: Some, if not most, should just be recomputed (i.e. marks for inlay hints, or whatever we may use them for). Others (i.e. the carets of users other than the one that just did the undo) should apply a coordinate transform.

Another very viable idea

Instead of remembering where exactly the cursor was, just use a coordinate transformation to move the carets accordingly, and then (optionally, no reason not to make this configurable) ensure that the caret is moved within the range of text that was affected by the undo / redo action by moving it into that range if required. That way, we can ensure users are always aware of what changed. We'd simply need to ensure that in the simple case (inserting, then undoing) the cursor is where the user would expect it to be, i.e. at the start of the range that had been undone.

We could also just move the viewports to visualize the area that the undo happened in, without actually moving the cursor. That may actually be a preferred UX for many users.

Currently, we're infinitely accumulating undo history events, which bloats both the undo history and our CRDT.
At a given max history length, we should discard older entries. Ever so often we should run garbage collection on the discarded entries.

flake.nix using fenix and naersk.

Regex-based search should be supported at the Buffer level, and should be exposed through an EditOp.
This would most likely also be the first instance of using Marks for things other than carets, so some architecture around how we want to store that state should be discussed - should these be on the view level?

Both for actual cursor-movement, as well as for things like "double-click-on-word", adding a new cursor etc it is required to describe positions in the document on a semantic level, often relative to the current cursor position.
We should design an abstraction that can define things such as "Next start of a word", "next end of a word", "end of line", "next occurrence of /foo/", "previous occurrence of character )", which would then allow us to use it in movement commands as well as any other abstractions (motion-based edit commands such as vim-style diw, cw, dt), etc)

DoD:
A basic protocol for rpc communication between backend and frontend is specified and implemented.
Supported features:

• inserting characters
• deleting characters
• saving file
• moving the cursor

As long as we don't have any other UI, the editor view should really fill the entire webpage.
This also means that we'll need to properly meaure the width and height to send accurate viewport information to the backend (see #67)

Given that we're planning to be on nightly, we should add a rust-toolchain.toml file, decide on some recent version of nightly and then use that.

Core currently ignores MouseInput events. Instead, we should jump the caret to the mouse position, only if there actually is text where the mouse clicked (no snapping in this case)

When moving vertically, cursors should remember their initial column, even when moving to a line shorter than their original column.

Plan how folds will be stored, on which layers they'll have to be considered (i.e. for things like movement, edit actions, etc), and how they'll be communicated to the frontend layer as well as to plugins.

Most likely by using syntect, for now. Treesitter should be kept in mind as a desired feature later.

We should write some integration tests based on the RPC api, that test actual end-to-end interaction with the editor core through RPC.
This should be relatively trivial to achieve, as the frontend shouldn't need to keep much state.

Possibly also run this in tests, although its,... kinda slow, and we rarely actually run cargo doc locally 👀

Original original ETA: about 14th Jan.
Original ETA: 17th Feb.