[lobster_johnson]

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

[twic]

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!

[atombender]

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.

[seeekr]

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

[ori_b]

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

[arandomcoder]

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

[netheril96]

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

[chriswarbo]

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.

[atombender]

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

[chriswarbo]

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

[netheril96]

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

[vidarh]

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.

[martanne]

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

[tatterdemalion]

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.

[lisivka]

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.