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

#441

Post by mrob » Sat, Jan 07, 2017, 9:21 PM UTC

jstimpfle wrote: post #425

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…

1 to 2 screen frames per key input, not 1 to 3. But I acknowledge there's a general problem with the slow screen refresh rates we have. What are people doing if they want an ergonomic FPS shooter, or a video decoder that must decode videos with arbitrary video and audio rates? Probably ignore the problem and drop a frame here and there.

It's 1 to 3 screen frames. Remember that the phase of the autorepeat is not aligned with anything. ASCII timing diagram showing one possibility:

  Key   : !___!___!___!___!__
  Term  : _!_!___!_!___!_!___
  Screen: _!_!_!_!_!_!_!_!_!_

First key is shown for 3 screen frames, second for 1, third for 2, then the cycle repeats.

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

#442

Post by vidarh » Sat, Jan 07, 2017, 9:22 PM UTC

lobster_johnson wrote: post #200

arandomcoder wrote: post #180

Earlier quoted context omitted.

I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p

> Alacritty follows the Unix philosophy of doing one thing, and doing it well. That principle is often misapplied, and I think that's true here, too. The "do one thing" about Unix is really about composability (e.g. "find" doesn't need to sort because you do "find | sort"), but you don't compose a terminal app with anything. A terminal app that has terminal features doesn't violate any principles of simplicity.

As I pointed out elsewhere, in AmigaOS you actually did often compose the terminal/console handler with other software... The reason we don't in Unix-y systems is that we've gotten used to terminals implemented as standalone applications rather than as reusable components that integrate well with other things.

In AmigaOS it was fairly common for applications to reuse the standard console handler - the same one used for the shell - to provide a custom console or even editor windows etc.. For minimal integration all it takes is to read from/write to a filehandle.

That said, though as I noted elsewhere, even AmigaOS got scrollback in the console handler by '87 - the extra code measures a few KB; it'd be more hassle than it was worth to split it out.

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

#443

Post by bezhermoso » Sat, Jan 07, 2017, 10:26 PM UTC

ehsanu1 wrote: post #276

fernandotakai wrote: post #257

Earlier quoted context omitted.

same. my tmux conf is really small (maybe 20 lines) and it does everything i want -- mouse support, vim keybinds, huge scrollback.

Are y'all on Linux/xterm or something? I've had trouble getting this to work in OSX with the default terminal. At one point I got it to partially work by installing some scary looking plugins, but it broke other mouse behavior for me (copy/paste I think).

I'm on OSX and mouse-support. vim bindings, clipboard, and extended scrollback in tmux "Just Works™" in both Terminal.app and iTerm2. The only external software that I had to install separately is reattach-to-user-namespace to get the clipboard working.

The only problem I encountered was really bad kernel panics when the tmux server exits (i.e. last session is closed), but it has been fixed as of tmux 2.1 as far as I can tell.

I'd say give it another try; the problems you were having might no longer be an issue now.

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

#444

Post by traverseda » Sun, Jan 08, 2017, 12:11 AM UTC

jwilm wrote: post #336

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…

> do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really lookin…

Is adding those features in a backwards compatible way really that important? Couldn't you just have a program send an escape code telling your term to go into "new" mode, and implement some completely different standard?

Or I suppose use terminfo, but I like the idea of dealing with text streams better.

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

#445

Post by __ddd__ » Sun, Jan 08, 2017, 1:02 AM UTC

I really, really like this so far. Interestingly, it's dependence on tmux (which I really like overall) for 'extra' terminal features presents some problems for performance and usability.

Tmux has its own non-trivial rendering bottlenecks, the most significant of which comes into play when you have multiple clients attached to a session. As a test, I went into a notes folder and did `grep -r e .`. When Alacritty was sized larger than mate's default terminal, mate's default terminal finished rendering first. When Alacritty was sized smaller than mate's terminal, Alacritty finished first. Also of note was that Alacritty running tmux rendered slower than mate's default terminal without tmux. This was an uncontrolled experiment, especially since this was a tmux session with a couple windows with a couple panes per window, on a tmux server with 2 other sessions (with a lot of vim windows etc), but something tells me the results would be the same if I used a tmux server with one session/window/pane. As a tmux user, this isn't a huge deal to me, but it should be concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable.

