Hacker News Reader

Comment by abnercoimbre | Hacker News Reader

It's so cool to see more terminal(-adjacent) experiments! We're overdue in evolving this space.

Self-plug: last month I demoed [0] my own terminal. The goal is to dispense with traditional shells and see what happens. It generated quite a bit of hooplah, with a 50-50 split on how people felt about it.

I'll keep an eye on Fui; might come in handy for future Linux builds.

[0] https://terminal.click/posts/2025/04/the-wizard-and-his-shel...

View on HN

I've thought that if I did this, the one thing I'd like to change is the intermixing of command and output. The command line should be an entirely separate part of the GUI from the output area. Possibly separate output areas for different commands, if they're running concurrently. There's no reason anything other than my input should ever need to appear in the middle of my input box.

This is amazing... I'm asking to have those features (which were available in Genera) all this time! The hard distinction between Terminal/Text and GUI can be somewhat diluted.

I wanted to download it, but I see there is contribution needed. I will see how I can convince you :)

Thank you! Yes it's currently in closed beta (the project is TempleOS-level crazy, which means it's too easy to get it wrong.)

If someone thinks they're a good fit to test experimental terminals, an email will suffice: abner at terminal dot click

It doesn't seem that radical from the Github readme, I must say. That's not a criticism, nor at all a high bar! What you're doing appears to be trying to exist within a category that ever has had or will have any other member - so, definitionally, not "TempleOS-level crazy." :D

(Not interested in testing, sad to say. I've spent the last fifteen years trapping "I wish this shell/terminal had X feature" to "time to find a tool for X that isn't as garbage as a shell and a terminal." But I have also used Emacs for about the same length of time, and that implements its own terminal emulators, anyway.)

The very first video there is about setting opacity and picking a theme and a background. I don't care about those things. I want only a dark background color palette, which every modern terminal emulator has.

The rest is all about how smart the terminal is and lets you do things without your shell having to be involved. But... now I have to know _two_ major things: the shell and the terminal. Ugh. Why can't I just have a better shell to do all of that?

How does this stuff work over ssh/mosh? Answer: it doesn't:

> Can’t Shells Do All This Stuff Too?

> Maybe. You could extend the TTY protocol or add new escape codes to mimic some of these features. But as Terminal Click evolves this argument gets sillier. [...]

But if you don't want to add escapes then now you have to define new protocols to make this work across the network. Or give up on the network. Or continue to insist on the terminal interpreting what it sees and being a layer completely detached from the shell, though now it can't see the PATH on the remote end and other such problems.

Don't you see that a plain old terminal emulator + tmux + shell is just an awesome stack?

Now maybe we should never need remote shells. In a zero-touch world it really has to be the case that there are very few places to ssh/mosh over to, though even then we'd need this terminal to be so smart as to understand that this shell is a Windows PowerShell and now whoops we're in a WSL2 bash shell (which is a lot like ssh'ing over to a Linux box).

I just don't have high hopes that these things can make my life easier.

Thanks for the feedback! You definitely grok the (currently annoying) consequences of what I'm doing. I believe this is the gist of your point:

> Don't you see that a plain old terminal emulator + tmux + shell is just an awesome stack?

I think it's only awesome to those of us brought up on RTFM culture. If you read the commentary [0] from HN's little cousin they center the battle around this very subject, which is what I personally care for the most. So much so that I'm willing to smash the stack (heh) and persuade others it's worth reinventing even if we ultimately fail. We will preserve what we can; I'm not going at it blindly.

You'll never meaningfully convince newer generations to leverage man pages for discovering new commands/functions: "Oh oops add a 3 to read about that one. Why? Let me explain man sections to you." Ditto for environment updates: "Try putenv, which should not be confused with setenv! No no, run env first to dump what you have!"

I ALWAYS get blank stares from (imo competent) GenZ devs who were initially curious. They were willing to read and learn and discover but not like this. They tip toe away from me and switch back to IDEs. My examples were contrived but the general observation propagates across the entirety of workflows within classic terminals.

[0] https://lobste.rs/s/ndlwoh/wizard_his_shell

Thanks for the thoughtful reply. I laughed. You're probably right. And just as one might never convince newer generations to RTFM, one will have a similarly difficult time convincing older generations to do the newfangled thing.

Although I should say that I work with colleagues in newer and older generations, and I find that the younger ones do end up learning how to RTFM.

That's very interesting, two comments:

- Automatic black box with autocomplete is a deal breaker for me. It'll drive me mad.

- I only use the mouse in the terminal if I have to (it disturbs and slows my flow!). So anything that helps me NOT using the mouse would be better. At the moment I think it's only text select/copy I use the mouse for. And resize the window. So a magic quick way to select text and copy from the keyboard would be very nice.

But I do realize I'm not the intended audience.

There’s a lot of parallels between what you’re working on and my projects. In fact nearly all of your features exist in my projects too.

It’s great to see others working in this field. When I started out (nearly a decade ago now) there was a lot more resistance to these kinds of concepts than there are now.

your terminal looks cool!

Depends, I for one, am quite happy no longer having to use a computer like in 1986 - 1990.

There is a big difference between "having to" and "being able to" (if you want, like, find it convenient or feel so, for some use case)

Anyway unless you were a happy Genera user at that time, I would like what terminal did you use then with color highlighting, dynamic feedback, auto completion, transparency and the other features...

I used what Timex 2068, MS-DOS 3.3 - 5.0, CP/M, allowed me to do, until I was freed into Windows 3.x and Amiga 500, in 1990.

Until 2005, I also had to put up with using Xenix, DG/UX, Aix, Solaris, HP-UX, GNU/Linux via telnet as development servers.

Thankfully by 1996, X Win32 and Hummingbird came to rescue as my X Windows servers of choice, when possible.

As for all those features, you could already do most of them in 4DOS (1989).

https://en.m.wikipedia.org/wiki/4DOS

It is like asking me about electronic typewriter features, when the World has moved on into digital printing.

Some of the authors in my circles still use typewriters. Some don't. That's fine. But people do enjoy going back to older techniques, sometimes.

I've seen many debates about the correct carriage return. The world does not move on uniformly.

Epaper based "typewriters" that "print" to a text file on an SD card are a thing. Not useful to me since I'm not an author but I can appreciate the desire to get rid of unnecessary distractions. It's the same reason I use a terminal emulator.

Now that you say it, I remember using command completion and color highlighting in the prompt with DOS4. I was liverated from the terminal a little bit before that.

On the other hand, I'm also sad that I don't longer have a computer interface like I had from 1995 - 2010, i.e. that everything is webflat and image-heavy. So weighing the timeline options, I'm not sure I'd pick the look and feel of the post-optimal time frame on a given day ;)

Reply on news.ycombinator.com