Great idea and I hope Alacritty continues to evolve because it should eventually be the fastest given the GPU integration. However, st is faster on my system, supports bitmap fonts like SGI screen, handles true color, works when no GPU is present, has half the LoC, and has less dependencies.
Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
381–390 of 491 posts
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#382Earlier quoted context omitted.
> because of .Xresources format? Specifically this. Without being above-average proficiency with X, the format and available options are likely to be difficult to figure out. > "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt The config file is well documented and in a human-friendly format. Most flags will also take effect immediately without restarting the program. > One featu…
> One thing I'm considering as a key-binding option is to exec a command. This would be pretty awesome. I definitely would love to have that as a feature, assuming it's not excessively difficult to implement.
You don't need to implement this in the terminal. You can bind macros to keys in anything that uses readline. Search for "inputrc" and the READLINE section in bash(1). While this is usually used for binding builtin functions (i.e. editing, history), you can simply provide the literal expansion.
# in ~/.inputrc
$if Bash
# - find this with "{KEY}"
"\e[24~": "sh \"${HOME}\"/path/to/swap_config.sh
"
# (the newline is included, which is
# usually bound to accept-line)
$endif
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#383I 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…
FWIW one of the biggest reasons I use iTerm is the hotkey window.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#384As a tmux+vim user, this hits right home for me. I never use terminal tabs and do almost everything inside tmux.
The only time during development I use a other app is when I start neovim-qt, just so I have faster rendering and squeeze even more performance out of it. If Alacritty is giving me the same speed without me having to spawn a graphical vim for it, sign me up!
I'm going to try this as my main tool for a couple of days and collect some feedback :)
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#385Earlier 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 am the one with you. If you decide to add scrollbar later, please at least make it optional.
I am using firefox with pentadactyl, and the firefox is configured as a minimal terminal like st. Basically, firefox becomes my GUI terminal. But what I want is a much lighter weight GUI terminal than firefox.
I am using three terminals, st for regular use. mlterm for its image support (sixel). and firefox for heavy-GUI needs. Alacrity seems perfect to replace st now.
Thanks for good work.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#386I 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…
Yes, "tabs and scrollback are unnecessary" seriously, must be some sort of a joke, I work all day long in a terminal and tabs are a must have.
I work all day long in a terminal and use neither.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#387I 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…
"... generally infinite willingness to accept web apps..."
Interesting.
I stay in textmode. Hence I do not need an emulator.
If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc.
My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make textual interfaces feel snappier.
But I doubt that jobs execute any faster in X11/Wayland/whatever than they do in textmode. I cannot see how the processes would be completing any sooner by virtue of using a graphics accelereted emulator.
But I could be wrong.
I sometimes use tmux for additional virtual consoles because on the computers I control (custom kernel, devices and userland) I do not use multiple ttys, just /dev/console.
I rarely ever work within tmux. I only use it to run detached jobs. I view screen output from my tty with something like
case $1 in -B|-E|-S|-t)
tmux capturep $@ --
exec tmux showb $@ --
esac
Not sure why I would ever need these slow "web apps".
I guess the third parties controlling the endpoints might be able to utilise the data they gather about users. And I am sure some users appreciate the help. Thus it is a symbiotic relationship.
I am continually making my "tooling" faster by eliminating unecessary resource consumption. It is an obsession of sorts. Constant improvement.
But given that I am working with text, graphics processing is not something I need. I would not mind being able to run my non-graphical jobs on a fast GPU, but my understanding is that the companies making these processors are not very open. For example, the GPU in the RasperryPi.
Always interesting to hear how others are meeting their computing needs.
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#388Earlier quoted context omitted.
"Integration into your products" is too narrow. For example, AGPL may mean that contractors who use company internal web services must be given access to the source code of those services. That's a frightening prospect for companies.
I meant use more in "install and use, maybe fix a few bugs", which is what I'd primarily expect for a terminal emulator. It's not the kind of software you're likely going to specially interface with your systems, unless you ship it with your own OS.
Software can be "shipped" to users in ways you may not anticipate. Even a lowly terminal emulator might find its way into a POS system, factory line, etc. (These interfaces are often shockingly primitive).
And even if not, developers might use internal code search, find what they want, and then copy and paste. The pushback on AGPL code (and GPL code even) comes from the difficulty of establishing internal policies to keep the code segregated. Much easier to have simple-to-undersatnd policies enforced at the boundaries, e.g. "no AGPL, period", instead of "AGPL code is OK for software that won't interface with our systems, as determined by either biased engineers or technically-shaky lawyers."
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#389I'm the author of Alacritty, and I'm here to answer any questions!
[deleted]
Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust
#390It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue? On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering fast…
I started up Alacritty on macOS and the improvement in responsiveness and speed is immediately obvious relative to Terminal.app. It's not like it's a huge deal, but why put up with compromised performance when you don't have to?