My biggest concern, however, is not performance related, but usability related. Consider this use case: Alacritty -> ssh into remote server -> run tmux on remote server. How am I supposed to paste anything into that remote tmux session now? Am I supposed to nest my remote tmux session in a local tmux session? That sounds awful! I've found satisfactory workarounds to the lack of copy/paste when working locally, but it falls apart when I can't rely on duplicating the tmux register to the clipboard (and vice versa) because the clipboard is remote.

If I can find a workaround to the remote paste issue, I will probably use Alacritty exclusively. Otherwise, I can't use this terminal for remote work, and I'd rather not run two different terminals just so that rendering is faster _sometimes_

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

#446

Post by jwilm » Sun, Jan 08, 2017, 2:01 AM UTC

__ddd__ wrote: post #445

I really, really like this so far. Interestingly, it's dependence on tmux (which I really like overall) for 'extra' terminal features presents some problems for performance and usability. Tmux has its own non-trivial rendering bottlenecks, the most significant of which comes into play when you have multiple clients attached to a session. As a test, I went into a notes folder and did `grep -r e .`. When Alacritty was…

I'm happy to hear you're enjoying it!

> concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable

The project initially started to be an optimized tmux renderer. It's not supposed to appeal to everybody. That said, there's a big segment of users with tiling window managers that are only blocked by not having scrollback, and we're talking about adding it. Features like tabs/splits will likely never be introduced.

> If I can find a workaround to the remote paste issue

What platform are you on that the selection copy and mouse paste isn't working? It's also possible to configure this to another keybinding if you prefer.

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

#447

Post by Godel_unicode » Sun, Jan 08, 2017, 2:33 AM UTC

hvis wrote: post #440

sjwright wrote: post #374

Earlier quoted context omitted.

You might be thinking of Lesser GPL? It should be immediately obvious why any Bigco would treat the AGPL like an exploding canister of infected blood and sharps. The AGPL treats web publishing as the same as binary distribution. If a bigco (e.g. Google) used AGPL code as part of a web service (e.g a web-based email client) there is a risk that they'd be required to comply with requests for source code. It's a pretty…

Why would you use notty's code inside a web service?

This is the mindset that lead to people not realizing the impact of shellshock. If your webservice shells out to use any other tools (imagemagick for instance) the shell is now part of your app.

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

#448

Post by i336_ » Sun, Jan 08, 2017, 2:46 AM UTC

rescbr wrote: post #423

i336_ wrote: post #400

Earlier quoted context omitted.

The Web is two things. First, it's the promise that a certain runtime with a specific minimum set of capabilities is available almost anywhere. Secondly, it's a staggeringly-huge installed base of stuff written for that runtime. I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild. The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg i…

> The alternative is storing an entire world map, or subsetted map(s) for the locations you think you'll need, but that'll kill almost all the storage on phones without massive SD cards. And that's what HERE Maps does best, without needing massive storage.

Oh okay. Would be interesting to look into the compression they use... I wonder if it's open.

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

#449

Post by alexnewman » Sun, Jan 08, 2017, 3:08 AM UTC

millstone wrote: post #375

kevin_thibedeau wrote: post #264

Earlier quoted context omitted.

You can still make modifications so long as it isn't distributed outside the company.

The problem is that "outside of the company" can be murky. What if the company outsources? What if the company hires contractors? What if the company employs an intern - does the intern now have the right to distribute the software? These are the legal landmines that BigCos want to avoid, mainly because they're questions that have not really been decided.

It is not as murky as you think. Are you referring to any particular precedent?

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

#450

Post by yakubin » Sun, Jan 08, 2017, 11:06 AM UTC

atombender wrote: post #136

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…

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

> 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 form the foundation for the kind of interactivity and statefulness provided by modern graphical UIs. If terminals were as powerful as, say, web browsers (not that I'm suggesting that anyone conflate them), the world would be a different, happier place.

I have the opposite impression. I actually anjoy time spent in my tmux + vim setup while I hate the time spent in a web browser. Web browsers seem bloated to me and I always feel like I'm forced to use the mouse too much while using them. I've heard about vimperator, but every time I've tried it seemed poorly integrated (the authors did an incredible job nonetheless).

The only drawback of delegating scrolling to tmux that I see is that my experience running tmux locally and using ssh to use a remote machine with another (remote) tmux session wasn't great. Keyboard shortcuts were usually caught by the local machine and not by the remote one. So I just don't run tmux locally when I want to ssh into a remote machine. Problem solved more or less.