Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust • Hacker News Board

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

#351

Post by stuckagain » Sat, Jan 07, 2017, 3:55 AM UTC

chadcmulligan wrote: post #337

stuckagain wrote: post #270

Earlier quoted context omitted.

That's not what I said. What I said was that terminal was unbelievably fast. Especially for backwards scrolling which is an important use case to me.

I was just having a little joke, apologies if it came off as a criticism. It seems very strange to me that people are still talking about speeds of terminals, but not my field (any more) fortunately. One of the first things I wrote was a terminal emulator using telnet to run on PC-DOS using a port of curses to connect to our Sun 3's. To think in 2017 people are still concerned about terminals is very surprising to me…

The problem is the terminals have been getting monotonically slower over the last 20 years, whereas the amount of build spew I need to grope around in to find the relevant error has not decreased :-/

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

#352

Post by saghm » Sat, Jan 07, 2017, 4:09 AM UTC

mrob wrote: post #339

jstimpfle wrote: post #334

Earlier quoted context omitted.

keyboard autorepeat doesn't have anything to do with the terminal emulator (or I would be surprised). There's an X11 setting, try "xset r rate ", e.g. "xset r rate 170 30".

The timing of the input itself doesn't vary, but the timing of the visual feedback does. I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting). If the terminal is displaying at 40fps then some separate inputs will be merged and displayed at the same time. And if you like 30Hz autorepeat, instead of co…

> I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting).

I thought I was the only one who turned the key repeat way up and then navigated things by moving one line/character at a time really fast! I've always felt a bit guilty about this due to feeling like I'm just too lazy to get used to using more typical navigation, but "preferring lower cognitive load" sounds like a more more positive spin on it.

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

#353

Post by ericbb » Sat, Jan 07, 2017, 4:12 AM UTC

jwilm wrote: post #6

h4nkoslo wrote: post #3

Earlier quoted context omitted.

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 performance is fine at smaller sizes and with less going on. In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty. Alacritty is about having tools that do…

With the C-c issue specifically, I don't think that emulator throughput is the most likely culprit.

It could be that the emulator is not handling inputs fairly: maybe it tries to process all available input from the pseudoterminal before processing the next batch of keyboard input. Or it could be that the pseudoterminal (kernel driver) is not configured to send the signal as expected. Or it could be that the process you're trying to interrupt is not responsive to the signal.

I maintain a terminal emulator that is not optimized at all and I just tested interrupting a process that was dumping one gigabyte of text to the screen. The interrupt was handled instantaneously.

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

#354

Post by saghm » Sat, Jan 07, 2017, 4:21 AM UTC

jwilm wrote: post #300

pera wrote: post #71

Earlier quoted context omitted.

Hey, nice project :) I do have a question: you mentioned that urxvt is difficult to configure (because of .Xresources format?), but then you also say that "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt? One feature that I really miss in rxvt is an easy/fast way to change the color scheme, or at least reverse colors (like with xterm, which if correctly configured it's just ~3 t…

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

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

#355

Post by Bromskloss » Sat, Jan 07, 2017, 4:27 AM UTC

> 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?

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

#356

Post by valarauca1 » Sat, Jan 07, 2017, 4:29 AM UTC

rsync wrote: post #345

jwilm wrote: post #2

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

"I'm the author of Alacritty, and I'm here to answer any questions!" I don't know whether to throw money at you or tell you to get off my lawn. For now I will wish you a very happy new year and you can have a free rsync.net account if you want. BUT I RESERVE THE RIGHT to shoo you from my lawn once I figure out what is going on here. With your GPU accelerated terminal emulator? Christ.

>>With your GPU accelerated terminal emulator? Christ.

Kids these days with their Rock and Roll music and their 144FPS terminal emulators.

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

#357

Post by barrkel » Sat, Jan 07, 2017, 4:30 AM UTC

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.

I generally use rxvt because xterm is too slow. It doesn't have menus or URL highlighting and scrollbars are nonfunctional in the presence of screen, tmux, Emacs or generally any interesting terminal app.

On Windows I use mintty and I turn off scrollbars there. I simply don't use the mouse to interact with the terminal other than to select text, and that's with selection buffer to copy.

Speed is highly relevant to me. Most modern terminal emulators are very slow, most noticeable when you get a lot of output in a panel in something like tmux.

(Simplistic benchmarks that test full screen scrolling usually hand the crown to terminals that don't bother to refresh the screen with everything output, but that's not the only bit of a terminal emulator that can be slow.)

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

#358

Post by chadcmulligan » Sat, Jan 07, 2017, 4:34 AM UTC

stuckagain wrote: post #351

chadcmulligan wrote: post #337

Earlier quoted context omitted.

I was just having a little joke, apologies if it came off as a criticism. It seems very strange to me that people are still talking about speeds of terminals, but not my field (any more) fortunately. One of the first things I wrote was a terminal emulator using telnet to run on PC-DOS using a port of curses to connect to our Sun 3's. To think in 2017 people are still concerned about terminals is very surprising to me…

The problem is the terminals have been getting monotonically slower over the last 20 years, whereas the amount of build spew I need to grope around in to find the relevant error has not decreased :-/

yeah, I use ide's (Xcode/Appcode/VS/Delphi) for all my work so not really an issue. I can see if you're stuck with command line compilers though it would be annoying. I would hate to go back to make files and command lines ugh!

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

#359

Post by aoeu345 » Sat, Jan 07, 2017, 4:39 AM UTC

Bromskloss wrote: post #355

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

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

#360

Post by rsync » Sat, Jan 07, 2017, 4:40 AM UTC

saghm wrote: post #352

mrob wrote: post #339

Earlier quoted context omitted.

The timing of the input itself doesn't vary, but the timing of the visual feedback does. I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting). If the terminal is displaying at 40fps then some separate inputs will be merged and displayed at the same time. And if you like 30Hz autorepeat, instead of co…

> I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting). I thought I was the only one who turned the key repeat way up and then navigated things by moving one line/character at a time really fast ! I've always felt a bit guilty about this due to feeling like I'm just too lazy to get used to using more…

I have slowly, over the course of 20 years moved to holding down movement keys to trying (and not always succeeding) to remember to use forward and backward search to jump around to the string I am moving to.

I think it's the "right thing to do" but it's hard to not just hold down 'k' ...