3 ms·

Congrats on your 1.0 release! Building a term from scratch is no small task. And it looks like after 2 years you already have something I'm seriously considerin

Congrats on your 1.0 release! Building a term from scratch is no small task. And it looks like after 2 years you already have something I'm seriously considering switching to. That's seriously impressive. And though I'm mostly a Linux supremacist, I genuinely appreciate and respect your dedication to providing native applications on all major platforms. I see too many projects do one of two things: only support one platform at first, with some vague promise of doing others in the future left unfulfilled for years. Or going the easy route of using electron or some other cross-platform toolkit, getting cross-platform support at the cost of a significantly worse experience. There is no substitute for doing the extra work, at the end of the day, and you're already well on your way there at such an early point. Again, I'm impressed! Now, the one thing I've coveted for years is a linux term with tmux control mode support, ever since I used iterm2 during my short tenure as a Mac user. I can see from your github issues that this is in the works(https://github.com/ghostty-org/ghostty/issues/1935 https://github.com/ghostty-org/ghostty/issues/1935), which is great. It looks like a lot of the necessary UI elements are already in place, as well as partial support for the control mode protocol. Do you have any idea how far off this is from being completed? I don't wanna make demands or anything, I know this is a passion project with lots of things still to work on. As far as I know(and I look around quite often) control mode support is still something no existing term for linux supports. Being the first could drive a lot of adoption! I'd also like to offer my help in pushing it over the goal line. I haven't touched Zig, but I'm a polyglot with plenty C experience and Im highly motivated to bring this feature to my Linux systems. Some guidance on things I might do to help would be welcome. The final 3 points of the checklist don't have much detail provided. Again, no pressure, thanks for all your amazing work, and good luck with continued development!

pzmarzly 2y ago
This. To add some words why this is important: Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its "backend" (tmux, code-server) is a great design decision, which I think will ultimately define what the "next generation" of terminal emulators is. Imagine being able to open tabs directly on remote host, reconnect without losing state, etc, all while using native UI (so Cmd+T to open new tab, Cmd+F to search, etc). Productivity game changer, which currently only the iTerm2 users can fully enjoy. Ptyxis (putting its backend in running containers), WezTerm (native handling of ssh sessions) and VSCode's terminal (starting a proprietary code-server binary and connecting to its TCP port) have reached some of this functionality, but in their design they need some out-of-band mechanisms to handle the connections, ultimately limiting the scenarios they can handle. Meanwhile tmux -CC [0] and ht [1] are sending both their control channel and data channel over the opened terminal itself (in-band), making them flexible enough to support any configuration. Something complex like `ssh jumpbox -- ssh prod -- podman exec -it prod /bin/bash -- tmux -CC` should just work, as if everything was running on your local machine. [0] https://github.com/tmux/tmux/wiki/Control-Mode https://github.com/tmux/tmux/wiki/Control-Mode [1] https://github.com/andyk/ht https://github.com/andyk/ht
- diggan 2y ago
  > Given the remote-first container-based world we're heading towards You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment. If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime. In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.
  - pzmarzly 2y ago
    Good point, I also want things to work offline. By "remote" here I was also thinking of scenarios like: - Connecting from Windows/macOS host to a local VM - Connecting to a build server over LAN (I have a beefy PC but prefer to work from my couch) Both work offline just fine, but from tooling perspective you are connecting to remote host over the network
  - nine_k 2y ago
    Not very small; most corporate non-Windows development uses containers, I'd bet on the ratio above 90%. Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.

pzmarzly 2y ago

This. To add some words why this is important: Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its "backend" (tmux, code-server) is a great design decision, which I think will ultimately define what the "next generation" of terminal emulators is. Imagine being able to open tabs directly on remote host, reconnect without losing state, etc, all while using native UI (so Cmd+T to open new tab, Cmd+F to search, etc). Productivity game changer, which currently only the iTerm2 users can fully enjoy. Ptyxis (putting its backend in running containers), WezTerm (native handling of ssh sessions) and VSCode's terminal (starting a proprietary code-server binary and connecting to its TCP port) have reached some of this functionality, but in their design they need some out-of-band mechanisms to handle the connections, ultimately limiting the scenarios they can handle. Meanwhile tmux -CC [0] and ht [1] are sending both their control channel and data channel over the opened terminal itself (in-band), making them flexible enough to support any configuration. Something complex like `ssh jumpbox -- ssh prod -- podman exec -it prod /bin/bash -- tmux -CC` should just work, as if everything was running on your local machine. [0] https://github.com/tmux/tmux/wiki/Control-Mode https://github.com/tmux/tmux/wiki/Control-Mode [1] https://github.com/andyk/ht https://github.com/andyk/ht

diggan 2y ago
> Given the remote-first container-based world we're heading towards You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment. If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime. In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.
- pzmarzly 2y ago
  Good point, I also want things to work offline. By "remote" here I was also thinking of scenarios like: - Connecting from Windows/macOS host to a local VM - Connecting to a build server over LAN (I have a beefy PC but prefer to work from my couch) Both work offline just fine, but from tooling perspective you are connecting to remote host over the network
- nine_k 2y ago
  Not very small; most corporate non-Windows development uses containers, I'd bet on the ratio above 90%. Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.