10 ms·

I think that the autocomplete story is abysmal. Modern IDEs can tell me exactly what can follow after a certain piece of text, and even the best tab completion

I think that the autocomplete story is abysmal. Modern IDEs can tell me exactly what can follow after a certain piece of text, and even the best tab completion in terminals is limited, ugly, and text-mode for no good reason. Some protocol for a real dropdown rendered in the style of the OS, plus a standard data format that allows tool builders to specify options, their meanings and the kinds of allowed parameters in a structural way (much like doccomments in code), is direly needed. If I type "git " I want to see "add" as an option, with docs in a tooltip as I navigate the options. When I "git add " I want to see a list of files that make sense to add, eg only files that can be staged right now. I want this to be consistent across commands, I want any shell to be able to add support for this and I want any command line program to be able to add support for this.

jstanley 9y ago
Text mode is handy because it works transparently over SSH.
- skrebbel 9y ago
  Sounds like a solvable problem, right? The same protocol that allows the shell to communicate with the terminal window can be used over SSH. I don't know much about how SSH works, but there has to be a way to communicate between the daemon and the client that both support this protocol and send the data separate from the screen content? In the typical case where you SSH from your own terminal window your ssh client just forwards the connection to your terminal window and done. It's not like anything stops working when this stuff isn't there. It's just like colors in that respect.
swiley 9y ago
>Modern IDEs can tell me exactly what can follow after a certain piece of text I don't think that's computable in a terminal.
- skrebbel 9y ago
  It could be, if there was a standard format or protocol by which a shell can ask a command what flags/options make sense in what context. A bit like how man pages are a standard format for static docs, every tool could ship "autocomplete files" which tell a shell how to build the autocomplete. These files could even contain runnable code (in sh or something) without an additional security risk - after all, they came with a program that you're about to run :-) I'm sure there's all kinds of challenges with this when you go deeper, but when even a relatively lightweight tool like VS Code can give me perfect C# IntelliSense on every major OS, I find it a bit abysmal that unzipping a file from the terminal is non-trivial.
  - rapala 9y ago
    This is pretty much how bash completion works...
  - swiley 9y ago
    That's not exact, it only works when certain conventions are followed, which is the situation we have now and will always have because unlike IDEs which typically autocomplete context free (or nearly so) languages your asking for auto completion to be done on what is essentially a very complex recursive language. Also zip sucks, use tar or cpio.
ropeladder 9y ago
This. I would love to be able to type "[command] --[tab]" and have it list all the options, and/or common options, so when I'm learning 'tar' I don't have to start typing, realize I've forgotten the command, and then have to go use man or --help or go Google it.
- stevewillows 9y ago
  Have you checked out ZSH? It can do this nicely.
  - signa11 9y ago
    zsh via its ultra-tunable completions can do only 1st part of op's request i.e command option completion, but not the second part i think... for example, i do the following: anupam@virat ~ % autoload -Uz compinit anupam@virat ~ % compinit anupam@virat ~ % git a<TAB> add -- add file contents to index am -- apply patches from a mailbox apply -- apply patch to files and/or to index archimport -- import an Arch repository into git archive -- create archive of files from named tree edit-001: added trivial example.
    - mtrycz2 9y ago
      My (pretty much vanilla) zsh works quite nicely https://i.imgur.com/SZqu63p.png https://i.imgur.com/SZqu63p.png I'm not sure it covers all of the obscure commands you can think of, but 99% of the time it's great.
      - btschaegg 9y ago
        As far as I can remember the only standard command I use and that my ZSH has trouble with is `dd`. Luckily, its arguments aren't that complicated.
    - asgeir 9y ago
      My zsh autocompletion list for git add actually contains the stageable files. I don't know if this is stock zsh behaviour or related to my prezto https://github.com/sorin-ionescu/prezto https://github.com/sorin-ionescu/prezto config but it can be done Edit: looks like it might be stock behaviour https://github.com/zsh-users/zsh/blob/master/Completion/Unix/Command/_git#L47 https://github.com/zsh-users/zsh/blob/master/Completion/Unix...
