Hacker News Reader

Comment by rollcat | Hacker News Reader

This looks wonderful, and I can't wait for these kinds of e-ink displays to get more affordable.

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.

View on HN

The really frustrating thing with this trend is that the colorful terminal apps don't bother checking if their stdout is a pipe.

Inevitably, they get run in CI, and then my web browser window / text editor is full of control characters and other bullshit.

Counterargument is that if i pipe them to e.g. grep, i do not want them lose terminal control sequences, as the output ends in terminal anyways.

The only correct behavior is to (at the very minimum) call isatty(3), and (ideally) query terminfo for specific capabilities.

If your stdout is not a terminal, and you're sending out escape codes, you're just spewing useless garbage.

> 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.

> 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

It can, but should it?

http://harmful.cat-v.org/cat-v/

> 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.

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.

> Exactly because you don't know it makes sense to optimize for the common case.

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.

You are just repeating the behavior from the GGP, that has the exact problem the GP said.

If you do that, add a command line switch to forcefully enable or disable the control.

The color codes could intefere with your grepping though, and it won't guarantee clean output unless all the begin/end codes are on the same line

Same if you still use a real terminal. I still love my VT520 <3. But so many programs just barf out xterm-256 without checking. .

I mean, termcap/terminfo was invented just for this. It's a solved problem.

> I can't wait for these kinds of e-ink displays to get more affordable.

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:

https://news.ycombinator.com/item?id=22831323

For some individuals, that price-point is not a blocker (:

> 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.

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.

There are off the shelf laptops with e-ink now: https://goodereader.com/blog/product/lenovo-thinkbook-plus-1...

It's technically dual screen, e-ink and OLED that rotate, but even better, you can choose the best one for the job.

The one in the linked article doesn't rotate. You may mean https://www.theverge.com/2023/1/5/23541379/lenovo-thinkbook-... which will be available in summer and is pretty pricey.

$1650 isn't cheap, but it's pretty normal for the high end of mid-range ultrabooks. It's less than I paid for my M2 MacBook Air, which has neither OLED nor E-Ink. Truly high-end laptops easily go for $2500+, but it is nice that more budget-friendly (sub-$1000) options that aren't terrible do exist these days.

I'm certainly excited to see reviews for that Lenovo laptop when it comes out.

You can't type on the e-ink side though. That would be the best, a simple laptop with an e-ink display, a good keyboard, nothing more. You could work anywhere you could also read a book!

They linked to the wrong laptop. See https://www.theverge.com/2023/1/5/23541379/lenovo-thinkbook-...

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.

Sweet! Since I started hacking on the v1 Kindle I've been waiting for this.

Would you share a screenshot, I'm really interested and I must not be the only one.

Any theme you can share for editors?

In my dotfiles:

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

I have also noticed that about the JS ecosystem, I would also like to add emojis as an example of something I see as abused in that ecosystem. There seems to be a lot of form-over-function going on over there, I wonder what characteristic of JavaScript developers inclines them to build their apps in that way.

Putting down JavaScript devs is so 2015. Haven't you got better things to do than make snarky comments belittling an entire profession?

  > There seems to be a lot of form-over-function going on over there, I
  > wonder what characteristic of JavaScript developers...

It seems to be the combination of a low barrier to entry with the ADHD-Is-Fashionable trend.

Reply on news.ycombinator.com