Hacker News new | comments | show | ask | jobs | submit login
Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust (jwilm.io)
1170 points by jwilm on Jan 6, 2017 | hide | past | web | favorite | 476 comments



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 bounds of an intriguing ecosystem.

As someone who is especially concerned about the performance of my tooling these days due to what seems to be a generally infinite willingness to accept web apps that are slower than desktop apps from decades ago, and which seem to continually demand more resources year over year, I really appreciate that such a distinguishing eye has been given to Alacritty's speed and resource usage. Some contemporary alternatives like Electron-based terminals are academically interesting, but are programs I'd never want to use due to the huge step backwards in these areas.

One question: do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? e.g. Displaying images, richer interfaces that don't depend on ASCII bar characters, graphs, properly tabulated results, etc. This is a direction that I wish we were going, but it's not clear to me how to get there without many sacrifices.


> 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 looking forward to see where it goes!

[0]: https://github.com/withoutboats/notty [1]: https://github.com/jwilm/alacritty/issues/51


As long as we're talking about terminals:

1) TERM is broken: https://www.facebook.com/notes/daniel-colascione/term-is-ter...

2) We need to start adding capabilities to terminfo again --- see the incredible mess in bracketed paste support, true color support, etc.

3) TIOCSTI is a giant truck-sized security hole. We need to stop supporting it.


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.


> Or I suppose use terminfo

What do you think terminfo does?!


Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating.

[1]: https://github.com/withoutboats/notty


notty author here. notty is basically way down a yakstack for me - I wanted better CLI/TUI tools, so I wanted to write a framework for writing CLI/TUI tools, but some of the features I wanted aren't supported by terminals, so I started writing a new terminal. But I don't know anything about graphics programming & this is really far away from what I actually wanted to be doing - so when jwilm showed me alacritty & mentioned implementing notty with it I was pretty stoked.


That's really cool and their README gives some great background. Thanks!


It's too bad notty is licenced under the AGPL. That basically guarantees 0 usage at any sort of bigco.


That is not how Copyleft software licenses work at all. All the AGPL gurantees is that 'Bigco' must contribute back to the community any modifications they make to the software.


Exactly! How many bigco's have a terminal emulator incorporated into a product? If you're just using this to run tmux, vim, etc. the AGPL's strengthened sharing provisions aren't going to affect you at all :-)


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's company policy

Yes.

I was just pointing out that regardless of modification/distribution/whatever, bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company.

The author(s) are free to use AGPL, but there are significant downsides if they care about adoption.


They care about the freedom of software users, not weird corporate policies.

Non-adoption by non-respecters of freedom isn't a downside.


These aren't "weird corporate policies", they're very sensible. If they wish to use such software they need to be very careful in how, and track its use, and they just don't think having such a framework is worth it.

See https://news.ycombinator.com/item?id=13342657 , https://news.ycombinator.com/item?id=13342804


It's a downside if it leads to general non-adoption, either directly or because a competitor with a different license gets the market share.

I'm all for the moral stance, but moral purity in a vacuum is essentially irrelevant. Effective morality is about impact on the world. A morality that's only about the good feelings of the purist is sterile self-indulgence.


Precisely. And even RMS has been known to agree with that principle.

http://lwn.net/2001/0301/a/rms-ov-license.php3


> bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company."

Wait, that seems extremely paranoid, even if only meant figuratively... Can you explain the thinking on restricting the use of AGPL'd licensed applications?


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.


Why?


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 scary license. I wouldn't touch it... and I run a teeny tiny little speck of a website by comparison.

https://en.wikipedia.org/wiki/Affero_General_Public_License


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.


A shell could conceivably be used in a webapp's backend, but a terminal emulator is a lot less likely.


Which then begs the question why the author chose AGPL over regular GPL, if it's unlikely to ever apply in practice. What was the author worried about?

Meanwhile, it's much easier for a BigCo to have a blanket policy for a license which has incredibly high theoretical dangers and little clarity around its scope. And I don't blame them.


Is that true? My understanding of the AGPL was that any software product which uses it as a component becomes subject to the AGPL - it has the linking semantics of the GPL, not the LGPL. If that's not the case, please do disabuse me of my misconception!


Yes, it is like the GPL. But in this case, where the product is a standalone application, that distinction shouldn't matter unless you're actually planning on bundling it into your own product somehow.


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?


There are pretty simple As to these Q's. c


I think your understanding of the AGPL (specfically) is in error.


See EDIT2 on my post.


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.


While licenses are not simple, AGPL is specifically meant to "counter" closed source services based on AGPL code.

So unless you want to offer Alacritty-as-a-Service, you should be just fine with the license.


There's a big difference between "should be fine" and "will be fine". When the stakes are small, the former can be enough. But as the stakes get larger, people favor the latter.

At a large company, the stakes get large in two ways. One is that all the numbers are just larger. But more important is that an individual decision maker's career success can become dependent on a relatively small number of things. E.g., if a lawyer approves a license that should be fine but actually isn't, that could substantially harm career prospects. It still may be a small problem overall for a major company, but if it means somebody gets fired, those are pretty big stakes.


Use or integration into your products?


"Integration into your products" is too narrow. For example, AGPL may mean that contractors who use company internal web services must be given access to the source code of those services. That's a frightening prospect for companies.


I meant use more in "install and use, maybe fix a few bugs", which is what I'd primarily expect for a terminal emulator. It's not the kind of software you're likely going to specially interface with your systems, unless you ship it with your own OS.


Software can be "shipped" to users in ways you may not anticipate. Even a lowly terminal emulator might find its way into a POS system, factory line, etc. (These interfaces are often shockingly primitive).

And even if not, developers might use internal code search, find what they want, and then copy and paste. The pushback on AGPL code (and GPL code even) comes from the difficulty of establishing internal policies to keep the code segregated. Much easier to have simple-to-undersatnd policies enforced at the boundaries, e.g. "no AGPL, period", instead of "AGPL code is OK for software that won't interface with our systems, as determined by either biased engineers or technically-shaky lawyers."


That may be the theory, the practice is that the policy of many companies with regard to integrating *GPL code is "not with a ten-foot stick".


I think you make a good point in this instance, so I upvoted. The follow-on discussion establishes the policy of big-cos pretty well and I don't think Alacritty much benefits from the AGPL since actual integration into other software base is unlikely (except for some of the sub-libs perhaps, but personally I feel that fundamental libraries flourish better under less-restrictive licenses anyway)


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 systems, our security software (OpenSSL, NaCL, OpenSSH), and if you're a developer, things like our databases. Although I can ostensibly write C and C++, I still don't contribute to these projects because oftentimes a whole new set of local conventions around build tools and utility libraries needs to be learned for every project, and there's a high bar of experience required before contribution is possible without the risk of introducing a memory leak or security problem.

Rust has the potential to change all of this, and that's really, really big.

> Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.

I definitely appreciate Mathematica and its sort of rich prompt is probably closer to what a terminal should look like rather than what we have today. But most of what I'm doing all day is text editing and using companion tools like Git, which isn't a good fit for it. I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica.


> I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica.

I believe that's what the parent meant. And I like this idea – a lot.


Sort of like old TTYs with better features and fewer dead trees? Or Plan 9 with less Rob Pike? :-)


Jupyter with a sh kernel perhaps?


To change what exactly? What is the current issue with c++ that prevent you from doing a terminal using OpenGL?


Reading his comment, his concern isn't with c++ as a language, it's with the tooling and development practices around it. He suggests that because of the generally project specific nature of the tooling and development idioms, generally a higher bar of experience is required to contribute.

I can't argue with him there, and I'm about as much of a C and C++ fan as it's possible to be.


I fully agree with you here - neither C/C++ are a gateway to salvation. http://www.redox-os.org/news/rust-is-softwares-salvation-17/


That is far from what I meant, and the suggestion that Rust is "salvation" is the stuff of infantile delusion. I'm a big fan of Rust, too, but it isn't going to be the "salvation".


I would characterize about 1/3 of HN posts as infantile delusion. You just learn to tune it out and get to the adult posts more quickly.

There are browser extensions to help with this, too.


Ok, now you have got me. What extensions are those?


I personally use Hacker News Enhancement Suite for Chrome and tag users whenever I find myself mentally rolling my eyes. Then when I'm reading a page with lots of comments and see the "SKIP" tag I collapse the thread.


Not your parent, but the third paragraph covers this, starting with "Although I can ostensibly write C and C++".


Isnt most of your points just the relative newness of rust?

I could rewind a few years, replace [rust] with other platforms like [node] or [erlang] and the same statements apply.

I'm not disagreeing with you, I'm just pointing out that it seems to be the stage an a natural progression of platforms.


