
CLUI: Building a Graphical Command Line - amasad
https://blog.repl.it/clui
======
atoav
As somebody who worked professionally with Adobe Premiere I think the
criticism of its UI misses the point. Premiere was never meant for hobbyists
(reflected by it's actual name: Premiere _Pro_).

The only valid point made here is that it is hard to learn for someone who
never used any editing software at all. But it certainly isn't slow or
"unfocused". That source monitor is on screen for a reason. Keyboard shortcuts
will always be faster than moving your mouse around. And by the way: Premiere
has a modular interface, so if you hate the clutter or don't need it, you can
get rid of it.

If you are the person who just wants to edit some stuff together once a year
Premiere _Pro_ is not for you. Turns out software interfaces that are meant to
be used by people 8 hours a day for weeks at a time follow different design
paradigms than stuff made for amateurs. I'd go completely insane if I had to
edit a movie on anything simpler tho.

I like their TLI ideas, but I am honestly a bit alergic against designers who
lack the phantasy of realizing that sometimes a UIs complexity is a reflection
of the complexity of the problem it helps to solve in conjunction with the
level of control you want to give to the user.

Steep learning curves should be avoided — sure — but sometimes they are
necessary to shave of that extra second. Something that multiplies if you do
it hundred times an hour.

Premiere is like vim: not for everybody, but if you wield it in the right way,
there is not much that can beat it.

~~~
Cthulhu_
It's why I use intellij instead of e.g. vim at the moment, I can use a lot of
the features and they provide a definite advantage over my previous editor, VS
Code, which was also pretty densely packed with features (although it has a
much cleaner UI).

The other question is discoverability. I mean I'm sure vim is incredibly
powerful, but none of the features are obvious and you have to trudge through
two decades of websites to discover anything.

I've been unable to find out (actually I haven't really looked) how to use vim
as a software developing tool (with basic features like autocomplete/suggest
and error reporting)

~~~
buzzkillington
>I've been unable to find out (actually I haven't really looked) how to use
vim as a software developing tool (with basic features like
autocomplete/suggest and error reporting)

Vi is a text editor with an incredibly powerful language to edit text tied to
keyboard keys.

Emacs is a lisp interpreter that's optimized for text editing.

They are not IDEs.

~~~
jpitz
What do you consider to be the defining set of features for an IDE, and what
do you think Vim and Emacs are lacking from that list?

~~~
mdtusz
They are not integrated.

That said, vim and emacs can be in a way a component of a DIY IDE - you just
need to put the work in and build it yourself. I exclusively use vim with a
handful of useful plugins, scripts, and additional CLI tools in other terminal
splits.

The terminal is my IDE.

