4 ms·

Great article. Terminal emulators / shells are an area where we haven't seen much improvement for years. I can't help but think there could be a much nicer comm

by davemp 5y ago

Great article. Terminal emulators / shells are an area where we haven't seen much improvement for years. I can't help but think there could be a much nicer command-line-esque interface other than a classic psuedoterminal and shell. At the same time, I doubt any improvements could really be large enough to gain adoption.

imsnif 5y ago
I totally agree. I'm actively working in that direction.
0235005 5y ago
I think that for sure something line the Plan9 shell woukd be something cooler to have
- MisterTea 5y ago
  As in graphics in the terminal? The way that works is through the draw(3) kernel device which is a 2d engine with an rpc interface. You load text and bitmaps into the draw device and then issue rendering commands. The kernel terminal device, cons(3) is where the terminal text is written to and cons sends that to to draw. When you start a graphical program, it overwrites the window graphics from cons(3) until the graphical program exits or the window deleted. There is no in band cursor control in plan 9 as it is a graphics oriented OS. So its not just porting a terminal. It's the entire OS. Of course there is p9p, plan 9 port, which is a port of the core plan 9 user space tools to Unix systems. It does offer a draw server that can be mounted.
  - vidarh 5y ago
    A lot of terminals supports at least somewhat similar functionality via Sixel (bitmaps) and ReGIS (vector graphics). It's limited and certainly could be improved a lot, though.
vidarh 5y ago
There have been many attempts. Sixel and ReGIS being among the oldest attempt at augmenting terminals with graphics. But most modern apps that run in terminals don't even push the limits of what terminals can do, and that makes it kind-of hard to justify putting effort into adding more capabilities to terminals. Part of the challenge is to find capabilities to add that are sufficiently simple and compelling to use in command line apps vs. as a web app or native GUI app that'd be more widely accessible than a new terminal capability.
- imsnif 5y ago
  IMO the issue is not the capabilities of the terminal, but rather the culture around it. It is very often seen as a "leet" platform for hackers and advanced users. Its users looked at with respect and envy. Which is unhealthy for the kind of adoption one would wish for in their apps. Really, I think this mostly requires imagination from those of us developing for this platform. We have all the capabilities we need. We just need to create apps that don't require you to look up cheat sheets and man pages to use, and provide powerful alternatives to existing GUIs. There's a bit of a renaissance in this area as of late, but I feel this is just the beginning.
  - lakecresva 5y ago
    Could not agree more with this. Thanks for the interesting article and your work on zellij.
  - vidarh 5y ago
    I think we're looking for very different things. I use my own text editor. I expect to remain its only user, and that's fine. It's not intentional. It just isn't a priority for me to make it usable for anyone else (though I do separate out parts of it into libraries / gems as functionality matures). As such, I'm looking for improved terminals not to make things that doesn't require cheat sheets (because to use my editor you'd have to be comfortable with reading the source). It's fine that others want other things, but I think this is part of the challenge with improving terminals: A lot of the user base are advanced users who want to improve their own workflows, not write something user friendly, and who wants tools that are easy to combine and chain, where the priority is not something user friendly. The balance is fine in that if you're looking for something particularly user friendly in the sense of friendly to less advanced users, targeting a GUI framework or the web is very quickly going to provide a better experience. EDIT: I saw zellij mentioned in a sibling, and looked at it, and incidentally it's quite similar to my setup, except I use bspwm and scripts to manipulate the tiling so that e.g. doing a vertical or horizontal split in my editor results in a new editor instance in a new tiled window rather than in a new pane in a single terminal. That way I can treat the few GUI apps I use exactly the same way (mostly Chrome). I'd love it if there was a standard API to split panes and start apps in a given pane, so both terminal multiplexers and tiling wms could be targeted with a single standard mechanism.
uuddlrlr 5y ago
TempleOS comes to mind.
matheusmoreira 5y ago
Can terminals even be improved without breaking everything? Even maintenance work and fixing bugs has historically caused problems: https://lwn.net/Articles/343828/ https://lwn.net/Articles/343828/

by davemp 5y ago

imsnif 5y ago

I totally agree. I'm actively working in that direction.

0235005 5y ago

I think that for sure something line the Plan9 shell woukd be something cooler to have

MisterTea 5y ago
As in graphics in the terminal? The way that works is through the draw(3) kernel device which is a 2d engine with an rpc interface. You load text and bitmaps into the draw device and then issue rendering commands. The kernel terminal device, cons(3) is where the terminal text is written to and cons sends that to to draw. When you start a graphical program, it overwrites the window graphics from cons(3) until the graphical program exits or the window deleted. There is no in band cursor control in plan 9 as it is a graphics oriented OS. So its not just porting a terminal. It's the entire OS. Of course there is p9p, plan 9 port, which is a port of the core plan 9 user space tools to Unix systems. It does offer a draw server that can be mounted.
- vidarh 5y ago
  A lot of terminals supports at least somewhat similar functionality via Sixel (bitmaps) and ReGIS (vector graphics). It's limited and certainly could be improved a lot, though.

vidarh 5y ago

There have been many attempts. Sixel and ReGIS being among the oldest attempt at augmenting terminals with graphics. But most modern apps that run in terminals don't even push the limits of what terminals can do, and that makes it kind-of hard to justify putting effort into adding more capabilities to terminals. Part of the challenge is to find capabilities to add that are sufficiently simple and compelling to use in command line apps vs. as a web app or native GUI app that'd be more widely accessible than a new terminal capability.

imsnif 5y ago
IMO the issue is not the capabilities of the terminal, but rather the culture around it. It is very often seen as a "leet" platform for hackers and advanced users. Its users looked at with respect and envy. Which is unhealthy for the kind of adoption one would wish for in their apps. Really, I think this mostly requires imagination from those of us developing for this platform. We have all the capabilities we need. We just need to create apps that don't require you to look up cheat sheets and man pages to use, and provide powerful alternatives to existing GUIs. There's a bit of a renaissance in this area as of late, but I feel this is just the beginning.
- lakecresva 5y ago
  Could not agree more with this. Thanks for the interesting article and your work on zellij.
- vidarh 5y ago
  I think we're looking for very different things. I use my own text editor. I expect to remain its only user, and that's fine. It's not intentional. It just isn't a priority for me to make it usable for anyone else (though I do separate out parts of it into libraries / gems as functionality matures). As such, I'm looking for improved terminals not to make things that doesn't require cheat sheets (because to use my editor you'd have to be comfortable with reading the source). It's fine that others want other things, but I think this is part of the challenge with improving terminals: A lot of the user base are advanced users who want to improve their own workflows, not write something user friendly, and who wants tools that are easy to combine and chain, where the priority is not something user friendly. The balance is fine in that if you're looking for something particularly user friendly in the sense of friendly to less advanced users, targeting a GUI framework or the web is very quickly going to provide a better experience. EDIT: I saw zellij mentioned in a sibling, and looked at it, and incidentally it's quite similar to my setup, except I use bspwm and scripts to manipulate the tiling so that e.g. doing a vertical or horizontal split in my editor results in a new editor instance in a new tiled window rather than in a new pane in a single terminal. That way I can treat the few GUI apps I use exactly the same way (mostly Chrome). I'd love it if there was a standard API to split panes and start apps in a given pane, so both terminal multiplexers and tiling wms could be targeted with a single standard mechanism.

uuddlrlr 5y ago

TempleOS comes to mind.

matheusmoreira 5y ago

Can terminals even be improved without breaking everything? Even maintenance work and fixing bugs has historically caused problems: https://lwn.net/Articles/343828/ https://lwn.net/Articles/343828/