The difference there is that Rust is directly targeting the ecosystem where this C and C++ stuff is being written; Node or Erlang never were.


Why was erlang "hot" for you a few years ago?


Not a fan of rust, but why rain on parent's parade? What the hell's wrong with some genuine enthusiasm?


It is an amazing project! One thing to note is that the terminal emulator itself isn't GPU-accelerated (there's no parallel computations that run on the GPU), the UI graphics are only rendered by the GPU (much like in the Chrome browser).


Comparing it with Mozilla's Servo project (specifically WebRender) would be more accurate.


"... generally infinite willingness to accept web apps..."

Interesting.

I stay in textmode. Hence I do not need an emulator.

If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc.

My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make textual interfaces feel snappier.

But I doubt that jobs execute any faster in X11/Wayland/whatever than they do in textmode. I cannot see how the processes would be completing any sooner by virtue of using a graphics accelereted emulator.

But I could be wrong.

I sometimes use tmux for additional virtual consoles because on the computers I control (custom kernel, devices and userland) I do not use multiple ttys, just /dev/console.

I rarely ever work within tmux. I only use it to run detached jobs. I view screen output from my tty with something like

   case $1 in -B|-E|-S|-t)
   tmux capturep $@ --
   exec tmux showb $@ --
   esac
I'm not a seasoned tmux user. I was a very early adopter. tmux is useful high quality software IMHO.

Not sure why I would ever need these slow "web apps".

I guess the third parties controlling the endpoints might be able to utilise the data they gather about users. And I am sure some users appreciate the help. Thus it is a symbiotic relationship.

I am continually making my "tooling" faster by eliminating unecessary resource consumption. It is an obsession of sorts. Constant improvement.

But given that I am working with text, graphics processing is not something I need. I would not mind being able to run my non-graphical jobs on a fast GPU, but my understanding is that the companies making these processors are not very open. For example, the GPU in the RasperryPi.

Always interesting to hear how others are meeting their computing needs.


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 implementation of "run arbitrary code in a safe sandbox," because the Web is also the world's biggest collection of legacy dependency.

IMHO, the source of the engineering cringe making everything so much sadder and less than what it could be is that the W3C/WHATWG/IETF/etc are made up of consortiums of large, foghorn-equipped corporations - corporations that have vested interests in advertising, consumer retention, and strong guarantees of indefinite consumption.

I've never really gotten the reasoning behind the technical directions the Web's gone in; a lot of things have stuck and worked, but so many more have flopped, yet the associated implementations for both the successes and failures have to be maintained going forward indefinitely.

The iterative pace on the various Web standards is another problem - things go so fast that the implementations can never get really really good, and Chrome uses literally all of your memory (whether you have 2GB or 20GB, apparently!) as a result.

---

Regarding $terminal_emulator being faster than VGA, I can emphatically state that virtually all of them are disasterously slow. aterm had some handcoded SSE circa 2001 to support fake window shadowing (fastcopy the portion of the root window image underneath the terminal window whenever the window is moved; use SSE to darken the snagged area; apply as terminal window background) but besides that sort of thing, terminal emulators have more or less never been bastions of speed.

If by VGA you mean true textmode (the 720x400 kind, generated entirely by the video card), I don't think there's much that's faster than that. Throw setfont and the Cyr_a8x8 font in there to get 80x50 (I think it is, or 80x43) and you have something hard to beat, since spamming ASCII characters at the video card's memory will always be faster than addressing pixels in a framebuffer.

Which is why GPU-accelerated terminal emulators are so interesting: they're eliminating as many software/architectural bottlenecks as possible to make those expensive framebuffer updates as quick as possible. It's definitely the way to go; games are generally rated on their ability to push GPUs to >60fps at 1080p (and increasingly 2K/4K/8K), so the capacity is really there.

The i3 window manager could be considered one of many comparable similar implementations to tmux. It's not perfect (it's not as configurable as I'd prefer), but it'd get you X and the ability to view media more easily.

I do really appreciate the tendency to want to view a computer as an industrial terminal appliance though. Task switching is still best done by associating tasks with different objects in physical space, so keeping the computer for terminal work and keeping tablets (et al) for other tasks does make legitimate sense.

---

Regarding data usage, that's a tricky one - most successful Internet companies provide some kind of service that necessarily requires the collection of arguably private information in exchange for a novel convenience. As an example, mapping services don't truly need your realtime location but having that means that they can stream the most relevant tiles of an always-up-to-date map to you. 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.

---

I find elimination of unnecessary resource consumption a fun concept to explore, almost to the point of obsession. In this regard I often come back to Forth. I was reading this yesterday - http://yosefk.com/blog/my-history-with-forth-stack-machines.... - and it explores how Forth is essentially the mindset of eliminating ALL but the smallest functional expression of the irreducible complexity of an idea, often to the point of insanity. It's not a register-based language so it's never going to beat machine code for any modern processor, but it's a very very interesting concept to seriously explore, at least. (And I say that as someone interested in actually using Forth for something practical, as described in that article.)

---

AFAIK, the RPi actually boots off the GPU, or at least the older credit-card-sized ones did. I'm not sure about the current versions.

ATI released some documentation about their designs a while back with the subtext of enabling open-source driver development. I don't think that panned out as much as was hoped.

My understanding is that Intel has both NVIDIA and AMD beat nowadays when it comes to Linux graphics support; the two former vendors still heavily rely on proprietary drivers (on Linux) for a lot of functionality.

Sadly, since they both have to successfully compete in the market, they're unlikely to release their hardware designs in significant detail anytime soon. (Even if they did like the idea of merging, single gigantic monopolies have a lot of risk, and the behemoth that resulted would be impossible for Intel to compete with, likely.)

So, learning OpenCL and CUDA (depending on the GPU you have) is likely your best bet. There are extant established ecosystems of resources and domain knowledge for both implementations, and the relevant code is not too tragically licensed AFAIK.


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


Do you know of any forks or clean implementations of browsers which cut out legacy support more aggressively and/or are tuned for performance? Something like Chrome with less overhead because it doesn't bother to support deprecated features.


Unfortunately there's currently nothing out there that generally meets all of the points you've touched on. There are some projects that tick one or two boxes, but not all of them.

Dillo parses a ridiculously tiny subset of HTML and CSS, and I used it to browse the Web between 2012 and 2014 when my main workstation was an 800MHz Duron. Yes, I used it as my main browser for two years. Yes, I was using a 19 year old computer 2-4 years ago. :P

Its main issue was that it would crash at inopportune times :D taking all my open tabs with it...

The one thing it DID do right (by design) was that the amount of memory it needed to access to display a given tab was largely isolated per tab, and it didn't need to thrash around the entire process space like Chrome does, meaning 5GB+ of process image could live in swap while the program remained entirely usable. This meant I could open 1000+ tabs even though I only had 320MB RAM; switching to a tab I'd last looked at three weeks ago might take 10-15 seconds (because 100MHz SDRAM) but once the whole tab was swapped in everything would be butter-smooth again. (By "butter-smooth" I mean "20 times faster than Chrome" - on a nearly-20-year-old PC.)

I will warn you that the abstract art that the HTML/CSS parser turns webpages into is an acquired taste.

---

Another interesting project in a significantly more developed state is NetSurf, a browser that aims to target HTML5, CSS3 and JS using pure C. The binary is about 3MB right now. The renderer's quality is MUCH higher than Dillo's, but it's perceptibly laggier. This may just be because it's using GTK instead of something like FLTK; I actually suspect firmly kicking GTK out the window will improve responsiveness very significantly, particularly on older hardware.

I have high hopes for this project, but progress is very slow because it's something like a 3-6 man team; Servo has technically already superseded it and is being developed faster too. (Servo has a crash-early policy, instead of trying to be a usable browser, which is why I haven't mentioned it.)

---

The most canonical interpretation of what you've asked for that doesn't completely violate the principle of least surprise ("where did all the CSS go?!?! why is the page like THAT? ...wait, no JS!?? nooo") would have to be stock WebKit.

There are sadly very few browsers that integrate canonical WebKit; the GNOME web browser (Midori) apparently does. Thing is, you lose WebRTC and a few other goodies, and you have to lug around a laundry list of "yeah, Safari doesn't do that" (since you're using Safari's engine) but I keep hearing stories of people who switch from Chrome back to Safari on macOS with unilaterally positive noises about their battery life and system responsiveness.

I've been seriously think-tanking how to build a WebKit-based web browser that's actually decent, but at this exact moment I'm keeping a close eye on Firefox. If FF manages to keep the bulk of its extension repository in functioning order and go fully multiprocess, the browser may see a bit of a renaissance, which would be really nice to witness.


