[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