12 ms·

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)
widespace_ 5y ago
I am not the one who you are asking but, for example, fish breaks shell scripts because it's not POSIX compliant.

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)

widespace_ 5y ago

I am not the one who you are asking but, for example, fish breaks shell scripts because it's not POSIX compliant.