451–460 of 491 posts
Earlier quoted context omitted.
Why would you use notty's code inside a web service?
This is the mindset that lead to people not realizing the impact of shellshock. If your webservice shells out to use any other tools (imagemagick for instance) the shell is now part of your app.
Earlier quoted context omitted.
> Adding tmux just to get scrollback goes against Unix philosophy. There are also simpler tools which can provide scrollback support. The whole Unix tty subsystem goes against the "Unix philosophy", that is why it was completely scraped in Plan 9.
Could you give me some reading to do? I had never heard of this before.
1.) A UI which is just a line/text field to enter commands. Something like the command prompt but which fuzzy matches commands like the mini-buffer in emacs or the omni text field in Chrome or Firefox or even Enso from a few years back.
2.) Each command is name spaced to an "agent" to avoid command collisions. For example agent 'jarvis' would have a set of commands it response to like jarvis/foo, jarvis/bar or jarvis/baz.
3.) The output of each command is a list of 0..N items/objects rendered in a master/detail view where navigation over the list shows a detailed view of each object/item in the list.
4.) An item/object can be anything from an email, rss entry, web page, graphic, tweet, contents from a text file. Basically anything that is renderable.
5.) The output of any command can be piped to any other command which is able to parse the list of items/objects from the prior command and render its own new list.
This UI paradigm seems to cover an incredibly large set of use cases. The only use cases I can think of which are not covered are those where the keyboard input device is not sufficient; such things as graphics manipulation where a mouse or pen & tablet are needed.
The frustrating thing for me has been to witness the vast number of systems over the years that have nibbled at the edges of this paradigm but have not gone all the way. What I'm talking about mostly here are the numerous launcher systems like Enso or Quick Silver or dMenu. All these systems have UIs very similar to what I'm talking about but they're restricted to launching existing apps and controlling the options exposed in menus of existing apps.
The other class of applications I've seen that come close are the ones like that mentioned in this topic. Applications like notty where the effort is spent trying to shoehorn extra rendering capabilities into a terminal emulator.
What I want is essentially a Grand Unified User Interface (GUUI) such that applications as we know them are done away with and we only deal with commands and output.
A system where I can type web/news.ycombinator.com and a one item list comes back with that first item selected by default in the details view. And that item is the front page of Hacker News. Then I could next type email/inbox and a list of emails in my inbox are rendered. And of course while viewing one of the items in my email/inbox I could type email/reply which would render a text area to reply to my previously selected email.
As I said earlier, the use cases seem endless and this paradigm seems like it would be incredibly efficient for those who can type well.
find ~
iTerm2 1m20s
alacritty 47s
iTerm 130% (peak up to 140%)
alacritty 25% (peak up to 29%)
Earlier quoted context omitted.
Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.
Ok, so you're interactively using a program on a remote server and you don't want it to die if you lose your connection? Screen isn't a hack in that case :) Although you could ditch it and use MOSH instead.
To me, it's a deficiency in the lack of session management for SSH. All that SSH gives me is a two-way pipe to the other server's I/O. That's simple and elegant, but why does it create a new pipe every time? It's connection-oriented, which is a concept that hasn't seen any innovation since the 1970s.
My preferred innovation here would be a local shell that had remote access. Rather than pipe I/O to the remote shell, give me a local shell which happens to execute its verbs on the remote machine, and let the remote file system simply be a volume. All my session state (including command history) can be local, there's no need to keep that on the remote host. A remote host is just another context.
I believe Plan 9 tried something similar, but very few people have picked up on its innovations.
Earlier quoted context omitted.
Konsole is the only emulator I've used (other than actual tty) that doesn't have this problem. It's actually been frustrating, becasue there is plenty about it that I don't like. I'll be giving Alacritty a try shortly - if it does what it says on the tin, it's exactly what I've been looking for.
Curious: What don't you like about Konsole?
Beyond that, it has a ton of features - none of which I use since I manage my sessions with tmux. So I guess it's mostly a matter of not wanting a sledgehammer when the right tool is a finishing hammer?
Earlier quoted context omitted.
Thank you for the thoughtful comment. There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider. I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to…
I'd be very happy if you more closely integrated with tmux and used the features from tmux instead transparently. I don't care how the terminal does scrollback, as long as it does. If you forwarded the scrolling commands to tmux then great. Same thing with tabs, panes etc. As much as I like tmux (although I exclusively use it via byobu), the single most annoying thing is that it won't let different viewers see differ…
> Using vim inside tmux in many terminals was a particularly bad experience. None of them were ever quite fast enough. When does this slowness show itself?
If you have four large files open in Vim tabs, it can be quite slow. If you print out a large text file or script output with cat or less, it can be slow as well. This is on a 1.8ghz i5 machine running Linux. I can already notice the speed of Alacritty. We'll see how it performs in the next few months for me.
I really, really like this so far. Interestingly, it's dependence on tmux (which I really like overall) for 'extra' terminal features presents some problems for performance and usability. Tmux has its own non-trivial rendering bottlenecks, the most significant of which comes into play when you have multiple clients attached to a session. As a test, I went into a notes folder and did `grep -r e .`. When Alacritty was…
I'm happy to hear you're enjoying it! > concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable The project initially started to be an optimized tmux renderer. It's not supposed to appeal to everybody. That said, there's a big segment of users with tiling window managers that are only blocked by not having scrollback, and we're talking about adding it. Features like tabs/splits will like…
> Features like tabs/splits will likely never be introduced.
I wholeheartedly support this. Count me among those that like the idea of an "optimized tmux renderer".