5 ms·

The article paints command palettes as a return to terminal inputs. However there are two massive differences. Firstly, the use of fuzzy search and natural lang

The article paints command palettes as a return to terminal inputs. However there are two massive differences. Firstly, the use of fuzzy search and natural language makes the commands discoverable. Secondly, there is a feedback mechanism that shows what the command will do before it's run. Together, these massively lower the learning curve.

godDLL 5y ago
That's right. Did you see/use Fish as a shell? I'm having much fun scripting in the Fish language at the moment, and using the shell in interactive programs.
firexcy 5y ago
I'd like to add a third, pro-terminal point, that cli tools are inherently ready to be scripted, piped, executed in batch and in parallel, none of which are common in gui apps with or without command palattes.
worldsayshi 5y ago
Is love to see a command palette terminal fusion. Thought about this many times.
- austinjp 5y ago
  Although I don't use it, I see plenty of positive feedback about fzf [0] and I'm sure I've seen palette-style tools built with it that enable command and options discovery. [0] https://github.com/junegunn/fzf https://github.com/junegunn/fzf
- slightwinder 5y ago
  People do this already with fuzzy-finders. fzf or rofi to name some. See here for some usages: https://github.com/junegunn/fzf/wiki/Related-projects https://github.com/junegunn/fzf/wiki/Related-projects
- p2t2p 5y ago
  I use fzf as command autocomplete tool in my zsh. It is still not a command palette but gets pretty close.
- varenc 5y ago
  https://warp.dev https://warp.dev is trying!
  - michlim 5y ago
    Hi! Michelle, an engineer from Warp here. Thanks for mentioning us. We've been building a Rust-based terminal. Currently, we're currently building a feature called "Tasks Not Commands".that allows users to interact with the terminal via a task instead of an obtuse command or series of commands. See the mock here [1]. For example, be able to type "undo last git commit" instead of needing to memorize `git reset --hard SOFT`. We envision users being able to create and share their own custom tasks as well. What do you think? Join our discord to stay updated. [2] [1] https://assets-global.website-files.com/60352b1db5736ada4741b380/615cadc276c3762ce5ad880c_tasksnotcommands-p-500.png https://assets-global.website-files.com/60352b1db5736ada4741... [2] https://www.warp.dev/discord https://www.warp.dev/discord
epberry 5y ago
This is a great observation. In the end, the goal of a terminal usable by people and machines was folly. Machines can use the shell, humans can use the command prompt.
_dain_ 5y ago
zsh completions with fzf replicates somewhat in the terminal
- nerdponx 5y ago
  Ironically, Zsh has a huge amount of thorough documentation, which is badly undiscoverable due to the "conversational" writing style as well as the utter lack of "semantic" search ability in man pages.
nerdponx 5y ago
It also possibly increases discoverability even compared to a traditional GUI, because you can scroll through the list and see things you otherwise might not have known about.
- worldsayshi 5y ago
  I think there's a great potential in command palette like interfaces especially if there was a library that helped you build command palette grammars.
- jackson1442 5y ago
  This is absolutely my favorite thing about command pallets. Any time I need to do anything in vscode I just type something close to what I'm trying to do and scroll until I see something that looks right. Way easier than just about anything else. macOS has a similar feature for the menu bar- every app has a Help item that allows you to search all menus at the same time. It doesn't work as well as a command pallet but it is incredibly useful for menu-heavy apps.