I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s.

It might be super fast, but I've not really been scroll speed limited.


I generally use rxvt because xterm is too slow. It doesn't have menus or URL highlighting and scrollbars are nonfunctional in the presence of screen, tmux, Emacs or generally any interesting terminal app.

On Windows I use mintty and I turn off scrollbars there. I simply don't use the mouse to interact with the terminal other than to select text, and that's with selection buffer to copy.

Speed is highly relevant to me. Most modern terminal emulators are very slow, most noticeable when you get a lot of output in a panel in something like tmux.

(Simplistic benchmarks that test full screen scrolling usually hand the crown to terminals that don't bother to refresh the screen with everything output, but that's not the only bit of a terminal emulator that can be slow.)


Interesting. For me, there isn't enough integration between the GUI and terminal ... they shouldn't seem separate, but should be bridged to create a coherent experience.


Heh. Does it also have less space than a Nomad?

Point is, that stuff is easy to add in subsequent releases. Its an early project. Give it time to become.


As a suckless terminal user I would say it is not the goal of the terminal emulator to provide scrollback, gnu screen or tmux are far better tools for that purpose.


Some people like using the mouse for scrollback, and the experience in tmux and screen isn't great by default.


In the case of tmux, it's only a single line change to activate mouse scrolling. It's nice to have the times when I switch over from a browser and instinctively try to scroll around.


"Not nearly as functional as the original xterm from the early 90s.:"

Early Alpha concentrates on stability before bells and whistles. Agree though scroll bars would be nice but patience.


Why do people still say C/C++? They are two different languages with different purposes and strengths/weaknesses. Rust might be a worthy competitor with C++, assuming many improvements down the line, but it's not even in the same category as C, no matter how much the enthusiasts like to claim otherwise.


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 these days.

I need tabs. At any given time many of those tabs might have instances of tmux somewhere in their multiply nested depths, generally on remote hosts.

I'm not going to start tmux on every local prompt just so I can use Alacritty and thus intentionally starting a tmux in tmux funshow.

I use "Monitor for Silence" "Monitor for Activity" pretty consistently.

It's free software so I glad the author is making something and hopefully enjoying the process. I can't really use this or consider it until he reconsiders. Maybe he'll get some collaborators that will argue him around on this.

Cool project otherwise.


> 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 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 think Hyper [1] is going down the wrong path, but I strongly believe a new "terminal-oriented UI model/protocol" could be invented that would scratch every possible itch — good for text, mouse support, custom UI widgets, seamless remote connections, multiple screen regions — without sacrificing functionality at all.

[1] https://hyper.is


Thank you for the thoughtful comment.

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.


Scrollback support was added to AmigaOS ca. 1987 (with 2.04), and enabled on machines with 512KB RAM and a 7.xx MHz M68k CPU... Performance was not a problem then. Of course the highest resolution most people would run it on would be 640x512 back then, with typically 2 bit planes. But data volume has grown much less than CPU speed and memory bandwidth.

Incidentally, AmigaOS' terminal design is worth exploring - it is a fascinating example of layering. And the AROS re-implementation, while not very clean, is also partially object oriented (in C; disclaimer: I wrote part of it) in how it layers the console units from the simplest to most complete (cut and paste support + scrollback). Even back in the 80's performance was good enough for this that AmigaOS started using dispatch-function based OO all over the place, and the AROS re-implementation of the console code uses that method, which is not at all the fastest way of doing it, but it's fast enough even on real M68k's.

Any modern PC is going to be at a minimum several hundred times faster.

All you need is to maintain a linked list of lines, and add code to free or reuse when you reach the maximum size of the scrollback buffer. If you want you can easily also just use a ring-buffer and wrap around if you want to set a size limit in bytes instead of lines, and just maintain indexes into it. It's trivial to do this in ways that doesn't cause performance issues.


The developers of the VTE widget had a problem a few years ago. The widget was using 16 open file descriptors per terminal emulation instance. This was causing problems for terminal emulator programs that had the architecture of a central server process that does all of the terminals on multiple X displays.

A GUI terminal emulator for such an architecture needs at least two open file descriptors, one for the connection to the X server and one for the master side of the pseudo-terminal. The other 14, it turned out, were being used by VTE's scrollback buffer mechanism, which involves writing data that have scrolled off the top of the screen out to (temporary) files.

They had managed to reduce this, by rearranging the structures of the scrollback files, to 8 open file descriptors per emulation by 2011, and reportedly it will be soon down to 4.

Interesting tidbit #1:

It was mentioned elsewhere in this discussion that the alternate screen on many terminal emulators has no scrollback. This is because the programs that switch between primary and alternate screens aren't actually doing that as far as they are concerned. They are switching between scrolling mode and cursor addressing mode (see http://superuser.com/a/715563/38062 for details), the latter not really having the concept of a negative row coördinate.

The VTE widget was using twice the number of open file descriptors, because both scrolling and cursor addressing modes had scrollback files.

* https://bugzilla.redhat.com/show_bug.cgi?id=667539

* https://bugzilla.gnome.org/show_bug.cgi?id=646098

* https://bugzilla.gnome.org/show_bug.cgi?id=738601

* https://bugzilla.gnome.org/show_bug.cgi?id=741520

Interesting tidbit #2:

LXTerminal has this single centralized emulator process architecture, too. It has a rather nasty open file descriptor leak with which one can render LXTerminal completely unusable in about 1 minute (if one has an open file descriptor limit of 1024).

* http://unix.stackexchange.com/a/333578/5132


I've already tested alacrity and it's super easy to configure, the only thing stopping me from making the move is scrollback. I understand not adding tabs or a GUI config: I use my WM to do tabbing on linux even though my terminal implements tabs. However scrollback is an absolute must for me. If you implemented scrollback I would be able to switch terminals from terminology (at first glance).


Honestly, I don't like tabbing terminal instances.


I use tmux a lot, but I don't use it for every session. To me, forcing me to use tmux to get scrollback is precisely violating the idea of 'one tool doing one thing'. You're forcing me to compose a Swiss army knife (tmux) into situations where all I need is a knife (a terminal that works well with the idioms of my environment).

I don't need tabs (I use i3wm), I don't need splits or session management (when I need that I use tmux). But I do often need to scroll back on a temporary session when I didn't plan for it in advance. I open a lot of terminals. They're never all going to be tmuxed.


> Performance with large amounts of output is also a concern.

Frankly, removing two very important features for a lot of people (me included) and then claiming highest performance feels a bit like cheating.


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


> 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

This is the problem of Unix philosophy, because it applies differently for different people.

For example, I use i3, that is a tilling window manager, so I don't need tabs or split management for tmux. Actually, I removed tmux since I started to use i3 because using i3 features feels much more natural, since they apply to every window. However, there is only one thing that I can't have with i3 that is scrollback buffer, so while I don't need a terminal with tabs, I need support for scrollback buffer. Adding tmux just to get scrollback goes against Unix philosophy.


> Adding tmux just to get scrollback goes against Unix philosophy.

I agree. Rather than adding scrollback support to allacritty, maybe someone could write an independent program for scrollback support (a la dtach/abduco for detaching/reattaching)?

Such a program would be useful for all terminals which lack scrollback (alacritty, st, possibly others).

For the record I use st with dtach and dvtm; scrollback is supplied by dvtm, but it would be nice to decouple it some more.


100% agree, to the best of my knowledge there exists no tool that adds scrollback support to a terminal emulator without doing anything else. My solution now is to use tmux for this, but it is not really elegant. Piping everything through less is not an option :P


If you want decoupling, look at the AmigaOS design: The console (terminal) consists of a bunch of independent elements:

- Device drivers feeds raw input to input-handler

- console.device manages a single console window. it receives raw input from the windows message port (courtesy of the input-handler) and "cooks" it into escaped character streams (which can include things like mouse reporting), and processes simple output that it translates into window output.

- console-handler receives the escape codes and interprets more complex sequences before passing the result on to the application that has the console open, and writes output back to the console.device.

Most of this would run in separate threads.

This lets any application open special filenames like "CON:" to open a console window.

Within console-handler, multiple different "units" are layered - in AROS (AmigaOS compatible open source), the basic (no copy and paste, no reflow, no scrollback) unit, the unit with copy and past and reflow, and the unit with above and scrollback, are layered on top of each other via inheritance, using a system-wide OO system modelld after Commodores old BOOPSI (basically a simple vtable based approach with a "catch-all" method dispatch entrypoint for user-added methods; it's not fast with deep inheritance hierarchies, but it's fast enough for this kind of use).