terminalcommand 9y ago
> If I type "git " I want to see "add" as an option, with docs in a tooltip as I navigate the options. When I "git add " I want to see a list of files that make sense to add, eg only files that can be staged right now With fish you can customize auto completion for individual commands with full color and tooltip support. As a long time emacs user I want to believe that much of the required functionality for menus can be achieved via a text only format (either using standard escape codes or a markup language). I completely agree that we need to be able to incorporate native UI elements in CLI programs. Recently I stumbled upon Steve Jobs's presentation of Next computers and the initial UIkit. Jobs himself programmed without writing a single line of code, only using the built in interface builder. This was in the 80s, now the year is 2017 and we are still trying to remember the parameters for tar to extract files :) I think the future should not rely on terminals where we extensively type and read. There should be drop-down menus for all applications, whether text based or GUI based. And these menus should be able to incorporate system-native dialogs e.g choose a file, choose a font etc. And I'd want PostScript support to all terminals. Green on black mono fonts are cool but we have 4K displays now, come on! I want to be able to specify font, show images, draw charts etc. in a terminal window. Frankly the future of terminals should look like Python Notebooks such as Jupyter. We need to be able to use cool fonts graphics UI elements and we need to be able to share our terminal "page" with others.
- murukesh_s 9y ago
  > Recently I stumbled upon Steve Jobs's presentation of Next computers and the initial UIkit. Jobs himself programmed without writing a single line of code, only using the built in interface builder. This was in the 80s, now the year is 2017 and we are still trying to remember the parameters for tar to extract files :) I watch it regularly. Every time I see even seasoned developers takes weeks or even months for building even a simple application, whether it's frontend or backend, I wonder if we developers have a subconscious bias towards tougher way of building things instead of a much easier way. Visual basic comes into my mind. Visual basic is probably inspired by interface builder and had similar rapid development features. Where/when have we lost it? > Frankly the future of terminals should look like Python Notebooks such as Jupyter. I second that. A terminal should ultimately do it's purpose. Not mimic a 1950's thin client terminal with 80x25 resolution and dark colors (Nothing against dark theme, just saying). A user whether a normal user or power user or even a developer shouldn't be bothered with remembering the exact parameter or it's structure. It should be completely scriptable, but it need not appear like existing terminals.
FullMtlAlcoholc 9y ago
check out black-screen terminal emulator
FullMtlAlcoholc 9y ago
check out black-screen terminal emulator for IDE style auto completion
chenglou 9y ago
You might be interested in this: https://news.ycombinator.com/item?id=15138613 https://news.ycombinator.com/item?id=15138613

jstanley 9y ago

Text mode is handy because it works transparently over SSH.

skrebbel 9y ago
Sounds like a solvable problem, right? The same protocol that allows the shell to communicate with the terminal window can be used over SSH. I don't know much about how SSH works, but there has to be a way to communicate between the daemon and the client that both support this protocol and send the data separate from the screen content? In the typical case where you SSH from your own terminal window your ssh client just forwards the connection to your terminal window and done. It's not like anything stops working when this stuff isn't there. It's just like colors in that respect.

swiley 9y ago

>Modern IDEs can tell me exactly what can follow after a certain piece of text I don't think that's computable in a terminal.

skrebbel 9y ago
It could be, if there was a standard format or protocol by which a shell can ask a command what flags/options make sense in what context. A bit like how man pages are a standard format for static docs, every tool could ship "autocomplete files" which tell a shell how to build the autocomplete. These files could even contain runnable code (in sh or something) without an additional security risk - after all, they came with a program that you're about to run :-) I'm sure there's all kinds of challenges with this when you go deeper, but when even a relatively lightweight tool like VS Code can give me perfect C# IntelliSense on every major OS, I find it a bit abysmal that unzipping a file from the terminal is non-trivial.
- rapala 9y ago
  This is pretty much how bash completion works...
- swiley 9y ago
  That's not exact, it only works when certain conventions are followed, which is the situation we have now and will always have because unlike IDEs which typically autocomplete context free (or nearly so) languages your asking for auto completion to be done on what is essentially a very complex recursive language. Also zip sucks, use tar or cpio.

ropeladder 9y ago

