What I would really like to see is more integration between terminal emulator and the shell (and commands you run in it). Currently in Fedora/GNOME the shell prompt is set up to make the terminal notify you (with a native GUI notification) about long running commands completing. That's cool, but we could go so much further.

For one, the shell could let the terminal know the current directory, hostname, username, git branch, current command, last command status, etc. etc.

The terminal then would display that info in its GUI, and perhaps even let you interact with it (imagine a GtkPopover for changing git branches and a Nautilus-like pathbar for the cwd!) We could then shrink back the prompt back to a simple dollar sign.

That would already be infinitely cool, but it gets better.

What if the shell could send its completions to the terminal and the terminal would display them in a native autocomplete widget (like in Builder)?

What if the terminal could track where the output of each command is and allow you to collapse/expand it with a GtkExpander? What if it could visually present each command and its output as this expandable card, along with the time it was issued and the time it took to run (like `time` outputs) and its exist code? And if it failed, paint that card red? And if it segfaulted, add a button to duck duck go the error, run ABRT or even run dnf debuginfo-install and coredumpctl gdb?

What if pagers like `less` could make use of the native scrolling instead of faking it by moving lines? What if `man` rendered the content to HTML (or GTK's native markup format) and presented it as an actual page, sort of like what you get by running `yelp man:foo` but right there in the terminal?

What if `ls` could make use of the native list/table widget and render file icons, just like Nautilus? What if you could expand the folders it outputs right there using mouse and get a tree view?

Don't tell me that fish or vim already display completions in a pop-up using some magical pseudographics. I'm not talking about abusing the old grid-of-characters model of terminals. I'm talking about making the shell and the terminal communicate better so we can use *native* (e.g. GTK+) widgets for what is traditionally done using text-based interfaces.

Mind, just like currently `ls` knows to columnize and colorize its output and `grep` knows to highlight the matches in red *when outputting to a terminal*, but fall back to plain text when piped to something, what I'm describing here would simply fall back to plain text when piped or run in a less magical terminal. So this is about enhancing the existing tools, not about breaking compatibility in any way.

And at the same time that would really get the terminal/shell experience from "emulating ancient hardware to be able to do stuff we haven't yet made a GUI for" to "a way to do advanced stuff with your computer using a command-based interface".

That would truly be a command-based interface for the 21th century. That would be something I'd be proud, not ashamed, to show off to Windows users as the advanced way to tune your system.

I've made a mock-up to illustrate my ideas about the next-gen terminal experience!

Featuring:
• the pathbar
• username, hostname and git branch displayed in the UI, shrinking the shell prompt back to just a $
• commands as cards
• syntax highlighting, including graying out the output a bit to differentiate it from commands themselves
• autocompletion (displayed in a native widget)
• built-in error handling options
• the time each command took (on the right)

@bugaevc this seems overcomplicated, I'd much rather have something like Acme or Plan 9's rio shells and build these things on top of that

@grainloom @bugaevc Both of you are not contradicting each other there :)

@ckeen @bugaevc I mean, it looks cool but uuugh, I hope it doesn't end up as its own OS and will integrate with the rest of the system

otherwise this just looks like ZSH with some GTK/Qt added

@grainloom @ckeen I am, in fact, a fan of Plan 9 and have used acme as my editor in the past! (On freaking :windows: 10 vk.com/wall268678817_641)

And this ideas are partly inspired by how Plan 9/acme/rio are all integrated, whereas in today's systems we have a sleek GUI and a powerful CLI that live in very different, disconnected worlds.

It would not be feasible to adopt acme's model directly, because modern interfaces are not all text, so instead, I opted to enhance the CLI UX with modern GUI advancements

@bugaevc @ckeen how about Emacs? they combine text with images pretty well AFAIK, although that IS its own OS

@grainloom @ckeen I don't know much about Emacs — are you talking about displaying images inline (with X11-specific hacks?..) or integrating actual GUI widgets into the CLI experience?

Follow

