search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.17k stars 8.26k forks source link

Terminal desperately needs a horizontal scrollbar (similar to Command Prompt) #1860

Open c0d3h4x0r opened 5 years ago

c0d3h4x0r commented 5 years ago

Note: 📌 Pinned comment: https://github.com/microsoft/terminal/issues/1860#issuecomment-1622136376

Summary of the new feature/enhancement

Windows Terminal needs to have a configurable horizontal scrollbar (similar to Command Prompt) so that lines longer than the window width are actually readable by scrolling to the right, rather than being a big indecipherable word-wrapped mess as is typically seen on UNIX-like systems.

Proposed technical implementation details (optional)

Make it so.

o-sdn-o commented 1 year ago

Windows Terminal already has everything you need for seamless integration. You could just add a new profile like this

{
    "commandline": "vtm -r term _your_favorite_shell_with_args_",
    "...: ..."
},

For example using powershell.exe as a shell

{
    "commandline": "vtm -r term powershell.exe",
    "guid": "{ff27e49f-ae21-4834-98f0-3e3d597e3d19}",
    "hidden": false,
    "name": "Powershel on Steroids"
},

In case of using WSL

{
    "commandline": "vtm -r term wsl.exe",
    "guid": "{ff27e49f-ae21-4834-98f0-3e3d597e3d20}",
    "hidden": false,
    "name": "WSL on Steroids"
},
o-sdn-o commented 1 year ago

If you expect performance to drop, then this is not the case. Some tests show a performance increase of about tens of times - 145kcg/s (WT only) vs 2114kcg/s (WT with vtm)

https://user-images.githubusercontent.com/11535558/194543266-83a9cc3a-83dd-492f-99ec-8b82448e1f6f.mp4

Alois-xx commented 1 year ago

That looks like a nice way, but the main reason for me to use Windows Terminal is that I can copy colored text as RTF so I can add text and no screenshots to presentations. So far I was not able to copy RTFwith vtm. Is this not supported? That would be a pity.

o-sdn-o commented 1 year ago

This is not supported yet, but adding RTF support shouldn't be too hard.

Update: vtm supports RTF and HTML clipboard formats for copied text since v0.9.6.

Gershy commented 1 year ago

It's a real pity this feature isn't available - I was psyched to be using Terminal until I realized I won't be unable to view wide, formatted output legibly. This is a dealbreaker for me. I understand there are 3rd-party programs that may be able to truncate wide outputs, but such a 3rd-party approach seems drastically too inconvenient across all my use-cases.

I do seriously appreciate the devs who are trying to better the lives of us windows users! Let's keep in mind that many windows devs rely on wide console buffers as an essential part of their workflow.

c0d3h4x0r commented 1 year ago

Yep. It's still a total dealbreaker for me as well. I won't be switching to Terminal until it can offer this basic decades-old capability.

Keith F. Kelly

https://www.soundcloud.com/syrinx_keith_f_kelly https://www.pastcurfew.band/

o-sdn-o commented 1 year ago

The 3rd party tool (ala terminal of infinite width) I mentioned doesn't truncate wide output, but rather allows horizontal scrolling of wide text content. In addition, PowerShell itself truncates wide content to the viewport width if no buffer width is specified. In that case you can use OSS function to specify the text buffer width.

E.g.

Get-ChildItem C:\Windows\ | oss 1000
# or
dir C:\Windows\ | oss 1000
c0d3h4x0r commented 1 year ago

That doesn't sound like the same app at all. This is about the standalone app literally called "Windows Terminal".

Keith F. Kelly

https://www.soundcloud.com/syrinx_keith_f_kelly https://www.pastcurfew.band/

AloisKraus commented 1 year ago

I have tried vtm which now also supports to copy text as RTF, HTML and ASCII. It works inside Windows Terminal and also from any other shell. Since this one is cross platform (Linux, Windows, MacOS) and supports wrap/non wrapping modes this is all I need. It have found a bug when RTF was copied to Word which was fixed within one day.

If you have problems with Windows Terminal not fixing bugs off you go to vtm!

Unlike other shells it renders very fast without screen glitches. The only things I miss are

whaaaley commented 1 year ago

