IMO, it makes no sense.
Go Terminal_ Elegant and Efficient Linux Terminal
61–70 of 84 posts
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#62Earlier quoted context omitted.
It's not that simple. The shell for you and me is muscle memory. For someone who takes a "boot camp" and then doesn't use what they've learned for 3 weeks, the boot camp was a waste of time. Haven't you ever come back to a piece of code from a month ago and had to reacquaint yourself with it? (I know I can't be unique in that... ;) ) We cram an awful lot into our heads as devs, there's no room for things we barely us…
Here's what you do: in the middle of the night, sneak into all of your devs' offices and fuck with their xorg.conf's. Make them drop to command line only for a couple weeks (because we all know it takes at least that long to diagnose an xorg.conf....) and they'll learn. Oh they'll learn ;)
Or they'll quit. Oh they'll quit ;)
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#63Earlier 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…
> Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script.
It really isn't, see e.g. whiptail.
And using ncurses for anything today is not a good idea. Surviving terminals are overwhelmingly ANSI, and can be supported by a single codebase that uses escape sequences directly, wihtout the horrors of ncurses.
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#64Earlier quoted context omitted.
Don't be fooled by the name, this application is not written in Go, that is just a random word that they chose for the name. The application was written in HTML and bundled with a webview powered by CEF (probably Electron). Just download the application and execute `strings goterminal | grep chromium` and you will see what I am talking about; again, this has 0% Go code. EDIT: Here is the list of 720 NPM packages used…
720 npm packages..........................................
Guess the chances that it won't built anymore in 1 week are 99.9%.
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#65Earlier quoted context omitted.
I agree with each and every one of your comments; in addition, I would like to know how this project was created: what language it was made in, why the author found it necessary to create it, etc.
> 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
>HTML + JavaScript + Electron
This was my creeping suspicion the moment I saw the screenshots. Utter garbage.
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#66Earlier quoted context omitted.
> Just what I've always wanted from a terminal - things I can only do with a GUI and mouse. /sarcasm Just what this conversation needs - someone who fundamentally doesn't get that web browsers and their derivatives have more affordances for accessibility than a native terminal interface ever did. > This product seems to fundamentally misunderstand people that use terminals. > Either way, why is there a group of peopl…
> Just what this conversation needs - someone who fundamentally doesn't get that web browsers and their derivatives have more affordances for accessibility than a native terminal interface ever did. I do not have sight impairment, but I'm quite certain that I could navigate a fixed number of keystrokes more reliably than I could operate a mouse. If I were listening to synthesized speech dictating on-screen output, I…
I don't understand why you're perfectly happy to consider assistive technology for your terminal but completely unwilling to consider assistive technology for the browser.
The Web is an order of magnitude more tooled for usability than nearly any application you use on a day to day basis. Requiring pointer actions has nothing to do with that.
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#67Earlier 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…
> Please, let's not pretend we'd not benefit massively from richer tooling here. Absolutely nothing about this project or the way they went about building it shows any tendency towards richer tooling. A web interface also does not inherently enable richer tooling. You could implement this non-line oriented protocol entirely without 500+ MB of JS and the interpretation of that data could obviously be done without it t…
> you've picked a strange submission to take these fights in.
I don't see how that's germane. I didn't object to concrete references to the software (which is not as good as other submissions). I objected to knee-jerk silverbacking.
> You seem to have made this a personal crusade,
No, but I am so tired of people on HN mimicking the style of development we put together in the 80's and 90's because... well I have my opinions about this practice, but they're uncharitable. We'll leave it at that.
There is a cult of terminals in our industry that has fundamentally missed why terminals were an effective interface and throw shade on anything that isn't a terminal, even when it's actually a refinement on the terminal concepts.
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#68Earlier 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…
> Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. It really isn't, see e.g. whiptail. And using ncurses for anything today is not a good idea. Surviving terminals are overwhelmingly ANSI, and can be supported by a single codebase that uses escape sequences directly, wihtout the horrors of ncurses.
I have seen whiptail. It's still easier to make a list of selectable options in html or markdown.
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#69There'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 whatever other way you think other people should do it?
Re: Go Terminal_ Elegant and Efficient Linux Terminal
#70Earlier quoted context omitted.
Yikes. Thats a great way to make a terminal into a memory hog and unresponsive under load.
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.