UI to Page / up and down by command + copy all output

[stuaxo]

It would be good if there was a UI element somewhere to page up or down to the previous or next command: [▲][▼]

This is something so useful, I'm not sure why no terminal emulator has it.

Would need a keybinding, ctrl pageup / down ?

Similarly, useful: Right click to copy all the output from a single command to the clipboard.

The terminal would probably need to have some idea about when it is rendering a prompt vs something else to enable this.

[zadjii-msft]

As much as I love the idea, you've hit the nail on the head as to why no other terminals have this:

The terminal would probably need to have some idea about when it is rendering a prompt vs something else to enable this.

I'm not totally sure that's possible at all. I'm gonna leave this open for discussion, probably @egmontkob would have thoughts here. If there was some mechanism that terminal emulators agreed upon for marking a line as a "prompt", then we'd totally implement it. It would have to work for things like vim, emacs, Far Manager, in addition to simple shells like powershell and bash. Even then, it probably wouldn't be possible to ad to cmd.exe ever unfortunately, but that's not terribly relevant to this discussion 😝

[stuaxo]

I guess this really needs some new ANSI sequences.

To bikeshed for a moment: there could be an idea of text types, "prompt" - the non editable bit of the prompt "editable" - the editable bit of the prompt, and "output", where program output goes.

ANSI codes would specify all output from that point is of one of those types.

Being able to see where the editable bit of the prompt is would make it easier for terminal emulators to implement selecting just the user edited text (e.g. by triple click) and not the prompt as well.

Example showing where ANSI codes would go (but not the actual sequences):

/home/me $ ls
burger.txt

[text-type-prompt]/home/me/ $[text-editable]ls
[text-type-output]burger.txt

[egmontkob]

gnome-terminal discussion counterpart here

One possibility for the terminal is to guess, based on (hardcoded or customizable) prompt regexes or such. Not user friendly in the long term, the ideal goal is to make it work out of the box even for those who customize their prompt, and also there's always a chance of false matches when such detection happens. If done this way, the feature is a close friend of the "search in the terminal" feature, in fact, a user might already use the "search" feature to search for the previous some-string-specific-to-the-prompt. This approach is doable solely in the terminal, without requiring cooperation from other parties, and might work with cmd.exe too.

Another possibility is to remember the rows where the user pressed Enter and jump through them.

Probably the "proper" solution would indeed require for shells to emit markers. A huge short-term disadvantage is that it requires cooperation across some parties, like popular terminals and shells. Unfortunately my previous experiences with trying to get buy-in from bash's author to other integration ideas weren't quite supportive, I doubt he would be interested in this, but maybe. Also this would be one of the first steps towards a "semantical terminal", a pretty new direction, as right now terminals are about the look only. Whether it's a good direction or a bad one, opens up a can of worms or a can of great ideas, I don't know. iTerm2 does its "shell integration" along these lines, it configures the shell to emit some escape sequences. I don't know how robust it is, e.g. how it interferes with the shell occasionally redisplaying its prompt, or maybe just a part thereof, etc. I also don't know any further details, like which points are remembered (as per the "bikeshed" part of stuaxo's comment). It's also unclear to me how it's best to define "where" this data is stored, e.g. are these markers tied to the previous character cell, or the subsequent, or a new in-between-cell storage, or to the current line (and then what to do when rewrapping on a resize?), or to the current paragraph (between explicit newlines); what operations exactly erase them, scroll them, etc., it's all brand new area.

[DHowett-MSFT]

I'm gonna close this one out, but only for now. I'd love to see if we can pursue a standards-compliant way to do this that all TEs can agree upon, but in the meantime search is a perfectly serviceable option. Once search gets things like regex support and marker highlighting, it will be an even more compelling solution to this problem.

[zadjii-msft]

Oh I'm SO reopening this. This is gonna be so easy with the rest of #11000. Yes, it requires shell integration, but there's gonna be a lot of reasons to want to enable that.

[zadjii-msft]

"I needed to make sure that I had implemented OSC 9 ; 12 right"

dev/migrie/f/4588-select-shell-output

[DHowett]

Holy crap. That's cool.

[zadjii-msft]

From #14642:

Make sure to select the current command (if there is one) first

[Araxeus]

Right click to copy all the output from a single command to the clipboard.

Added in #15020 🥰

[stuaxo]

This is a fantastic feature, are any of the dev evangelists here ?

Would love to see this written up on the windows terminal dev blog, including the mechanisms used to mark the start and end.

[zadjii-msft]

Would love to see this written up on the windows terminal dev blog, including the mechanisms used to mark the start and end

You know what - we should! I'll take a personal todo item to write something up for the commandline blog after this all merges (and we're closer to shipping 1.18)

[zadjii-msft]

FWIW I did write something up about this: Shell integration in the Windows Terminal

[stuaxo]

This is great, ~~it would be good if you could go a little into which ansi codes enable which functionality (and just the technical side in general) - maybe that's another post or something to expand on in the comments.~~

Edit: just noticed you did cover this :) /Edit

I've only just skimmed this but will go back and have a proper read, theres some good functionality there.