The copy and paste itself is implemented via a separate tool - ConClip - started on boot (and optional; if you don't start it you simply don't have cut and paste), which receives messages about what to cut and paste and writes it to the "clipboard.device", which by default writes each cut/copied piece of data to the CLIPS: volume as IFF formatted files, which by default maps to a directory in a ram-disk, but which can be re-mapped elsehwere. This all happens asynchronously, to accommodate cases where people e.g. remapped CLIPS: to a floppy and had to swap it in (rare, but possible if you had to deal with low memory situations).

This is something that frustrates me to date with Linux etc. - AmigaOS was far more decoupled, with clear, well-documented boundaries for people to hack on (e.g. several people wrote alternative console-handlers and console.device's that you could totally replace the original with to the point that any application that used terminal windows could be made to use your preferred console device. Even third party components tended to follow this approach (e.g. compression in AmigaOS is usually done via the XPK suite of libraries, which provided a third party API for opening compressed data streams, that let you plug in any compression algorithm as a library - as a result most apps in an Amiga system that supports compression can support most compression algorithms you drop in a system-wide library for).


Thanks, that's really interesting. I grew up with Amigas exclusively until getting a family PC around 2000, although I didn't tend to use the CLI or do any programming back then.

I'm aware of BOOPSI, and the datatypes system which sounds similar to what you describe.

One problem on AmigaOS was(/is?) the lack of packaging and dependencies, e.g. installing many programs on a fresh copy of Workbench won't work, due to missing libraries, etc. Thankfully that's easier to manage these days by scouring Google and Aminet, but it's still manual.

Interestingly, I've found Amigas to become more stable over time, unlike e.g. Windows where some people recommend formatting every year or so to remove cruft. The more stuff you install in Workbench, the more libraries, etc. you accumulate, so the fewer problems you encounter trying to install/use other things. I'm not sure if this is a consequence of the OS design, or from developers bending over backwards to avoid problems (e.g. conflicting names, etc.)


Yes, BOOPSI was the model for the OOP used in AROS.

> One problem on AmigaOS was(/is?)

Is, sort-of. Package managers didn't enter the scene until much later, but Commodore did release Installer, which while not a package manager provides a s-expression based mechanism for describing installation flow.

It's alleviated because Amiga libraries tends to very strictly insist on backwards compatibility, so you should generally be able to drop a newer version of a library over an older version and things will keep working (and the libraries and all compliant binaries contains version numbers).

But of course the community today is very small, and was smallish originally too, and so it's gotten easier and easier to deal with.

If there was to be a resurgence (there is new hardware but it's expensive niche PPC hardware; AROS runs on pretty much "anything", but is incomplete), it'd need a lot of big overhauls - in particular memory protection (some work is ongoing but it's hard due to AmigaOS APIs relying a lot on pointer passing) and SMP, but also lots of tooling we take for granted today like package management.

I'm not holding my breath for that, but I do wish more AmigaOS ideas will get picked up elsewhere. Linux still feels like a hodge-podge in comparison.


> Adding tmux just to get scrollback goes against Unix philosophy.

There are also simpler tools which can provide scrollback support.

The whole Unix tty subsystem goes against the "Unix philosophy", that is why it was completely scraped in Plan 9.


Could you give me some reading to do? I had never heard of this before.


The Plan 9 manual pages and papers are probably a good starting point:

http://man.cat-v.org/plan_9/

http://doc.cat-v.org/plan_9/4th_edition/papers/


I use i3 too, but it doesn't replace tmux or screen for me for a simple reason: I can't maintain state for a remote server as i3 windows. My screen session outlive my laptop uptime by years. And easy API to let a remote terminal management tool create child windows/tabs would be fantastic...


When I need state in remote servers, of course I still use Tmux. I was referring to local Tmux sessions, that I mostly used for tabs/splits before I started to use i3.


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


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 practice, but it annoys me in principle!


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 way that makes them aware of each other and able to exchange information; and secondly, that the pipe protocol is based on typed, structured data. I want both things.

Imagine if you had that, then you could conceivably also do:

    psql -c "select firstname, lastname from foo" |
      sort -f lastname
and psql would automagically rewrite its query to:

    select firstname, lastname from foo order by lastname
That's the future I want to live in, anyway.

The inability to do this sort of thing really a product of a failure to modernize the 1970s text-oriented pipe data model. I believe PowerShell (which I've never used, only read about) provides a mechanism to accomplish this sort of thing, at the expense of being extremely Microsoft-flavoured.

I don't think there's anything even vaguely scifi about those abilities, but the Unix world is hampered by a curious reticence to innovate certain core technologies such as, well, Unix itself. That's why we still have tmux and such.


... or the downstream program could ask the upstream one (or get automatically along with the stream) about meta-data/type information for the stream it is being passed, and then it could benefit fully from already-known information. Though that does not solve the need to potentially read the full stream and buffer it before doing the processing.


I certainly wouldn't want to implement psql if it neededs to handle all that extra communication.


Ah, but you do compose it -- with tmux, for instance :-)


The composition is very different from the integrated case. Alacritty with tmux is wildly different from Terminal.app.


I use st as my terminal application. Inside, I run dtach to provide detaching/reattaching functionality. Inside that I run dvtm to provide multiplexing and scrollback. Inside that I run bash. Inside that I run ad hoc commands.

Everything's highly composable, e.g. I can switch out bash for zsh, fish, etc. I can switch out dtach for abduco. I can switch out dvtm for tmux or screen. I can switch out st for xterm or urxvt. And so on.

Adding an extra layer for scrollback, separate from a multiplexer, wouldn't disrupt anything, and would provide more flexibility for composition.


Each to his own. Your setup sounds like a parody of the most outlandishly neckbeardy things devs can do in a shell. Most users don't want to deal with that sort of "layering".


> Your setup sounds like a parody of the most outlandishly neckbeardy things devs can do in a shell.

I shaved off my neckbeard, I'll have you know! ;)

My setup's no more outlandish than using tmux or screen, except instead of typing `tmux` or `screen` I type `shell`, which aliases a `dtach dvtm` one-liner (with a few options sprinkled around, so I don't have to bother with config files).

The point is that none of these applications care if/how they're composed; if I want to add in or swap out something, it's just a change that one-liner.

Not so if, say, my terminal application were hard-coded to rely on tmux, as some sibling comments have suggested.


The famous saying: every problem can be solved by another layer of indirection, except the problem of too many indirections.


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.


> A terminal app that has terminal features doesn't violate any principles of simplicity.

It still depends how these features are implemented.

For example in dvtm scroll back history is made searchable by piping it to $PAGER. Similarly, copy mode is implemented by using $EDITOR as an interactive filter.


This wasn't a feature of the original VTE videoterminals these apps are emulating though. I'm pretty pro-scrollback, but I have to say the way its been implemented so far has frankly not been very principled.


PuTTY does lot of things. PuTTY is good solution for world of Windows, but alien in world of UNIX. "Do one thing" rule applies to terminals too.


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.


I've honestly never seen anything but love for tmux, can you explain why you hate it?


Not your parent, but here's my take. For remote usage, tmux doesn't provide much beyond vanity over screen, and is less likely to be installed on a shared host. Locally, I generally get by with &, bg, fg, and Ctrl-Z if I absolutely can't open another TTY, and a tiling window manager (or Emacs) provides a superior tiled workflow for the applications I use.

There are some cases where tmux could help me, but my X session and terminal emulators are stable enough where I'm not worried about them crashing and interrupting my shell session. As such, I have no need for tmux, and using it just for terminal emulator scrollback seems hamfisted.

The only use case I can think of is running large distribution updates which might potentially pull the rug out from under your graphical session, but I tend to run those on a non-X terminal if they look sketchy.

Edit: I'd totally consider using tmux as an alternative to X on my Raspberry Pi, but if I have X/Wayland, It doesn't offer me much.


Personally, I don't hate it. It just doesn't do anything for me -- I can just open a new terminal if I want another split.


Can you go into details about tmux vs tabs & a scrollbar?


It's not cheating if you gain those features back by using a separate program (tmux) and still see a performance improvement over all other tools, which is what the author is implying. All that does is suggest that terminals might not be the proper layer at which to implement those features (and for the record, I'm on the side of having scrollback, but the lack of it isn't a dealbreaker).


I'd be very happy if you more closely integrated with tmux and used the features from tmux instead transparently. I don't care how the terminal does scrollback, as long as it does. If you forwarded the scrolling commands to tmux then great. Same thing with tabs, panes etc.

As much as I like tmux (although I exclusively use it via byobu), the single most annoying thing is that it won't let different viewers see different content. (eg start two terminal emulators, run tmux in both and any switching you do in one affects the other. There are supposedly elaborate workarounds, but far too much effort.)


In Byobu, you simply need to create a new session. Ctrl-Alt-F2. Then Alt-Up/Alt-Down to move among sessions. Each user can have their own session easily like this! Shift-F1 for the hotkeys, if you need a reminder ;-)


What would you know about byobu :-)

