221–230 of 279 posts
Every macOS application has a command palette in the help menu: command-shift-/ will bring it up and you can incrementally search all the commands in the menus.
However, you can bind it to any shortcut, so binding it to Cmd+P would give you a command palette in any app (and then you can exclude e.g. Sublime Text/Merge who already have their own palettes).
Earlier quoted context omitted.
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!
What sort of features are you thinking of that would require changes to the tools and/or the kernel?
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)
Earlier quoted context omitted.
Correction: Event logs should be transaction logs instead and you must be able to travel through it reverting and re-applying actions. It should be branch-able and allow you to jump between those branches.
I can do that with Emacs. What other tools make it easy to branch in history?
I only learned now that emacs could do it.
Earlier quoted context omitted.
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!
What sort of features are you thinking of that would require changes to the tools and/or the kernel?
Earlier quoted context omitted.
Tomorrows shells already exist: - murex https://murex.rocks - elvish https://elv.sh - fish
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!
Hi, author of _murex_ here. I don't believe that to be true. I mean, I do agree that it would be great to replace the 50 years of legacy of TTYs, byte streams, in-lined control sequences (eg ANSI escape sequences), etc but you can still achieve what you're after. And murex does aim to do this because it is as much inspired by IDEs as it is by scripting languages.
To give an example of these feature:
+ Murex does "fuzzy" search against all possible completions (so does Bash et al with addons, but murex does it out of the box). Do this by pressing ctrl+f
+ Murex does in-line spell checking
+ Murex supports typed pipelines (inc complex formats like JSON, YAML and CSV) and will autocomplete commands that support that data type by default. But it will also work seamlessly with existing POSIX / CLI tools too. It does this by passing the type information in a separate channel to the byte stream. So POSIX pipes work the same but processes that support murex can do richer things with the pipes
+ in expansion of the above, structured data is handled intelligently within murex. eg if doing a regex match against a JSON array you don't need to escape out the JSON formatting. Your tools will automatically only work against the values inside the array. And you can use the same commands against JSON, YAML, TOML, CSV, C-Expressions and others -- the commands understand what the file format is and natively adapt to it. Meaning you don't need to learn different tools for working with JSON than you would for CSV, YAML nor any other format.
+ Murex will display descriptions against each command suggestion (Fish does this too)
+ Murex parses man pages to help build up autocompletions if no autocompletion are defined (Fish also does this)
+ If you're running tmux, you can press F1 against any command in murex and it will open a pane alongside your interactive terminal with the man page (if an external command), a cheat sheet, or the code (if a murex function) so you don't have to remove yourself from the terminal to double check a commands usage
+ Murex has a hint line that acts like a status bar. In there you'll see descriptions of each command (also parsed from man pages if external executable) and also details about the type of command (alias, function, external executable), where is sits in your file system (even showing the path of symlinks) -- so you know exactly what command you're calling and what it is supposed to do.
+ syntax highlighting (this is an increasingly common feature in shells these days)
+ syntax completion (eg quotation marks will smart close)
+ multiline pipelines are handled much better (eg you can up array to the line above and murex wouldn't erase the current pipeline to show the previous one)
+ smarter support for pasting multiple lines (murex will detect if you're pasting multiple lines and allow you to preview it before it then runs those lines. Saving potential mistakes where you're pasting the wrong thing from clipboard)
+ murex can in-line images. It supports client specific ANSI escape sequences for iTerm2's, Kitty, Terminology (Enlightenment) as well as Sixel and ANSI blocks; and will auto-detect what mode will work best with your terminal emulator.
+ colours errors in red (inc STDERR)
+ displays stack traces of errors (inc STDERR)
These features are configurable (can be turned off if you wish) too so if any one of them is not to your tastes you can change the default behaviour.
To be clear, it is still beta software but I've been using it as my primary shell for ~5 years and there are other shells that exist that support some of the same feature sets too. So there definitely are other shells out there that are striving to achieve what you're after, and I'd like to think are having some success at it too.
Something I've been noticing lately is the disappearance of the “power user”. Someone who's not a programer, but has learned lots of smart and efficient ways to getting their computer work done over the years. Shortcuts (keyboard or otherwise), click-hold-cmd-tab-drop or similar patterns, tags/labels for deep file organization, etc. It seems like there's now a much wider gap between the smartphone tap-only user and…
I don't think that they are disappearing; life will find a way. Although, I do think that the median software is becoming harder to automate or stitch together (at least for someone without existing scripting knowledge). Tools that do have APIs don't offer a nice, smooth gradient from beginner to "power-user" that anyone could find themself pulled up.
An exception to this is Excel, which I believe exposes this "gradient" rather well.
I hate this trend. Give me back menus and toolbars. I avoid using VS Code for this reason.
> I hate this trend. Give me back menus and toolbars. Everyone has their own preferences; personally, every time I open Word, I am confused and disoriented and have no idea where to look for what I want. I think it's best for no-one to try to impose their UI preference on everyone, and for all of us just to use the software with which we find it easiest to interact.
Earlier quoted context omitted.
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!
What sort of features are you thinking of that would require changes to the tools and/or the kernel?
Earlier quoted context omitted.
Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`? It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used. Surprisingly, git seems quite humane, even when you screw things up it gives you a lo…
> Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover. You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again
Earlier quoted context omitted.
Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`? It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used. Surprisingly, git seems quite humane, even when you screw things up it gives you a lo…
> Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover. You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again