hoosieree/wim

modal text editor

Wim aims to be a modal text editing control, implemented in a web page, with the ability to interface with persistent storage ...somewhere... so that it can be used as a normal text editor. This is my 2nd iteration on this concept, hence the above logo. The first iteration (now abandoned) was cred.

Motivation

Software in general and developer tools in particular are beyond bloated and I find it ridiculous that a "minimum" developer machine, if you ask in certain places (cough Hacker News cough) needs 16GB of ram and an i5 processor. I can say this with some confidence because I'm still developing (mostly C++ or JavaScript) on my 5-year-old ARM Chromebook.f

But at the same time I feel the shame of using a bloated system. My local dev environment uses:

• Crouton, to give me an
  • Ubuntu Linux command-line environment, which I then use to run
    • emacs 25.x (lol nope, not emacs-24, that's in aptitude and would be too easy) (without x11) kitted out with full
      • Spacemacs, and of course I sync all my local work back to GitHub/GitLab using
    • git's command-line interface.
    • And sometimes I also use gcc.

If you are keeping track of indentation in the above bulleted list, you might notice that I have to go 2 levels deep before anything useful happens.

So the goal of Wim is to pull the text editor all the way up to the top level. I could just use Caret, but for some reason (NIH-syndrome?) I decided I wanted to do it the hard way:

Vanilla JS. No dependencies.

Architecture

Wim is built around a Core which keeps track of the state of the text document you're editing. It also listens to messages from input devices (keyboard, maybe mouse or touch(?)) and posts messages to output devices (canvas, maybe WebGL, native, or networked/x11) when there's something to display. That "something" could be as simple as a blinking cursor, or as complex as updates to the syntax highlighting of the currently-displayed text.

The above is aspirational. Here's what currently exists:

• Parser.js receives raw KeyboardEvent objects and turns them into messages (indicating parsing progress)
• Window.js draws a string to a canvas
• main.js instantiates these modules, pre-populates a string for demo purposes, and attaches event listeners to the browser's window object

One goal with these separate roles is to make different backend/rendering schemes easier to experiment with. Another is to make it easier to swap out the entire "front end" if for example you don't care for Vim-style modes, you can just use a different front-end. I'm not sure how to go about this yet, but I'd like for this modularity to make it easy to write your own functions and just hand them to the Core. Similar in a way to device driver handling in operating systems, my half-formed notion of how this would work is that users could provide pluggable functionality into something like a device descriptor table, and the Core could dynamically select that functionality depending on what front-ends and other plugins are present at runtime. But this is definitely half-baked and more complex than anything else I've attempted in here so far.

Features

Everything below here is a desired (and maybe implemented) feature.

• Input Inspired by Vim and Spacemacs.

  • modal When in Insert mode, Emacs-style commands may be used. Otherwise you can use Vim style commands.

  • other modes -- mostly Spacemacs-inspired

    • shared clipboard between Wim and main system.
    • find-file
    • js-git integration

• Display -- currently renders to canvas. Still not commited to a particular rendering backend. DOM has a lot of already-made toys. On the other hand, canvas is closer to WebGL, which could be interesting.

wim's Issues

test tokenizer

assert that:

• partial valid inputs don't fail
• complete valid inputs succeed, and signal their done-ness to whoever cares
• explicitly quitting and starting over is possible to do on purpose
• invalid inputs automatically quit/reset the tokenizer

transform tokenized input into commands

should be done optimistically; partially formed commands might contain useful information (e.g. incsearch)

interactive feedback as you type commands

Some commands should have UI updates to reflect their progress, and enable discovery, similarly to "onhover tooltips" or "nested menu" UI idioms.

Example: delete around paragraph

• full command: dap
• result: deletes surrounding paragraph, including all trailing newlines (if any)
• earliest opportunity for UI update: d

In Spacemacs, typing d results in the cursor shape changing from a full-height rectangle to a half-height rectangle. Typing a after the d (so the current sequence is da) brings up a drawer showing possible completions.

Example: surround a word with <tags>

• full command: ysetb>
• result: word changed to <b>word</b>
• earliest opportunity for UI: y

Again, Spacemacs shows a half-height cursor after typing y. It also brings up a minibuffer/gutter (1-line-high buffer at the bottom) which appears after typing t and shows a < followed by a full-height cursor. You can see your tag-text as you type, displayed in this gutter. Finally, typing a > ends the interaction resulting in the gutter disappearing and the main buffer updating its text.

An alternative (better?) UI would still show the tag as-you-type, but display the live-updating in the main buffer instead of the gutter.