Ctrl-ALT-F2 would take a miracle to work. Shift does as you describe, but the net effect is still nowhere what is intended.

Also note I am the same user. The functionality I want is how byobu behaves with screen. eg you can start 3 xterms, in each one run byobu. And each one can jump around as they see fit all sharing the same screen session. No work, no fuss and exactly sane.

The tmux behaviour baffles me. I can't understand why anyone would want all their viewers to change in sync. Short of a classroom demo environment, it really doesn't make sense as a default.

I'd be delighted if by default byobu did whatever was needed to make tmux behave usefully.


Interesting... Frankly, I love the tmux default, to sharing the window, while also supporting the concept of "sessions". The shared view makes paired programming with a colleague across the world, while on the phone or a video conference super easy. Different users start in the same "session", and share the view of "windows" and "panes (aka splits)". If they want separate views/control, then they start separate sessions.


For your usecase I can understand. But when it is the same user using defaults it makes absolutely no sense. Why would they want separate xterms on the same display to be in lockstep by default?

Am I the only one who runs more than one terminal at a time? What happens now is I start an xterm on monitor #1 and start byobu within that. Various windows (whatever you switch amongst on pressing F3 and F4) are started - eg one might be client code running, one might be server code, one might be a database server etc. But sometimes for example I want to look at the client code output and server output simultaneously. At that point I switch byobu to the client window, and start a new terminal on monitor #2 and tail logs or whatever is appropriate. It is an annoying pain that I can't just run byobu and switch as I see fit.

In any event this is a multi-year frustration for me. People keep coming with convoluted workarounds (pointing tmux to tmux as far as I can tell) which it then isn't possible to figure out how to apply to byobu. All the while I wonder why two xterms running next to each other would ever want to be in lockstep by default?


A concrete example of what I mean. The user starts 3 xterms each running byobu with no additional parameters:

    for i in 1 2 3 ; do xterm -e byobu & ; done
Why would they want the view in each xterm to be identical, and why would they want changing the window (is that right terminology? pressing F3 and F4) in one xterm cause the other two to change in lockstep?


You probably want to do something like this:

  tmux new-session -t main -s main2
In practice it looks the same as attaching to the same session twice, except you can look at different windows at the same time.


Ok, now make byobu do that since it is how I actually use tmux. Also make sure it happens on every system I use. This gets tedious and annoying very fast. Heck mouse support not being on by default, requiring a single line in a config file on every system is already annoying enough.

The problem isn't that it is possible in theory. It is annoying in practise, unless you only have one machine and only need to do all this once in one system.


> There's been a lot more pushback on the scrolling decision than I had anticipated.

Even if tmux is in theory a better solution, it's not such a radically better solution that the benefits outweigh the switching cost. Terminals with scrollback have been around at least 30 years at this point [1], and scrollback is by far the majority use mode. You're asking 95%+ of your potential userbase to spend a bunch of time retraining themselves for little or no benefit.

You're also up against a variant of Jakob's law:

https://www.nngroup.com/articles/end-of-web-design/

Scrolling down and back is a key part of the web user experience. Even if every terminal emulator got rid of scrollback, most of your users would still have scrolling back baked into their brains. When they want to see something that just scrolled past, they are going to do what they do in a web browser, which is to look for a scroll bar, hit a scrolling key, or perform a scrolling gesture.

That's not to say you shouldn't try radical things. But if you want user adoption, you have to make sure the benefits you offer are very much larger than the costs you impose. So radically different UI can't be about as good as the existing one; it has to be radically better.

[1] And of course terminals are made to emulate teletype machines, which had infinite scrollback to begin with.


Scroll back is the only feature missing that would block me, assuming you permit changing the colour mappings.

I generally run five or six desktop terminals, only one of which is running screen locally. I more normally run something like screen to get persistence across suspends on an SSH connection. I usually don't do much side by side stuff in terminal so tmux isn't a big win for me. Also tmux didn't run on cygwin for the longest time, and I expect the same experience on all my platforms.

However the big tmux users in my life would still use it as is.


I am the one with you. If you decide to add scrollbar later, please at least make it optional.

I am using firefox with pentadactyl, and the firefox is configured as a minimal terminal like st. Basically, firefox becomes my GUI terminal. But what I want is a much lighter weight GUI terminal than firefox.

I am using three terminals, st for regular use. mlterm for its image support (sixel). and firefox for heavy-GUI needs. Alacrity seems perfect to replace st now.

Thanks for good work.


> I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern.

Just do it. I doubt it will be hard to beat tmux performance, in my experience it's slow like molasses and I only use it if I must - remote persistency, screen sharing, etc.


I love tmux since I regularly move between OSX and linux machines across several versions. With tmux I can create one .tmux.conf file that standardizes my tab/split behavior across all of the systems regardless of the emulator I use. This works a lot better for me than having to install specific emulators on each machine, several of which I do not have administrative rights over.


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


> Solutions like tmux arguably exist because terminals have poor UIs

Whilst I totally agree with you, I think Tmux is a lot like vim in its power. Along the same note, I'd wager a gTmux, much like gVim would be q real nice way to multiplex terminals when we get the UI to beat the TUI.


I mean Terminator is basically gTmux, right? They aren't quite the same: tmux is a terminal multiplexer, Terminator is a terminal emulator with tabs and panes. Both approaches have benefits and drawbacks.

If you want keyboard only, I don't think GUIs can beat TUIs. But yeah, there's a learning curve.

The problem with GUIs is a very display-session centric view. tmux/vim work fine over SSH, Terminator/gVim don't. With tmux, your sessions are separate from your terminal instance. If your X session crashes, depending on how you started tmux, you just have to relaunch a terminal and reconnect to tmux. This is pretty invaluable. So this separation is powerful, and IMO very Unix-y.


The multiplexer v emulator is the key difference. At least for me. Exactly because of the ssh and session persistence you mean.

For the thing to replace the TUI, I'd expect something in between current terminals and X11. With the simple, limited (and thus easily remotable) data of the current terminal emulators, but with much more drawing capabilites than the current grid-limited ascii art.

I came to this idea when trying to get vim up to a full IDE. Trying to get even half of netbeans' interface into vim just takes so much space in the ascii grid. And anything dynamic moves half the screen a shitton.


Have you heard of nohup?


Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.


Ok, so you're interactively using a program on a remote server and you don't want it to die if you lose your connection? Screen isn't a hack in that case :)

Although you could ditch it and use MOSH instead.


It presumably doesn't feel like a hack to you because you're used to this mindset.

To me, it's a deficiency in the lack of session management for SSH. All that SSH gives me is a two-way pipe to the other server's I/O. That's simple and elegant, but why does it create a new pipe every time? It's connection-oriented, which is a concept that hasn't seen any innovation since the 1970s.

My preferred innovation here would be a local shell that had remote access. Rather than pipe I/O to the remote shell, give me a local shell which happens to execute its verbs on the remote machine, and let the remote file system simply be a volume. All my session state (including command history) can be local, there's no need to keep that on the remote host. A remote host is just another context.

I believe Plan 9 tried something similar, but very few people have picked up on its innovations.


Maybe you want eshell then:

    ~ $ cd /ssh:tol-eressea:.
    /ssh:tol-eressea:/home/db48x $ ls
    db48x.net  libvirt-sandbox  rpmbuild  zone.sh  zone.sh~  zone.txt  zone.txt~
If you've set ssh up to use control sockets then it can reuse existing connections.

MOSH is also nice; it decouples the program you're running from your connection, just like screen does, and it also uses udp instead of tcp so that it doesn't have to worry about dropped connections. Even your client's ip address can change and everything keeps working.


or you could type CTRL+Z BG


Still can't reattach after logout/reconnect, which is a very common screen/tmux use case.


And that will still send the program SIGUP, killing it when you close the terminal or lose your ssh session.


You can do that (or spawn in the background from the start, with &) while also using nohup.


Yeah, that was my reaction.

> Features like GUI-based configuration, tabs and scrollback are unnecessary. The latter features are better provided by a terminal multiplexer like tmux.

This seems kind of like saying "everyone should use their computer the same way I do". I don't use tmux; maybe I should learn to use it. However, I seem to be getting along fine without it, and no scroll back is a deal-breaker for me.

That said, this is still a cool project and I wish them success.


> This seems kind of like saying "everyone should use their computer the same way I do".

