My first experience with this idea was Sublime Text’s Ctrl-P. Every program needs it’s own Ctrl-P.
Nice to see the idea spreading!
Emacs’ M-x takes this one step further imo, in that it exposes every function that is reachable through the GUI as a callable function with a text interface.
Of course the whole thing is quite dated and could use some modernizations, e.g. context awareness and a nicer graphic design, but the basic idea is there and super powerful.
That’s where helm comes in!
Emacs’ C-h k and C-h w are great, too. The former tells you the function bound to a key, and the latter tells you which keys are bound to a function.
Ubuntu experimented with something similar with Unity, where hitting a specific key combo would let you search the menus of the current application. I thought it was cool, and a nice alternative to scanning menus.
Care to explain what Ctrl-P does in Sublime for those of us who don’t use Sublime?
I haven’t used Sublime in years now, but IIRC it is a fuzzy finder, opening files, function defintiions etc in the same place, which inspired ctrlp.vim plugin and other similar plugins
Ctrl-p exists in VSCode, chrome devtools. Even Visual Studio has this in the form of Ctrl-Q, though it doesn’t search the files.
The version 1 of Sublime Text is from 2008. The version 2.0 dates back 2012. This editor came long, very long, before VSCode, and Atom etc..
But maybe Sublime Text took inspiration from another software that predates. In which case I don’t know which one it is.
I remember trying SciTE, Scintilla and TextMate. But chose Sublime Text compared to them.
I should have been more clear. I intended to say, it exists in those editors now. I am pretty sure it is a sublime innovation.
I also thought so, but reading other comments they say it’s in Emacs. Meta-x . emacs is even way older :-)
I use Emacs really roughly, essentially for magit. I’ll have to check this M-x but I don’t edit projects in emacs in general….
It’s the Sublime equivalent of M-x.
This strongly reminds me of xiki which I found promising a few years ago:
There had been some crowd founding for this project years ago. But it did not gain the momentum I was expecting. My usage was more of a exploratory thing, and I did not invest in using it longer cause I switched OS (NixOS), and I have not tried on it.
But that gave me a good lasting impression of a possible future for CLI interfaces.
I remember when I first stumbled upon Xiki I was amazed by its flexibility. Sadly it didn’t really make it much beyond a prototype stage and nowadays it seems pretty dead.
It also reminded me of the Acme editor from plan9. And a little bit of squeak/e-toys.
Being able to very easily create some one-off interfaces for special use cases is super powerful.
But to be really useful you need tight integration with many parts of the operating system and other software and those integrations need to be written and maintained by someone…
Also I think this coincides nicely with the post on text based cli tools by danluu from a few days ago. It helps immensely to have some structured information on how your tools compose and what data they expect, because it allows you to generate these sorts of interfaces and good context aware autocompletion.
More ideas off the top of my head:
Easily scriptable GUIs. Think VBA at its most primitive, and AppleScript being able to fully automate across multiple applications. For a more macro approach, AutoHotKey.
TUIs with different ideas: It appears I’m going to be the local IBM i user, so: F4 prompting everywhere for suggestions and prompts more powerful than tab completion (it basically has a form), context sensitive help everywhere (done on GUIs too, see balloon help on the classic Mac OS), separating commands from programs (commands handle structured arguments and wrap the program; also done by VMS), and using its richer object based environment.
Embracing shells as documents and transcripts - Mathematica, Jupyter, MPW, Oberon, Acme.
Awesome! I was thinking about same concept lately.