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

291–300 of 491 posts

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

#291

Post by Manishearth »

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

Made a pull request to switch it almost completely to stable. https://github.com/jwilm/alacritty/pull/131

I didn't remove the dependency on proc_macro since that stabilizes in the next release and I'm lazy (if someone else wants to try, go for it!)

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

#292

Post by dekhn »

Anderkent wrote: post #266
nopreserveroot wrote: post #207

Earlier quoted context omitted.

That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"

It's a very common company policy, because it's 'never use GPL' is a much easier rule to follow than 'only use GPL when it doesnt expose the company to risk'. Programmers aren't lawyers.

No, GPL is fine. AGPL is not.

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

#293

Post by shmel »

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?

tmux handles mouse events very well. Scrolling, pane resizing (in tmux and vim), selection work once you add one line in config. For me it works so perfectly that it successfully goes in nested tmux sessions over ssh.

However, some people complain about mouse issues. I would suspect that some terminal emulators are trying way too hard to properly handle mouse events.

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

#294

Post by dekhn »

nopreserveroot wrote: post #207
dekhn wrote: post #202

Earlier quoted context omitted.

The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.

That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"

That only addresses part of the reason for the policy. Please, you have to be aware the legal world and companies is very complicated, and smart people spend a lot of time analyzing this.

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

#296

Post by jalopy »

jalopy wrote: post #268
jwilm wrote: post #2

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

For some reason I can't run Emacs in terminal/unwindowed mode in Alacritty. Every "regular" character I type (ie to enter text into a buffer), Emacs says it's "unrecognized". Control sequences work - ie I can exit with C-x C-e. Works fine in regular Mac OS X terminal. Any suggestions appreciated. Looks like an awesome project!

Nevermind -- Turns out I was just trying to type some characters in Emacs' welcome screen, which doesn't allow that in any terminal. I was so focused on kicking the tires of Alacritty I wasn't paying attention.

Looks interseting!

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

#297

Post by wott »

netheril96 wrote: post #223
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

Well, the difference all comes down to how one views tmux, and I'm on the side of hating it. I personally use tmux only to background applications, and any of its other features are "bloat" to me.

After reading everyone praising tmux, tmux, tmux, I tried to use it several times, several days or weeks each time. The thing only got in my way all the time, to the point that now I prefer to lose sessions than to use tmux. It has to be a really important and peculiar and heavy operation, to have me still launch tmux punctually.

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

#298

Post by [deleted] »

atombender wrote: post #235
twic wrote: post #222

Earlier quoted context omitted.

That particular example of find not needing to sort persistently annoys me. sort doesn't know anything about the structure of its input, so it has to read and buffer all of it before it can sort it. find knows that its input is a tree of strings, which it could exploit to produce sorted output at the cost of buffering one directory's worth of filenames at each level of the tree. It's rarely a significant problem in p…

To avoid cluttering "find" with a sorting interface, we could use the modern technique processing push-down: If you do "blah | sort", then "sort" could ask its upstream processing node whether it supported sorting on the requisite fields, and "push down" the necessary sort-order descriptor into the "blah" step. That requires two things: That the pipe API sets up a communications channel between the two programs in a…

[deleted]

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

#300

Post by jwilm »

pera wrote: post #71
jwilm wrote: post #2

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

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 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 times slower than urxvt). This is something really important when your screen receives direct sunlight.

You could have two `colors` sections in the config file and just uncomment one or the other. Not quite as convenient I suppose. One thing I'm considering as a key-binding option is to exec a command. This could be anything like `sh swap_config.sh` and then you could bind it to whatever you like.

Post reply on HN