xterm.js

Thanks for the work on getting libghostty 1.4 out! :D Wanted to add too that I can't wait for xterm to eventually support libghostty, you've been super supportive providing feedback! https://github.com/xtermjs/xterm.js/issues/5686

It seems like a big problem that xtermjs has is iOS copy/paste, so I fixed that today [1]. [1] https://github.com/xtermjs/xterm.js/issues/3727

The terminal the game uses have some known issues on Chrome/Android (https://github.com/xtermjs/xterm.js/issues/5343). Firefox with desktop mode should work fine

Hi! I work on TUI rendering for Claude Code. I know this has been a long-standing frustration — it's taken longer than any of us wanted. The good news: we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch[1] and only ~1/3 of sessions see at least a flicker. Very, very few sessions see flickers in rapid succession which was so annoying before. Those numbers will keep dropping as people update. We've also been working upstream to add synchronized output / DEC mode 2026 support to environments where CC runs and have had patches accepted to VSCode's terminal[2] and tmux[3]. Synchronized output totally eliminates flickering. As always, I recommend using Ghostty which has 2026 support and zero flicker. Happy to answer questions! [1]: https://github.com/anthropics/claude-code/issues/769#issueco...

Went searching and found a few more: -PlayStation: https://github.com/micah5/PSone.css -Gameboy: https://github.com/luttje/css-pokemon-gameboy -Windows7: https://github.com/khang-nd/7.css -Win95: https://github.com/AlexBSoft/win95.css -Oldschool RPG: http://ronenness.github.io/RPGUI/ -MacOS 8: https://github.com/npjg/classic.css -MacOS 6: https://github.com/sakofchit/system.css And some that are more than just CSS: -386 DOS: https://github.com/kristopolous/BOOTSTRA.386 (Bootstrap Theme) -Terminal: https://github.com/xtermjs/xterm.js -another Terminal: https://github.com/andersevenrud/retro-css-shell-demo -90s website: http://code.divshot.com/geo-bootstrap/ (Bootstrap)

This brings back memories. I haven't looked at it in a while, but I'm glad to see the fork[1] of my fork[2] from 12 years ago is still thriving. Looks like it's been mostly rewritten. Probably for the better. [1] https://github.com/xtermjs/xterm.js [2] https://github.com/chjj/term.js

Perhaps something like https://github.com/xtermjs/xterm.js can be used to show interactive sessions for TUI apps.

Stack traces are very valuable. Sometimes it can even help to attach them to some object creation, when you later wonder why/how/where this object was created. E.g. in TensorFlow, every single Tensor had a traceback attached to it, so when there was any error later on, it would show you where it was created. This is maybe less needed now with eager mode, but you might have other similar situations. One problem with stack traces is maybe that they can be too verbose. E.g. if you print them for any warning you print to log (or stdout). Sometimes they will be extremely helpful for debugging some problem, but in many cases, you maybe don't need them (you know why you get the warning and/or you don't care about it). You could also add more information to the stack trace such as local variables. That can be even more helpful for debugging then,

I've used xterm.js for this, but I was already in a webview. It's pretty good, might even be worth the webview for https://github.com/xtermjs/xterm.js Used by vscode among others

Here is a screenshot: https://github.com/xtermjs/xterm.js/pull/4519#issue-17129655...

I am working on a re-write (https://github.com/xtermjs/xterm.js/issues/4800) of the xterm.js "BufferLine" data structures that (among other benefits) could potentially support variable-width fonts in the terminal. Instead of a 2-dimensional grid of character cells, the primary data structure will be a list of logical lines, each consisting of characters and attributes. A rather modest enhancement to the vt100/xterm escape sequences would be a mode where screen addressing would be in terms of logical characters and logical lines. The application should not need to know the width of characters or how lines are broken into screen rows. This makes use of variable-width fonts practical - which is necessary for decent rendering of many scripts. DomTerm's display engine (https://domterm.org) does support lines containing a mix of monospace and v

The master branch of xterm.js (which will become version 5.4) has a new experimental support for grapheme clusters, combining characters, and partial support for variation selectors, based on Unicode 15. (Contributed by Your Truly.) For now it needs to be explicitly enabled (see https://github.com/xtermjs/xterm.js/tree/master/addons/addon...) but in a later release we hope to make it the default. Most of the work is handled by the browser and the font, but xterm.js does need to detect cluster boundaries - which is what the addon does.

I'm on the VS Code team and maintain xterm.js which is what Hyper's frontend is based on. There are actually multiple developments happening in this area. First, there's a contribution from the author of DomTerm which adds grapheme cluster support to xterm.js, which will correctly merge and size things like emoji that are called out in the post. This is currently based on Unicode 15. See https://github.com/xtermjs/xterm.js/pull/4519 Second, while Windows Terminal does seem to work with emoji sometimes, it doesn't all the time. I'm not 100% sure, but I think it may only work on Windows ptys, not in WSL for example. Last time I spoke with the team they said they're working on a rewrite which could lead to proper emoji support.