Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you love/hate about terminals? Would you change them?

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 204 posts

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#141

Post by [deleted] »

terminal-survey wrote: post #137
EpicEng wrote: post #135

Earlier quoted context omitted.

I'm not sure I understand; if you don't care about the output then send it to /dev/null. If you do care then pipe it to an editor. A terminal is not a text editor (I mean, I suppose it could be, but that seems like a rather large scope change.)

I think the problem is that you only know if you care about the output after the fact. For example, if "make" runs through, I usually don't care about the output. But if "make" fails, then I want to read the error messages. As I said somewhere else, we have a concrete solution in mind for implementing folding as GP describes.

[deleted]

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#142

Post by sigjuice »

ravenstine wrote: post #139

I love how terminals are a universal tool that can do a lot with just the default GNU toolset. I hate how I can't choose the caret position with my mouse when using a terminal emulator. Nothing seems designed to allow this. Sometimes there's too much input and using the arrow keys or HOME/END gets tedious.

M-x shell in Emacs lets you use your mouse.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#143

Post by terminalcommand »

tjalfi wrote: post #101
terminalcommand wrote: post #35

Earlier quoted context omitted.

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

Are you referring to The NeXT Introduction - October 12, 1988[0]? [0] https://www.youtube.com/watch?v=92NNyd3m79I

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.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#145

Post by terminal-survey »

btschaegg wrote: post #88
terminal-survey wrote: post #85

Earlier quoted context omitted.

Oh yes. We want to have an API where clients (i.e. programs running in the terminal) can receive actual key/pointer/touch events if they choose to. The terminal may retain control over a few crucial keysequences (similar to how Ctrl-Alt-Del is always handled by the OS on Windows), but it has to inform the client about that.

Very good to hear! That alone makes me root for you guys. Edit: BTW: If you really get a project going, make sure to inform us how to chip in (at least in monetary way, if nothing else. I'd like to be able to pay anyone who tackles this a beverage of their choice ;-) ).

As soon as the project is at a point where we feel comfortable showing it to a wider audience, we'll make a proper announcement and post it to HN (among other places).

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#146

Post by EpicEng »

terminal-survey wrote: post #137
EpicEng wrote: post #135

Earlier quoted context omitted.

I'm not sure I understand; if you don't care about the output then send it to /dev/null. If you do care then pipe it to an editor. A terminal is not a text editor (I mean, I suppose it could be, but that seems like a rather large scope change.)

I think the problem is that you only know if you care about the output after the fact. For example, if "make" runs through, I usually don't care about the output. But if "make" fails, then I want to read the error messages. As I said somewhere else, we have a concrete solution in mind for implementing folding as GP describes.

I don't know that make is a good example here. This is a tool you use constantly, so I imagine you'd know to pipe std err if you wanted its output. We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again."

But hey; your time to spend :)

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#147

Post by terminal-survey »

saulrh wrote: post #119

If I were building a terminal from scratch... Hm. Attempts to improve the terminal are not backwards-compatible or do not otherwise provide a clean upgrade path. I would love to use one of those fancy graphical terms that comes up on HN every now and then, but because they only work with a special toolchain that speaks its language and its language only there's no way they'll ever gain critical mass and take off. Any…

> I would love to use one of those fancy graphical terms that comes up on HN every now and then

One of these (Black Screen) is among the many inspirations with which we started.

> Any attempt to improve the terminal has to be something that I could switch to on a whim and then gradually grow into.

Backwards-compatibility is a hard requirement for us because of that. And oh boy, it causes a lot of pain.

> I've essentially duplicated the evolution of HTML+JS webapps

This is a huge fear of mine. We need to find a way of opening the GUI can-of-worms without ending up with terminals that are as bloated as contemporary web browsers.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#148

Post by skrebbel »

adambyrtek wrote: post #59
ropeladder wrote: post #28

Earlier quoted context omitted.

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.

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

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.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#149

Post by jstimpfle »

baq wrote: post #129
jstimpfle wrote: post #92

Earlier quoted context omitted.

I would not recommend that. That would be the source for endless bikeshedding and could never satisfy all people. (See the mess that HTTP / REST are). It's not a problem to have this handled in the shell such that the output is rendered in such a way as to please the terminal. You can do this manually (e.g. append a "| display-jpeg-in-terminal" command to the pipeline), or use a magic bytes based file viewer. Look at…

if shells had some more types than a stream of bytes, it'd make sense for 'image' type data to be displayed as images. the pipes you mention are then simply type casts or conversion functions.

I don't know what you think is missing. "Displaying 'image' type data as images" totally works. Are you aware of magic bytes (which I mentioned above)?

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#150

Post by skrebbel »

jstanley wrote: post #19
skrebbel wrote: post #16

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…

Text mode is handy because it works transparently over SSH.

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.

Post reply on HN