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

Post by lilyball » Fri, Jan 06, 2017, 8:04 PM UTC

fiddlerwoaroof wrote: post #85

eridius wrote: post #50

Earlier quoted context omitted.

The problem with this is using tmux screws with using mouse for selection (since tmux takes over the mouse and does its own selection thing, which usually doesn't do what I want). This approach also means you can't do anything interesting like what Terminal.app does with detecting prompts, marking them, and letting you jump back to them (or clear history back to them). This approach could be excused if the terminal a…

I just disable tmux's mouse usage by putting "bind m set -g mouse off" into my tmux.conf: tmux is useful enough just with key shortcuts, and I generally dislike terminal programs that use the mouse anyways. Also, some terminal emulators (iTerm2 on Mac) let you disable mouse grabbing by holding a special key while clicking, maybe Alacritty could implement something like this?

Post by brandur » Fri, Jan 06, 2017, 8:07 PM UTC

Florin_Andrei wrote: post #110

brandur wrote: post #52

Earlier quoted context omitted.

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…

Hm. So, for that to work, I'd basically have to forever hardcode the terminal to launch tmux every single time. Basically, this new terminal + tmux = the old terminal behavior. I'm not saying this is necessarily a bad thing (haven't tried it), I'm just saying this is the way to get my scrollback... uh... back. Might as well ship the terminal with tmux as a hard dependency and launch a tmux child process by default.

Post by ninjakeyboard » Fri, Jan 06, 2017, 8:09 PM UTC

Post by Yoric » Fri, Jan 06, 2017, 8:10 PM UTC

brandur wrote: post #114

wang_li wrote: post #102

Earlier quoted context omitted.

You do seem overly excited. :) Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.

> You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating syste…

Post by j1f4 » Fri, Jan 06, 2017, 8:22 PM UTC

llimllib wrote: post #65

steveklabnik wrote: post #53

Earlier quoted context omitted.

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

My feeling is that having a lot of people running on different rust versions is likely to raise the bar to contribute to the project; for example if I go to hack on a python project the odds that I have to change my interpreter setup are basically zero. In this specific example, I saw that building the project required mucking with my rust version/setup and decided that the cost of that was too high for me to proceed…

    rustup override set $(cat rustc-version)