Monochrome terminal setup for an E-ink monitor (2022)
bsandro.tech
bsandro.tech
Looks like a perfect display for outdoors, very long trips (battery time?), long writing sessions, etc. I'd love to build a "DIY laptop" like that, but at these prices I'm likely better off with a Macbook Air...
I'm already experimenting with using a heavily desaturated/monochromatic color scheme for coding (it's working surprisingly well - e.g. using bold text to differentiate keywords).
I think most CLI apps are abusing color for little gain. Reading the output of some programs feels like wading through a room filled with fruit salad - the JS ecosystem is particularly bad in this regard. I'm using red in my prompt to indicate a root shell and/or an SSH session, and I think that's as far as it should go.
Inevitably, they get run in CI, and then my web browser window / text editor is full of control characters and other bullshit.
If your stdout is not a terminal, and you're sending out escape codes, you're just spewing useless garbage.
That is just not the case, as the previous poster already said.
"prog | grep foo" outputs to the terminal. From prog's perspective it doesn't, but it does. Do you want escape sequences in there? Sometimes you do, sometimes you don't.
Even "prog | less" outputs to the terminal, indirectly, and less can interpret escape sequences.
"Always unconditionally output escape sequences" is wrong, but "always unconditionally disable them with isatty()" is also wrong. What a reasonable default is depends on the type of application and how it's likely to be used.
No default (other than calling isatty) is reasonable, because you don't know (and you don't want to know) what your output is being piped through.
If you really must, add a flag to force enable/disable escape codes.
> "prog | grep foo" outputs to the terminal. From prog's perspective it doesn't, but it does. Do you want escape sequences in there? Sometimes you do, sometimes you don't.
What happens if "prog" outputs an escape sequence (e.g. set color) on one line, and outputs another one (reset color) a few lines down? grep might match one or the other, or none, or something in the middle. grep might want to output its own escape sequences (like it can do for highlighting a match). "prog" can't know what grep could possibly want to output, without inspecting grep's entire argument line, and effectively re-implementing all of grep - bug-for-bug, compensating for differences in GNU, BSD, BusyBox, etc.
There is no sane way to handle every edge case here, and you will get frustrated every time you hit one.
> Even "prog | less" outputs to the terminal, indirectly, and less can interpret escape sequences.
$ echo hello | less > hello.txt
$ cat hello.txt
hello
Exactly because you don't know it makes sense to optimize for the common case.
> What happens if "prog" outputs an escape sequence (e.g. set color) on one line, and outputs another one (reset color) a few lines down?
Don't do that then. Or do use isatty() is your escape sequences are complex like that.
> It can, but should it?
Yes, because it's useful.
What is "common"? What if I want grep to match text that has an escape code in the middle of it - do I have to first inspect the generated escape codes? What if I'm redirecting the output to a file, and opening that file in a program that doesn't process escape codes?
Every sane tool I know of calls isatty. It's only those that don't that cause problems.
> Yes, because it's useful.
Please read the article I've linked about "cat -v". There's no doubt someone (perhaps many people) find it useful; that doesn't mean it isn't a bad idea and/or a poor design.
If you do that, add a command line switch to forcefully enable or disable the control.
I mean, termcap/terminfo was invented just for this. It's a solved problem.
Is there any indication that will happen? I’ve been impressed by the occasional E-ink hack too but displays larger than e-reader sizes seem to not drop in price.
This project caught my eye 2 or 3 years ago but it looks like the display used hasn’t come down in price at all:
I feel the same way. I still want colour on the CLI, but tend to configure my most commonly used tools and par back the colour almost completely, then use it very selectively for things that I want to stand out.
I think the only case it really makes sense to have colour salad is syntax highlighting, there's a lot of different types of things going on and the colour really does help to differentiate more easily.
I also find sticking to 16 ANSI colours really helps to manage the chaos and enforces consistency.
It's technically dual screen, e-ink and OLED that rotate, but even better, you can choose the best one for the job.
I'm certainly excited to see reviews for that Lenovo laptop when it comes out.
The one they linked to does not have OLED or rotate, even though they claimed otherwise. Clearly they meant to link to the new version.
https://github.com/rollcat/dotfiles/blob/0d44759/.emacs.d/th...
There's also a dark variant, and a "base" variant to convince Emacs not to touch colors when running in a terminal. There's also support for matching the system theme in Emacs & Terminal.app on macOS: https://github.com/rollcat/dotfiles/commit/b3e49ad
> There seems to be a lot of form-over-function going on over there, I
> wonder what characteristic of JavaScript developers...
It's a shame the technology hasn't reached economies of scale yet despite the Kindle, it has so much potential for signage and other mostly static applications.
You cant always whip enough factory workers in vietnam to transform resources mined in Myanmar for 250$, and sometimes you have to pay a bit more. I suppose most of the money goes to R&D to finally find a way to get high refresh rates, anyway.
I think nobody's sleeping on high margin for these things, collecting massive mountain of cash to buy sport cars. It's a difficult concept to bring up, this doubly stable state display that require electricity only on change. It's really worth paying for it to evolve.
That would also be a very interesting post-apocalyptic computer monitor ( for the low consumption of it only, maybe it has drawback like being brittle, heavy, not durable ? )
Neat.
More seriously, I think in post apocalyptic world “computer skills” would be utter garbage.
Ham radio maybe. Or being able to bring Wikipedia / encyclopedic knowledge of some specific subject like plant granfting technic, maps, and so on.
But I envision “camping & fishing & gardening” as far far more important.
Collapse OS is neat, but what would be a real use case?
( it’s a real question, I want to be convince otherwise )
It's all explained in the FAQ / motivation document:
http://collapseos.org/why.html
> Q: Is computing worth saving?
> Some people doubt that computers will stay relevant after a civilizational collapse. I mostly agree. The drastic simplification of our society will mean that we have a lot less information to manage. We'll be a lot more busy with more pressing activities than processing data.
> However, the goal of Collapse OS is not to save computing, but electronics. Managing electricity will stay immensely useful.
> Q: Aren't there more important things to do than an operating system?
> Yes! Yes! Yes! A metric ton of projects are more important than Collapse OS with regards to civilizational collapse. This doesn't make Collapse OS useless.
> [...]
> However, when you look at it from a communal perspective, Collapse OS starts to make sense. Once a particular community already took care of its immediate survival and is looking at going from "surviving" to "thriving", if it has Collapse OS and someone who can make sense of it, then that community will have a great asset.
Managing electricity. Ok. Hm. I’ve seen shoddy grid. And … yeah. They all use some type of contrôler.
Ok. Anyway thanks for pointing out the obvious page I missed.
No idea if that would imply this is needed as an adult though. And that is assuming I don't misremember in the first place.
Eink refresh is slow-ish, but only because if say scrolling a bunch of pixels, you need to invalidate and redraw the whole screen.
The advantage of terminals is that you can easily keep a matrix of squares, and by looking at the flux of information, you can pick the opportunistic times for refreshes.
With characters, there should be more recouping. (a B and a P overlap except in the bottom right)
With line editing, the problem should be limited to the line
All these small gains should add up to provide an excellent terminal experience.
Although perhaps it automatically does a comparison between current and previous frame to do its own dirty-pixel optimization.
This
> Although perhaps it automatically does a comparison between current and previous frame to do its own dirty-pixel optimization.
Some do, like the Boox regal mode, but it stills feels a bit slow and leaves some ghosting. Baking that into the terminal would limit the comparison to the invalidated area, which in a terminal would be a smaller square that the full screen frame, so I'd expect some speed gains.
I wonder if maintaining a buffer in software that counts for each pixel how many times it has been dirty, combined with, say, the kind of quadtree one would normally use for hit detection, would let one do "local" refreshes and make this a generic solution. It sounds like the kind of thing that someone already must have thought of (let's hope it's not one of the software patents holding e-ink back)
Which patents are these?
Right now, we seem to be in a vi revival period, and we've new hardware (eink) that bring back old problems (latency + screen update speed) vi was made to tackle, along with new ones (2 refresh modes, one of which can leave ghosting) that should be easy to fix.
So I can't help but notice how vim on eink just needs this one little extra thing to give a great experience on modern hardware
Digression - This is of course less of an issue if you use the terminal in a style where you just move one page at a time, but you're just restricting yourself to a subset of possible use cases. I scroll in the terminal with the mouse wheel for skimming.
To solve motion blur, you either need strobing (along with a refresh rate above the flicker fusion threshold: ~80Hz), which E-ink will never have, or a high refresh rate, something like 240Hz. Still, if E-ink could even reach 50Hz it would be a massive improvement over LCD for use cases that don't require color.
E-ink does solve the pixel density problem and viewing angle problem (reducing eye strain and bad posture). Overall I'm still using high end CRTs for all use cases, and will switch to OLED once they get proper strobed offerings without all kind of bugs (and I'm still not sure if OLED fixes viewing angle shift. IPS-type LCD certainly didn't).
The self-luminescence problem that E-ink solves is also nice, but I'm not sure it matters much (it used to be my biggest pet peeve); you can just take an OLED which supports nice low luminescence levels at or below 120cd/m^2 (unlike most LCDs) and roughly match your room lights to it.
Low framerate and input lag will also cause eye strain and bad posture, respectively.
That last image: https://bsandro.tech/epaper/dasung_photo_3.jpg
gives me nostalgia of the late 90s when some of my friends had those new experimental LCDs, the same aspect ratio, the same slow pixel response, interesting frame, and brands I've never heard of.
Buried the key sentence. That's pretty wild. Isn't any CRT now 20+ years old and consequently a small fraction of its design brightness? Or do you have old stock and you open a fresh box every 5 years?
I know there wasn't a lot of old stock of CRTs are the end of the CRT era because when I needed a warranty fix on a Sony 21" Trinitron FD in the final year of its 5-year warranty they said they could not repair or replace it and they send me a 24" model instead. When that one broke they could not fix or replace and paid me out for the warranty.
I was surprised at how good a fake game like Genshin Impact looks compared to even the highest contrast VA LCDs. The difference is night and day. But then again the game spent all their budget on graphics and marketing.
Arrrgh, maybe if I win the lottery one day I can create an e-ink coding and documentation setup. Would have to be Linux because newer Macs don't support more than 2 external displays unless you get the most powerful CPU.
LCD but persistent (if nothing changes very low power) and with colors (limited is ok, pebble time had 64) and higher frame-rates.
Contrast was suffering on those displays compared to the pebble 2 ones, but maybe there is something better now?
You can get them in 8" tablet form as found in the TCL Nxtpaper S8 and in 32" monitor form as found in the Sun Vision Display.
If you went with B/W LCDs you can improve this by ~3x and might achieve 5:1 contrast with good antireflective surfaces. That's what you see in car LCDs.
I can't imagine using one as a general monitor.
Maybe if you live in a sunny place they have some merit? I can't remember the last time I couldn't read a regular screen living in England.