161–170 of 204 posts
Having to use the mouse to select/highlight/copy output I didn't know I was interested in until after it'd been outputted. Being able to export/open the currently visible history/output to an editor would be great.
> - What do you love about terminals?
Unless I'm suddenly interested in the output of a previously run command that can't be reproduced, I can interface with them without using the mouse at all.
There are some that split to various degrees already; I don;t know how aware the panes are of each other or if they'll happily pipe into each other. I'd like to be able to run a script in one pane and have the outputs go into different panes as directed by the script.
Earlier quoted context omitted.
Along with this, it'd be so nice to have line numbers for certain outputs along with a simple way of outputting a specific line to the clipboard or a file.
iirc, there is a program called 'nl' that should do the trick
There's "cat -n" which numbers all lines. (-n is not POSIX, but it's available on at least on BSDs and Linux.)
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…
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…
Earlier quoted context omitted.
iirc, there is a program called 'nl' that should do the trick
I find "nl" pretty useless, because it only numbers non-empty lines, which is never what I want. There's "cat -n" which numbers all lines. (-n is not POSIX, but it's available on at least on BSDs and Linux.)
> sed -n 16p filename > newfile
where 16 is the line number.. this is it! That's quite handy.
It would be cool if the local terminal could render text at the speed of typing and while lazily sending that back to the other machine.
Earlier quoted context omitted.
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 :)
That seems like an incredibly common use case to me. It's common for a command to have a lot more output than I originally expected, and when it happens, I usually want to examine that output in detail. It would be great to retroactively be able to open captured output in a text editor, dump it to a file, pipe it to another tool, or collapse it.
I don't really want to edit the output in the terminal, but it would be great to be able to say "oops, do X with stdout from that last command, and do Y with stderr".
Earlier quoted context omitted.
Not really, just the way that keyboard input is mapped to a charset (like ANSI or Unicode). A keyboard is not a device that is 100% compatible with any character set (mainly because it is an array of keys that have an arbitrary meaning in a charset). The current terminal architecture enforces any application to adopt its mapping of key combination to code points, which doesn't really make sense, at least from an inpu…
What you say about keyboards is true for PC keyboards, but was not always, historically, the case. Terminals always sent the ASCII code of the pressed key(s), and especially in early terminals, all CTRL really did was to mask off the highest bits of the transmitted code leaving a value between 0-31 -- the ASCII control range. That's why ^I is TAB and ^[ is escape. If we implemented what you proposed, terminal emulato…
While that's a worthwhile discussion to have and I see the difficulties in maintaining compatibility (see my original post), I'd say that arguing either way goes somewhat against the premise of this thread.
Fix scrollback. Sometimes I run a command and it has 50,000 lines of output. Either I don't care about the output — in which case I should be able to click to fold it up and be able to see my history before that one command — or I do care about it, in which case I want every scroll, search and export operation that a full-fledged document editor would have. In either case, UI latency shouldn't suffer, scroll bars sho…
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.)