If you're using WSL you can use tmux to do this. It's pretty great. tmux resize-window -x 1000 then Ctrl+b+[ will put you into "scroll mode" or whatever where you can use arrow keys and pg up/down and home/end to move around.

...Actual scroll bars would be better tho

marbaa commented 1 year ago

I'm daily working with linuxes over ssh for 13 years now. I never think of that windows cmd has this ability, to scroll horizontally. Now, the more I think about it, the more I need it.

Which other terminal software do you use which supports horizontal scrollbars other than Windows Console Host?

ixtk commented 1 year ago

So, it's either deal with broken multi-line string mess or decrease font size to such a small value that the log lines fit, but you can no longer see the output...

norrisgc commented 1 year ago

This is at least partially needed because - as has mentioned in this context - Windows Terminal often wraps output well before the width of the window it is in. That is nothing to do with an application wrapping it at the wrong length.

DHowett commented 1 year ago

Windows Terminal often wraps output well before the width of the window it is in

This isn't a report we've seen before! Would you mind filing a separate bug for it? It sounds like a bug, not a design decision that would be helped by having a horizontal scroll bar (after all, if we keep wrapping far too early there wouldn't be content off the right side for you to scroll to see!)

mathematician001 commented 1 year ago

4 years later, the scrollbar is still not there :( I'm inspecting a dataframe with 16 columns, and it looks atrocious. I have to resort to other apps for now. This comment is another plea to prioritize this feature over other features like retro effect.

SlimeQ commented 1 year ago

4 years later, the scrollbar is still not there :( I'm inspecting a dataframe with 16 columns, and it looks atrocious. I have to resort to other apps for now. This comment is another plea to prioritize this feature over other features like retro effect.

Maybe you can use Putty to log in to a wsl instance

xtender commented 1 year ago

Horizontal scrollbar is the only thing that doesn't allow me to switch to Windows terminal :( We really need it for sqlplus/sqlcl/pgsql/etc: image

FrankRay78 commented 1 year ago

I imagine many consumers of the popular spectre.console console library rely on no-wrap/a horizontal scrollbar for correct layout, eg table widget: image

jm903 commented 1 year ago

Same here, I work with database outputs, quite often 1000+ char wide. Line wrapping is forcing me to stick with cmd.exe. :( I spent 2 days trying out, got sooo close. I would also have some 10 more suggestions/bugs to report, but this one's a deal breaker.

Gershy commented 1 year ago

Any update here? Of all the top issues (based on thumbs-up count) this is almost certainly the most workflow-breaking, and most likely to turn away users.

SlimeQ commented 1 year ago

Any update here? Of all the top issues (based on thumbs-up count) this is almost certainly the most workflow-breaking, and most likely to turn away users.

Haha no

We're 4 years deep in this, it's never getting fixed

DHowett commented 1 year ago

The best way to be notified about updates to this issue is to subscribe! You can customize what level of information you receive on updates to this issue (such as an e-mail that is generated for every comment sent to every subscriber) by using this widget in the sidebar.

image
larioteo commented 1 year ago

Wow, after 4 years this issue is still open, that's how Microsoft listens to the community?

It's really annoying with forced word wrapping, nearly unusable. Some people like me use the Terminal also as "live-logger", with word wrapping over 1000 lines I don't know where the line starts or ends.

It would be cool from you guys to listen to the people that are using your products and supporting you in their free time.

It is not an excuse to say the console host had problems with larger buffers, this is a new project which could solve the issues the console host had.

travisterrell commented 1 year ago

Same here, I work with database outputs, quite often 1000+ char wide. Line wrapping is forcing me to stick with cmd.exe. :( I spent 2 days trying out, got sooo close. I would also have some 10 more suggestions/bugs to report, but this one's a deal breaker.

That what gets me about the comments asserting there's no need or that this would be non-standard. Many of Microsoft's own CLI apps produce very wide or columnar layouts, like sqlcmd, some az cli functions, etc.

zadjii-msft commented 1 year ago

Alrighty, I'm gonna come through and clear up this thread a bit.

First off: The community is definitely heard on this one. This was a big part of Conhost who's absence from Terminal is clearly felt. For folks where this is a part of their workflow, simply using tools like less isn't good enough.

There's been a lot of other priorities we've had over the last few years that have prevented us from getting to this. Alas, this just hasn't bubbled up the list of priorities yet (it's currently sitting as the 13th most 👍'd issue that's still open).

For the sake of issue maintenance, I'm gonna aggressively collapse a lot of the "omg i can't believe this doesn't work"-like comments in this thread, so that we can drill in on technical solution details without getting distracted.

I'm gonna copy in half a thought I had here: https://github.com/microsoft/terminal/issues/1860#issuecomment-738814484 into this comment, and iterate over time.

As always, the Terminal is an open-source project, and we'd love help from anyone passionate about this issue.

implementation notes here

wip branch: dev/migrie/f/1860-this-is-literally-what-less-is-for

We could add an experimental.minimumBufferWidth setting. When we do resizes, we make sure the conpty buffer is always at least that big, regardless of the terminal viewport width. I'm sure there would be weird edge cases. We'd need to make sure that the handling of cursor positioning in the Terminal buffer isn't too reliant on the terminal viewport, but instead the underlying buffer.

I really have no idea how bad the UX would be. But it would be a place to start.

I'd absolutely stick this as an experimental. setting, because I want to make sure it's clear that it's an unsupported scenario.

IIRC I was going to start by sticking a member on Terminal in https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalCore/Terminal.cpp that's just "minimum buffer width", and make sure that when we resize the connection in ControlCore, we never resize the width to less than that. Though, we'd need to make sure that we allow Terminal to have a VISIBLE viewport whose width can be less than the buffer width. From VT's perspective, the viewport will remain the buffer width, it just won't all be visible. Interesting.

Obviously, if the window is resized wider, then we'll just use that width as the buffer width.

I wonder if there's a way that we can track the longest actual line we've seen, without constantly calling MeasureRight. If we did that, then we could have the scrollbar only work as a function of the longest printed row, rather than just the full backing buffer width.

There's a whole bunch of assumptions on the TermControl/ControlCore/Terminal boundary that bakes in an assumption that there's no difference between the buffer width and the visible viewport width.

Other stuff to do:

o-sdn-o commented 1 year ago

I wonder if there's a way that we can track the longest actual line we've seen, without constantly calling MeasureRight. If we did that, then we could have the scrollbar only work as a function of the longest printed row, rather than just the full backing buffer width.

Perhaps the following approach will be useful, it is possible to use std::map for this

std::map is a sorted associative container that contains key-value pairs with unique keys.


std::map<int, int> sizes;

// Register a new line. void invite(int new_size) { ++sizes[new_size]; } // Drop the line. void undock(int size) { auto iter = sizes.find(size); assert(iter != sizes.end()); auto pool = --(*iter).second; if (pool == 0) sizes.erase(iter); } // Update existing line. void recalc(int old_size, int new_size) { if (old_size != new_size) { undock(old_size); invite(new_size); } } // Return the max line length. auto getmax() { return sizes.empty() ? 0 : sizes.rbegin()->first; }


If it is known in advance that all strings are short, then std::vector\<int\>[max_length] will be sufficient (+ check for the maximum when deleting).
jm903 commented 1 year ago

There's been a lot of other priorities we've had over the last few years that have prevented us from getting to this. Alas, this just hasn't bubbled up the list of priorities yet (it's currently sitting as the 13th most 👍'd issue that's still open).

I understand if you flag this as off topic, but do have to ask. Seems that you guys follow the thumbs-up counts, you certainly refer to it as the thing that sets your priorities. Seeing the #1 on that list being emoji support, does not seem to make sense to be religous about that list? There are show stoppers that prevent people from using the tool at all, but the most important thing is to add emoji support? I admit I may not understand how important emojis could be to someone's work.

j4james commented 1 year ago

I wonder if there's a way that we can track the longest actual line we've seen, without constantly calling MeasureRight. If we did that, then we could have the scrollbar only work as a function of the longest printed row, rather than just the full backing buffer width.

@zadjii-msft In order to be compatible with the VT windowing extension, we need to handle this more or less the same way it's done in conhost, i.e. with a fixed buffer width that's independent of the visible viewport width. Once you've set the buffer width, that's the defined the extent of any VT cursor movement. It doesn't change based on how much text has been output.

I've actually considered just implementing the VT side of this without any UI as a first step. Once we have the basic architecture in place, we can worry about things like the scrollbar and settings for the initial buffer size as a later enhancement.

zadjii-msft commented 1 year ago

@jm903 👍's aren't a hard & fast rule, but they're certainly a good analog. "emoji support" is also kinda a misnomer - yes, it means emoji, but it's also more broadly "Support a broader array of unicode glyphs, that may or may not be more than one wchar per cell, on both output and on input, including the win32 console input APIs"[^1]. That's relevant not just for emoji, but really any language that's not just using latin characters.

[^1]: you can see how that doesn't roll off the tongue as easily 😝

zadjii-msft commented 1 year ago

, i.e. with a fixed buffer width that's independent of the visible viewport width. Once you've set the buffer width, that's the defined the extent of any VT cursor movement. It doesn't change based on how much text has been output.

That's exactly what I was thinking. So, with a viewport width of 80 and a buffer width set to 5000, a \x1b[9999C\x8\x8 would take you to column 4998, not column 72. It'd be annoying, sure, but I don't imagine there's a lot of overlap between users that that do full-screen VT stuff (linux-y) that are also in the camp of needing this (windows-y) simultaneously.

My commentary about

we could have the scrollbar only work as a function of the longest printed row

was more just musing on "could we start with the horizontal scrollbar hidden, and only show it when the app emits l o n g lines? and could we have it's width be relevant to what's been output?" So that there's not just vast empty space the user can scroll into on the right side of the screen.

j4james commented 1 year ago

was more just musing on "could we start with the horizontal scrollbar hidden, and only show it when the app emits l o n g lines? and could we have it's width be relevant to what's been output?" So that there's not just vast empty space the user can scroll into on the right side of the screen.

I'm not sure. I think I'd find that confusing. If I've configured the buffer width to be wider than the screen, I'd expect to be able to scroll over that full width regardless of whether there's been any text output there or not. Otherwise I'd probably assume something wasn't working.

That said, I'd also prefer a hidden scrollbar that only showed on hover, and the option to scroll using the keyboard instead. Because from a VT compatibility point of view, changing the buffer width shouldn't shrink the available page height. So either the scrollbar space is allocated up front, regardless of whether it's initially visible, or it needs to be rendered as an overlay when it does appear.

zadjii-msft commented 1 year ago

Fair enough. That was noodling on the UX, not a definite requirement.

So either the scrollbar space is allocated up front, regardless of whether it's initially visible

This seems infinitely easier than reveal on hover. At least the winui scroll bars are pretty subtle when not moused over.

zadjii-msft commented 1 year ago

Well, I hate the code. And I hate that the DX and Atlas engines both seem to not support horizontal scrolling (even in conhost).

but like, proof of concept:

seriously-just-use-less-001

j4james commented 1 year ago

I hate that the DX and Atlas engines both seem to not support horizontal scrolling

DX seems to work for me. Atlas has a few issues, but I'm almost sure it used to work in the past, so maybe there's something that regressed recently.

bigvzhang commented 1 year ago

The problem seems resolved. But I don't know how to configure it on my desktop. Would you guys kindly tell me how to do it?

AloisKraus commented 1 year ago

@bigvzhang: The issue #15707 which is merged just deals with bugs in the rendering engine. The bug fixes which are needed later to implement the feature are now shipped with the next release. I do not see any scrolling code in the public.

zadjii-msft commented 1 year ago

That's correct. I only ever got this to a WIP state. My notes are up in https://github.com/microsoft/terminal/issues/1860#issuecomment-1622136376. Not sure I'll have time to loop back around to polish for shipping any time soon.

larioteo commented 1 year ago

I personally can't await this feature ...

simonjha commented 11 months ago

Yes, we absolutely need this feature, which "Command Prompt" provided before through its properties-buffer setting.

We've been using "Command Prompt" console to print the application logs, which are long string lines. When we read those lines, we definitely don't want the text line wrapped, but want a horizontal scrolling.

It is so bad that it lost this function, after "Command Prompt" was moved to Windows Terminal.

By the way, we mostly use "Command Prompt" console to SSH to the Unix systems to read app log text files having the long string lines. If the lines are wrapped, no way you can read them.

So, please, please add non-word-wrap & horizontal scrollbar back in Windows Terminal.

BerndHme commented 8 months ago

Please add word wrapping. Like the VS output console can. There is a toggle button.

karunkrishna commented 7 months ago

Seeing data on a horizontal scroll would be killer Currently need to subset data columns or shrink terminal to non-legible level just to view data in tabular format.

image

thisismygitrepo commented 7 months ago

Until this is implemented, please use a scroller utility (pager or whatever you call it). This one works fine data scroller

I switched to wezterm and its the same problem so it seems that this is the way to go.

cesar-o9 commented 7 months ago

Seeing data on a horizontal scroll would be killer Currently need to subset data columns or shrink terminal to non-legible level just to view data in tabular format.

image

You can try "tput rmam" (remove auto margin). that works for me. to reset it "tput smam" to set it again.

zehawki commented 6 months ago

Yup here is another example of unreadable madness:

image

Cremesis commented 5 months ago

Yeah, SQL outputs and the like are extremely useless without the ability to disable word wrap and use a horizontal scroll bar. Please, we need this feature!

marbaa commented 4 months ago

Someone would not believe that it is 5 years, since request was made...

Cfun1 commented 3 months ago

I have the latest version of windows command line terminal. When executing a console app from VS that prints long line (just few characters off screen), there is no word wrap being applied nor horizontal scroll available also I can't find any relevant setting. The only way is to select and move mouse cursor to right direction to be able to see off screen text of the long line

scharnyw commented 2 months ago

As mentioned in https://github.com/microsoft/terminal/issues/6895#issuecomment-1048641000, a workaround for now is to temporarily decrease the font size with ctrl-minus

mcdonamw commented 1 month ago

That's not a good workaround. In many cases, e.g., that screenshot above, you'd have to lower the font to the point it was unreadable.

mcdonamw commented 1 month ago

One of the biggest requests we had for Windows 10 was to add support for wrapping to the traditional/legacy console!

keyword: add