WTH is it with some requirements for "advanced" terminal emulators?

cracauer@ said:
I observe an increasing tendency of TUI/terminal software that needs special "advanced" terminal emulators.

Homebrew on macOS is an example. If I am on FreeBSD in an xterm and ssh into one of my Macs, I can't directly run homebrew commands to manage software. The problem being that theyy use terminal sequences that xterm doesn't understand and that end up spewing into control sequences making a mess, and a potentialy dangerous one. Of course nobody stopped to think about using termcap for this, which would (as the name implies) either send the right sequences, or at least not send ones not understood.
Likewise, Claude Code (the so-called CLI that is really a TUI) also requires special terminals, otherwise output is garbled. And they say that they need them to process Shift-Return. Never mind that Shift-Return works just fine on xterm. https://code.claude.com/docs/en/terminal-config

Now, what are th terminals wanted? The two non-Mac specific ones are ghostty and kitty. Both have FreeBSD ports. So I can open one of them on my FreeBSD screen and then use Claude Code or ssh into a Mac. Sounds good? Not quite. Both are using 3D APIs (Vulkan and OpenGL) and have no fallback to X11. So you can have one over ssh forwarding. Configuration is also laughable compare to xterm. Big loss of functionality here.

Opinions? I wish I could blame this on Linuxisms, but half of it is Mac driven. Weak rant?

Is anybody voluntarily using ghostty or kitty?
Click to expand...

Homebrew: "Hey kid! Do you like candy? I got some candy in the back of my van. Come get some candy... All different colors!"
 
aphor said:
Homebrew: "Hey kid! Do you like candy? I got some candy in the back of my van. Come get some candy... All different colors!"
Click to expand...

The funny thing is that homebrew seems to do all of this for nothing. When running in kitty I see nothing that any old TUI app does with no problems on any old terminal.
 
homebrew just wants a UTF8 terminal with UTF8 fonts. I verified by running xterm from freebsd on the MBP display and then sshing to MBP from it and running brew info zsh and it displayed check (✔) and cross(✘) marks fine. $LANG is set to C.UTF8 & the VT Fonts popup display shows UTF-8 fonts are selected.
 
cracauer@ said:
I just about had it with your constant barrage of useless, meaningless replies everywhere.
Click to expand...
I find this assertion very uncouth. It's effortless to simply ignore those posts whose purpose you don't understand, especially in the off-topic forum, where we are. There's no need to rebuke any user so harshly.
 
cracauer@ said:
I observe an increasing tendency of TUI/terminal software that needs special "advanced" terminal emulators.
Click to expand...
Mine personal and probably faulty answer... Recently, TUI is perceived as a dev-cool and portable way, for building development and admin tools. Because TUI tries to replace some tools based on desktop GUI or web based UI, they use some features at the limits, or above them, with the problems you and others correctly mentioned.

For exampe, I'm "migrating" from Doom Emacs to Helix. Helix is a TUI. Helix under Alacritty works visibly better than standard terminals. And it is surprising good for being a TUI. Also nushell add a lot of graphical elements to normal shell interaction. On the opposite side, for remote GUI applications, I'm also using waypipe with wayland, and it works very well, at least in local networks.

Probably in an ideal world, there should be some standard API, or some standard remote GUI tool, for having applications more rich and graphical than TUI, but still "ssh" friendly, and maybe also with a strong structural/DOM-like information. Sorry if I'm ambiguous.
 
cracauer@ said:
If I am on FreeBSD in an xterm and ssh into one of my Macs
Click to expand...

What happens if you ssh over to Mac and export the Mac terminal back your FreeBSD? In the "old days" Mac was still X Windows compatible, but I have to admit I haven't tried to export a Mac terminal back to a Unix or Linux host in a long time.

You can always (try?) TigerVNC? A quick check of their Source Forge repository shows a Mac OSx binary.
(Link: Source Forge): TigerVNC binaries

(From the link)
macOS

TigerVNC-X.Y.Z.dmg
Universal (Intel and Apple Silicon) macOS package of the TigerVNC viewer.

I have had good luck with TigerVNC between Linux hosts and FreeBSD
 
EDIT: In case it helps and leads somewhere... this software seems to be being recently updated in 2026 !

In the older days of Mac OSx I used to continuously upgrade MacOS with the easily downloadable XQuartz package so that X Windows would work. And indeed - I got the right X Windows features working once I download/updated/etc the XQuartz package and connected from (at the time) Linux hosts to Mac and back.

(Link XQuartz): XQuartz Home

You would also have to consider issues between INTEL and "M" series chips? I am pretty sure I was on an INTEL based Mac when I last installed it ... but that was largely because I hadn't tried it on an "M" series.

And... it can be installed using homebrew ! :) -- Ya, I know, I find homebrew challenging as well..

EDIT: Well.. actually there is an April 19, 2026 version of XQuartz in "pre-release"
(Link XQuartz): XQuartz Releases

Good luck !
 
You must log in or register to reply here.
Back
Top