Mizuki is a collaborating coding tool.

The idea is that code is much more than text. There are multiple ways of looking at code.

Also there are multiple ways of coding:

Archtecture building, debugging, AI generation, pair programming.

All should be possible.

So to handle this I want to create a multi service biosphere of tools that work together to

create an illusion of one application, but which holds the possibility for a developer

to connect to a code base, let multiple AI explore it, have linters and code analysis tools

all work on the code together.

Services

ProjectExplorer

This is a python microservice that has the concept of a project.

A project is simple, it is a collection of folders. Ideally it is one folder,

but subprojects might be a thing.

The project explorer starts up, and waits for its initial message.

{“msg”:”explore-project”,

“path”:somepath}

The project explorers task is to monitor the project for all other services.

Other services might subscribe to the project explorer, and ask to get information

about certain files or files in certain folders. The project explorer can also deliver

a map of files.

{“msg”:”fetch-project-file-map”}

{“subscribe-file-type”:”.cpp”, “reply_to”:me}

The project explorer walks the directories and checks which files that are there.

After this it sets up monitoring, so that the explorer know when a file is added,

updated or deleted.

{“msg”:”project-file-change”,

“path”:some_path,

“action”:”update”}

The subscribers get notification about files that it is interested in.

FileManipulator

This will be a C++ microservice. Its job is to run manipulation tasks on file contents.

It switches files in and out of memory, depending on requests. It is the only service that

touches the files. It has concepts of cursors. That is points in the files where the file

can change. And it has the concept of textual windows. That is a number of lines a reader

can see. A textual window can also have a width, to prevent slow updates of files with extremely long lines.

When a file window is open, it will receive updates if the text changes there. The window also

have an anchor that decides what symbol is the one the window is fixed on.

{“msg”:”open-file-window”,

“path”:some_path,

“height”:80,

“width”:200,

“anchor:[25,25],

“subscriber”:me}

{“msg”:”delete-chars”,

“cursor”:510230,

“char-count”:10}

The service doesn’t immediately save the changes, but still updates watchers.

DesktopClient

Consist of a

DisplayEngine

This part is made in C++ It can create multiple windows which all contain OpenGL contexts.

It contains multiple layers of graphics that are displayed on top of eachother.

Other clients can send requests to the display engine to update their parts of the display.

The two first layers will be the TextLayer, which enables us to display text, and

the text overlay, which allows a client to place graphics al

KeyboardCommander

This is a python extendable part of the client. It receives keystrokes, which is translated

to a command. A command is a set of messages that is sent to other services. A command can

also have parameters that is passed on to the messages.

The keyboard commander might have many key-contextes to use, so that “F” might mean type

case f, but it might also mean “forward” in another key-context.

ContextEngine

This is the core of most clients. It holds the context of the actions, making it possible to

work coherently. For example if you want to type something in a file. The context already know

that you have selected to work with it, so the “active-file” is known,

the position of the “cursor” is known. then the keyboard

commander receives a keystroke, issuing a command “insert-key” the key is passed as a argument

in the command, while it refers to context data for the rest. The context, receives the

message, fills out the content requests

Planning

Concepts

The File Window

The File Window is a fundamental concept in Mizuki that represents a view into a portion of a file’s content. It acts as a viewport that can be positioned anywhere within a file and provides a controlled way to display and interact with file content.

Location and Dimensions

A File Window has specific dimensions defined by:

  • Height: The number of lines visible in the window (e.g., 80 lines)

  • Width: The maximum number of characters per line to display (e.g., 200 characters)

The window’s position within the file is controlled by:

  • Window Position: The [row, col] coordinates within the file that represent the top-left corner of what’s currently visible

  • This determines which part of the file content is actually displayed

The Anchor Point

The anchor point is a crucial concept that provides stability when the file content changes:

  • It’s defined as [row, col] coordinates within the file

  • The anchor represents a “fixed point” that the window tries to keep visible

  • When text is inserted or deleted elsewhere in the file, the window adjusts its position to keep the anchor point in view

  • This prevents the user’s view from jumping around unexpectedly during collaborative editing

  • The anchor point is usually the cursor in a standard text window.

Example Scenario

Consider a file with 1000 lines:

  • Window dimensions: height=25, width=80

  • Window position: [100, 0] (showing lines 100-124)

  • Anchor point: [110, 15] (line 110, character 15)

If another user inserts 5 lines at line 50:

  • The anchor point is now at [115, 15] (shifted down by 5 lines)

  • The window position automatically adjusts to [105, 0] to keep the anchor visible

  • The user’s view remains stable relative to the content they were focused on

This system allows multiple users to work on the same file simultaneously while maintaining coherent, stable views for each participant.