Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

blog.jwilm.io

Post reply on HN
Print view View original

361–370 of 491 posts

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#361

Post by stormbrew »

jwilm wrote: post #160
atombender wrote: post #136

Earlier quoted context omitted.

> Features like ... are better provided by a terminal multiplexer I would strongly argue that this thinking is putting the cart before the horse. I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to fo…

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 use tmux a lot, but I don't use it for every session. To me, forcing me to use tmux to get scrollback is precisely violating the idea of 'one tool doing one thing'. You're forcing me to compose a Swiss army knife (tmux) into situations where all I need is a knife (a terminal that works well with the idioms of my environment).

I don't need tabs (I use i3wm), I don't need splits or session management (when I need that I use tmux). But I do often need to scroll back on a temporary session when I didn't plan for it in advance. I open a lot of terminals. They're never all going to be tmuxed.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#362

Post by barrkel »

jwilm wrote: post #160
atombender wrote: post #136

Earlier quoted context omitted.

> Features like ... are better provided by a terminal multiplexer I would strongly argue that this thinking is putting the cart before the horse. I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to fo…

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…

Scroll back is the only feature missing that would block me, assuming you permit changing the colour mappings.

I generally run five or six desktop terminals, only one of which is running screen locally. I more normally run something like screen to get persistence across suspends on an SSH connection. I usually don't do much side by side stuff in terminal so tmux isn't a big win for me. Also tmux didn't run on cygwin for the longest time, and I expect the same experience on all my platforms.

However the big tmux users in my life would still use it as is.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#364

Post by steveklabnik »

conradk wrote: post #363

Not sure why they rebuilt a clipboard library when "clipboard" exists (I think it might even be used within Servo, not sure): https://crates.io/crates/clipboard

> A non-GPL licensed cross-platform clipboard library,

(That is, that project is GPL licensed, and they didn't want that)

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#365

Post by ori_b »

atombender wrote: post #235
twic wrote: post #222

Earlier quoted context omitted.

That particular example of find not needing to sort persistently annoys me. sort doesn't know anything about the structure of its input, so it has to read and buffer all of it before it can sort it. find knows that its input is a tree of strings, which it could exploit to produce sorted output at the cost of buffering one directory's worth of filenames at each level of the tree. It's rarely a significant problem in p…

To avoid cluttering "find" with a sorting interface, we could use the modern technique processing push-down: If you do "blah | sort", then "sort" could ask its upstream processing node whether it supported sorting on the requisite fields, and "push down" the necessary sort-order descriptor into the "blah" step. That requires two things: That the pipe API sets up a communications channel between the two programs in a…

I certainly wouldn't want to implement psql if it neededs to handle all that extra communication.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#366

Post by ori_b »

kibwen wrote: post #285
netheril96 wrote: post #223

Earlier quoted context omitted.

Well, the difference all comes down to how one views tmux, and I'm on the side of hating it. I personally use tmux only to background applications, and any of its other features are "bloat" to me.

I've honestly never seen anything but love for tmux, can you explain why you hate it?

Personally, I don't hate it. It just doesn't do anything for me -- I can just open a new terminal if I want another split.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#367

Post by [deleted] »

sliken wrote: post #341
brandur wrote: post #80

I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the boun…

I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.

[deleted]

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#368

Post by bootload »

sliken wrote: post #341
brandur wrote: post #80

I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the boun…

I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.

"Not nearly as functional as the original xterm from the early 90s.:"

Early Alpha concentrates on stability before bells and whistles. Agree though scroll bars would be nice but patience.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#370

Post by therein »

glandium wrote: post #192
WhatIsDukkha wrote: post #95

I really disagree with the authors definition of minimal. Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have. I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know…

Moreover, tmux does its own output parsing, so when you do your `cat 1gb_file.txt` inside tmux inside a terminal, you have two layers of output parsing happening. I can't see how that doesn't impact the performance that is claimed for Alacritty. But perhaps tmux is really fast. I wouldn't trust a third party application to be part of the performance experience I'm claiming for my own application, though.

Couldn't you say that about SSH? If your application is taking forever reading from the stdout buffer, your application will block when it is trying to write to stdout with say, printf, or fprintf.
Post reply on HN