151–160 of 491 posts
Earlier quoted context omitted.
Very cool, how are you handling glyphs? Do you have an LRU font cache or something simpler?
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.
can it handle zalgo?
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 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…
tmux does provide full scrollback with mousewheel support too. # Enable mouse support including scrolling set -g mouse on # Versions prior to 2.1 may want this too: set -g mouse-utf8 on history-limit 5000 # 5000 lines of history per pane. Adjust as needed.
Also, scrolling is somewhat unreliable, although I still haven't figured out why.
In any case, I use tmux in some of my terminal tabs, and very frequently I have to hit ⌘R to disable terminal mouse support just so I can select & copy something without tmux interfering (I could also hold down the Fn key, except I use an external Das Keyboard, and the Das Keyboard folks still haven't figured out that their Fn key should actually behave like Apple's Fn key and let the system know when it's pressed by itself, as opposed to what it does now which is simply modifying the keypress events for other keys without sending any independent event for the Fn key).
Earlier quoted context omitted.
> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?
I guess the idea of no scrollback is taken from st [0]. [0] http://st.suckless.org/
> 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,…
Rustup automates this process so much that it costs you nothing to compile from a specific nightly release without compromising your existing configuration. I downloaded the nightly within a minute, and I compiled a release within 125 seconds. Immediately after I changed back to stable. It took two cli commands to swap between. NPM couldn't get all my packages for my React crud app that quickly. One thing that Rust r…
Earlier quoted context omitted.
tmux does provide full scrollback with mousewheel support too. # Enable mouse support including scrolling set -g mouse on # Versions prior to 2.1 may want this too: set -g mouse-utf8 on history-limit 5000 # 5000 lines of history per pane. Adjust as needed.
It's not as good as native scrollback though. For example, by default, as soon as you select something in tmux, the selection goes away, and you have to hit a tmux-specific keybinding to paste it back into the terminal. That's never what I want! If I'm selecting something it's probably because I'm going to copy it to my system keyboard. I think you can disable this part, except of course what you're left with at that…
I'm the author of Alacritty, and I'm here to answer any questions!
cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. can you really read at ~10mbps?
Just a few weeks ago I accidentally ran a command on a remote machine that generated so much spew in the few seconds it ran before I hit control-c that it took 5 minutes to scroll through before I could do anything else.
But yes, you probably want to avoid that much text spew even if your terminal is super fast.
Earlier quoted context omitted.
It is a little unfortunate, but Rust isn't blind to the problem. The community is converging on everyone using rustup (e.g. as of a few weeks ago, the install page recommends it https://www.rust-lang.org/en-US/install.html ) because it makes managing things like cross compilation[0] and upgrading stable compilers much easier. It also makes working with pinned compiler versions smoother: run `rustup override set night…
While it's nice that they want to converge on rustup, I greatly prefer using my distro-provided compiler in almost all cases. Right now that is rustc 1.14, which means that that alacritty is currently beyond my compilation capability. I don't think this is nearly as bad as the grandparent suggested though. The language is young, I'd prefer experimental features remain in the experimental branch rather than get bad de…
On another front, Rust is working hard to get people off of nightly. This project, for example, uses 3 unstable features. Clippy can already work on stable (edit: code that is linted with Clippy can also build on stable in some setups), Custom Derive will be stable in less than a month, and inclusive ranges is a pretty minor feature.
I would expect this project to begin working on stable for Rust 1.15, but I'm not affiliated with it directly, that's just my guess.
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…
There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider.
I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to add support, it could be designed as a build feature and be removed completely if it were undesired.