161–170 of 214 posts
Dependability has to come before the bells and whistles and this appears to be a long ways out just skimming through the amount of bugs that are caught in this comments section.
Earlier quoted context omitted.
I've asked several of these people to explain the attraction http://quoteinvestigator.com/2013/02/10/where-money-is/ Javascript is a "workable" or "decent" language, and it happens to run where the users are. This is also a large part of why C++ was a success and C before it.
This works when you're executing code "where the users are", as I conceded in the parent post (it's the language you use when you have to). It doesn't explain why they'd willingly switch away from another server-side language to re-implement the whole thing in server-side JavaScript.
Whether or not that makes it a solid, durable terminal program is another question, though.
I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release: * The .deb package seems to install everything in /opt. This seems to be pretty common practice for electron apps and isn't a huge deal, except for the fact that a wrapper executable/link isn't installed anywhere else on the system. As a…
> I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. Me too, although in the case of terminal apps, they really haven't moved on since the 70s. How many support images? Completion popups? Browsable history? Current directory widget? Collapsible output? Honestly if it takes some insane over-engineering to get some actual innovation in terminal apps I'm all for it! And whe…
A lot of them, actually. Sixel is a thing.
>Completion popups? Browsable history?
No terminal emulator supports that. Because that's not the emulator's responsibility. That's your shell's job. Asking for your terminal emulator to support command completion is like asking X Windows to add tab completion to Gedit.
Go grab a copy of fish if you want, though. I've heard a lot of good things about it.
>Current directory widget? Collapsible output?
Those are just hard to implement, and usually not worth the effort. The directory widget is essentially provided by your prompt in many shells anyways.
This is really cool and it's clear that a lot of work went into it. I've used it a bit and it's generally solid. I've been looking for improved terminal clients for years. To that end, I have a simple benchmark that I run: find / Then repeat the same within a tmux session. In both cases I check to see if I can interrupt the output with Ctrl+C. Hyper on linux under X actually stops rendering the output very quickly, b…
To that end, I have a simple benchmark that I run: find / Well crap. Years ago during an phone interview for a position that wasn't going to use Python, I was discussing that the current python script was exponential, then I wondered what would happen if I just let it run. It very quickly completely froze my laptop. In VisualWorks Smalltalk, I would have been able to Ctrl-Y interrupt into the "emergency evaluator." P…
I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release: * The .deb package seems to install everything in /opt. This seems to be pretty common practice for electron apps and isn't a huge deal, except for the fact that a wrapper executable/link isn't installed anywhere else on the system. As a…
> I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. Me too, although in the case of terminal apps, they really haven't moved on since the 70s. How many support images? Completion popups? Browsable history? Current directory widget? Collapsible output? Honestly if it takes some insane over-engineering to get some actual innovation in terminal apps I'm all for it! And whe…
URxvt, XTerm, etc. do this very well, and they're also quite fast. Why would I switch to an implementation that is demonstrably worse at everything I care about, and better at things that don't matter? Do I just really hate my DRAM, and want to see it under constant max use?
I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release: * The .deb package seems to install everything in /opt. This seems to be pretty common practice for electron apps and isn't a huge deal, except for the fact that a wrapper executable/link isn't installed anywhere else on the system. As a…
Wait, what, really? Wouldn't that leave you without dependencies if you don't have internet connection at the time?
Seems a very dangerous thing to do for many, many reasons.
emphasis mine.
I have to say I'm pretty tired of this attitude that the whole world should use the anglo-centric defaults (but in case you won't we add support for you later).
Regrettably most of us developers (even those of us who live in non-english speaking counties and don't speak english natively) seem to just "settle" for the english keyboard layouts when we are developing. We tell our self that the english layout is "superior for programming". Perhaps we are correct (I doubt we are), but that is irrelevant. When we think like that we are causing accessibility problems to a huge portion of the users of our products.
What bothers me most, as an Icelandic developer who prefers my native keyboard layout, is how we shun ISO third level shifts[1]. For example, when I type TILDE (U+007E; ~), I press and hold the third level shift (remapped to ; traditionally ), press and release , and release the third level shift. Most English speaking developers use the ANSI keyboard layout[2], which historically doesn't have a notion of third level shift. Mac OS X is a terrible perpetrator by mapping the third level shift to the key, which also serves as a modifier. I never know when I type COMMERCIAL AT (U+0040; @) ( + Q) whether I will input the character or quit the program.
[1]: https://en.wikipedia.org/wiki/ISO/IEC_9995#Levels_.28.E2.80....
[2]: https://en.wikipedia.org/wiki/Keyboard_layout#/media/File:AN...
---
Edit: Formatting
Earlier quoted context omitted.
> I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. Me too, although in the case of terminal apps, they really haven't moved on since the 70s. How many support images? Completion popups? Browsable history? Current directory widget? Collapsible output? Honestly if it takes some insane over-engineering to get some actual innovation in terminal apps I'm all for it! And whe…
I really don't think it's all that much "over engineering". I mean, if you want images, history, tabs, to support every language under the sun, and support for most platforms, I'd say a browser is a fantastic way to get most of that "for free".
I’ve been using Hyper on and off for a while now. I recently returned to zsh in iTerm2 for the same reasons many others mentioned here. It _works_. I still do toy with Hyper from time to time. A feature I do like is the hotkey-enabled pane-splitting. CMD+D to open a vertical pane. CMD+SHIFT+D to open a horizontal pane. CMD+W closes them — though I wish this option would prompt as I’ve accidentally closed panes a numb…
> I’ve accidentally closed panes a number of times by a poorly-timed keystroke. PSA: In iTerm you can hit CMD+Z within a few seconds to unclose a tab or window.