~~~
kragen
The standard way to use Emacs is as an IDE; you use M-x compile to run the
compiler in a window under Emacs and M-x gdb to run the debugger in a window
under Emacs, in both cases with hypertext capabilities. These are standard
packages included in a default Emacs install, although you may want to bind
them to more convenient keys. (I bind [f5] to recompile.) You do not need to
run Emacs in a terminal, and copy and paste to and from Emacs (not to mention
things like viewing SVGs you're editing) works better if you run it in a
window on its own. You do not need to "put the work in and build [an IDE]
yourself" if you are using Emacs.

(Of course if you're writing programs in Elisp, Emacs is a more tightly
integrated IDE, but the success of Emacs, org-mode, Magit, and Amazon
notwithstanding, Elisp is not a very good programming language. Also, if you
run Emacs in a terminal, you can quite reasonably use it over a low-bandwidth,
high-latency ssh -C connection, and it becomes good for remote pair
programming, which is not true of running Emacs in VNC. I haven't tried
running it in Xpra.)

Historically Emacs started up far too slowly and used far too much RAM to be
convenient to use it in the way you're describing, as a text editor invoked by
a larger IDE; I remember waiting over a minute for a new Emacs process to
start up in the mid-90s. Nowadays it might be reasonable, but it still takes
almost 4 seconds on this laptop, which I find to be a painfully long wait for
opening a file. Also, Emacs's language-agnostic autocomplete M-/ works a lot
better if you have a lot of files open in the same Emacs session.

Although there are packages that configure Vim to work the same way, it is
more common to use Vim in the way you describe, as a component of the IDE
rather than an IDE in its own right. And Vim has the great advantage that it
starts up instantly, and the advantage or disadvantage that its equivalent of
M-/ (^P and ^N) is buffer-scoped, so it doesn't matter if you have more files
open.

~~~
sedachv
> Nowadays it might be reasonable, but it still takes almost 4 seconds on this
> laptop, which I find to be a painfully long wait for opening a file.

That is one of the use cases for emacsclient/Emacs server.

~~~
kragen
Yes! I should have mentioned that. I mostly use emacsclient as an $EDITOR for
git and similar programs in Emacs shell-mode, but you can also use it as a
version of Emacs that you can run quickly in a tmux window, if that's what
floats your boat!

------
amasad
Might be interesting to people here: this blog is hosted on Repl.it on a
single repl/container[1] (2GB memory, 2vCPUs[2]) that's also powering IDE
functions like editing, collaboration, chat, intellisense, etc.

We're able to fix typos and bugs and have it live-deployed as it's serving
traffic. I recorded a gif here of what it looks like from the inside:
[https://twitter.com/amasad/status/1235742525056380929](https://twitter.com/amasad/status/1235742525056380929)

Where is the fabled "hackernews hug of death" if a tiny container can handle
the traffic? :-)

[1] [https://repl.it/@turbio/replit-blog](https://repl.it/@turbio/replit-blog)

[2] [https://repl.it/site/pricing](https://repl.it/site/pricing)

~~~
lonelappde
Hug of death is for non static content. And sometimes people unnecessary
dynamically generate their static content.

~~~
amasad
Unfortunately we fall into that bucket. It's a dynamic app :-)

------
carapace
> On a technical level, a CLUI command is conceptually similar to a file path
> or URL. Since a complete CLUI command is simply a path down the command
> tree, each potential subcommand is like a portion of a file path or URL.
> Flags, on the other hand, function like query parameters. CLUI’s resemblance
> to URL paths means you can send someone a complete, executable CLUI command
> as a URL. They’re mapped 1:1.

This is really cool.

> Since we have a GraphQL backend, we know all the potential fields and
> arguments a client can use. By using an introspection query we generate a
> tree of commands/sub-commands that map onto their respective resolve
> functions. Now, to add a new admin command all that's needed is a new field
> on a GraphQL type.

And _that 's_ really _really_ cool.

The main thing I see that could be improved would be a clear, simple
underlying model or metaphor, a semantic layer that sits between the CLUI and
the GraphQL backend, to unify and simplify the various contexts and languages
and runtimes and whatever.

I've been toying with a UI demo that unifies GUI and CLI through a dialect of
the Joy language. Everything you can do at the CLI can be done through the
mouse, and everything done through the mouse has a corresponding textual
representation as Joy code. It's inspired by Oberon OS and Jef Raskin's
"Humane Interface" (among other influences.) I haven't integrated widgets
(yet) because you mostly don't need them, mostly.

W/O getting into a lot of details, there are no menus nor buttons because any
text can be used to activate any command and/or enter any data; there are no
forms because the UI metaphor (Joy) is stack-based so you just put values onto
the stack; and so on.

~~~
asiachick
Autodesk Maya has always been both CLI and GUI based. Every GUI interaction
generates a visible CLI command you could have typed to accomplish the same
thing. It’s been the way since PowerAnimator in the 90s

~~~
kragen
I think AutoCAD has been this way for a long time too. The first version I
used was 2.14K+ADE; you could invoke any operation from the keyboard (and
often had to) but I don't remember if selecting from menus with the mouse
would generate the CLI command. In later versions of AutoCAD it did.

~~~
donaldihunter
Yep, automating CSG, transforms etc. from the command line in AutoCAD was very
powerful. I fondly remember a Stonehenge 3D model project from school.

~~~
kragen
I don't think it was possible to automate anything in 2.14K+ADE (that was
before AutoLISP), and its 3-D support was almost nil, let alone CSG.

------
wrigby
The discoverability aspect of this reminds me quite a bit of working on a
Cisco IOS command line. At any point while typing a command, you can mash the
? key, and the shell will print out a list of acceptable inputs given what
you've already typed (this example stolen directly from Cisco's docs[1]):

    
    
      Router# configure ?
       memory             Configure from NV memory
       network            Configure from a TFTP network host
       overwrite-network  Overwrite NV memory from TFTP network host
       terminal           Configure from the terminal
       <cr>
    
    

It's really quite a great experience.

1:
[https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken...](https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken_guide/cli.pdf)

~~~
macintux
I recall working on a Pix firewall, which IIRC was a product Cisco acquired
from someone else and had something IOS-like, and a true Cisco IOS router more
or less simultaneously.

The difference in usability between the two was quite notable, exactly for
that reason.

------
highmastdon
This reminds me of what fish [1] (friendly interactive shell) brings for me.
Together with z for directory jumping [2] and fzf for interactive lists [3]
there's really no need for a "finder" or "explorer".

Aside from it I've run into Xiki [4] that seems to bridge the gap on multiple
levels between GUI and CLI. GUI to bring the discoverability and CLI to keep
it scalable.

[1] [https://fishshell.com/](https://fishshell.com/) [2]
[https://github.com/jethrokuan/z](https://github.com/jethrokuan/z) [3]
[https://github.com/jethrokuan/fzf](https://github.com/jethrokuan/fzf) [4]
[https://xiki.org/](https://xiki.org/)

------
Someone
Macintosh Programmer’s Workshop had something similar in 1986
([http://mirror.informatimago.com/next/developer.apple.com/too...](http://mirror.informatimago.com/next/developer.apple.com/tools/mpw-
tools/commandref/commando.html)). It was incredibly useful.

Apple’s first Unix copied that in 1988
([http://toastytech.com/guis/aux3.html](http://toastytech.com/guis/aux3.html))

Powershell has ‘Show-Command’ which also is similar
([https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.utility/show-
command?view=powershell-7))

I think PowerShell generates the GUI, while MPW commando had human-designed
dialogs (and, for complex commands such as compilers, sub-dialogs)

I think this is worth copying in modern Unixes. Those GUIs make it way easier
to use rarely used flags than man pages.

~~~
uxamanda
Wow, Commando looks really similar to the Kui tool mentioned in a sibling
comment [0]. Would you agree? Or was Commando only used for options / an
alternate to flags?

[0]
[https://news.ycombinator.com/item?id=22500032](https://news.ycombinator.com/item?id=22500032)

~~~
Someone
Commando didn’t do graphical output. It was a tool to help compose a command
line. Command output went to the terminal, or, in MPW, into the file being
edited (Mac OS didn’t have a terminal)

~~~
uxamanda
Ah, I see, input vs output. Could see both being useful at the same time.

------
satya71
This just reminded me of Emacs. There's not a whole lot of menus. All the
available commands (also variables and values) can be searched and
autocompleted. The initial hump is hard to get over, but after that things are
so discoverable and extensible it's a pleasure.

I recently switched to VS Code for creature comforts that come from a much
large ecosystem and using more modern OS affordances. VS Code gets close but
not quite as pleasant as Emacs.

~~~
eequah9L
I wish LibreOffice, GIMP etc. had an M-x way of finding the commands, and a
describe-function to ask what exactly a given command is doing. Or C-h b way
of sifting through keyboard shortcuts, in just another buffer with search and
everything.

~~~
chootisk
GIMP has something similar, triggered by pressing /. I discovered it way too
late, but I haven't touched a menu ever since.

Libreoffice has a feature request for such a function [1].

[1]:
[https://bugs.documentfoundation.org/show_bug.cgi?id=91874](https://bugs.documentfoundation.org/show_bug.cgi?id=91874)

~~~
eequah9L
Wow, thank you!

------
p_l
Congratulations to repl.io team on rediscovering Symbolics Lisp Machine's
Dynamic Windows / Common Lisp Interface Manager's _presentation_ and
_listener_ systems!

Not being sarcastic, even - it's a pretty powerful approach that deserves
better, unfortunately distribution of knowledge in Computing Science,
especially historical knowledge if you never encountered it yourself, is
pretty hard.

~~~
amasad
That's interesting -- thanks for sharing! I try to be as erudite in computer
history as possible but I still somehow missed this.

I pay homage to the Lisp community w/r/t programming interfaces in this post:
[https://amasad.me/disintegrated](https://amasad.me/disintegrated)

~~~
hhdave
Genera on the Lisp Machine is very much an embodiment of this graphical
command line (or rather just command) user interface. There's quite a lot to
it. CLIM (and the open source McCLIM) is the current realisation of this.

There's some documentation about 'Commands' in CLIM II here for example:
[http://www.lispworks.com/documentation/lwu41/climuser/GUID_1...](http://www.lispworks.com/documentation/lwu41/climuser/GUID_194.HTM#HEADING194-0)

Commands are first class objects which live in command tables and which CLIM
can look at to generate bits of UI and allow parameters to be specified.
Central to this in CLIM is the idea of presentations - where domain objects
are 'presented' onto the screen and the link to the domain object is
maintained. That way you can invoke a command on that object in various ways,
for example you can type a command name and then click a presented object
which is acceptable as a parameter.

The Symbolics S-packages used these concepts to make (I presume) powerful 3d
modelling programs back in the day (I haven't used them):
[https://www.youtube.com/watch?v=gV5obrYaogU](https://www.youtube.com/watch?v=gV5obrYaogU)
\- sorry for the poor video quality.

[https://twitter.com/rainerjoswig?lang=en](https://twitter.com/rainerjoswig?lang=en)
(lispm on here) sometimes posts interesting things about Genera

------
dreary_dugong
While I agree wholeheartedly with the stated goals, I do worry that the CLUI
isn't quite as perfect s solution as it's implied to be. The CLUI is listed as
having all of the upsides of both GUI and CLI but none of the downsides of
either, but I feel it's more like halfway on everything. It's /more/
approachable than a CLI, but still /less/ approachable than a GUI and this
goes for most of the categories listed. It's still an interesting idea but it
strikes me as a bit risky. At what point does less approachable become too
unapproachable? I fear CLUI may have accidentally gained many of the downsides
at the same time as mere pieces of the upsides

~~~
airstrike
I agree. It feels like an improvement over the very limited interaction from a
plain CLI, but it isn't foolproof. The user still needs to know e.g. whether
the right way to set an user's role is through 'admin roles' or 'admin user'

~~~
tangert
replit designer here - yes, totally agree. the current implementation
definitely is not foolproof, but it's just the start. ideally it will handle
more unstructured commands in the future!

~~~
airstrike
For the avoidance of doubt: I think this is awesome! Keep up the good work!

~~~
tangert
thank you :)

------
hawaiian
Bash already has autocomplete and there are shells with richer feature sets.

What I would like to see is something like CLUI to be integrated with an IDE
or a productivity tool like Adobe Photoshop. PyCharm/JetBrains already
embraces the keyboard with double-Shift => Search Everywhere, and other
similar shortcuts. Similarly, Photoshop would benefit from keyboard
interaction for common tasks. We already have single-pixel nudge actions via
the arrow keys, but a CLI prompt you could conjure up and type into would be a
game changer for actions that require repetition and precision.

That is, rather than bringing GUI to the CLI, bring CLI to the GUI.

~~~
ash
> Bash already has autocomplete

What kind of autocomplete does bash have? Do I need to enable it? I've just
tried bash 5.0.16. I don't see any. For example, I've typed `pw`, but `pwd`
was not suggested to me.

(I know there's Tab-completion, this is _not_ what I'm talking about. I'm
looking for automatic completion. Similar to Google's search suggestions and
CLUI demo.)

~~~
andai
I think fish has that?

~~~
ash
Thanks! Fish is close, but not there yet. It provides only a _single_
autocomplete suggestion. I had to press Tab to get a list of suggestions. So:

bash: no auto suggestion at all, Tab twice to see a list

fish: shows single auto suggestion, Tab once to get a list

zsh + zsh-autosuggestions: looks similar to fish behaviour

Is there some combination of shell/plugin/terminal that provides _multiple_
auto suggestions?

------
boilerupnc
Another great project in this space is Kui[1] - a framework for graphical
terminals. It gives a hybrid command-line/UI development experience for cloud-
native development.

[1] [https://github.com/IBM/kui](https://github.com/IBM/kui)

~~~
moudy
nice. I've seen this with markdown previews but makes total sense to
generalize

------
dangoor
This is cool, and it's great to see you work on this (and thanks for open
sourcing!)

One more bit of prior art that might be interesting to you: I worked on the
Mozilla Bespin project a long time ago with Joe Walker. Joe was also really
big on the command line idea for much the same reason and created
[GCLI]([https://github.com/joewalker/gcli/blob/master/docs/index.md](https://github.com/joewalker/gcli/blob/master/docs/index.md)).

GCLI ultimately landed in Firefox Developer Tools, but I don't think it's in
the current shipping version. Funnily enough, I just found a video on YouTube
of me demoing the command line in Firefox Dev Tools:
[https://www.youtube.com/watch?v=YwOwJ1_JaKE](https://www.youtube.com/watch?v=YwOwJ1_JaKE)

The state of the art in web UIs has definitely moved forward, and I'm really
happy to see more experimentation with graphical command lines.

~~~
uxamanda
This is great! Would love to hear more about your experience working on it if
you are interested in sharing – did you notice any particular tasks where this
type of interaction shined?

My dream would be to have something like built into an IDE so I could save
edits directly.

~~~
dangoor
As features go, this didn't prove to be super successful (it's no longer
shipping with Firefox).

I do still think it's a valuable interaction style for being able to activate
less-frequently-used features all from the keyboard. It's possible that the
fact that web browsers _also_ have the JS Console is just too much, because
the JS Console has a command line that people are familiar with. The
interaction model is very different, though. GCLI made it quick to type
commands, whereas the JS console requires valid JS.

~~~
uxamanda
Interesting, I could see how that could be confusing.

------
dreamcompiler
This description sounds very much like CLIM, which was a graphical, clickable
CLI originally designed in the early 80s for Lisp machines. (CLIM is much more
than that, but building a graphical CLI is one of the things that's easy with
CLIM.)

[https://en.m.wikipedia.org/wiki/Common_Lisp_Interface_Manage...](https://en.m.wikipedia.org/wiki/Common_Lisp_Interface_Manager)

------
fit2rule
I regularly use a pretty GUI-intense program, called REAPER, for editing
digital audio. Its a very powerful application, full of amazing features and
powerful yet simple tools.

Its a bit daunting at first, and can be overwhelming if you don't really have
the patience to dig into it and find where everything is, in terms of grouped
functionality.

However, one key thing made learning to use REAPER smooth as butter - the '?'
key. This shows the "Action List", which is a list of all the things you can
do in REAPER, in a text list .. so I can quickly type '?' \- then 'section'
and find all the actions related to sections. VERY useful, and quite a great
way to explore the periphery of features I would otherwise not have
discovered.

In fact, its the very first thing I teach anyone I'm introducing to REAPER,
that they should use. I'd say, without this "text-based UI", the rest of the
program wouldn't be nearly as accessible. A lot of that has to do with the
fact that the REAPER developer seems to have a Power > Eye-candy attitude
about the UI design - its clean, minimal, and functional when you first get
started - but the UI is also fully tweak-able such that once you start getting
productive with it, you find ways to make the GUI really shine (track colours,
Layout customisations, etc.)

Anyway, I think its pretty interesting that the entire UI is accessible from
the text-based '?' Action list query... I wish more programs would adopt this
abstraction.

------
InfinityByTen
I wouldn't take this article to be a be all, end all. It's quite thought
provoking for me personally. The reason I switched from bash to zsh was simply
the UI like interface in path completion with OhMyZsh. The reason sublime
works quite well for me is that there are tabs that I love to move around and
see at the same time and I like the visual feedback of moving things around
and switching contexts. But if I want to do something quickly.. I can easily
find the command for from a simple keyboard shortcut.

I think this idea can be refined further and made more and more robust and is
a design pattern in the right direction. With more and more percentage of the
population heading in coding-friendly direction I see this as a very viable
next step.

------
ratel
I think it is an interesting idea that needs some further exploration.

I do see some problems with it that were not addressed. The way the demos are
setup are by definition an NP!=P problem. It is easy to verify you found the
right command, but may be fiendishly difficult to navigate the tree to get
there. Menus with sub-menus having sub-menus at least makes it visually clear
which paths you have not taken and allow retracing your steps. Something akin
to Ctrl-R in shells may be needed to allow you to type certain keywords to
find all possible actions.

Options and parameters are not part of a decision tree as they don't specify a
logical action that will follow, they just change the action. Those parameters
need evaluating the entire progress in the tree to be able to suggest a next
available parameter, option and action. Try it with something like ffmpeg.
Modelling this to work in a CLUI will evolve into a hard problem very quickly.

The more actions, options, parameters I add as a user the more important it
becomes that I can backtrack and correct mistakes. Corrections may or may not
have consequences for the position in the tree I already choose. Starting over
even from there might not be the right solution in terms of usability if the
correction does not necessitate it.

------
smitty1e
One interface that reeks of genius is Magit[1]

Taking a sprawling interface like that of git and making it work in a console
window in Emacs is an idea that bears repetition across other tools, e.g. tar.

Would I'd the time to work on such.

[1] [https://magit.vc/](https://magit.vc/)

~~~
sullyj3
Is there anything similar that doesn't require me to use Emacs?

~~~
Myrmornis
I sort of want to question what you mean exactly by "use Emacs"? Emacs is a
lisp environment / UI framework for application development. So in principle
saying you don't want to use an application implemented in Emacs is like
saying you don't want to use an application implemented in Electron. I'm only
85% serious there, obviously Emacs has a certain amount of cruft that Electron
I assume does not.

You could start an emacs process just in order to use Magit -- you wouldn't
have to use it for anything else. However, I totally understand that you might
well not want to mess about configuring emacs to load magit and working out
how to start it etc. How about these?

[https://github.com/vlandeiro/magit-
docker](https://github.com/vlandeiro/magit-docker)

[https://github.com/akirak/nix-magit](https://github.com/akirak/nix-magit)

~~~
omaranto
There are some people who refuse to use applications implemented with
Electron.

------
screenbeard
I was with you for the first half, until the demo of the command completion
with clickable dropdown options and thought it looked just like the nested
menus you're trying to kill. The difference is a slightly less cluttered
interface, but for someone who knows what they're looking at is a menu all
that different than selecting a command that gives a subset of followup
commands on a single line?

~~~
Sammi
The article addresses this:

"Because the tree is hierarchical, you might think that it actually resembles
a large dropdown menu. The difference is that search is built directly into
its navigation, not just pointing and clicking. One clear improvement that
could be made is being able to search for any subcommand without having to
specify its parent command first. That way you can access any deeply nested
information instantly, similar to spotlight search."

------
time4tea
AutoCAD amongst other software has been doing this for about 25+ years, I
think. Clicky-clicky if you want, or just type in the command, same output.

IntelliJ also, more recently, with its actions input.

~~~
jfoucher
I absolutely loved autocad for this. One hand on the keyboard, one on the
mouse is an easy way to double your productivity. The speed at which you could
draw things was amazing. I had a custom alias file with most commonly used
shortcuts and the enter key was bound to right click which removed the need to
move your left hand over the keyboard. This was in the 2000. Sadly the more
recent versions I have tried make this harder to do. If I hadn’t switched
career I’d still be using autocad 2000 !

~~~
TheSpiceIsLife
I use DraftSight with AutoHotkey and a Razer Naga, makes CAD work very swift!

------
lqs469
This idea is so great, really like it. But I don’t know how practical it is.
From the article, It improves the UI and interaction of the CLI, "That means
that images, gifs, video, graphs, interactive diagrams, buttons, and forms
should be able to integrate directly into the CLI experience." which may
improve the user experience, But the basic mode of interaction of CLI doesn't
change. The CLI experience is still not intuitive. Maybe CLI will work well
for simple scenarios, but I don't know if it is a good choice for the complex
circumstances. The complex interaction and graphical interface display of some
industrial scenes may not be well expressed by the CLI, Even they cannot
interact only through the keyboard. So I worry that CLUI will face a situation
where complex circumstances are too much to handle and simple scenarios are
unnecessary. Actually, there has been some CLI tool through shortcuts and
custom instruction to do these things (autocomplete, fuzzy-search, tips or
guidelines) with text way, They also did well.

~~~
silentwanderer
I think the main value of CLUI is that it flattens the learning curve for
users who don't normally use the terminal, not that it scales all the way from
new users to experienced ones.

~~~
lqs469
Completely agree.

------
elagost
It's been more than 5 years since I've used AutoCAD or other AutoDesk
professional design software, but it has this. There's a command line that
interfaces very well with its GUI. You can draw shapes entirely in the command
line, or you can use it to help you place a second point in a line, for
example.

------
pault
The help > search menu is the thing I miss the most from Mac OS since I
switched to windows. Especially in programs like Photoshop where there are
dozens of nested dropdowns, hitting cmd + ?, typing a few characters, and
hitting enter is such a huge boost to productivity when you haven't memorized
all of the keyboard shortcuts, and it even works on menu items that don't have
a shortcut. The Microsoft office suite has this functionality as well, and I
really wish they would integrate it at the system level like Mac OS does.

~~~
uxamanda
Agreed, love this feature and use it often. I wish it saved the last few
searches to quickly access commonly searched items.

------
lapinot
I really like the general idea of bridging the gap between graphical and text-
based interfaces, abstracting away the differences and be able to use a
mixture of both. In the realm of interactive programming (eg heavily ide
assisted), people with some functional and statically typed programming
background would be interested in this magnificent talk about idris2:

[Edwin Brady - Idris 2 - Type-driven Development of Idris]

[https://www.youtube.com/watch?v=DRq2NgeFcO0](https://www.youtube.com/watch?v=DRq2NgeFcO0)

------
0xCMP
Using an iPad has inspired me to rethink things like terminal and CLUI is very
close to ideas I’ve been wanting for work on for a long time.

My idea originally came from using ssh on my iPad and thinking it would be
cool if more native controls were used over RPC instead of text to display
what was happening on the server. Then I could more easily navigate the
responses and maybe even if there was more intelligent autocomplete which a UI
on iOS could take advantage of. Or maybe interactive confirmations and stuff
(similar to what was Demo’d). And also then provide an easy way to edit files
using either a remote editor or a way to sync changes being done in a local
editor. Kind of how vscode seems to do it (e.g. a remote service handling the
work)

The one thing a system like I’m describing would still need is the ability to
switch from this rich interface back to the terminal when using things like
tmux, curses, or vim/emacs because obviously those things still work well.

But the cool thing was realizing that this would also be great on the desktop.
Looked into some terminals like Hyper thinking maybe I could hack those up to
get a proof of concept for myself, but can’t find the time. And obviously it
wouldn’t work for the iPad where I really wanted it.

------
johnlorentzson
This reminds me a bit of the Dynamic Lisp Listener from Symbolics Genera-based
Lisp machines.

------
Razengan
The examples look really cool. I'd like to add a sort of wish I have for such
a "smart CLI": Being able to preview the effect of the command(s) you're
currently typing, like the files/directories it's going to modify, whether
it's going to change something for the entire system or specific users.

Something like that would lower the intimidation factor for beginners even
further.

------
tenaciousDaniel
This is really cool. I'm actually building a coding language for UI designers,
and a UI like this would be super helpful.

~~~
moudy
that sounds interesting. do you have anything you can share?

~~~
tenaciousDaniel
Not yet, but hopefully I'll have something simple to show in the next few
months.

------
momokoko
So, upterm[0] / hyper-autocomplete[1]?

[0] [https://github.com/railsware/upterm](https://github.com/railsware/upterm)
[1] [https://github.com/Inlustra/hyper-
autocomplete](https://github.com/Inlustra/hyper-autocomplete)

------
iovrthoughtthis
This is great and a very powerful technique. Are there any things like this
that provide similar interfaces for OSs?

~~~
khimaros
Requires a bit of initial setup, but possible it's what you're looking for:
[https://github.com/denisidoro/navi](https://github.com/denisidoro/navi)

Also, at least some of the scaffolding for CLUI seems to be available at
[https://github.com/replit/clui](https://github.com/replit/clui)

------
roryrjb
I don't agree that GUIs are a replacement for the CLI. Yes in the past that is
all we had, but really they are completely different and should be considered
in parallel. CLIs were never really meant for non-technical users though as
far as I'm aware, or at least the end user was already expected to have some
kind of established context. I'm not really against exploration in this area
but I disagree that CLIs are flawed. I'm biased of course, excuse me while I
get back to my UNIX/xterm/tmux/vim development environment.

EDIT: I would like to point out that I've only been in the industry for 6/7
years so it's not like I started my career where this established environment
was the only choice.

------
Waterluvian
This might be what they're getting at. Discoverability with the basic Python
repl is bad. You can use help and dir and both are clunky. But install ipython
and you're off to the races with autocomplete menus you can arrow key through.

~~~
mixmastamyk
ptpython is great at that also and probably easier to grok at first.

The fish shell does much of this as well but is not as attractive.

------
l0b0
Interesting idea. I expect it would be a hell of a lot more impactful if the
demo used some well-known commands like `tar`, `find` or `grep`, though, all
of which have absolutely _heaps_ of options and complex command structures.

------
zeveb
They've got some great ideas and insight here. The thing is, there already
_is_ a wonderful two-dimensional, general-purpose, interactive
terminal/graphic interface: it's Emacs. And it really is awesome!

I think this is a corollary to Greenspun's Tenth Rule ('Any sufficiently
complicated C or Fortran program contains an _ad hoc_ , informally-specified,
bug-ridden, slow implementation of half of Common Lisp'): any sufficiently
powerful UI will be an ad-hoc, inextensible, inconsistent, weaker version of
Emacs.

------
lonelappde
They mock standard OS tree menus and then advertise their...tree menus, and
justify it by saying theirs have search, ignoring that OS tree menus also have
search

------
zenocon
Seems to be in line with my fav Postgres tool pgcli:
[https://www.pgcli.com/](https://www.pgcli.com/)

------
talkingtab
Cool thinking.

And thought provoking. I find myself increasingly being annoyed by GUI's with
their rich interfaces. An interesting project is lazygit which uses gocui. For
me it is useful and appealing alternative to the command line git. With each
pane you press a meta key to get list of commands for the pane, and it would
be interesting to see a mash up with replit somehow.

------
miki123211
This is what Microsoft Office has been doing for the past few years.

For those unfamiliar, modern Office versions use ribbons instead of menus.
Ribbons have a few tabs like home, layout etc. The tabs change depending on
what object you're interacting with, so i.e. if you're editing a pivot table
in Excel, you get two new tabs for working with pivot tables. That means you
only see the options that are actually relevant to you. Each tab has buttons
separated into groups. So, there might be a "alignment" group with "left",
"center", "right" and "justify" inside. Most buttons have detailed
descriptions of what they do and multi-layered, visible keyboard shortcuts
that activate them quickly. Some even have an additional drop down for more
options, so i.e. the "view" button in Access might switch you between the two
most common views when clicked, but you can expand it and select a different
view if need be. The latest office versions also have a search field that
allows you to find any command, no matter what tab it is in. It has
autocomplete, so typing piv usually shows you "pivot table" as one of the
first suggestions.

I use Excel and Access pretty often, and do some moderately complex things
with them, but I almost don't use the traditional ribbon at all. I use
shortcuts for the commands I need very often, and search for the rest. If I
don't know how something is called, I go through the commands on the relevant
tabs and find it eventually.

I think this kind of UI scales pretty well. MS Office apps are pretty
complicated and packed with features, especially the pro versions, but I think
that UI paradigm is pretty scalable and nice for users.

~~~
s_gourichon
What follows is only partly related to the overall conversation, rather an
answer to the ribbon episode.

The ribbon in MS Office came along roughly at the same time as 16:9 and 16:10
screens (on laptops in my memories anyway). Already on a 4:3 screen, WYSIWYG
editing wastes much space on left and right of the screen, to show paper
margins and page limits. And that goddamned ribbon eats up all the top of the
screen, making you see only a limited band of what you could see on that very
screen. Had no one the idea to make the ribbon a vertical tool bar on the left
or right, like in Photoshop/Gimp and a number of other tools? Such a feeling
of UI failure at the time. At that moment my computers were already all
running Linux anyway, so I've never used it more than a few times on a
coworker's machine.

Now I no longer use WYSIWYG software. Text editing with the WYSIWYG paradigm
feels superficially seducing, until you realize it actually hides the actual
document content. How many times has Word shown some items in a bullet list
with a different size without any visible reason ? Or in Google docs one
bullet horizontally misaligned? Why? No one knows.

When editing text, seeing how the final document would look like is not that
important. It's more important to know the state of what you're editing. With
markdown or asciidoc what you see it what your document actually contains.

On top of that, WYSIWIG assumes that there is one final document appearance,
which is just not true for a digital document in a digital world that could be
rendered countless ways in different styles (unless your workflow targets
documents in try-to-mimick-paper-form, like PDF, until that changes).

------
gitgud
> _" On a technical level, a CLUI command is conceptually similar to a file
> path or URL. Since a complete CLUI command is simply a path down the command
> tree, each potential subcommand is like a portion of a file path or URL."_

Sounds like walking the tree of a REST api... potential CLUI framework for
REST?

------
nojvek
Bashing premier pro is a low blow. It’s a very powerful tool that really can’t
be replicated in Cli. Even using ffmpeg CLI is a painful experience.

That being said code completion, contextual help and form-ish guis give a
better user experience.

The most used UI element is a button and thereafter is the search input.

------
microcolonel
Most of the tools to do this exist in ordinary terminal emulators, with
ordinary shells. This would be interesting as an extension for Fish or
similar. AFAIK (somewhat) typed auto-complete information is already available
for a lot of commands.

------
tie_
The article describes pretty much what SAWS has implemented -
[https://github.com/donnemartin/saws](https://github.com/donnemartin/saws)

(mad props to ~donnemartin for the implementation!)

------
thanatropism
Most of this research program is already realized in Windows 10, where you
press the Win key and get universal search through programs, settings and
files.

(And unwanted Bing search results that open in Edge, but that’s Something
else)

~~~
lonelappde
Totally different. That only works for finding programs, not running commands
in them.

Windows is 15+ years behind Mac in simply implementing menu search inside
programs.

------
perl4ever
I never used it a great deal, but I had the impression that MPW (Macintosh
Programmers' Workshop) was an evolution of the command line that unfortunately
didn't really catch on.

------
sedatk
With the prevalence of search-driven interactions and increasing popularity of
GUIfying the CLI, I feel like we are somehow converging to Oberon. I wonder
how that will look like.

------
dharmatech
Presentation-based UI for PowerShell:

[https://github.com/dharmatech/PsReplWpf](https://github.com/dharmatech/PsReplWpf)

------
js2sj
The combination of this and a ncursor app framework is much better than GUI
application. Unfortunately, I don't find an active great ncursor app
framework.

------
_ZeD_
so it's like bpython ([https://bpython-interpreter.org/](https://bpython-
interpreter.org/))?

------
jancsika
Part 1 of 4721: A GUI program in a domain that usually strains all a
computer's resources, probably ought to perform within soft realtime
constraints, and is aimed at professionals is complicated.

Part 2 of 4721: Let us now persuade you there is a better way by demo'ing a
souped-up terminal window that helps non-specialist Unix enthusiasts enter a
record into a database.

 _???_

Part 4721 of 4721: As we have clearly shown, our realtime video-editing CLUI
application is more approachable, discoverable, interactive, and scalable than
Adobe Premiere.

------
syrusakbary
This is awesome! <3

I think the technique of creating UI forms based on GraphQL metadata is going
to be key for building the admin tools of the future.

------
MR4D
They should name the shell CLASH.... for

Command Line Again SHell

I think the idea they have is awesome. Managing servers with this would be a
dream!

------
flyinglizard
Last year I made a bulk photo management software using this exact UI pattern.
It’s very effective.

------
megapatch
This is already implemented, modern bash offers completion and suggestions,
which look exactly like shown (text only though) when you press Tab.

This includes parameters, flags (with documentation), context (eg files in
current directory).

Autocomplete is available for most commands on modern Linux installations.

~~~
eequah9L
Bash is apparently capable of showing the completions with explanations,
however there doesn't seem to be a de facto standard way of doing it. Or did I
miss something? Are there like libraries to help out with this, so that the
help text is shown consistently?

But yeah, agreed that pursuing this path would be less effort and get 90% of
the way to the goal.

------
timka
How come noone mentioned Aza Raskin's Ubiquity? This is HN after all!

------
maerF0x0
someone could improve the scalability of windows by adding better scripting
options. Like how can I open 10k windows , programatically change a form input
and then click the submit button?

Selenium comes to mind..

------
29athrowaway
I use Zenity to create interactive graphical dialogs from shell scripts.

------
longtermd
Implementing a working and fast CLUI (as a search feature) was one of the
easiest ways to get a real WOW-effect from our customers. /founder here

think of: the website (and search results) updates in realtime with every
letter you type

------
m4r35n357
It isn't a command line "interface", it is a command line "interpreter". If
you don't know this you have lost at the start. I'll stick to my shell,
thanks!

------
_pmf_
Matlab, Mathematica et. al. are used by tens of thousands of people daily. You
have several decades of catch up to get anything resembling feature parity.

------
hereisdx
Hey! I wrote this command in a GUI CLI!

------
mayli
So, did you ever heard the /etc/bash_completion?

------
justlexi93
Unless I'm missing something this seems to just be a blog post about a
prototype of an idea, and not something you can actually use.

~~~
reportgunner
Yeah also they are talking about GraphQL backend so I suppose it's just a
gimmick you put on your website and not an _actual_ CLI.

------
ailideex
I am quite annoyed with text user interfaces, especially in lui of a proper
CLI. On two occasions that I asked people to make a CLI for something and then
they made some abomination that can't be used from a script but needs to be
used interactively.