This. I would love to be able to type "[command] --[tab]" and have it list all the options, and/or common options, so when I'm learning 'tar' I don't have to start typing, realize I've forgotten the command, and then have to go use man or --help or go Google it.

stevewillows 9y ago
Have you checked out ZSH? It can do this nicely.
- signa11 9y ago
  zsh via its ultra-tunable completions can do only 1st part of op's request i.e command option completion, but not the second part i think... for example, i do the following: anupam@virat ~ % autoload -Uz compinit anupam@virat ~ % compinit anupam@virat ~ % git a<TAB> add -- add file contents to index am -- apply patches from a mailbox apply -- apply patch to files and/or to index archimport -- import an Arch repository into git archive -- create archive of files from named tree edit-001: added trivial example.
  - mtrycz2 9y ago
    My (pretty much vanilla) zsh works quite nicely https://i.imgur.com/SZqu63p.png https://i.imgur.com/SZqu63p.png I'm not sure it covers all of the obscure commands you can think of, but 99% of the time it's great.
    - btschaegg 9y ago
      As far as I can remember the only standard command I use and that my ZSH has trouble with is `dd`. Luckily, its arguments aren't that complicated.
  - asgeir 9y ago
    My zsh autocompletion list for git add actually contains the stageable files. I don't know if this is stock zsh behaviour or related to my prezto https://github.com/sorin-ionescu/prezto https://github.com/sorin-ionescu/prezto config but it can be done Edit: looks like it might be stock behaviour https://github.com/zsh-users/zsh/blob/master/Completion/Unix/Command/_git#L47 https://github.com/zsh-users/zsh/blob/master/Completion/Unix...

terminalcommand 9y ago

> If I type "git " I want to see "add" as an option, with docs in a tooltip as I navigate the options. When I "git add " I want to see a list of files that make sense to add, eg only files that can be staged right now With fish you can customize auto completion for individual commands with full color and tooltip support. As a long time emacs user I want to believe that much of the required functionality for menus can be achieved via a text only format (either using standard escape codes or a markup language). I completely agree that we need to be able to incorporate native UI elements in CLI programs. Recently I stumbled upon Steve Jobs's presentation of Next computers and the initial UIkit. Jobs himself programmed without writing a single line of code, only using the built in interface builder. This was in the 80s, now the year is 2017 and we are still trying to remember the parameters for tar to extract files :) I think the future should not rely on terminals where we extensively type and read. There should be drop-down menus for all applications, whether text based or GUI based. And these menus should be able to incorporate system-native dialogs e.g choose a file, choose a font etc. And I'd want PostScript support to all terminals. Green on black mono fonts are cool but we have 4K displays now, come on! I want to be able to specify font, show images, draw charts etc. in a terminal window. Frankly the future of terminals should look like Python Notebooks such as Jupyter. We need to be able to use cool fonts graphics UI elements and we need to be able to share our terminal "page" with others.

murukesh_s 9y ago
> Recently I stumbled upon Steve Jobs's presentation of Next computers and the initial UIkit. Jobs himself programmed without writing a single line of code, only using the built in interface builder. This was in the 80s, now the year is 2017 and we are still trying to remember the parameters for tar to extract files :) I watch it regularly. Every time I see even seasoned developers takes weeks or even months for building even a simple application, whether it's frontend or backend, I wonder if we developers have a subconscious bias towards tougher way of building things instead of a much easier way. Visual basic comes into my mind. Visual basic is probably inspired by interface builder and had similar rapid development features. Where/when have we lost it? > Frankly the future of terminals should look like Python Notebooks such as Jupyter. I second that. A terminal should ultimately do it's purpose. Not mimic a 1950's thin client terminal with 80x25 resolution and dark colors (Nothing against dark theme, just saying). A user whether a normal user or power user or even a developer shouldn't be bothered with remembering the exact parameter or it's structure. It should be completely scriptable, but it need not appear like existing terminals.

FullMtlAlcoholc 9y ago

check out black-screen terminal emulator

FullMtlAlcoholc 9y ago

check out black-screen terminal emulator for IDE style auto completion

chenglou 9y ago

You might be interested in this: https://news.ycombinator.com/item?id=15138613 https://news.ycombinator.com/item?id=15138613