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