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

91–100 of 491 posts

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

#91

Post by fiddlerwoaroof »

eridius wrote: post #62
steeve wrote: post #4

I love iTerm3, but the speed compared to Terminal.app sometimes makes me jealous. So I guess we all need a faster term emulator :)

Out of curiosity, why do you love iTerm? It's always struck me as kind of ugly (especially its preferences). And AFAIK, the only real feature it has that Terminal.app doesn't (besides the native tmux integration, because I still don't really see the point) is support for apps customizing the 256-color palette on the fly (e.g. the initc capability), and wile I really would like to see Terminal.app gain support for tha…

The coolest feature of recent versions of iTerm is the "Selection respects soft boundaries" feature: with it on, iTerm will detect vim/tmux splits and constrain the selection to just one side of that split. For my workflow, at least, it makes a huge difference.

Also, if you start tmux as "tmux -CC" iTerm will open the tmux session in a new window, with GUI tabs for tmux tabs and GUI splits for tmux splits.

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

#92

Post by dragonne »

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…

Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating.

[1]: https://github.com/withoutboats/notty

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

#93

Post by loeg »

sanderjd wrote: post #38
tetraodonpuffer wrote: post #27

Earlier quoted context omitted.

the use case seems to be using tmux inside the terminal emulator, with tmux you'd use its own scrollback buffer (edit) from the project's github page in fact The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as tmux.

Interesting - maybe this (or someone else) could skip the middle-man and just be a cross-platform tmux gui, instead of a terminal emulator.

Not really. After all, the applications inside tmux are ordinary terminal programs that need terminal emulation.

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

#94

Post by loeg »

h4nkoslo wrote: post #3
jwilm wrote: post #2

I'm the author of Alacritty, and I'm here to answer any questions!

Cool project, but I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. What applications benefit from a terminal that's even an order of magnitude faster than the alternative?

Terminal speed is the primary reason I (and some others) use 'terminology', which is a relatively quick terminal emulator out of the enlightenment project.

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

#95

Post by WhatIsDukkha »

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 these days.

I need tabs. At any given time many of those tabs might have instances of tmux somewhere in their multiply nested depths, generally on remote hosts.

I'm not going to start tmux on every local prompt just so I can use Alacritty and thus intentionally starting a tmux in tmux funshow.

I use "Monitor for Silence" "Monitor for Activity" pretty consistently.

It's free software so I glad the author is making something and hopefully enjoying the process. I can't really use this or consider it until he reconsiders. Maybe he'll get some collaborators that will argue him around on this.

Cool project otherwise.

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

#99

Post by brandur »

dragonne wrote: post #92
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…

Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating. [1]: https://github.com/withoutboats/notty

That's really cool and their README gives some great background. Thanks!

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

#100

Post by tatterdemalion »

Manishearth wrote: post #14
jwilm wrote: post #11

Earlier quoted context omitted.

Nope. The idea is that perf should be good enough that it's not necessary. withoutboats and I are hopefully going to collaborate and add notty protocol support to Alacritty. This should make text splits as performant as GUI splits.

My issue with tmux splits is not that it's not fast, it's that GUI stuff like scrolling / selection / etc don't integrate as smoothly.

I (withoutboats) agree. The real problem in terminals is that this goes both ways - if you let tmux or just vim/emacs split the window, you get no GUI integration - but you use the GUI to split the terminal window, you now have two disconnected shell sections, so none of the CLI integration works.

The notty screen splitting protocol should support a "GUI" interface shared by a single process, solving this problem.

Post reply on HN