People do have that attitude from time to time, in this case i'd phrase it more like "no one seems to use their computer the way i want to, so i wrote some software"


What you said doesn't make any sense to me.

Firstly you insinuate that the author is requiring people to interact as they do - this evidently is not the case, a suggestion has even been made on one of many ways to behave differently.

Secondly the "I seem to be getting along fine without it" statement pointlessly hampers progress. There is no basis or reasoning for this, instead there is a decision - whimsical by the looks of it - to not use it. You could say that you don't anticipate the gains of the system to be worth the transition cost, or you could actually try it and have some useful criticism, or any number of other things.

Thirdly, the linked page doesn't ever mention the 'minimal' your parent introduces. Minimal implies sufficiency (least sufficient, but sufficient none the less), the Alacritty page states simple - which does not.

I find the final comment hilarious. You have just denounced a tool based on an implementation triviality (which can be easily bypassed) and choose to summarise with a statement as undoubtedly false as it is trite. Did you read the page?


I think it's a cool project, but I personally wouldn't use it because it lacks a feature I expect terminal emulators to have and am not motivated to change how I use my computer. Other people may be happy with this program. If someone implements the feature I want some day, then I might use it as well.

I'm sorry if I came across as overly critical of the project, that wasn't my intent. I just think they're limiting their audience by assuming that a feature that isn't important to the developers is unimportant to users because a workaround exists that the developers are satisfied with. People really don't like to change how they do things, regardless of whether the way they're doing them now is "the right way" or "the best way". Maybe they're making the right decision and everyone really should be using tmux, and if so, great, they'll have have a community of happy users. If their target audience is someone other than me, I'm okay with that.


Moreover, tmux does its own output parsing, so when you do your `cat 1gb_file.txt` inside tmux inside a terminal, you have two layers of output parsing happening. I can't see how that doesn't impact the performance that is claimed for Alacritty. But perhaps tmux is really fast.

I wouldn't trust a third party application to be part of the performance experience I'm claiming for my own application, though.


Couldn't you say that about SSH? If your application is taking forever reading from the stdout buffer, your application will block when it is trying to write to stdout with say, printf, or fprintf.


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 point is a tmux selection, which is NOT a terminal selection, meaning you still can't copy it to your system clipboard.

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).


Apple's Fn key isn't ideal. The USB HID usage ID is not one from the keyboard or consumer key pages. It's in one of the "vendor defined" pages, meaning that every keyboard driver supporting has to specifically recognize the device vendor and model, because without that context one cannot know what a vendor-defined ID means, and every new keyboard supporting this requires an operating system device driver update across many operating systems as well as system firmware updates to machines whose firmwares recognize this vendor-defined ID as a keyboard key, all to add another vendor ID in to the drivers' lists of "this vendor+device has Apple's Fn key".

* http://lxr.free-electrons.com/source/drivers/hid/hid-apple.c...

* https://bugs.launchpad.net/ubuntu/+source/linux/+bug/942184


Huh, that's wacky.

Still, Das Keyboard has been making a Mac-specific keyboard for many years now, you'd think they'd at least reach out to Apple to see if they can get their keyboard recognized as having a Fn key (or, alternatively, provide a kext that adds support themselves). But the one time I asked them about it, they didn't seem to even care about how the Fn key behaves, so I doubt they've even made an attempt.


Just get used to the keybindings. I find it much faster to search up and yank in tmux than scrolling and dragging to copy stuff.


that as the case may be, the same argument applies to vim (i use vim, with at least some of its keyboard shortcut glory, and love it); it might be faster in a lot of cases, but at the end of the day editors like sublime, atom, brackets, etc all have a much larger user base because people aren't willing to learn


You sure about the user base count?

vim is a lot older and's got a lot more time behind it than all the alternatives you mention.


But you're criticizing tmux - which is solely used by power user programmers who are willing to learn.


No, they're criticising tmux as a proffered alternative to a full-featured terminal emulator, which is often used by non-power user programmers who are not willing to learn (like me).


I switched to tmux a few years ago and never looked back. What is your problem with mouse? I have quite basic tmux config, very basic terminal emulator (st) and enjoy mouse scrolling even in nested tmux scenarios. Selection is done with vim keybindings which is much faster than mouse especially if you scroll and look for something visually.

I can relate to your feelings. In the beginning I was _very_ skeptical about running tmux locally. But very quickly I reconfigured tmux as I felt and stopped noticing at all if I work locally or remotely. Everything is very smooth and pleasant since then.

The only bad thing I remember: default tmux keybindings suck. I just redefined almost everything.


> The only bad thing I remember: default tmux keybindings suck. I just redefined almost everything.

It's true, e.g. ^B / Ctrl+B is a terrible prefix. All of this just makes tmux harder to learn, and less portable/transferrable. But I think there's value in having to feel out the ideal configuration for your workflow - but the prefix is still inexcusable.


I agree. I also have a very basic tmux/vim setup and I can scroll, copy/paste and even resize tmux panels with the mouse.


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


Can you paste that config somewhere for the rest of us to see?



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.


I never managed to actually like tmux. It breaks too much of what I'm used to, like mouse wheel scrolling, Ctrl-arrows, ESC in Vim and a lot of other small things.

The ESC thing is fixable by configuration, at least, but I really doubt I can make tmux behave like my native terminal.


I'm not quite sure what you expect Ctrl-arrows to do, but I'd be surprised if tmux can't be made to keep that behaviour.

If you spend a lot of time in the terminal, there's a lot of value to be gained from using tmux. It takes some configuration to get value from it, but there is value there.


tmux has copy-mode (^B : copy-mode <enter>) which lets you scroll through history and copy out snippets without using the mouse. There are also some tips out there for nested tmux sessions.

For what it's worth, I use tmux just like the author of this project: a single urxvt terminal with tmux running inside (no scrollbars, tabs, menubars, etc) and it works for me.


> I need tabs.

At some point, every application (browser, terminal, tmux, ...) re-implementing their own version of tabs is kind of silly.

Ideally "look at 'window' X of application Y" (where window == window / terminal tab / tmux pane / whatever) is what the local window manager should be used for.

E.g. instead of 1 tmux session with 4 tabs in it (or 1 terminal window with 4 tabs in it), I will run 4 mosh/tmux sessions (or 4 terminal windows) with 1 tab each, and use my regular window manager commands (i3) to switch between them.

In theory this is a better separation of concerns, and I can have one set of key bindings to do all window switching. Not:

1. Use window manager keys ctrl-foo to get to the right desktop/terminal window 2. Use terminal keys ctrl-bar to get to the right terminal tab with my tmux session in it 3. Use tmux keys ctrl-zaz to get to the right tmux pane

(Obviously a contrived example.)

...that said, I still use a crap load of tabs in Chrome, so theory != practice.


I avoid tmux and screen to. Instead I use SSH multiplexing (great for rsync tab complete too), and let the window manager so its job.

All I need is an orthogonal solution for persistent shells (how about I persist arbitrary login process trees, graphical or textual, OK?) And I'll truly have no need for tmux.

Then again I don't ssh too often for too long, so the last part is endlessly low priority.


Surprised people consider tabs and scrollback similarly basic features. As someone using only basic linux terminal emulators like x/u/aterm or urxvt its interesting to see that people consider tabs a basic feature, while I don't know a single term without some scrollback. Really makes you realize how different people's expectations are.


Yes, "tabs and scrollback are unnecessary" seriously, must be some sort of a joke, I work all day long in a terminal and tabs are a must have.


yeah, it's less "unnecessary", more "provided elsewhere". in this case, he's saying by tmux... which does mean learning a bunch of new keybinds, which is a little upsetting


You can also implement tabs in the window manager, e.g. as kwin does. Then you use tabs for everything.

You can tab between terminal windows, which have tabs between terminals, which run shells in a multiplexer ;)


I work all days long in terminals and I never ever use tabs. So, "must have"...


I work all day long in a terminal and use neither.


For anybody who agrees that they need scrollback to start using Alacritty seriously, the best way to show it is to give thumbs up on https://github.com/jwilm/alacritty/issues/124.


Yup, I'd consider MacOS Terminal to be minimal. Anything less than that I just wouldn't use.

Anything with more features I probably wouldn't use, either.


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 unlikely to be part of your target audience. (However, I could live without GUI config and menus, because I configure my terminals once every few years at most.)

Also, a silly question: Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux.


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


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

This will be available also on Windows?


That's the plan! Most components of Alacritty are platform agnostic aside from font loading, font rasterization and setting up a pty.


