71–80 of 84 posts
While I agree with pretty much all the criticisms raised by others, I would just like to qualify that I like the idea of attempting to disrupt the traditional terminal.
A terminal will always be a window from GUI land to the shell, but that doesn't mean we can't play with it! :)
There's literally nothing about this I like. A terminal with a gradient background might look pretty for screenshots, but for long sessions it just adds to fatigue and makes text harder to read. "Saving your favorite commands" in a normal terminal involves writing an alias into your rc file, not a bunch of button clicks. Same goes for the whole "interactive flags" thing. Whoever made this clearly hates the terminal a…
You seem to have made this about you, which is fine, but why should we care what _you_ like? Are you a person whose opinion is deeply valued and sought after? Because if you are, then certainly a subjective statement will be weighted by the knowledge, experience and the expertise of the person saying it. So my question is, why does it bother _YOU_ if someone, somewhere, finds value in this and prefers this to whateve…
Earlier quoted context omitted.
> what language it was made in HTML + JavaScript + Electron Just download that archive, extract its content, and you will find the "goterminal" script that is basically an ASAR archive [1] with a copy of CEF [2] as the webview for the web application that they (for some unknown reason) decided to create. [1] https://github.com/electron/asar [2] https://bitbucket.org/chromiumembedded/cef
> that they (for some unknown reason) decided to create. That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
Earlier quoted context omitted.
> HTML + JavaScript + Electron flips over table
Actually, let me unflip that table. I am desperate for someone to come along and realize that the current terminal interface is a perpetual train wreck, and that if we can break compatibility but end up with something better we should . Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. Consider for a second how trivial that could be made if each command li…
Earlier quoted context omitted.
> that they (for some unknown reason) decided to create. That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
I see at least two possible reasons to create such a terminal: One: The author might have problems with how other terminals work. The other: The author just wanted to create something, without providing a superior value proposition. If it is indeed the latter scenario, it just wastes others' time.
What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way.
You should really reconsider your position. One point is that, while you may have the skills and experience to only work on projects that improve the status quo, many of us do not; and even those who do, as beginners had to pass through the stage where they did not.
Earlier quoted context omitted.
I see at least two possible reasons to create such a terminal: One: The author might have problems with how other terminals work. The other: The author just wanted to create something, without providing a superior value proposition. If it is indeed the latter scenario, it just wastes others' time.
> If it is indeed the latter scenario, it just wastes others' time. What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way. You should really reconsider your position. One point is that, while you may have the skills and experience to only work on proj…
The time wasted is exactly the time it takes to find out that “elegant and efficient” is at best hyperbole, at worst a lie.
Earlier quoted context omitted.
Actually, let me unflip that table. I am desperate for someone to come along and realize that the current terminal interface is a perpetual train wreck, and that if we can break compatibility but end up with something better we should . Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. Consider for a second how trivial that could be made if each command li…
In your vision where text is not the universal interface, how would Unix pipes work? After all, often the output of one tool is the input of another – that usually has not been written to interact with the first.
And it's a logical extension of the UNIX stream model, where in reality you're passing around a whole heck of a lot more than text when you type 'cat | sed'. You're passing environment context, multiple streams, etc.
The idea that this is "more complex" than unix pipes is understandable, but the reality is that IPC is pretty complex and a whole lot of magic and shared expectations go into the "simplicity" that bash offers. And even then that model breaks down all the time (e.g., as Docker becomes common as a deploy target the idea that you should output error conditions to STDERR has rapidly become problematic).
Earlier quoted context omitted.
> If it is indeed the latter scenario, it just wastes others' time. What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way. You should really reconsider your position. One point is that, while you may have the skills and experience to only work on proj…
If a project does not improve the status quo, I think it should not be presented as something one “should have”. The time wasted is exactly the time it takes to find out that “elegant and efficient” is at best hyperbole, at worst a lie.
Earlier quoted context omitted.
In your vision where text is not the universal interface, how would Unix pipes work? After all, often the output of one tool is the input of another – that usually has not been written to interact with the first.
Powershell accomplishes this by making the pipes pass tagged objects around containing streams. This actually has a lot of nice properties when you go to manipulate the objects programatically. And it's a logical extension of the UNIX stream model, where in reality you're passing around a whole heck of a lot more than text when you type 'cat | sed'. You're passing environment context, multiple streams, etc. The idea…
Earlier quoted context omitted.
Oh? Historically most terminal implementations have been fraught with performance issues. We'd moved off xterm to aterm and then back. We'd been hesitant to adopt gnome-terminal because of the GTK+ chrome then saw its font kit actually rendered faster. What most people don't get is how absurdly well-optimized the text rendering and reflowing is for web browsers. With care, people can get modern cellphone browsers to…
Maybe I am wrong, but I have yet to see a modern browser take anywhere near as little memory of CPU as a modern terminal emulator. There is also the matter that no matter how much optimization you put into something you can't recoup the cost of the fundamental design choices you went with. Choosing something with less power can solve a lot of headaches.
Browser instances can be quite svelte. But uh... I mean... shared lib pages tend to be actually shared pages. That's why the physical memory for multiple browser instances is a lot lower.
What's more, I'd gladly pay a higher price for a richer experience. We no longer need to or should rely on ANSI interfaces. In fact, they're becoming increasingly awkward in a world that really wants endpoints to be stateless by design rather than stateful sockets.
Many people have already discarded the single socket model oh SSH in favor of Mosh. Let's also ditch the console for all but the most basic of tasks. It's not 1997, the lingering stink of proprietary rich client environments is cleansed. Web browsers have annihilated that assumption and made something truly open and pretty amazing.
I use a web browser as my core text editor and I miss emacs not a whit and quite honestly it feels more responsive than my emacs setup. I don't notice any tangible performance differences from Vim in a terminal.
We can do better.