[skrebbel]

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.

[terminalcommand]

> 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]

> 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.

[sametmax]

> I wonder if we developers have a subconscious bias towards tougher way of building things instead of a much easier way.

That and the fact you we don't know everything that's possible and stick to what we know.

But, there is another side of the story: reusability is hard, plus similarity and equality are very different things. Generalizing a problem can be more or less productive depending of your situation. Also learning how to use something and bend it to your needs can be an mistake too on the long run.

Mix complexity, money, human factors in that and you get the average IT project.

Which is still awesome if you ask me. Current softwares have many warts, but they are so freaking amazing.

[tjalfi]

Are you referring to The NeXT Introduction - October 12, 1988[0]?

[0] https://www.youtube.com/watch?v=92NNyd3m79I

[terminalcommand]

Yes I am, for a pin-point location you might want to look at the second video on http://www.computerhistory.org/atchm/the-deep-history-of-you...

You do not need to watch the whole 2 hours, only 20-25 mins where Steve Jobs introduces Nextstep and demonstrates it on a Next machine.

[tjoff]

>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.

I see how that would easily break scripts. Not in theory no, but in practice. The instant developers gets a choice on this they will develop for their needs and break others.

It breaks what I as a user expects from a terminal and if such a terminal was launched today I don't believe anyone would use it. Not because the idea is bad but because the users of a terminal have a very confined idea of how the communication is supposed to work.

It absolutely must work the same over ssh on my phone or my fridge as on my workstation (regardless of OS). KISS.

Now that doesn't mean we can innovate or improve things, but it must be done without breaking expectations and it must be compatible with the mindset of today or I don't believe anyone will pick it up.

[setr]

Presumably it would be in the same fashion that file dialogs are generated; you defer the actual selection to some OS-provided library function, and just accept a standardized output (some FileObject construct). So the terminal would provide this file selector, based on context: a script would take it as the filename itself, the interactive shell would provide the file dialog, etc.

Terminal Programs are already outputting differently based on context (ie ls to a pipe vs screen), so supporting interactive and scripting is hardly a novel idea in the space; its just that the interactive support hasn't fundamentally improved in decades

[ropeladder]

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.

[adambyrtek]

Pretty much any modern shell (bash, zsh, fish, etc) provides command line completion.

[skrebbel]

If you really think the completion in current shells is the best there can be then I think you lack imagination.

I don't want remembered commands, I want the terminal to tell me what stuff means. I want it to tell me what makes sense in which context. Like the IntelliSense when coding Java or C#. Docs at your fingertips, all relevant options (and none else) available, etc. This is incomparable to the kind of autocomplete any shell I've seen to date has. Zsh is a nice step in the right direction but it's still shit.

[adambyrtek]

Of course you could always do better, but the specific feature mentioned in the parent comment (completing flags for "tar" instead of checking the man page) has been around for ages.

Regarding contextual analysis, the fundamental problem is that command execution relies on a list of strings (argv) with no types or meaning. Each command is responsible for parsing its own arguments, either manually or using a shared library (e.g. getopt). This provides loose coupling and flexibility, but makes introspection really difficult, and features like completions become an afterthought reimplemented in every shell either by special cases for each command or hacks like parsing help messages.

[geoelectric]

fish shell does exactly what you say, out of the box. c/p below:

  ~/.l/share: tar --<tab>                                                               
  --absolute-paths               (Don't strip leading /)
  --after-date                   (Only store newer files)
  --append                       (Append files to archive)
  --atime-preserve               (Keep access time)
  …and 58 more rows

As others have mentioned, zsh can be tuned to perform similarly. fish is nice in that if you don't have explicit completions for options set up it actually parses man pages.

[stevewillows]

Have you checked out ZSH? It can do this nicely.

[signa11]

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.

[asgeir]

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 config but it can be done

Edit: looks like it might be stock behaviour https://github.com/zsh-users/zsh/blob/master/Completion/Unix...

[ropeladder]

Weird. I'm using Zsh and I swear I've tried that before with nothing happening, but it does actually work. Thanks!

[mtrycz2]

My (pretty much vanilla) zsh works quite nicely

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]

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.

[jstanley]

Text mode is handy because it works transparently over SSH.

[skrebbel]

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]

>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]

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.

[swiley]

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.

[rapala]

This is pretty much how bash completion works...

[chenglou]

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

[FullMtlAlcoholc]

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

[FullMtlAlcoholc]

check out black-screen terminal emulator