I like opinionated software. If scrollback is better implemented on a different layer, leaving it out is reasonable. But I'm not using tmux because I use i3 as wm which does all the tiling/splitting. Now using a new tmux instance for each of my terminal (can be dozens) only for scrollback seems not the right way though. Any recommendations what would be The Right Way here? Anything that only implements scrollback maybe?


I'm also using i3wm (and currently terminology as terminal). I'd love to give alacritty a try but not without proper scrolling :(


>Completely understandable. This decision was expected to be polarizing.

The project being OK with polarizing decisions (instead of listening to the community and discussing it) is the dealbreaker for me.

It's OK to build opinionated software, but not at such basic level.


Of course it's always okay to build opinionated software at any level. If you don't like, don't use it.


Doesn't being opinionated necessarily preclude listening to a community and following consensus?


No. Rails is opinionated but also had great community driven improvements.


Emoji support would be huge. I can't get this working on Linux, iTerm supports it well though.


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


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.


> Hm. So, for that to work, I'd basically have to forever hardcode the terminal to launch tmux every single time.

Yeah, but it's not as bad as it sounds once you "move down a layer" and treat Tmux like your terminal manager rather than your terminal. When I need to a new shell, I don't open a new terminal window; instead I open a new Tmux "window" (the spiritual equivalent to a tab) and do the work there. I keep the same two terminal windows open with nested Tmux sessions for months at a time. By extension, opening new Tmux sessions is also an extremely rare event because the ones I already have are persistent.

> Might as well ship the terminal with tmux as a hard dependency and launch a tmux child process by default.

I think it's still nice to leave some room for customization here. Screen is still a pretty good Tmux alternative for example (in fact, five years ago you would have said that Tmux was a screen alternative rather than vice versa), and some people might prefer to use that instead.


You can also set tmux as your default shell with chsh. I've been doing this for a while on macOS and have enjoyed it (other than user namespace issues that still drive me crazy)


In a tmux workflow, you're generally not spawning that many new terminal windows, instead you ^a+c to spawn a new tty within tmux.


Sorry, but I want to keep multiple open sessions to different servers separate, even in tmux.


I actually didn't even notice Alacritty didn't have scrollback until now because I habitually open tmux when launching a terminal.

This definitely is a polarizing design decision, but one I support.


I may be reconsidering this position[0]. If scrolling support can be added in a non-intrusive way behind a feature flag (so it could be completely compiled out), it could potentially have a place in Alacritty.

[0]: https://news.ycombinator.com/item?id=13340369


Sounds great! I totally understand the motivations behind the decision to leave it out, but it's a great candidate for a compile time flag. I would love to throw out gnome-terminal for this!


the use case seems to be using tmux inside the terminal emulator, with tmux you'd use its own scrollback buffer

(edit) from the project's github page in fact

The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as tmux.


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 actually natively integrated with tmux, thus providing its own gui splits/tabs that represent tmux's panes/windows, but it doesn't sound like it does that.


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?


Terminal.app disables mouse mode if you hold the Fn key down (plus it has a ⌘R shortcut to toggle mouse mode on/off).


`mode-mouse off` helps tmux forget about mice.


Interesting - maybe this (or someone else) could skip the middle-man and just be a cross-platform tmux gui, instead of a terminal emulator.


Not really. After all, the applications inside tmux are ordinary terminal programs that need terminal emulation.


That makes so much sense that I now feel really silly about my suggestion :) Thanks for setting me straight!


It's also a deal breaker for me. I use a tiling WM instead of tmux.

That said, I really wanted to build this exact same project at some point, so maybe seems like a feature that could be added in a fork :)


I guess the idea of no scrollback is taken from st [0].

[0] http://st.suckless.org/



Aw damn this is the deal breaker right here. As someone using a tiling window manager, this is pretty useless to me.


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'"


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.


I know that screen can be configured to do that. I would be surprised if tmux cannot.


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


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


> One thing I'm considering as a key-binding option is to exec a command.

This would be pretty awesome. I definitely would love to have that as a feature, assuming it's not excessively difficult to implement.


You don't need to implement this in the terminal. You can bind macros to keys in anything that uses readline. Search for "inputrc" and the READLINE section in bash(1). While this is usually used for binding builtin functions (i.e. editing, history), you can simply provide the literal expansion.

    # in ~/.inputrc
    $if Bash
        # <f12>  -  find this with "<Control-v>{KEY}"
        "\e[24~": "sh \"${HOME}\"/path/to/swap_config.sh
    "
        # (the newline is included, which is
        #  usually bound to accept-line)
    $endif
The string indicating the key to binding to (left of the ":") can change depending on the environment (terminal, os, etc), so use <Control-v> to investigate what is actually being sent by the terminal into readline.


Thanks! Unfortunately I use zsh, and from a quick Google, it looks like it doesn't use inputrc.


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

I don't know whether to throw money at you or tell you to get off my lawn.

For now I will wish you a very happy new year and you can have a free rsync.net account if you want.

BUT I RESERVE THE RIGHT to shoo you from my lawn once I figure out what is going on here. With your GPU accelerated terminal emulator? Christ.


>>With your GPU accelerated terminal emulator? Christ.

Kids these days with their Rock and Roll music and their 144FPS terminal emulators.


Cool project, but I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. What applications benefit from a terminal that's even an order of magnitude faster than the alternative?


Have you even had Control-C take forever to kill that `cat` you accidentally ran against a 1GB log file? I have. Most terminal emulators are 'dumb' and try to render the whole backbuffer sequentially even if what you are seeing is no longer the tail of the output stream.

It's not so much that this is 'fast' (because even gnome-terminal which is not what I'd call crazy fast is 'fast enough' most days), but that it's much more responsive as a result. By locking the terminal refresh to your screen refresh rate and only rendering 'current' data this removes a lot of headaches you can run into with other terminal emulators (like the aforementioned cat of a 1GB text file).


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.


Thanks, though I've been on linux for the last couple of years.

On the mac side I had other performance issues with Terminal.app (particularly when using all of widescreen + tmux - lots of flicker during move/refresh operations). iTerm2 did well for me though, iirc.


Curious: What don't you like about Konsole?


The only real issue I run into is clipboard wonkiness when console apps integrate the clipboard (nvim+twmux).

Beyond that, it has a ton of features - none of which I use since I manage my sessions with tmux. So I guess it's mostly a matter of not wanting a sledgehammer when the right tool is a finishing hammer?


I use nvim inside Konsole/Yakuake and I don't have any issue with the clipboard. "+p and "+y works fine Also Shift+Inst and Shift+Supr keeps working fine.


Add to the mix Yakuake. It uses Konsole inside.


Terminal performance is fine at smaller sizes and with less going on.

In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty.

Alacritty is about having tools that don't get in your way and don't distract you from what you're trying to accomplish.


With the C-c issue specifically, I don't think that emulator throughput is the most likely culprit.

It could be that the emulator is not handling inputs fairly: maybe it tries to process all available input from the pseudoterminal before processing the next batch of keyboard input. Or it could be that the pseudoterminal (kernel driver) is not configured to send the signal as expected. Or it could be that the process you're trying to interrupt is not responsive to the signal.

I maintain a terminal emulator that is not optimized at all and I just tested interrupting a process that was dumping one gigabyte of text to the screen. The interrupt was handled instantaneously.


It isn't the most likely culprit. The mosh people point out that the place where people hit this is with a SSH session to another machine. Where the data are actually building up is the SSH connection. It's not a problem with the terminal emulators at all.


That's a lot more to do with Vim that your terminal emulator. It chokes on some files pretty reliably.


It's more of a user comfort / perception thing. Using a slow terminal is basically like playing a game with really inconsistent frame rates. It's a distraction and can cause you to make mistakes from mistimed inputs. In both cases what you're really looking for is consistency more than raw speed.


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?


Windows console is very slow (and terrible in many other ways). I think it is beyond salvageable. The only workarounds is probably write into a disk file or a pipe.


Try to use Cygwin + Mintty .

However, keeps being slower that any tty on any *nix. Sometimes fish autocomplete hangs for a few seconds when on the same machine running ubuntu fish autocomplete always is instantaneous. I don't know if it's related to something about the tty emulator or something weird on cygwin.


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.


Terminal speed is the primary reason I (and some others) use 'terminology', which is a relatively quick terminal emulator out of the enlightenment project.


I've literally never seen this problem.

However, a terminal emulator + X11 and so on can eat a bit of a CPU with noisy processes, eg. the output of mpv eats maybe 5-10 %, because it updates every(?) frame, so maximum work for the whole display stack. Getting the terminal emulator out of sight can get a bit more battery life in these cases.

(Somewhat related: If you have infinite scrollback it turns out that /tmp is actually very finite and can be filled by the wrong command with a couple dozen MB/s.)