@grainloom @ckeen perhaps you can point me at a demo of how it works in Emacs then? I thought it was TUI-only, possibly in a basic GUI frame.

· · Web · 1 · 0 · 0

@bugaevc @ckeen I'm not a huge emacs user either, I sometimes use it with Idris and the Idris shell displays an image on startup

but maybe things like Jupyter are more relevant to the "what if we could render HTML in the terminal" question

@bugaevc @ckeen and these all use their own languages (well, jupyter has multiple kernels but whatever) so I'm curious how these would fit in with the shell

do they need a new shell language? or just new escape codes?

if this was Plan 9 these could be handled by things like /dev/draw but it's not

@grainloom @ckeen yes! Jupyter is *amazing*, even though it's web-based.

OTOH, I'm focusing on the Unix shell and native widgets here. Python/Jupyter is mostly about visualizing data — it does nothing to display or let you control the state of your Python session in its GUI.

@Shamar @ckeen @bugaevc @grainloom
$www-browser --dump $file

where www-browser is something like lynx or w3m.

@bugaevc @grainloom @ckeen @lanodan

I appreciate the objection, but printing text extracted by HTML is not rendering HTML for any useful definition of rendering. :-)

#Lynx dump IS rendering but without any interactivity.
Until it ignores #CSS, #JavaScript and any other external resource, it's not a road to #hell.

But integrate the rendering into a terminal emulator and you'll soon face the joy of #JS hijacking your shell.

@Shamar @ckeen @grainloom @bugaevc
If a program is hijacking your shell you have a serious Operating System hell.
Anyway elinks has CSS and probable JS support and does work in a terminal.

@lanodan @Shamar @ckeen @grainloom @bugaevc In fact it already has been done multiple times before :

TermKit
Terminology
Notty
Hyper

Sometime there is a working PoC sometimes just specs.

@lord @ckeen @bugaevc @lanodan @Shamar and it seems like a lot of them just needlessly replicate functionality that is better served by other applications, like image rendering :blobsad:

@grainloom @Shamar @lanodan @bugaevc @lord

On a more serious note: the disability to just render images on screen is the serial line interface heritage.

Plan 9's graphical windows are just graphical windows, you can blit anything on them. Even the shell could, no special support required (apart from generating the right pixels).

@grainloom @ckeen @bugaevc @lord @lanodan

Yet on rio, window + rc cannot intersperse text and graphics: when you need to see an image, you either open a new window or replace the contents of the current one.

AFAIK, you would need a different `window` program and a different shell to do that, exposing to rc a new folder (say /dev/images/) where you can copy an raster image to see it rendered as the output (under the command, before the next prompt).

I wonder if it's worth the effort though.

@grainloom @ckeen @bugaevc @lord @lanodan

I mean: once you are freed from the scrolling nature of a teletype, why you need a top-down sequence for image?

For text it make sense anyway, but for images?

@Shamar @ckeen @bugaevc @lord @lanodan
how do you reflow the text + images if you don't have a flow direction? rio windows can be resized and as a user i absolutely despise unresizable windows

@grainloom @ckeen @bugaevc @lord @lanodan

With text you have a flow direction.

Do you have a flow direction with images? It depends.

For example why the water-drop photo should be flowing with text in this screenshot?

@Shamar @ckeen @bugaevc @lord @lanodan
could it not work like a nested rio session where each (top-level ?) command in rc gets its own /dev/draw while it's running which is drawn under its invocation and after it finished running the multiplexing stuff is dropped and the image is stored with its position

slight problem: how do you echo -n > /dev/text for clearing images as well?

@grainloom @ckeen @bugaevc @lord @lanodan

You don't need a rio: AFAIK you can do most of this scripting a window: each window has it's own /dev/draw and if you cat it's wsys/n/window you get an image to show.

The "problem" is to show, scroll and reflow the immage with the text: simply there is no program that do that on Plan 9.

Actually, it shouldn't be that hard to write (but I've never programmed graphics in Plan 9 for real, just made others' programs work).

But is it a good idea or not?

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!