Hacker News new | ask | show | jobs
by bsder 387 days ago
> I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes.

Please, no. There is no reason for this to be querying a hack from 1978 in 2025 when there are effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pressed and released".

Ghostty actually does something like you ask, and I really wish it wouldn't. It's a pain in the ass with virtualization. I have Ghostty on my host, but I have to install Ghostty in all my guest instances to pick up some stupid termcap/terminfo entry, or I get garbage all over my terminal.
2 comments
quotemstr 387 days ago
> Ghostty

I bet it has a setting to set TERM. I mean, TERM is hardly a panacea, but it's better than blindly spewing terminal control control codes without configuration or control or feature discovery.

> effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pressed and released".

And what, every terminal application should have its own special knob for you to tell it what kind of terminal you have?

This whole discussion is a great example of why Chesterton's fence is a thing. The terminal world is already pretty fragmented. Suggestions to ignore the only even halfway decent widely-supported app-agnostic config knob without replacing it with something better are short-sighted. In any multi-party ecosystem, you need some way for different programs, written by different people at different times, to discover each other's capabilities.

link
bsder 387 days ago
> And what, every terminal application should have its own special knob for you to tell it what kind of terminal you have?

No, they should default to the only sane thing left, ignore TERM/termcap/terminfo, and leave the people who still want to run a VT-52 or Tek4014 in the dustbin.

There is a single combination for terminal usage which isn't broken in 2025--ANSI escape codes for output with the Kitty escape codes for input.

(And don't get me started about resolving the dependencies around ncurses, terminfo, etc. because some program is welded to a 15 year old version of curses ...)

link
quotemstr 387 days ago
Most terminals are not kitty. Should my program not work with them? What happens when kitty adds a feature? How do I know whether it's supported?

What we really need is robust feature detection, not TERM. The terminal universe doesn't seem particularly receptive to the idea: https://github.com/alacritty/vte/issues/98

In the meantime, we have TERM. I'll stop advocating people use TERM when the terminal ecosystem learns what the web had to learn ages ago and embraces feature detection. It's pointless to break even UA detection.

(Unfortunately, as the thread shows, XTGETCAP is broken in too many places to use.)

link
codethief 387 days ago
> I have to install Ghostty in all my guest instances to pick up some stupid termcap/terminfo entry, or I get garbage all over my terminal.

That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

link
bsder 387 days ago
> That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

You should try it out for yourself first. It could be something weird in my setup since I'm running an immutable distro.

And, no, it doesn't have a Github issue because I didn't feel like tracking down all the moving pieces to replicate it when I can just resolve it with a package install.

link