I've messed around with this a bunch on some 9" hardware and custom waveforms to attempt to drive the display as hard as possible, it's almost certainly not what you want to be using, especially the color ones as they require multiple passes to actually attain the color. For my Color/Black/White panels that's normally rendering all the Black + Color as black, and then pulling the black pigment back as well to expose the Color one (red or yellow).
For the single color ones you can get sub-500ms latency for updating, at the cost of extreme ghosting. You need to do a lot of changes to the way you think about graphics to make this a reality. Think of an IRC program for example, normally every one of them scrolls up text from the bottom but this is completely a worst case solution for e-ink. To make it work you have to fill half the screen with text, then add new lines sequentially at the end and only scroll when you've run out of space. Additions can reasonably be done without a full refresh, scrolling text just causes it to mud out.
This is pretty spot on. I tried something similar a while back and found that the typing latency was on the order of ~120 ms which made it feel mushy and led to a lot of errors.
The need to rethink graphics to handle refreshes should not be underestimated. A lot of UI patterns (almost all animations and transitions) rely on a period refresh rate. In order to make a compelling experience you need to rework a good bit of the UI.
You'd just need to adjust to typing "by feel", without needing that instant feedback from the screen. A typewriter or teletype also has inherently high "latency", so this fits quite well with that whole "e-paper" approach.
Yeah, this is the best workaround. It is still slower and more error prone than typing on a standard LCD screen. Also, the benefit of an eInk reader is that it is easier to look at - not looking at the display sort of defeats the whole purpose.
The one I worked on had a tape drive, paper tape read / punch for CNC machines, and an analog joystick.
It had a very powerful Basic that included a ton of graphics primitives, capable of many of the images shown. There was a demo tape similar to that video.
Storage tube CRT.
Editing text was done a screen at a time, overwrites done right over existing characters.
When it all got a bit messy, just refresh and carry on after it rendered current text to the screen. Sometimes, and this was often true for the files we were creating, multiple columns could be used to get a lot on the screen to work with, depending on widths.
The higher end ones did something like 4k pixels x 3k pixels.
If you wanted hard copy, you sent it to a pen plotter, or took a photo of the screen.
For text I/O, tape or paper tape.
I was 19 at the time. Had a chance to get one and didn't do it. Still regret it.
Now that we have these nice 4k displays, I am tempted to go find or write an emulation.
I think the CPU was a 6800 running at maybe a few Mhz, or maybe just 1Mhz.
The old "xterm" program has "Tektronix mode" as a command line option. One could send the graphics data and get a scaled bitmap output. I used to do it on SGI computers.
It could become feasible with a custom UI. You could have a version of vim or emacs that doesn't even "scroll" your code conventionally, but just gradually rewrites lines starting from the top down (or from the bottom up when scrolling "back"), sort of doing away with a unified viewport - this would at least address the most common operation in a dev environment that currently requires quick full-screen update.
For the single color ones you can get sub-500ms latency for updating, at the cost of extreme ghosting. You need to do a lot of changes to the way you think about graphics to make this a reality. Think of an IRC program for example, normally every one of them scrolls up text from the bottom but this is completely a worst case solution for e-ink. To make it work you have to fill half the screen with text, then add new lines sequentially at the end and only scroll when you've run out of space. Additions can reasonably be done without a full refresh, scrolling text just causes it to mud out.