Sounds like an option to slow down output rendering to e.g. one 1 frame/s might be an interesting feature for a terminal emulator. Still enough to keep an eye on a long-running process, but less overhead?


Smart batching of similar output could be useful as well. Perhaps the ability to configure a similarity threshold.


> I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done.

Which one do you use ?


Noisy build processes?


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.


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)


Sure, but you're either going to have to generate the whole font up-front(can be many thousand characters) or you need to re-upload as you use/generate new characters which can thrash unless you're very careful about the regions you lock(and you have a driver that behaves appropriately).

Most font renderers I know do a tiered LRU cache of 3-4 texture "pages" which hurts your drawcall batching but tends to be a nice tradeoff in texture usage.


Okay so I dug into this. There is a font cache on the GPU and another in CPU ram. I believe it will fall into the drawcall batching issue you are concerned about... but terminals don't need to get >60FPS in most cases.


You really have nothing better to render on your GPU and store in that video memory than your terminal? I also use a web browser, and feel like it could use a performance boost a lot more than my terminal (particularly as I don't actually believe that using textures in this way is actually the most efficient way to render fonts with OpenGL).


What's your currently preferred way to render text with OpenGL?


There's Distance Fields[1] and Loop-Blinn[2] aside from standard textures that I'm aware of.

Valve uses the first, very few people use the second because of patent issues. They're more computationally expensive in some cases so there's always tradeoffs to be made depending on your hardware.

[1] - http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_...

[2] - http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html


Any idea how much memory it takes to store the full atlas for a font with full Unicode/emoji support? Also does it work for colored emoji?


~95k UTF characters x font sizes x font styles(bold, italic, etc) x outline size.

It's pretty large.


Don't combining characters, ligatures or scripts that fuse characters lead to a combinatorical explosion?

can it handle zalgo?


Terminal emulators tend to prefer fixed-width fonts so you don't really have to worry about those too much.


Just another vote for scroll back - would not use without. I do use tmux occasionally but it is just too awkward beyond keeping stuff running in SSH. I also have a tiling window manager and since I use mouse a lot in browser and other GUI apps it's too much of a pain to switch to keyboard only navigation for the terminal.


The tiling WM argument has basically sold me at this point. I'm expecting to open an issue about adding this feature behind a compile-time flag.


I want to encourage you to keep your product vision. It makes totally sense.

I am a heavy tmux + vim user, developing on a remote server. So, I have all my dev sessions always running and can access them on any client. I never needed scrollback or tabs in my terminal. tmux has it all. Excellent window and pane management + scrollback included.

And even on a remote connection I feel speed differences between terminal emulators as I wrote in another post. So, there is a strong need for such a product and great that somebody is innovating a console app in a time of locked-down fancy touch devices.

Well done and keep on going. Don't be intimidated by different requirements. Your product strategy is right (at least for me).


I love iTerm2 and hate tmux, but can't use iTerm2 on Linux. I greatly prefer iTerm's window splits and tabs to tmux's. Please reconsider.


Use Konsole


I put this comment elsewhere in the thread, but maybe if I put it in this subthread you'll get to see it.

I tested on my laptop (a ThinkPad X250) and alacritty is slower than xterm. xterm can display find / at 80x24 in 11 seconds, but alacritty takes 17 seconds or more, depending on how large the window is (smaller seems to be slower) and whether it's on-screen or not (off-screen seems to be slower).


There's a small subset of systems experiencing this. Do you happen to have a Radeon video card? In the profile I looked at, glClear was calling down into (through libxcb) __poll_nocancel which was eating 99% of the CPU time. I'm not sure if there's an issue open for this yet, but it's something we're looking into. One of my testers during development ran into this so we're aware of the problem.


Another data point with find /:

terminator: 0m58s

alacritty: 2m46s

Up to date Arch Linux.

OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile

OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.3

edit2: there is a bug report tracking this issue here: https://github.com/jwilm/alacritty/issues/125


It seems to be a OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)


My current Bash prompt contains a unicode character. I guess this is unsupported?

Can report find / works very quick on macOS (so quick, it is unreadable), and Fish works as well. Just the Rust install assumed I was using Bash.

Possible bug: on macOS when I minimize Alacritty, and I put it on focus again, it tries to select text. Strangely, not always.


> My current Bash prompt contains a unicode character. I guess this is unsupported?

Multibyte characters are 100% supported, but only if they are available in the chosen font. The fallback fonts feature will resolve this issue for you.

> Possible bug: on macOS when I minimize Alacritty, and I put it on focus again, it tries to select text. Strangely, not always.

Definitely a bug, and it's one that I knowingly shipped with (usually I just resize my terminal once and then it's static). The events triggering selection seem to work slightly different on macOS than Linux. The issue should be easy to resolve, but this comes down to making time.


> Multibyte characters are 100% supported, but only if they are available in the chosen font. The fallback fonts feature will resolve this issue for you.

How do I enable this feature?

The characters  and ⑂ don't work in Menlo.

 and  do work in Cousine for Powerline font.

In Terminal.App and iTerm2 this works in both fonts. Do those applications also have a fallback fonts feature?


It's mentioned in the article as one of the yet-to-be-implemented features.


Thank you.

Is there a way to command the terminal to enter/exit full screen mode (like iTerm2 has)?


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!


Is split-screen like terminator/iTerm part of the plans?

(Yes, I know tmux and screen exist, I just prefer GUI splitscreen)


Nope. The idea is that perf should be good enough that it's not necessary.

withoutboats and I are hopefully going to collaborate and add notty protocol support to Alacritty. This should make text splits as performant as GUI splits.


My issue with tmux splits is not that it's not fast, it's that GUI stuff like scrolling / selection / etc don't integrate as smoothly.


I (withoutboats) agree. The real problem in terminals is that this goes both ways - if you let tmux or just vim/emacs split the window, you get no GUI integration - but you use the GUI to split the terminal window, you now have two disconnected shell sections, so none of the CLI integration works.

The notty screen splitting protocol should support a "GUI" interface shared by a single process, solving this problem.


This looks like an awesome project! You mention tmux, what about GNU Screen? does it work as well?

I don't remember major perf issues using vim within screen, I'm afraid to use Alacritty and then never be able to come back to my past setup :)


From what I understand, screen should be roughly equivalent. I mention tmux because it's my multiplexer of choice.


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?


No, of course you can't read all of the text at 10Mbps. The problem is that when you start some task which has a lot of spew, just having all of that text scrolling past can slow everything down to the point where the task actually takes longer! Even a few percentage points of slowdown can add up to minutes just sitting there twiddling your thumb.

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.


You think that your bottleneck is the terminal emulator, but you are wrong. As the mosh people pointed out a few years ago, the output from the remote machine has to scroll for 5 minutes because it is all backed up in the SSH connection between your machine and the remote one. Your bottleneck isn't in the terminal emulator at all, and changing terminal emulators to whizzy new ones will not make any difference to it.


yep: cmd &> /dev/null maybe? :) or ctlr-z; disown; exit... at any rate we're optimizing for edge cases


&>- would be faster, as long as we're at it.

But, the point is that sometimes it's a huge cost, and the rest of the time it's a tiny continuous slowdown.


since it's GL-rendered at 60+fps, will I see a much more smooth scrolling effect ? Does scrolling introduce lines discretely or continuously ?


Generally continuously, but it depends on how you scroll. If you're in `less` for example and holding the down key, you will probably see one line at a time, and it should be very smooth. It's possible with high key repeat rates that you might get multiple lines on some frames.


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


This is planned once Alacritty reaches an alpha release. Today's release is considered pre-alpha and is source-only.


from the readme [1]

    This initial release should be considered to be pre-alpha 
    software--it will have issues. Once Alacritty reaches an 
    alpha level of readiness, precompiled binaries will be 
    provided for supported operating systems.
[1] https://github.com/jwilm/alacritty


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.


Per [0], it looks as though only Bash on Ubuntu on Windows is being targeted, and not CMD or Powershell.

[0] https://github.com/jwilm/alacritty/issues/28


Very cool project, I'm trying it out, but this is an unrelated question: what is that Vim colorscheme in your screenshot? Do you have a link?


According to his dotfile repo[0] it is Tomorrow-Night-Bright.

[0]: https://github.com/jwilm/dotfiles/blob/master/vimrc#L6


Good find, thanks!


Any reason your not using conrod?

Browsing the sources it looks like you're re-implementing a non-trivial part of it.


The renderer is custom in order to have complete control over when and how the screen is drawn.


Any interest in adding tabs and native UI toolkit support?


Why is it starting terminal to run alacritty?

More

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: