[em-bee]

i think part of the problem is the archaic interface that is needed to enable feature rich terminal apps. what we really want is a modern terminal API that does not rely on in-band command sequences. that is we want terminals that can be programmed like a GUI, but still run in a simple (remote) terminal like before.

[ButlerianJihad]

plan9 and 9term solved this decades ago, right?

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OnTerminal...

[em-bee]

seems they removed the dangers, but didn't provide an alternative to write safe terminal apps.

[ori_b]

Graphics. They're network transparent, and take over the terminal.

Terminal apps were obsolete once we had invented the pixel. Unix just provides no good way to write one that can be used remotely.

[em-bee]

Unix just provides no good way to write one that can be used remotely

well that's the issue, isn't it?

the graphics options that we have are slow and complex, and they don't solve the problems like a terminal and therefore the terminal persist.

[ori_b]

Yes, and plan 9 solved this; you open /dev/draw and start drawing.

[anthk]

Plan9 has no terminals. Well, it actually has one in 9front, vt(1), but as a tool to call against Unix systems (such as ssh), not to interact with 9front software. vt(1) in 9front it's as 'native' as HyperTerminal in Windows.

[kps]

A network-transparent graphics protocol? Who would ever think of such a thing?

[em-bee]

that's actually not what i am after. what i envision is a graphical terminal, that is a terminal that uses graphic elements to display the output.

consider something like grep on multiple files. it should produce a list of lines found. the graphical terminal takes that list and displays it. it can distinguish the different components of that list, the filenames, the lines matched, the actual match, etc. because it can distinguish the elements, it can lay them out nicely. a column for the filenames, colors for the matched parts, counts, etc.

grep would not produce any graphics here, just semantic output that my imagined graphical terminal would be able to interpret and visualize.

[jodrellblank]

PowerShell and Out-GridView are a rudimentary version of this. It looks like:

https://blog.rmilne.ca/wp-content/uploads/2020/04/image_thum...

PowerShell cmdlets output .NET objects with properties, in that example Get-Process makes an object-per-running-process with properties for Name, Id, and more. Out-GridView takes arbitrary objects and draws a resizeable GUI window with a list of the input, properties as columns, sortable, filterable, and has options to use it as a basic "choose one of these and click OK" user-prompt. It works with the grep-analogous cmdlet:

    select-string '<regex>' <filename(s)> | out-gridview

    # shorthand
    sls foo *.txt | ogv

and the output is the filename, line number, line, and regex match groups, of each match. [This dates back to Windows XP SP2, in 2004].

If we're talking about things we imagine in terminals, one I have wanted is multiple windows for making notes, similar to having a text editor open constantly reloading a file on any changes and running some terminal commands with tee into the file, but better integrated - so I could keep a few useful context results but ignore logspam results; and "keep" in another window without having to copypaste. Something better integrated - it always gets all command output, but disposes of it automatically after a while, but can be instructed to keep.

[jcgl]

That'd be really cool. I'd never thought about enabling deeper graphical capabilities in a shell. But if you were to have a shell with rich objects rather than dumb bytes, that is a world that would open up!

PowerShell, for instance, has Format.ps1xml[0] that allows you to configure how objects get displayed by default (i.e. when that object gets emitted at the end of the pipeline). Such a concept could in principle be extended to have graphical elements. How cool would it be to have grep's output let you collapse matches from the same file!

[0] https://learn.microsoft.com/en-us/powershell/module/microsof...

[WesolyKubeczek]

We call those “web browsers” nowadays, they even can execute untrusted code to make your UI livelier…

[skydhash]

Isn't that Emacs?

[anthk]

We have namespaces from the day one. Proper namespaces.

[red_admiral]

I shudder at the amount of backwards compatibility that would break. Is there anything more complicated than a simple input-output pipe (cat, grep, ...) that doesn't use terminal escapes? Even `ls --color` needs them!

[em-bee]

right, envision that we get tmux working in that new terminal (and that's already happening, just look at tmux -CC), then it can be there for all the backwards compatibility stuff while modern apps and maybe a new modern multiplexer work without.