deleted 5y ago
[deleted]
willghatch 5y ago
While I agree that adding fuzzy searching and natural language discoverability are great, there are some other pretty important differences. I thought a lot about this line: > you had the best of the terminal paired with the best of graphical interfaces Maybe there are many parts of a terminal that are “the best” for different people or use cases, but to me the key feature of the terminal is the ability to compose, extend, and abstract. Use a command with certain options a lot? Turn it into an alias or one-liner script. Use a pattern of commands a lot? Turn it into a script. Use a particular command really a lot? Add it as a custom keybinding. And it's pretty easy -- once you've paid the price of learning to use the shell at all, you are ready to start writing basic scripts. Granted, the price of entry to learn the shell is high compared to command palettes. But there is so much there that command palettes are still missing.
tgsovlerkhgsel 5y ago
Menus are great for discoverability because they show you all the options in an organized way, but they're slow. They're excellent for rarely used commands. Keyboard shortcuts are fast but they require memorization. They're great for something you do many times a day. Command pallets fit in the middle. They're most perfect for the niche where you use the command often enough to remember that it exists and at least roughly know the name, but nowhere near often enough to warrant memorizing a keyboard shortcut. Especially for text editors where you're already in typing position, they're much faster than menus and not that much slower than shortcuts, and you can give access to much more commands than you can define reasonable shortcuts for. And as you said, CLI with the precise syntax requirements is simply the worst.
moring 5y ago
I think the differences are not fundamental, but that the terminal inputs / shells did not evolve as much as they could or should have. There have been discussions all over the world on the merits of command-line vs. GUI, but too little of how tomorrow's command-line can be better than today's command-line. Things DID improve, e.g. tab-autocomplete evolved very well. But that's not enough, and editor's command palettes show that. I actually thought I'll give some more quick examples than discoverability, but then I realized that you could fill a whole document with them...
- laumars 5y ago
  Tomorrows shells already exist: - murex https://murex.rocks https://murex.rocks - elvish https://elv.sh https://elv.sh - fish
  - moring 5y ago
    Tomorrow's shells would require changes to various command-line tools and possibly even the kernel. Just changing the shell executable is fundamentally limited, so it cannot be more than the first step. But thanks for the links anyway!
    - omnicognate 5y ago
      What sort of features are you thinking of that would require changes to the tools and/or the kernel?
      - ReleaseCandidat 5y ago
        Dropping the idea of plain text output and input. In reality such text does not exist. It's always structured text: log files, CSV, configuration file formats, markup formats, source code, ... Language servers for almost any of these already exist, let's use them in the tools.
      - moring 5y ago
        Quick examples from my head: changes to tools: - output less noise that drowns the signal. The toolchain used to build a program from source is particularly problematic here. - if the output has to be huge, make it structured / collapsible - output messages that are both human-readable (so humans don't have to read cryptic data that is meant for the computer) and computer-readable (so the computer does not have to parse human-readable messages, which is fragile). Yes, that's hard. - Provides tools that each solves one problem, and solves it well. Some things that could have been changes to tools are implemented by tool-specific extensions (IIRC, bash autocomplete of tool parameters works like this). Discoverability can to some extent be implemented like that, including inconsistent naming of command-line options for different tools. Might require changes to the kernel (details depend on the OS, and on whether the terminal runs inside a GUI window): - proper handling of color. Right now, color is encoded as in-band information (ANSI escape sequences) that confuse various tools, e.g. grep cannot find a substring if there is a color change in the middle of a substring. The workaround is to have all tools detect if they write to the terminal or a pipe and not output color at all, which means that I can't grep without losing color. This might require changing the kernel because the terminal driver that defines how color is encoded sits there (again, might be different in a terminal window in the GUI). (edit: formatting)
deleted 5y ago
[deleted]

godDLL 5y ago

That's right. Did you see/use Fish as a shell? I'm having much fun scripting in the Fish language at the moment, and using the shell in interactive programs.

firexcy 5y ago

I'd like to add a third, pro-terminal point, that cli tools are inherently ready to be scripted, piped, executed in batch and in parallel, none of which are common in gui apps with or without command palattes.

worldsayshi 5y ago

Is love to see a command palette terminal fusion. Thought about this many times.

austinjp 5y ago
Although I don't use it, I see plenty of positive feedback about fzf [0] and I'm sure I've seen palette-style tools built with it that enable command and options discovery. [0] https://github.com/junegunn/fzf https://github.com/junegunn/fzf
slightwinder 5y ago
People do this already with fuzzy-finders. fzf or rofi to name some. See here for some usages: https://github.com/junegunn/fzf/wiki/Related-projects https://github.com/junegunn/fzf/wiki/Related-projects
p2t2p 5y ago
I use fzf as command autocomplete tool in my zsh. It is still not a command palette but gets pretty close.
varenc 5y ago
https://warp.dev https://warp.dev is trying!
- michlim 5y ago
  Hi! Michelle, an engineer from Warp here. Thanks for mentioning us. We've been building a Rust-based terminal. Currently, we're currently building a feature called "Tasks Not Commands".that allows users to interact with the terminal via a task instead of an obtuse command or series of commands. See the mock here [1]. For example, be able to type "undo last git commit" instead of needing to memorize `git reset --hard SOFT`. We envision users being able to create and share their own custom tasks as well. What do you think? Join our discord to stay updated. [2] [1] https://assets-global.website-files.com/60352b1db5736ada4741b380/615cadc276c3762ce5ad880c_tasksnotcommands-p-500.png https://assets-global.website-files.com/60352b1db5736ada4741... [2] https://www.warp.dev/discord https://www.warp.dev/discord

epberry 5y ago

This is a great observation. In the end, the goal of a terminal usable by people and machines was folly. Machines can use the shell, humans can use the command prompt.

_dain_ 5y ago

zsh completions with fzf replicates somewhat in the terminal

nerdponx 5y ago
Ironically, Zsh has a huge amount of thorough documentation, which is badly undiscoverable due to the "conversational" writing style as well as the utter lack of "semantic" search ability in man pages.

nerdponx 5y ago

It also possibly increases discoverability even compared to a traditional GUI, because you can scroll through the list and see things you otherwise might not have known about.

worldsayshi 5y ago
I think there's a great potential in command palette like interfaces especially if there was a library that helped you build command palette grammars.
jackson1442 5y ago
This is absolutely my favorite thing about command pallets. Any time I need to do anything in vscode I just type something close to what I'm trying to do and scroll until I see something that looks right. Way easier than just about anything else. macOS has a similar feature for the menu bar- every app has a Help item that allows you to search all menus at the same time. It doesn't work as well as a command pallet but it is incredibly useful for menu-heavy apps.

deleted 5y ago

[deleted]

willghatch 5y ago

While I agree that adding fuzzy searching and natural language discoverability are great, there are some other pretty important differences. I thought a lot about this line: > you had the best of the terminal paired with the best of graphical interfaces Maybe there are many parts of a terminal that are “the best” for different people or use cases, but to me the key feature of the terminal is the ability to compose, extend, and abstract. Use a command with certain options a lot? Turn it into an alias or one-liner script. Use a pattern of commands a lot? Turn it into a script. Use a particular command really a lot? Add it as a custom keybinding. And it's pretty easy -- once you've paid the price of learning to use the shell at all, you are ready to start writing basic scripts. Granted, the price of entry to learn the shell is high compared to command palettes. But there is so much there that command palettes are still missing.

tgsovlerkhgsel 5y ago

Menus are great for discoverability because they show you all the options in an organized way, but they're slow. They're excellent for rarely used commands. Keyboard shortcuts are fast but they require memorization. They're great for something you do many times a day. Command pallets fit in the middle. They're most perfect for the niche where you use the command often enough to remember that it exists and at least roughly know the name, but nowhere near often enough to warrant memorizing a keyboard shortcut. Especially for text editors where you're already in typing position, they're much faster than menus and not that much slower than shortcuts, and you can give access to much more commands than you can define reasonable shortcuts for. And as you said, CLI with the precise syntax requirements is simply the worst.

moring 5y ago

I think the differences are not fundamental, but that the terminal inputs / shells did not evolve as much as they could or should have. There have been discussions all over the world on the merits of command-line vs. GUI, but too little of how tomorrow's command-line can be better than today's command-line. Things DID improve, e.g. tab-autocomplete evolved very well. But that's not enough, and editor's command palettes show that. I actually thought I'll give some more quick examples than discoverability, but then I realized that you could fill a whole document with them...

laumars 5y ago
Tomorrows shells already exist: - murex https://murex.rocks https://murex.rocks - elvish https://elv.sh https://elv.sh - fish
- moring 5y ago
  Tomorrow's shells would require changes to various command-line tools and possibly even the kernel. Just changing the shell executable is fundamentally limited, so it cannot be more than the first step. But thanks for the links anyway!
  - omnicognate 5y ago
    What sort of features are you thinking of that would require changes to the tools and/or the kernel?
    - ReleaseCandidat 5y ago
      Dropping the idea of plain text output and input. In reality such text does not exist. It's always structured text: log files, CSV, configuration file formats, markup formats, source code, ... Language servers for almost any of these already exist, let's use them in the tools.
    - moring 5y ago
      Quick examples from my head: changes to tools: - output less noise that drowns the signal. The toolchain used to build a program from source is particularly problematic here. - if the output has to be huge, make it structured / collapsible - output messages that are both human-readable (so humans don't have to read cryptic data that is meant for the computer) and computer-readable (so the computer does not have to parse human-readable messages, which is fragile). Yes, that's hard. - Provides tools that each solves one problem, and solves it well. Some things that could have been changes to tools are implemented by tool-specific extensions (IIRC, bash autocomplete of tool parameters works like this). Discoverability can to some extent be implemented like that, including inconsistent naming of command-line options for different tools. Might require changes to the kernel (details depend on the OS, and on whether the terminal runs inside a GUI window): - proper handling of color. Right now, color is encoded as in-band information (ANSI escape sequences) that confuse various tools, e.g. grep cannot find a substring if there is a color change in the middle of a substring. The workaround is to have all tools detect if they write to the terminal or a pipe and not output color at all, which means that I can't grep without losing color. This might require changing the kernel because the terminal driver that defines how color is encoded sits there (again, might be different in a terminal window in the GUI). (edit: formatting)

deleted 5y ago

[deleted]