Console editor ideas

Console editor ideas.md

Single executable which works out-of-the box.

• Extra libraries could add extra features. I/e if no regex library available, then only text is available.
• Space for logs/temp files. If not available/writable, editor is still able to work, with diminished functions.

Plugin-based

• Core functionality is single-file, single-screen editing, with client-server. Almost everything else is plugins.
• Should have good defaults. Not minimal, but can be made minimal. Not an IDE either. Walk the thin line.
• You can replace core plubins with other plugins from the community
• Plugins are github repos + release (username/plugin v1.x) or straight urls (http://website.dev/foo/plugin.v1.tgz)
• Command-line flag for "no plugins" (besides core)
• Some plugins are built-in (inside the single core executable)? But can be overriden by putting files in the right folders.

Client-server

• First instance of editor opens a "server" and then creates a graphical client. All other calls to "open editor" open a client.
• Clients are more or less "dumb" (see below) and send commands to server. Server responds with "update screen" events (and saving files).
• Server is "source of truth". Internally it is similar to nginx - Main thread keeps evertyhing alive, Worker thread(s?) to the actual work. These might need some options but they should work well by default.
• Two clients can edit the same buffer simultaneously. But when they do, the server keeps them in sync (same memory in the server). This might mean storing large files partially or completely on a reserved "swap" zone on the disk.
• Maybe we can make clients be children of the main thread as well. No idea.
• This means that the bare minimum is 3 threads for a text editor. Is this too much? In 2020?
• Command format should be straightforward and uncomplicated. Possibly nothing as sophisticated as json.
• Possibly a direct transcription of what the user would type as "commands". But not always (example: "the console dimensions have changed").
• Minimal server response contains "diffs of text in the current screen".
• Quitting: The client sends the "quit" command to the server. The server has a last opportunity to say "bye" or "hold on (you have unsaved changes)".
• Server commits sepukku when the last client leaves.
• Default (built-in) client is console-based. Other clients can be GUI based.
  • This means that the server needs to tell the consumer orders in GUI-unspecific terms. "Open this dialog" instead of "Draw this bunch of characters representing a dialog".
  • Diffs of text need to also be "display-agnostic".
    • FIXME what happens with syntax highlighting

Copy and paste

• Use system clipboard. If you need more, use temp buffers.
• Internal server-managed "historic" copy-paste register contains the last X things that have been copied or pasted in the editor.
  • What happens if you copy a 10GB file.
  • Selecting is not copying (it does not add anything to the system clipboard).

Modal

• CAPS LOCK compatible because I want to be able to type CONSTANT_NAMES and then not have my editor die
  • Option: Don't use uppercase letters for anything. Or make uppercase and lowercase keys do the same commands.
  • Option: Detect caps-lock status (not always possible, ssh does not carry a "CAPS LOCK" flag)
• Able to open/manipulate big files without chocking
• Modes:
  • Select (commands select parts of the current buffer). Search/find is part of Select.
  • Transform (change the buffer). Insertion (usual text insertion/deletion) is part of Transform.
  • So yeah, Find and Replace are two separate actions. No /fancy/powerful/c regex.
  • Command (open a new file, execute plugin action, my screen size has changed).
  • Batch mode (operating over a file(s) folling a set of commands from the console.

Selection Mode

• Multiple cursors (like Kak). One of them is the "Main" cursor.
  • Each client has its own set of cursors.
  • Can you see other client's cursors in your client? (you should see their edits at least)
• When opening a new file, start on 0,0
  • Batch mode always starts on 0,0
  • On interactive mode
• Current selection clearly visible at all times
• Moving the cursor quite literally means selecting the caracter left, top, up or down (with jhkl or arrows)
• What happens when select the whole 10GB file? (The client doesn't care, but the server needs to do funky stuff).
• Mouse is used to select stuff
  • Gets translated to absolute actions from the top of the file ("Select line 399")
• By default the scrolls "follows" the main cursor (with some chars around it - configurable). User can move the scroll around (with special commands) but scrolls snaps back to cursor if any selection happens.

Transform Mode

• All transformations apply to current selection. Use is always "select and then stransform".
  • Possible editor name: st. Or est.
• One usual way to do things. Usual actions should take few keystrokes. TODO define/research usual actions.
• Undo typically reverts the last transformation.
  • So either each transformation is perfectly reversable, or we need to produce and store its diffs on the server. Problematic with 10 GB diffes.
• Optional: Log which stores all the transformations done to a file.

Batch mode

• Called from the console, but you can also batch a bunch of select/transform orders in interactive mode.

• Execute immediately (fast) or step-by step (debug).

  • Should be able to execute a bunch of transforms one after the other by keeping a key pressed.

• Batch mode can operate over several buffers.

• It still involves creating a client which sends a bunch of commands to the server, and then dies.

• Inter