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

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.

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

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.

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