The problem they cherry picked is about there with the simplest form of what you can practically get away with to justify their pitch. The little technical detail provided is so unusably shallow that it can barely ripple the surface. The solution have been tried plenty of times before and without proprietary $30M VC behind it, see also: Hyper and Upterm.
Yeah, that was my instinct, too. You can just simplify and get all that stuff for free, or complexify and attempt to recreate a lot of functionality on your own.
For what it’s worth, emacs’ M-x shell with some tweaks can work very similarly to an acme win window. And you get all the cut/paste/edit/hover functionality you have in emacs.
I dunno, the Vim mode in Fish, as limited as it is, does a good enough job for me in editing and navigating text on the command line. As a bonus, it’s terminal agnostic and works on the TTY.
I’m absolutely not “strongly opposed to any graphical elements or mouse interactions in the terminal on principle”. I think mouses for selection and pointing are great. I just don’t see what the fuss is in the examples they give, or why learning a few key bindings to navigate back and forth through a command line entry needs to be such a big deal.
Like Warp, the Arcan project’s shell (previous discussion) aims to remove the restrictions of a tty/pty from the terminal experience. Arcan’s higher-level shell Lash#Cat9 (previous discussion) doesn’t seem to innovate on the command text editing experience, but I think the low-level shell’s architecture would allow that.
Arcan’s components are all open source, unlike Warp. However, Arcan’s documentation doesn’t seem geared towards people trying it out. Arcan calls itself a “development framework”, but doesn’t explain what operating system it depends on, or whether Arcan is itself an operating system.
Very long article to say that they never learned readline’s keybindings.
Less snarky answer: Emacs already provides all of these things in its various shell modes (shell, term, eshell, and vterm), with various tradeoffs, mostly around how well or badly TUIs work.
This again? Gee… People won’t let go after almost 40 years.
Don’t get me wrong, I think CUA and the ubiquitous text areas of modern operative systems are practical, but this is absurdly short sighted.
Of course, if you use enter for its intended purpose, (ENTERING commands) you can’t have it hijacked by its other usages. How is this weird?
It has weird multi line editing ergonomics because it actively favoured single line commands as a design choice. That is a brutally useful feature, not a weirdness.
Don’t get me started about mouse support. Here we are in 2022 and each time I need to reach for the damn mouse still feels like usability rape. This caged mindset baffles me. What about stopping and thinking for a minute about the mouse. Is it really a good thing that it has such a central role? No doubt it is king of intuitiveness. But that is not the same as practicality or uaefullness.
I don’t see why you have to be so hostile to an alternative project that targets different people than you. Nowhere in this post do they suggest anyone should stop using their old terminal if they like it. You don’t like the mouse, cool. Other people don’t like readline-style shell editing.
And I don’t see how it’s shortsighted either. From the post it seems like they’ve gone out of their way to maximize interoperability with existing shells, and go the extra mile to emulate all the desirable features their approach overrides. You are the one who is being shortsighted.
Not everyone needs to be a shell ninja warrior. I’ve worked with world class engineers on low level database engine code who couldn’t use a shell at all. One guy kept a shell open exclusively to run the build and test commands, knowing literally nothing else except how to cd to the project directory. He didn’t like terminals, but he was one of the smartest people I’ve ever met, and produced a prodigious amount of high quality code.
I don’t see why you have to be so hostile to an alternative project that targets different people than you.
I am not hostile to the project. I mentioned in my post that I find CUA text areas useful. Heck, I prefer and use so called modern editors, CUA based and I too believe they provide a superior editing experience than terminal based editors.
What I criticize is this silly idea that terminals are weird and limited because they are too old. This is a baseless assumption stemmed from lack of understanding the design of text terminals.
Ask a user of a modern editor to use without ever touching the mouse. And they will be frustrated in seconds.
Yet this article just assumes mouse usage is better because of discoverability. Sure it is butter at that, but why ignoring all the usability problems it comes with? Has it ever occury to them that mouse can be a disadvantage?
And I don’t see how it’s shortsighted either.
It is very shortsighted and misguided because it totally ignores the design choice that the point is to enter commands easily and quickly (for which it absolutely rocks) and not to provide an advanced editing experience. Shellscripting has existed from the very beginning. The point has always been to edit them with whatever editor you wish.
I think there is a place for a workflow of executing the command under the cursor on an editing context. This has been an element of emacs phylosofy for decades. And many attempts of doing this have been tried over the last decades. Let’s not just ignore that they mostly failed to succed to a handful of orders of magnitude away from vt100 emulation. Projects like this should have the starting point at understanding why is that so. Not just gratuitously say that text terminal emulators are weird/old/obsolete. They did survive in the GUI world.
Not everyone needs to be a shell ninja warrior. I’ve worked with world class engineers on low level database engine code who couldn’t use a shell at all. One guy kept a shell open exclusively to run the build and test commands, knowing literally nothing else except how to cd to the project directory. He didn’t like terminals, but he was one of the smartest people I’ve ever met, and produced a prodigious amount of high quality code.
Sure. Then why are projects like this so fixated with the terminal? What is it that they want from it if they live ao happily in their mouse driven GUI world? The answer is: they don’t know. They are confused.
Don’t get me wrong, point and click UIs were one of the biggest revolutions in computing. But this idea that they render text based interfaces obsolete is non sense and lack of understanding of UX.
This is an advertorial (rantvertorial?) for a commercial proprietary product.
Previously, on lobste.rs:
Seems a bit more than that to me. The problem they describe and the solution is kinda neat.
The problem they cherry picked is about there with the simplest form of what you can practically get away with to justify their pitch. The little technical detail provided is so unusably shallow that it can barely ripple the surface. The solution have been tried plenty of times before and without proprietary $30M VC behind it, see also: Hyper and Upterm.
I don’t disagree - I’d definitely want to see what this could do to standards rather than being a single proprietary solution however.
For something not emulating a tty, http://man.9front.org/1/rio under section “Text windows”.
tt[0] (2/3 of a tty) is a small, neat implementation of the ideas found in 9term.
[0] https://github.com/leahneukirchen/tt
Heh. Came here to say “try Plan 9 for a decades-old implementation of something better than TTY emulation” and found you had beaten me to it :)
Yeah, that was my instinct, too. You can just simplify and get all that stuff for free, or complexify and attempt to recreate a lot of functionality on your own. For what it’s worth, emacs’
M-x shellwith some tweaks can work very similarly to an acmewinwindow. And you get all the cut/paste/edit/hover functionality you have in emacs.I dunno, the Vim mode in Fish, as limited as it is, does a good enough job for me in editing and navigating text on the command line. As a bonus, it’s terminal agnostic and works on the TTY.
The “can’t place cursor with mouse” bit isn’t exactly true. Some allow it via Alt/Cmd-click
I’m absolutely not “strongly opposed to any graphical elements or mouse interactions in the terminal on principle”. I think mouses for selection and pointing are great. I just don’t see what the fuss is in the examples they give, or why learning a few key bindings to navigate back and forth through a command line entry needs to be such a big deal.
Like Warp, the Arcan project’s shell (previous discussion) aims to remove the restrictions of a tty/pty from the terminal experience. Arcan’s higher-level shell Lash#Cat9 (previous discussion) doesn’t seem to innovate on the command text editing experience, but I think the low-level shell’s architecture would allow that.
Arcan’s components are all open source, unlike Warp. However, Arcan’s documentation doesn’t seem geared towards people trying it out. Arcan calls itself a “development framework”, but doesn’t explain what operating system it depends on, or whether Arcan is itself an operating system.
Very long article to say that they never learned readline’s keybindings.
Less snarky answer: Emacs already provides all of these things in its various shell modes (shell, term, eshell, and vterm), with various tradeoffs, mostly around how well or badly TUIs work.
This again? Gee… People won’t let go after almost 40 years.
Don’t get me wrong, I think CUA and the ubiquitous text areas of modern operative systems are practical, but this is absurdly short sighted.
Of course, if you use enter for its intended purpose, (ENTERING commands) you can’t have it hijacked by its other usages. How is this weird? It has weird multi line editing ergonomics because it actively favoured single line commands as a design choice. That is a brutally useful feature, not a weirdness.
Don’t get me started about mouse support. Here we are in 2022 and each time I need to reach for the damn mouse still feels like usability rape. This caged mindset baffles me. What about stopping and thinking for a minute about the mouse. Is it really a good thing that it has such a central role? No doubt it is king of intuitiveness. But that is not the same as practicality or uaefullness.
I don’t see why you have to be so hostile to an alternative project that targets different people than you. Nowhere in this post do they suggest anyone should stop using their old terminal if they like it. You don’t like the mouse, cool. Other people don’t like readline-style shell editing.
And I don’t see how it’s shortsighted either. From the post it seems like they’ve gone out of their way to maximize interoperability with existing shells, and go the extra mile to emulate all the desirable features their approach overrides. You are the one who is being shortsighted.
Not everyone needs to be a shell ninja warrior. I’ve worked with world class engineers on low level database engine code who couldn’t use a shell at all. One guy kept a shell open exclusively to run the build and test commands, knowing literally nothing else except how to
cdto the project directory. He didn’t like terminals, but he was one of the smartest people I’ve ever met, and produced a prodigious amount of high quality code.I am not hostile to the project. I mentioned in my post that I find CUA text areas useful. Heck, I prefer and use so called modern editors, CUA based and I too believe they provide a superior editing experience than terminal based editors.
What I criticize is this silly idea that terminals are weird and limited because they are too old. This is a baseless assumption stemmed from lack of understanding the design of text terminals. Ask a user of a modern editor to use without ever touching the mouse. And they will be frustrated in seconds. Yet this article just assumes mouse usage is better because of discoverability. Sure it is butter at that, but why ignoring all the usability problems it comes with? Has it ever occury to them that mouse can be a disadvantage?
It is very shortsighted and misguided because it totally ignores the design choice that the point is to enter commands easily and quickly (for which it absolutely rocks) and not to provide an advanced editing experience. Shellscripting has existed from the very beginning. The point has always been to edit them with whatever editor you wish.
I think there is a place for a workflow of executing the command under the cursor on an editing context. This has been an element of emacs phylosofy for decades. And many attempts of doing this have been tried over the last decades. Let’s not just ignore that they mostly failed to succed to a handful of orders of magnitude away from vt100 emulation. Projects like this should have the starting point at understanding why is that so. Not just gratuitously say that text terminal emulators are weird/old/obsolete. They did survive in the GUI world.
Sure. Then why are projects like this so fixated with the terminal? What is it that they want from it if they live ao happily in their mouse driven GUI world? The answer is: they don’t know. They are confused. Don’t get me wrong, point and click UIs were one of the biggest revolutions in computing. But this idea that they render text based interfaces obsolete is non sense and lack of understanding of UX.