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

51–60 of 491 posts

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

#51

Post by eridius »

sanderjd wrote: post #42
swsieber wrote: post #32

Earlier quoted context omitted.

They suggest passing that duty off to tmux. Kinda makes sense I guess... though I'd love to have it.

Does tmux interpret mouse scroll events, or is it only keyboard-based?

It does, but it's not completely reliable for me. Also, you have to configure it to make it actually work.

For example, here's my mouse-related tmux config:

  set -g mouse on
  # enter copy-mode by scrolling, but don't select the pane
  # The usage of #{mouse_any_flag} just forwards mouse events when in a fullscreen app that wants them
  bind -n WheelUpPane if -F -t = "#{mouse_any_flag}" "send-keys -M -t =" "if -F -t = '#{alternate_on}' 'send-keys -t = Up' \"if -F -t = '#{pane_in_mode}' '' 'copy-mode -e -t ='; send-keys -M -t =\""
  bind -n WheelDownPane if -F -t = "#{alternate_on}" "send-keys -t = Down" "send-keys -M -t ="
  
  # Start copy-mode with PageUp
  # For PageDown, if we're not in copy-mode, discard it
  bind -n PageUp if -F "#{alternate_on}" "send-keys PageUp" "copy-mode -eu"
  bind -n PageDown if -F "#{alternate_on}" "send-keys PageDown" "if -F '#{pane_in_mode}' 'send-keys PageDown'"

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

#52

Post by brandur »

Florin_Andrei wrote: post #25
jwilm wrote: post #2

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

> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?

Just to present an alternate opinion here: I haven't used my terminal's scrollback on purpose in 5+ years now, and it's fine. To me, Alacritty's trade off is perfectly acceptable, and even desirable.

As far as I can tell, using Tmux's scrollback instead has no downsides of note, but some _very_ significant upsides. For example, (1) shared buffer between terminal windows, and (2) copy/paste modes that are usable with Vim shortcuts.

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

#53

Post by steveklabnik »

llimllib wrote: post #35

> Make sure you have the right Rust compiler installed. Alacritty is currently pinned to a certain Rust nightly Ok, I'll... um not do that. Hope you publish a build soon though! edit: more seriously, the nightly compiler situation on rust is going to become a problem as it gets more developer use. I really hope they're able to stabilize it. edit 2: I'm really sorry if I derailed the conversation in a not useful way,…

Looking at the code, it looks like this basically only relies on two things: inclusive ranges, and clippy. But you don't have to use clippy this way; it's just one way of doing it. So it's really one feature. EDIT: Oh oops, and custom derive, which is stable in a month.

> I really hope they're able to stabilize it

In general, "nightly" is never going to be stabilized. Remember, it's how Rust development works. Some people will always want to be on the cutting edge. I elaborated here: https://news.ycombinator.com/item?id=13277438

Also, nightly-only is less of a deal here, since this is mostly an application, not a library. End-users won't need to worry about having Rust at all.

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

#54

Post by valarauca1 »

vvanders wrote: post #43
jwilm wrote: post #26

Earlier quoted context omitted.

Glyphs are rasterized once and stored in a texture atlas. When rendering a glyph, the fragment shader pulls from that texture. Once loaded, the glyph stays loaded for the duration of the program.

Got it, just a heads-ups that texture atlas tends to hammer your GPU texture upload if you want to support UTF or non-latin(esp glyph-based) character sets. Not trying to be discouraging just something to keep in mind if that's a direction you want to go. Pretty excited to see a GPU + Rust based stuff making it out into the wild.

Question:

With a modern discrete GPU card wouldn't the texture atlas just end up in it's VRAM as cards these days commonly have >1GB of VRAM?

(Sorry if this is a stupid question, still trying to grok opengl)

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

#55

Post by Bedon292 »

jwilm wrote: post #2

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

Might be a bit early, but will the Windows support be good for Bash on Ubuntu on Windows? Right now I use xming and run xterm inside it, but that is not a perfect solution, especially for things like vim. It works for now, but I am definitely looking for a good alternative.

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

#56

Post by eridius »

GrinningFool wrote: post #31
dom0 wrote: post #24

Earlier quoted context omitted.

I've done that (we all did), but "can't reproduce". So this seems to depend a lot on the emulator, eg. I'm using Konsole, which is superb, and don't see that problem there.

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.

Terminal.app seems to handle this case just fine as well.

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

#57

Post by steveklabnik »

ahoka wrote: post #13
jwilm wrote: post #2

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

Not really a question, but a request. Given you have a Travis CI setup, could you make binary snapshots available?

Incidentally, this is _very easy_ to do with Rust: https://github.com/japaric/trust

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

#58

Post by frozenport »

mrec wrote: post #21
frozenport wrote: post #10

Earlier quoted context omitted.

On Windows "std::cout" can take upwards of 3ms. I noticed this when writing high speed camera software that was supposed to hit my callback every 2ms. Instead it was limited by my print statement! Does this emulator solve my problem?

3ms sounds pretty dire, if you weren't writing very much. Out of curiosity, was this with or without `std::ios::sync_with_stdio(false);` ? I've found syncing makes a huge difference to IO perf in Windows, e.g. `_getc_nolock` is much faster than `getc`. (Assuming of course that you can get away with it.)

That's what I thought, but then I measured.

These have little effect, also omitting std::endl has little effect. The effect is somewhat mitigated by buffering, so that if the time between subsequent st::couts is large, you won't see the runtime overhead.

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

#60

Post by jwilm »

ekidd wrote: post #46
jwilm wrote: post #2

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

I just wanted to say that this looks like a fantastic and very cool project! Congratulations on the speed. Personally, the lack of scrollback and tabs is a dealbreaker for me. I know that I'm supposed to use tmux for that, but I can never remember how tmux scrollback and tab switching work without thinking about them. Plus I rely heavily on mouse selection of multi-screen text in the scrollback buffer. So I'm unlikel…

> Personally, the lack of scrollback and tabs is a dealbreaker for me

Completely understandable. This decision was expected to be polarizing.

> Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux.

Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.

Post reply on HN