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

@DHowett-MSFT commented on GitHub (Jul 8, 2019):

indecipherable word-wrapped mess

I mean, that seems a little strong. One of the biggest requests we had for Windows 10 was to add support for wrapping to the traditional/legacy console!

@DHowett-MSFT commented on GitHub (Jul 8, 2019): > indecipherable word-wrapped mess I mean, that seems a little strong. One of the biggest requests we had for Windows 10 was to add support for wrapping to the traditional/legacy console!

claunia commented

@c0d3h4x0r commented on GitHub (Jul 8, 2019):

That's because I feel strongly about it :) I absolutely hate line-wrapped console output... always have.

@c0d3h4x0r commented on GitHub (Jul 8, 2019): That's because I feel strongly about it :) I absolutely hate line-wrapped console output... always have.

claunia commented

@caitlynrw commented on GitHub (Jul 8, 2019):

Maybe make it a config,

"text-wrap": false

when true does as it does now, false gives horizontal scrollbar.

Edit: I didn't read the original post correctly, so proposed config*

@caitlynrw commented on GitHub (Jul 8, 2019): Maybe make it a config, ```json "text-wrap": false ``` when `true` does as it does now, `false` gives horizontal scrollbar. Edit: I didn't read the original post correctly, so proposed config*

claunia commented

2026-01-30 22:59:55 +00:00

@egmontkob commented on GitHub (Jul 8, 2019):

The traditional Unix terminal emulation (using ANSI escape sequences) is pretty much incompatible with this idea. See e.g. https://bugzilla.gnome.org/show_bug.cgi?id=769440.

@egmontkob commented on GitHub (Jul 8, 2019): The traditional Unix terminal emulation (using ANSI escape sequences) is pretty much incompatible with this idea. See e.g. https://bugzilla.gnome.org/show_bug.cgi?id=769440.

claunia commented

@zadjii-msft commented on GitHub (Jul 8, 2019):

Yea I don't think we're going to change this, for the exact reason mentioned by @egmontkob. What we're trying to build is a terminal, not a console. While the horizontal scrollbar made sense in the console, where the viewport could be smaller than the buffer in both the x and y directions, a terminal's viewport is fundamentally the same size as the buffer.

Even if we added this setting to the Terminal, it's still connected to conpty, which is acting like a terminal buffer itself, and it won't emit sequences that act like the old console did.

@zadjii-msft commented on GitHub (Jul 8, 2019): Yea I don't think we're going to change this, for the exact reason mentioned by @egmontkob. What we're trying to build is a _terminal_, not a _console_. While the horizontal scrollbar made sense in the console, where the viewport could be smaller than the buffer in both the x and y directions, a terminal's viewport is fundamentally the same size as the buffer. Even if we added this setting to the Terminal, it's still connected to conpty, which is acting like a terminal buffer itself, and it won't emit sequences that act like the old console did.

claunia commented

2026-01-30 22:59:55 +00:00

@c0d3h4x0r commented on GitHub (Jul 8, 2019):

Then I guess I won't be adopting Windows Terminal after all, because that's a dealbreaker for me.

@c0d3h4x0r commented on GitHub (Jul 8, 2019): Then I guess I won't be adopting Windows Terminal after all, because that's a dealbreaker for me.

claunia commented

2026-01-30 22:59:55 +00:00

@AlwaysHC commented on GitHub (Jan 2, 2020):

I need horizontal scrolling and wrapping disabled too

@AlwaysHC commented on GitHub (Jan 2, 2020): I need horizontal scrolling and wrapping disabled too

claunia commented

2026-01-30 22:59:56 +00:00

@AlwaysHC commented on GitHub (Jan 2, 2020):

Cmd and ConsoleZ have this feature

@AlwaysHC commented on GitHub (Jan 2, 2020): Cmd and ConsoleZ have this feature

claunia commented

2026-01-30 22:59:56 +00:00

@zadjii-msft commented on GitHub (Jan 2, 2020):

@AlwaysHC Could you elaborate more on why you need this feature? I don't think I really understand the use case. Maybe there's some way to make your workflow work in the Windows Terminal without a horizontal scrollbar?

@zadjii-msft commented on GitHub (Jan 2, 2020): @AlwaysHC Could you elaborate more on _why_ you need this feature? I don't think I really understand the use case. Maybe there's some way to make your workflow work in the Windows Terminal without a horizontal scrollbar?

claunia commented

2026-01-30 22:59:56 +00:00

@c0d3h4x0r commented on GitHub (Jan 3, 2020):

@zadjii-msft Because wrapped lines are obnoxiously more difficult to visually parse.

@c0d3h4x0r commented on GitHub (Jan 3, 2020): @zadjii-msft Because wrapped lines are obnoxiously more difficult to visually parse.

claunia commented

@AlwaysHC commented on GitHub (Jan 15, 2020):

@AlwaysHC Could you elaborate more on why you need this feature? I don't think I really understand the use case. Maybe there's some way to make your workflow work in the Windows Terminal without a horizontal scrollbar?

tail -f /var/log/messages

@AlwaysHC commented on GitHub (Jan 15, 2020): > > > @AlwaysHC Could you elaborate more on _why_ you need this feature? I don't think I really understand the use case. Maybe there's some way to make your workflow work in the Windows Terminal without a horizontal scrollbar? tail -f /var/log/messages

claunia commented

@matthewgdv commented on GitHub (Feb 6, 2020):

I'm in agreement that we need this feature. I use a lot of interactive workflows that display asciified tables in the terminal (which are often several screen-lengths long) and having them be wrapped is a dealbreaker since it turns them into illegible gibberish. Likewise with several other forms of console output where the formatting across lines is important. Please implement horizontal scrolling as an option because currently I think this terminal will be useless to a lot of users with similar requirements.

@matthewgdv commented on GitHub (Feb 6, 2020): I'm in agreement that we need this feature. I use a lot of interactive workflows that display asciified tables in the terminal (which are often several screen-lengths long) and having them be wrapped is a dealbreaker since it turns them into illegible gibberish. Likewise with several other forms of console output where the formatting across lines is important. Please implement horizontal scrolling as an option because currently I think this terminal will be useless to a lot of users with similar requirements.

claunia commented

@4nqyi commented on GitHub (May 15, 2020):

Would love to see a configurable horizontal size with horizontal scroll-bar.
Something similar to cmd window would be great.

Until this feature is implemented, i'll be sticking with the default Ubuntu shell.

@4nqyi commented on GitHub (May 15, 2020): Would love to see a configurable horizontal size with horizontal scroll-bar. Something similar to cmd window would be great. Until this feature is implemented, i'll be sticking with the default Ubuntu shell.

claunia commented

@AlwaysHC commented on GitHub (Jun 17, 2020):

Both issues are closed now, however we don't have the possibility to disable the word wrap yet :(

@AlwaysHC commented on GitHub (Jun 17, 2020): Both issues are closed now, however we don't have the possibility to disable the word wrap yet :(

claunia commented

@marveloo commented on GitHub (Jul 1, 2020):

I am copying the question which I asked here: #6730

Why is Windows terminal unable to load a wide window (of fixed width) behind the scenes with only a part of the window visible to the user and a horizontal scrollbar to move that window from side to side? The shell itself may not even be aware of me staring at it throw a smaller size window. In other words all this thing could be implemented on the UI part only by letting the shell think that I am on a wider window than it actually is.

@marveloo commented on GitHub (Jul 1, 2020): I am copying the question which I asked here: #6730 Why is Windows terminal unable to load a wide window (of fixed width) behind the scenes with only a part of the window visible to the user and a horizontal scrollbar to move that window from side to side? The shell itself may not even be aware of me staring at it throw a smaller size window. In other words all this thing could be implemented on the UI part only by letting the shell think that I am on a wider window than it actually is.

claunia commented

@jschiold commented on GitHub (Sep 14, 2020):

I was happy with trying the new Windows Terminal, but when I needed to turn off word-wrapping (because I wanted to use Oracle SQL*Plus and make some queries, etc.), to my surprise, I realized that it was not actually possible. That seems really silly to me.
I guess I'll have to go back to using the classic command prompt for the most part.

@jschiold commented on GitHub (Sep 14, 2020): I was happy with trying the new Windows Terminal, but when I needed to turn off word-wrapping (because I wanted to use Oracle SQL*Plus and make some queries, etc.), to my surprise, I realized that it was not actually possible. That seems really silly to me. I guess I'll have to go back to using the classic command prompt for the most part.

claunia commented

@DHowett commented on GitHub (Sep 20, 2020):

If we make any changes here, they are going to be in line with other terminal emulators that have established precedent: the typical options are wrap or truncate. Would truncate be more to your liking?

@DHowett commented on GitHub (Sep 20, 2020): If we make any changes here, they are going to be in line with other terminal emulators that have established precedent: the typical options are wrap or truncate. Would truncate be more to your liking?

claunia commented

@c0d3h4x0r commented on GitHub (Sep 20, 2020):

The behavior ought to be exactly the same as Command Prompt has been for ages: word-wrap, but only beyond a buffer width that the user can configure to be much wider than the actual window width. For example, allow me to set the buffer width to 9999 characters, so that word wrapping does not occur until the 10000th character on each line (which should effectively never wrap).

@c0d3h4x0r commented on GitHub (Sep 20, 2020): The behavior ought to be exactly the same as Command Prompt has been for ages: word-wrap, but only beyond a buffer width that the user can configure to be much wider than the actual window width. For example, allow me to set the buffer width to 9999 characters, so that word wrapping does not occur until the 10000th character on each line (which should effectively never wrap).

claunia commented

@j4james commented on GitHub (Sep 21, 2020):

I think the confusion here stems from the fact that some people were expecting a kind of "infinite" width, that would expand as more content was written out. I don't think that is feasible for a terminal. However, a wide (but fixed size) buffer within a smaller viewport is a different matter. As had been mentioned, we already support that in the conhost console. And it's worth mentioning that some of the DEC terminals supported a similar concept, so it's not without precedent.

That said, for many of the use cases mentioned, you can probably get by with piping your output through less -S. That should give you an unwrapped view of the content that can be scrolled horizontally.

@j4james commented on GitHub (Sep 21, 2020): I think the confusion here stems from the fact that some people were expecting a kind of "infinite" width, that would expand as more content was written out. I don't think that is feasible for a terminal. However, a wide (but fixed size) buffer within a smaller viewport is a different matter. As had been mentioned, we already support that in the conhost console. And it's worth mentioning that some of the DEC terminals supported a similar concept, so it's not without precedent. That said, for many of the use cases mentioned, you can probably get by with piping your output through `less -S`. That should give you an unwrapped view of the content that can be scrolled horizontally.

claunia commented

@matthewgdv commented on GitHub (Sep 21, 2020):

I totally agree with @c0d3h4x0r. As long as it can at the very least do exactly what CMD already does regarding large buffer sizes, I'll be happy. Currently I can't use this new terminal for any form of interesting ASCII-fied output, such as a database table returned by a SQL query.

@matthewgdv commented on GitHub (Sep 21, 2020): I totally agree with @c0d3h4x0r. As long as it can at the very least do exactly what CMD already does regarding large buffer sizes, I'll be happy. Currently I can't use this new terminal for any form of interesting ASCII-fied output, such as a database table returned by a SQL query.

claunia commented

@rossmassey commented on GitHub (Sep 24, 2020):

if you are using psql, try this when running it:

PAGER="less -S" psql ...

it will let you scroll horizontally like @j4james mentioned

@rossmassey commented on GitHub (Sep 24, 2020): if you are using psql, try this when running it: `PAGER="less -S" psql ...` it will let you scroll horizontally like @j4james mentioned

claunia commented

@Alois-xx commented on GitHub (Oct 26, 2020):

I also like to disable word wrapping for wide output which may be truncated at e.g. 500 char width but until then I do not want to see parts of it on the next line. One extreme example is e..g
C>wmic process
which needs ca. a width of 2000 to become readable. Tabular data is not uncommon. I can zoom out on my 4K monitor to some extent but this is still an big issue to become a console I would like to use always over the "old" one.

@Alois-xx commented on GitHub (Oct 26, 2020): I also like to disable word wrapping for wide output which may be truncated at e.g. 500 char width but until then I do not want to see parts of it on the next line. One extreme example is e..g C>wmic process which needs ca. a width of 2000 to become readable. Tabular data is not uncommon. I can zoom out on my 4K monitor to some extent but this is still an big issue to become a console I would like to use always over the "old" one.

claunia commented

@newtoniumx3 commented on GitHub (Oct 30, 2020):

Ya this feature is a must or simply can't use this terminal for developing with docker, the output especially for stat commands is super wide and with line wrap its unreadable

@newtoniumx3 commented on GitHub (Oct 30, 2020): Ya this feature is a must or simply can't use this terminal for developing with docker, the output especially for stat commands is super wide and with line wrap its unreadable

claunia commented

@cmario92 commented on GitHub (Dec 4, 2020):

so it this feature request dropped? or are we expecting to have it at some point?

@cmario92 commented on GitHub (Dec 4, 2020): so it this feature request dropped? or are we expecting to have it at some point?

claunia commented

@zadjii-msft commented on GitHub (Dec 4, 2020):

The official plan is no, we're not planning on supporting this. I'd be shocked to find another terminal emulator that's not conhost that supports this. If an application is emitting output that's too wide for the buffer, then that sounds like the app has a bad UX, not the Terminal, since all terminal emulators will have that bad UX (IMO).

<bottle-feeding thought>

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.

</bottle-feeding thought>

@zadjii-msft commented on GitHub (Dec 4, 2020): The official plan is no, we're not planning on supporting this. I'd be shocked to find another terminal emulator that's _not_ conhost that supports this. If an application is emitting output that's too wide for the buffer, then that sounds like the app has a bad UX, not the Terminal, since _all_ terminal emulators will have that bad UX (IMO). \<bottle-feeding thought> 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. \</bottle-feeding thought>

claunia commented

2026-01-30 23:00:00 +00:00

@c0d3h4x0r commented on GitHub (Dec 4, 2020):

"We're not going to do what users are begging for, because we are more interested in finding excuses to be lazy and weasel our way out of it."

Typical Microsoft, not listening to your users.

@c0d3h4x0r commented on GitHub (Dec 4, 2020): "We're not going to do what users are begging for, because we are more interested in finding excuses to be lazy and weasel our way out of it." Typical Microsoft, not listening to your users.

claunia commented

@pc223 commented on GitHub (Dec 5, 2020):

Can't we just lie to the terminal, say, real width is 500, but only show 80 to user, and a horizontal scroll?

This issue is a deal breaker for me, because I use horizontal scroll a lot on cmd and powershell to observe log. And logs are not always design for 80x24, sometimes it's really really long.

With horizontal scroll, 1 line of log, most of the time, means 1 thing happened, 3 lines?, 3 things, simple. With current line-wrapping, 1 line of log == multiple lines of logs -> consume all the terminal space.

@pc223 commented on GitHub (Dec 5, 2020): **Can't we just lie to the terminal, say, real width is 500, but only show 80 to user, and a horizontal scroll?** This issue is a deal breaker for me, because I use horizontal scroll a lot on `cmd` and `powershell` to observe log. And logs are not always design for 80x24, sometimes it's really really long. With horizontal scroll, 1 line of log, most of the time, means 1 thing happened, 3 lines?, 3 things, simple. With current line-wrapping, 1 line of log == multiple lines of logs -> consume all the terminal space.

claunia commented

2026-01-30 23:00:00 +00:00

@jschiold commented on GitHub (Dec 7, 2020):

The regular Windows Command Prompt solves this in a simple and elegant way.

I will have to continue using that instead.

@jschiold commented on GitHub (Dec 7, 2020): The regular Windows Command Prompt solves this in a simple and elegant way. ![image](https://user-images.githubusercontent.com/70741520/101322767-dc13bc80-3867-11eb-980c-2e376df86439.png) I will have to continue using that instead.

claunia commented

2026-01-30 23:00:01 +00:00

@dje-dev commented on GitHub (Dec 29, 2020):

Please count me as another user who thinks Windows Terminal is great, but force word wrapping makes this product unusable - the output becomes unreadable in many situations where it exceeds the current horizontal size.

@dje-dev commented on GitHub (Dec 29, 2020): Please count me as another user who thinks Windows Terminal is great, but force word wrapping makes this product unusable - the output becomes unreadable in many situations where it exceeds the current horizontal size.

claunia commented

2026-01-30 23:00:01 +00:00

@kzhangkzhang commented on GitHub (Feb 17, 2021):

same for me: I am running Oracle's sqlplus and many output line width >200 characters. need Windows terminal provide horizontal screen bar feature. I am so excited to use new Windows terminal until I see this issue and I am very regret to stop using this product. I will switch back in future once this feature is available.

@kzhangkzhang commented on GitHub (Feb 17, 2021): same for me: I am running Oracle's sqlplus and many output line width >200 characters. need Windows terminal provide horizontal screen bar feature. I am so excited to use new Windows terminal until I see this issue and I am very regret to stop using this product. I will switch back in future once this feature is available.

claunia commented

2026-01-30 23:00:01 +00:00

@iuricarraro commented on GitHub (Mar 22, 2021):

Fiquei feliz em experimentar o novo Terminal do Windows, mas quando precisei desligar a quebra automática de linha (porque queria usar o Oracle SQL * Plus e fazer algumas consultas, etc.), para minha surpresa, percebi que não era realmente possível. Isso parece muito bobo para mim.
Acho que terei que voltar a usar o prompt de comando clássico na maior parte do tempo.

I was happy with trying the new Windows Terminal, but when I needed to turn off word-wrapping (because I wanted to use Oracle SQL*Plus and make some queries, etc.), to my surprise, I realized that it was not actually possible. That seems really silly to me.
I guess I'll have to go back to using the classic command prompt for the most part.

I totally agree. It is a very important resource for executing SQLs and analyzing logs.

Windows Terminal is an excellent tool and you need to allow this configuration as soon as possible. Buffer size width already exists on the PowerShell console and CMD. If Windows Terminal wants to do a complete integration, it must provide this feature.

@iuricarraro commented on GitHub (Mar 22, 2021): > Fiquei feliz em experimentar o novo Terminal do Windows, mas quando precisei desligar a quebra automática de linha (porque queria usar o Oracle SQL * Plus e fazer algumas consultas, etc.), para minha surpresa, percebi que não era realmente possível. Isso parece muito bobo para mim. > Acho que terei que voltar a usar o prompt de comando clássico na maior parte do tempo. > I was happy with trying the new Windows Terminal, but when I needed to turn off word-wrapping (because I wanted to use Oracle SQL*Plus and make some queries, etc.), to my surprise, I realized that it was not actually possible. That seems really silly to me. > I guess I'll have to go back to using the classic command prompt for the most part. I totally agree. It is a very important resource for executing SQLs and analyzing logs. Windows Terminal is an excellent tool and you need to allow this configuration as soon as possible. Buffer size width already exists on the PowerShell console and CMD. If Windows Terminal wants to do a complete integration, it must provide this feature.

claunia commented

2026-01-30 23:00:02 +00:00

@oldtimerza commented on GitHub (May 7, 2021):

Is this feature in the works or has it been shelved?

It's a feature that I would also greatly benfit from, especially when reading docker container logs.

@oldtimerza commented on GitHub (May 7, 2021): Is this feature in the works or has it been shelved? It's a feature that I would also greatly benfit from, especially when reading docker container logs.

claunia commented

2026-01-30 23:00:02 +00:00

@zadjii-msft commented on GitHub (May 7, 2021):

It's in the icebox, so it's not something we're ever planning on getting to ourselves, but it's a neat idea that could be brought out of the icebox if there's enough community demand.

My only plan for ever enabling this is under an "experimental" flag (as described above). It's very likely that this would break more scenarios than it would fix, so I'd want users to know that before they enable it.

especially when reading docker container logs.

less -S may be your friend here. The right and left arrow keys can navigate left and right in the file - it's not quite like a horizontal scrollbar, but has always worked for me.

@zadjii-msft commented on GitHub (May 7, 2021): It's in the icebox, so it's not something we're ever planning on getting to ourselves, but it's a neat idea that could be brought out of the icebox if there's enough community demand. My only plan for ever enabling this is under an "experimental" flag (as described above). It's very likely that this would break more scenarios than it would fix, so I'd want users to know that before they enable it. > especially when reading docker container logs. `less -S` may be your friend here. The right and left arrow keys can navigate left and right in the file - it's not quite like a horizontal scrollbar, but has always worked for me.

claunia commented

2026-01-30 23:00:03 +00:00

@rajatsharmasubedi commented on GitHub (Jul 21, 2021):

I use SnowSQL via PowerShell at work, so obviously we are talking really wide outputs. I was so excited about Windows Terminal Preview that I spent hours customizing it to my liking only to find out I'll have to stick to the good old command prompt because of this one missing feature. What a waste--because everything else was so on point with this app.

@rajatsharmasubedi commented on GitHub (Jul 21, 2021): I use SnowSQL via PowerShell at work, so obviously we are talking really wide outputs. I was so excited about Windows Terminal Preview that I spent hours customizing it to my liking only to find out I'll have to stick to the good old command prompt because of this one missing feature. What a waste--because everything else was so on point with this app.

claunia commented

2026-01-30 23:00:03 +00:00

@yhh2021 commented on GitHub (Aug 27, 2021):

Haha, this post is very interesting to me since I have learnt to use computers on Windows then now work in *nix.

This feature is included in the Windows cmd, and everyone is used to it. However, in *nix world, to my humble knowledge more than 99% of the *nix terminals running now has no horizontal scrollbars, and more than 99% users haven't came with this idea even once, including me.

Hence, this is a really difficult choice for ms-terminal developers, since this product is trying to absorb from both Windows cmd and *nix terminals.

But why don't *nix users need this feature? I think that's because many of the *nix users need to work in a whole-console environment like DOS - in *nix systems GUI is usually a normal software, unlike in Windows it is packed in the operating system. *nix terminal software then were built under the assumption that they may be used without a GUI, and of course without scroll bars, therefore when they need to print really long lines like logs, like suggested in previous replies, they tend to dump it into files instead of printing them out directly to the screen. Then we have no problems.

@yhh2021 commented on GitHub (Aug 27, 2021): Haha, this post is very interesting to me since I have learnt to use computers on Windows then now work in *nix. This feature is included in the Windows **cmd**, and everyone is used to it. However, in \*nix world, to my humble knowledge more than 99% of the **\*nix terminals** running now has no horizontal scrollbars, and more than 99% users haven't came with this idea even once, including me. Hence, this is a really difficult choice for ms-terminal developers, since this product is trying to absorb from both Windows **cmd** and **\*nix terminals**. But why don't \*nix users need this feature? I think that's because many of the \*nix users need to work in a whole-console environment like DOS - in \*nix systems GUI is usually a normal software, unlike in Windows it is packed in the operating system. \*nix terminal software then were built under the assumption that they may be used without a GUI, and of course without scroll bars, therefore when they need to print really long lines like logs, like suggested in previous replies, they tend to dump it into files instead of printing them out directly to the screen. Then we have no problems.

claunia commented

2026-01-30 23:00:03 +00:00

@c0d3h4x0r commented on GitHub (Aug 27, 2021):

if there's enough community demand.
Has the entire discussion herein not already proven to you that there's plenty of community demand?

This is why expert users hate Microsoft, because you all never listen to your most important customers.

From: Mike Griese @.>
Sent: Friday, May 7, 2021 8:49 AM
To: microsoft/terminal @.>
Cc: Keith F. Kelly @.>; Mention @.>
Subject: Re: [microsoft/terminal] Terminal desperately needs a horizontal scrollbar (similar to Command Prompt) (#1860)

It's in the icebox, so it's not something we're ever planning on getting to ourselves, but it's a neat idea that could be brought out of the icebox if there's enough community demand.

My only plan for ever enabling this is under an "experimental" flag (as described above). It's very likely that this would break more scenarios than it would fix, so I'd want users to know that before they enable it.

especially when reading docker container logs.

less -S may be your friend here. The right and left arrow keys can navigate left and right in the file - it's not quite like a horizontal scrollbar, but has always worked for me.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fterminal%2Fissues%2F1860%23issuecomment-834554710&data=04%7C01%7C%7C2cdf5511aa20459a83db08d9116f9ace%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637559993293564162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a%2BIM3hEJzyYl4TUvSU6P3730Abjaqy%2Fnw7mMXaILY0A%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAF2EYJHABAEWJDQ2UFU4OHLTMQDWBANCNFSM4H6W2CBQ&data=04%7C01%7C%7C2cdf5511aa20459a83db08d9116f9ace%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637559993293574116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kq3EIUEe%2BG0eNNKLLzZhAibGe%2BhiFEmStVUV9NPDI9I%3D&reserved=0.

@c0d3h4x0r commented on GitHub (Aug 27, 2021): > if there's enough community demand. Has the entire discussion herein not already proven to you that there's plenty of community demand? This is why expert users hate Microsoft, because you all never listen to your most important customers. From: Mike Griese ***@***.***> Sent: Friday, May 7, 2021 8:49 AM To: microsoft/terminal ***@***.***> Cc: Keith F. Kelly ***@***.***>; Mention ***@***.***> Subject: Re: [microsoft/terminal] Terminal desperately needs a horizontal scrollbar (similar to Command Prompt) (#1860) It's in the icebox, so it's not something we're ever planning on getting to ourselves, but it's a neat idea that could be brought out of the icebox if there's enough community demand. My only plan for ever enabling this is under an "experimental" flag (as described above). It's very likely that this would break more scenarios than it would fix, so I'd want users to know that before they enable it. especially when reading docker container logs. less -S may be your friend here. The right and left arrow keys can navigate left and right in the file - it's not quite like a horizontal scrollbar, but has always worked for me. - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fterminal%2Fissues%2F1860%23issuecomment-834554710&data=04%7C01%7C%7C2cdf5511aa20459a83db08d9116f9ace%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637559993293564162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a%2BIM3hEJzyYl4TUvSU6P3730Abjaqy%2Fnw7mMXaILY0A%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAF2EYJHABAEWJDQ2UFU4OHLTMQDWBANCNFSM4H6W2CBQ&data=04%7C01%7C%7C2cdf5511aa20459a83db08d9116f9ace%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637559993293574116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kq3EIUEe%2BG0eNNKLLzZhAibGe%2BhiFEmStVUV9NPDI9I%3D&reserved=0>.

claunia commented

@zadjii-msft commented on GitHub (Aug 30, 2021):

you all never listen to your most important customers.

I literally re-opened this, because I am listening to folks who want this. Simple fact of the matter is that this is an engineering project, and we've only got so many development resources, so we can't just snap our fingers and do everything we want instantly. We've got to prioritize all community asks, and the best way we can do that is with 👍's on issues. As of right now, this issue isn't even on the first 3 pages of https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc. So pardon me if it takes a little while for us to get back to this one. Of course, this is an open-source project, so we'd be happy to accept a community contribution if anyone's got a clever idea how to implement this. I laid out a crazy idea on how we could up here: https://github.com/microsoft/terminal/issues/1860#issuecomment-738814484.

@zadjii-msft commented on GitHub (Aug 30, 2021): > you all never listen to your most important customers. I literally re-opened this, because I _am_ listening to folks who want this. Simple fact of the matter is that this is an engineering project, and we've only got so many development resources, so we can't just snap our fingers and do everything we want instantly. We've got to prioritize all community asks, and the best way we can do that is with 👍's on issues. As of right now, this issue isn't even on the first 3 pages of https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc. So pardon me if it takes a little while for us to get back to this one. Of course, this is an open-source project, so we'd be happy to accept a community contribution if anyone's got a clever idea how to implement this. I laid out a crazy idea on how we could up here: https://github.com/microsoft/terminal/issues/1860#issuecomment-738814484.

claunia commented

@kwame-codes commented on GitHub (Nov 9, 2021):

I understand that it may be a difficult feat of engineering, to reverse the windows console view-port functionality back into the already built terminal, but please can you consider that for many the ability to configure the console was a stand-out feature we took for granted.
We are not afraid of horizontal scrolling!
I myself automatically I've set every console to have a horizontal buffer of 1000 horizontally and 8000 height. I don't want any kind of wrapping, ever.
Please consider adding horizontal scrolling back to your new windows consoles/terminal.
Regards

@kwame-codes commented on GitHub (Nov 9, 2021): I understand that it may be a difficult feat of engineering, to reverse the windows console view-port functionality back into the already built terminal, but please can you consider that for many the ability to configure the console was a stand-out feature we took for granted. We are not afraid of horizontal scrolling! I myself automatically I've set every console to have a horizontal buffer of 1000 horizontally and 8000 height. I don't want any kind of wrapping, ever. Please consider adding horizontal scrolling back to your new windows consoles/terminal. Regards

claunia commented

@sourcenouveau commented on GitHub (Jan 27, 2022):

I want to use Windows Terminal as my general purpose console on Windows.

I monitor logs on a daily basis via tail -F over SSH. I periodically glance at my console to see which messages have been logged recently. It is faster and easier to scan through them when each log message is a single line (no wrapping).

When I see a message of interest, I want to quickly view the entire message. I want to avoid something like tail -F /var/log/syslog | cut -c -200 because then I'd need to run additional commands to find and view the entire message. Also, I do not want to interrupt my active command, which is continuing to display new messages.

I imagine that an option to manually override the terminal buffer dimensions, independent of the viewport size, would satisfy my use case while still being compatible with the nature of a terminal. The viewport would allow me to scroll horizontally and quickly check lines of interest, without affecting the active command.

@sourcenouveau commented on GitHub (Jan 27, 2022): I want to use Windows Terminal as my general purpose console on Windows. I monitor logs on a daily basis via `tail -F` over SSH. I periodically glance at my console to see which messages have been logged recently. It is faster and easier to scan through them when each log message is a single line (no wrapping). When I see a message of interest, I want to quickly view the entire message. I want to avoid something like `tail -F /var/log/syslog | cut -c -200` because then I'd need to run additional commands to find and view the entire message. Also, I do not want to interrupt my active command, which is continuing to display new messages. I imagine that an option to manually override the terminal buffer dimensions, independent of the viewport size, would satisfy my use case while still being compatible with the nature of a terminal. The viewport would allow me to scroll horizontally and quickly check lines of interest, without affecting the active command.

claunia commented

@Fetrovsky commented on GitHub (Jan 31, 2022):

I used to use the Terminator terminal emulator, which has a horizontal scroll bar. It's an option every terminal should have.

@Fetrovsky commented on GitHub (Jan 31, 2022): I used to use the Terminator terminal emulator, which has a horizontal scroll bar. It's an option every terminal should have.

claunia commented

@mcdonamw commented on GitHub (Feb 28, 2022):

So I guess I do not understand the purpose of this Windows Terminal. The only reason I'm even using it is for the tabbed interface and ability to combine my cmd prompt and Powershell windows into a single pane, but without the option to change my buffer/scrolling/wrapping options, this terminal is useless to me.

I'm dealing with Powershell output e.g. Write-Host that is absolutely terrible to read due to the wrapping. Am I supposed to somehow figure out my own formatting and take into consideration the unlimited window sizes people might be using, and somehow dynamically? Is that even possible?

Can someone explain to me wth the purpose of this thing is to be? Someone earlier said "this is not to be a console, but a terminal". What does that even mean?

FWIW I know I can simply resize the window to make it larger but that is not an option for me as I use FancyZones and I have my "terminal/console" window in a small subsection of my 4k monitor. Thus wrapping is even worse for me.

@mcdonamw commented on GitHub (Feb 28, 2022): So I guess I do not understand the purpose of this Windows Terminal. The only reason I'm even using it is for the tabbed interface and ability to combine my cmd prompt and Powershell windows into a single pane, but without the option to change my buffer/scrolling/wrapping options, this terminal is useless to me. I'm dealing with Powershell output e.g. Write-Host that is absolutely terrible to read due to the wrapping. Am I supposed to somehow figure out my own formatting and take into consideration the unlimited window sizes people might be using, and somehow dynamically? Is that even possible? Can someone explain to me wth the purpose of this thing is to be? Someone earlier said "this is not to be a console, but a terminal". What does that even mean? FWIW I know I can simply resize the window to make it larger but that is not an option for me as I use FancyZones and I have my "terminal/console" window in a small subsection of my 4k monitor. Thus wrapping is even worse for me.

claunia commented

@Fetrovsky commented on GitHub (Feb 28, 2022):

It's a ridiculous response. It means it's supposed to emulate a monitor
and a keyboard, and monitors have no scrollbars. But it's a useless answer
because you don't have to wrap the output just because you have a
terminal. Just like you can emulate a very large screen with a vertical
scrollbar, nothing impedes you from having a horizontal scrollbar and
voiding the need for line wrap. To make it simpler, just like you can,
say, enable scrolling (scroll lock or whatever) and scroll up and down, you
can use it to scroll left and right as well.

Daniel

@Fetrovsky commented on GitHub (Feb 28, 2022): It's a ridiculous response. It means it's supposed to emulate a monitor and a keyboard, and monitors have no scrollbars. But it's a useless answer because you don't _have_ to wrap the output just because you have a terminal. Just like you can emulate a very large screen with a vertical scrollbar, nothing impedes you from having a horizontal scrollbar and voiding the need for line wrap. To make it simpler, just like you can, say, enable scrolling (scroll lock or whatever) and scroll up and down, you can use it to scroll left and right as well. - Daniel

claunia commented

@mcdonamw commented on GitHub (Feb 28, 2022):

That's silly. I mean actual terminals/monitors don't have "windows" either. If that's what they are going for, then Terminal should be 100% fullscreen at all times with no ability to resize them.

@mcdonamw commented on GitHub (Feb 28, 2022): That's silly. I mean actual terminals/monitors don't have "windows" either. If that's what they are going for, then Terminal should be 100% fullscreen at all times with no ability to resize them.

claunia commented

@c0d3h4x0r commented on GitHub (Feb 28, 2022):

Irony at its finest :-D

@c0d3h4x0r commented on GitHub (Feb 28, 2022): ![BD8DD555-439B-482E-91D2-4CB490C849E2](https://user-images.githubusercontent.com/24398884/156078373-7a3af5a6-d1e5-44ed-98ed-27198c8b214f.jpeg) Irony at its finest :-D

claunia commented

@robertcatgithub commented on GitHub (May 24, 2022):

[c0d3h4x0r]
Irony at its finest :-D

what's the irony ?

@robertcatgithub commented on GitHub (May 24, 2022): > [c0d3h4x0r] > Irony at its finest :-D what's the irony ?

claunia commented

@theking2 commented on GitHub (Aug 30, 2022):

For me a simple use case is following of log files with

powershell Get-Content c:/wamp/logs/php_error.log -Wait

In this case wrapping is obstructing Uploading Screenshot 2022-08-30 093703.png…

@theking2 commented on GitHub (Aug 30, 2022): For me a simple use case is following of log files with ``` powershell Get-Content c:/wamp/logs/php_error.log -Wait ``` In this case wrapping is obstructing ![Uploading Screenshot 2022-08-30 093703.png…]()

claunia commented

@ghost commented on GitHub (Sep 3, 2022):

I work with spring boot, and spring product long lines of the log, for example in simple groovy web application I face with this, of course this is very bare bone appliances in serious work it gets worse

another example would be cloudflared tunnel -h

with several zoom-out key presses finally some clarity!

@ghost commented on GitHub (Sep 3, 2022): I work with spring boot, and spring product long lines of the log, for example in simple groovy web application I face with this, of course this is very bare bone appliances in serious work it gets worse ![image](https://user-images.githubusercontent.com/60809106/188287211-5fb90df9-816a-4d4a-b9c2-b7b40302aa6c.png) another example would be `cloudflared tunnel -h` ![image](https://user-images.githubusercontent.com/60809106/188287302-d134e047-dafe-4850-a63b-f0be68a69911.png) with several zoom-out key presses finally some clarity! ![image](https://user-images.githubusercontent.com/60809106/188287331-c4989574-2353-40b2-8e9c-53a53945677c.png)

claunia commented

@travisterrell commented on GitHub (Sep 16, 2022):

Throwing my my 2 cents, since it's been a couple of weeks. It's clear that the powers-that-be are strongly opposed to adding scrolling, but man it would be so helpful for some use cases.

The most recent case that's caused me to crave this feature is working with the Azure CLI (surely a proper use for Terminal). A ton of the output is in the form of tables and other types of formatting that span a very wide width. Tables wrap horribly, leaving half-lines all over the place that are impossible to reconcile with the columns. I work around it by maximizing my window, but even so, the largest tables still wrap. (And using the old-school command prompt is obviously a poor experience in a dozen other ways, so terminal is key!)

I think some are really stuck on this idea of emulating the behavior of other terminals. That is an important goal, as I utilize WSL and also SSH into Linux boxes, and I want content to display as designed. However, just because one provides full support for those standards, it doesn't mean that one can't also provide features that build on top of that! Compatibility is easily maintained with an off-by-default configurable nature. Given virtually every other detail of the terminal window so configurable, having a default disabled option doesn't really seem that problematic, and if this and a handful of closed issues are any evidence, there's a reasonably strong demand.

@travisterrell commented on GitHub (Sep 16, 2022): Throwing my my 2 cents, since it's been a couple of weeks. It's clear that the powers-that-be are strongly opposed to adding scrolling, but man it would be so helpful for some use cases. The most recent case that's caused me to crave this feature is working with the Azure CLI (surely a proper use for Terminal). A ton of the output is in the form of tables and other types of formatting that span a very wide width. Tables wrap _horribly_, leaving half-lines all over the place that are impossible to reconcile with the columns. I work around it by maximizing my window, but even so, the largest tables still wrap. (And using the old-school command prompt is obviously a poor experience in a dozen other ways, so terminal is key!) I think some are really stuck on this idea of emulating the behavior of other terminals. That is an important goal, as I utilize WSL and also SSH into Linux boxes, and I want content to display as designed. However, just because one provides full support for those standards, it doesn't mean that one can't also provide features that build on top of that! Compatibility is easily maintained with an off-by-default configurable nature. Given virtually every other detail of the terminal window so configurable, having a default disabled option doesn't really seem that problematic, and if this and a handful of closed issues are any evidence, there's a reasonably strong demand.

claunia commented

https://user-images.githubusercontent.com/11535558/194391026-0921d52e-80f6-4e40-9265-fdb1bf82ec30.mp4

@o-sdn-o commented on GitHub (Oct 6, 2022):

You can extend the Windows Terminal functionality with a small portable opensource tool that adds horizontal scrolling to the terminal. It almost completely supports win32 console api as well as wsl.

Run inside Windows Terminal:

vtm -t -r powershell

Run inside Windows Terminal with additional UI:

vtm -t -r term powershell

Run it in a self-hosted window (-g/--gui):

vtm -g -r term powershell

Note, powershell and cmd.exe do not know that lines can be unwrapped, so unwrap mode is best applied to already displayed lines using text selection by mouse + Wrap menu button.

@o-sdn-o commented on GitHub (Oct 6, 2022): You can extend the Windows Terminal functionality with a small portable opensource [tool](https://github.com/directvt/vtm) that adds horizontal scrolling to the terminal. It almost completely supports win32 console api as well as wsl. Run inside Windows Terminal: ```cmd vtm -t -r powershell ``` Run inside Windows Terminal with additional UI: ```cmd vtm -t -r term powershell ``` Run it in a self-hosted window (`-g/--gui`): ```cmd vtm -g -r term powershell ``` https://user-images.githubusercontent.com/11535558/194391026-0921d52e-80f6-4e40-9265-fdb1bf82ec30.mp4 Note, powershell and cmd.exe do not know that lines can be unwrapped, so unwrap mode is best applied to already displayed lines using text selection by mouse + `Wrap` menu button.

claunia commented

@jonas-metzum commented on GitHub (Oct 7, 2022):

OK this is constructive at least, but I'm not sure I'd use the Terminal with an add-on like this one over, e.g. the old cmd window. It just seems a bit cumbersome. But if this can be done in an add-on, maybe something like it could be implemented in the Terminal is self?

@jonas-metzum commented on GitHub (Oct 7, 2022): > OK this is constructive at least, but I'm not sure I'd use the Terminal with an add-on like this one over, e.g. the old cmd window. It just seems a bit cumbersome. But if this can be done in an add-on, maybe something like it could be implemented in the Terminal is self?

claunia commented

2026-01-30 23:00:07 +00:00

@o-sdn-o commented on GitHub (Oct 7, 2022):

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

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

For example using powershell.exe as a shell

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

In case of using WSL

{
    "commandline": "vtm -t -r term wsl.exe",
    "guid": "{ff27e49f-ae21-4834-98f0-3e3d597e3d20}",
    "hidden": false,
    "name": "WSL on Steroids"
},

@o-sdn-o commented on GitHub (Oct 7, 2022): Windows Terminal already has everything you need for seamless integration. You could just add a new profile like this ```json { "commandline": "vtm -t -r term _your_favorite_shell_with_args_", "...: ..." }, ``` For example using powershell.exe as a shell ```json { "commandline": "vtm -t -r term powershell.exe", "guid": "{ff27e49f-ae21-4834-98f0-3e3d597e3d19}", "hidden": false, "name": "Powershel on Steroids" }, ``` In case of using WSL ```json { "commandline": "vtm -t -r term wsl.exe", "guid": "{ff27e49f-ae21-4834-98f0-3e3d597e3d20}", "hidden": false, "name": "WSL on Steroids" }, ```

claunia commented

@o-sdn-o commented on GitHub (Oct 7, 2022):

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

@o-sdn-o commented on GitHub (Oct 7, 2022): 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

claunia commented

2026-01-30 23:00:07 +00:00

@Alois-xx commented on GitHub (Oct 7, 2022):

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.

@Alois-xx commented on GitHub (Oct 7, 2022): 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.

claunia commented

2026-01-30 23:00:07 +00:00

@o-sdn-o commented on GitHub (Oct 7, 2022):

~~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.

@o-sdn-o commented on GitHub (Oct 7, 2022): ~~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.

claunia commented

2026-01-30 23:00:08 +00:00

@Gershy commented on GitHub (Nov 1, 2022):

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.

@Gershy commented on GitHub (Nov 1, 2022): 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.

claunia commented

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

@c0d3h4x0r commented on GitHub (Nov 1, 2022):

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

@c0d3h4x0r commented on GitHub (Nov 1, 2022): 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/

claunia commented

@o-sdn-o commented on GitHub (Nov 1, 2022):

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

@o-sdn-o commented on GitHub (Nov 1, 2022): 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](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/out-string?view=powershell-7.2) to specify the text buffer width. E.g. ``` powershell Get-ChildItem C:\Windows\ | oss 1000 # or dir C:\Windows\ | oss 1000 ```

claunia commented

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

@c0d3h4x0r commented on GitHub (Nov 1, 2022):

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

Keith F. Kelly

@c0d3h4x0r commented on GitHub (Nov 1, 2022): 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/

claunia commented

@AloisKraus commented on GitHub (Nov 3, 2022):

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

Ctrl+C / Ctrl-V (that should be configurable)
Default selection handling where the copied text hovers over the mouse cursor this has tricked me several times to suspect display errors or even wrong data

@AloisKraus commented on GitHub (Nov 3, 2022): I have tried [vtm ](https://github.com/netxs-group/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 - Ctrl+C / Ctrl-V (that should be configurable) - Default selection handling where the copied text hovers over the mouse cursor this has tricked me several times to suspect display errors or even wrong data

claunia commented

2026-01-30 23:00:10 +00:00

@whaaaley commented on GitHub (Jan 19, 2023):

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

@whaaaley commented on GitHub (Jan 19, 2023): 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

claunia commented

@marbaa commented on GitHub (Feb 21, 2023):

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?

@marbaa commented on GitHub (Feb 21, 2023): 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?

claunia commented

2026-01-30 23:00:10 +00:00

@ixtk commented on GitHub (Feb 27, 2023):

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

@ixtk commented on GitHub (Feb 27, 2023): 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...

claunia commented

2026-01-30 23:00:10 +00:00

@norrisgc commented on GitHub (Mar 1, 2023):

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.

@norrisgc commented on GitHub (Mar 1, 2023): 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.

claunia commented

2026-01-30 23:00:11 +00:00

@DHowett commented on GitHub (Mar 1, 2023):

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!)

@DHowett commented on GitHub (Mar 1, 2023): > 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!)

claunia commented

2026-01-30 23:00:11 +00:00

@mathematician001 commented on GitHub (Apr 22, 2023):

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.

@mathematician001 commented on GitHub (Apr 22, 2023): 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.

claunia commented

2026-01-30 23:00:11 +00:00

@SlimeQ commented on GitHub (Apr 22, 2023):

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

@SlimeQ commented on GitHub (Apr 22, 2023): > 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

claunia commented

2026-01-30 23:00:12 +00:00

@xtender commented on GitHub (May 18, 2023):

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:

@xtender commented on GitHub (May 18, 2023): 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](https://github.com/microsoft/terminal/assets/243477/a60365b9-3d2f-40a4-b877-5ab229e32711)

claunia commented

2026-01-30 23:00:12 +00:00

@FrankRay78 commented on GitHub (May 21, 2023):

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

@FrankRay78 commented on GitHub (May 21, 2023): I imagine many consumers of the popular [spectre.console](https://spectreconsole.net/) console library rely on no-wrap/a horizontal scrollbar for correct layout, eg table widget: ![image](https://github.com/microsoft/terminal/assets/52075808/7ecf4132-a7ae-4fc0-993a-a6e44a54e288)

claunia commented

2026-01-30 23:00:12 +00:00

@jm903 commented on GitHub (Jun 8, 2023):

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.

@jm903 commented on GitHub (Jun 8, 2023): 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.

claunia commented

2026-01-30 23:00:13 +00:00

@Gershy commented on GitHub (Jun 14, 2023):

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.

@Gershy commented on GitHub (Jun 14, 2023): 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.

claunia commented

2026-01-30 23:00:13 +00:00

@SlimeQ commented on GitHub (Jun 14, 2023):

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

@SlimeQ commented on GitHub (Jun 14, 2023): > 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

claunia commented

2026-01-30 23:00:13 +00:00

@DHowett commented on GitHub (Jun 14, 2023):

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.

@DHowett commented on GitHub (Jun 14, 2023): 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. <img width="252" alt="image" src="https://github.com/microsoft/terminal/assets/189190/a15b8dd8-c062-4e72-84d2-7745f2d91965">

claunia commented

@larioteo commented on GitHub (Jul 2, 2023):

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.

@larioteo commented on GitHub (Jul 2, 2023): 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.

claunia commented

@travisterrell commented on GitHub (Jul 5, 2023):

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.

@travisterrell commented on GitHub (Jul 5, 2023): > 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.

claunia commented

@zadjii-msft commented on GitHub (Jul 5, 2023):

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.

ControlInteractivity::UpdateScrollbar only handles vertical scrolling.
_internalScrollbarPosition
the ScrollPositionChanged event
the throttled _updateScrollBar func

Other stuff to do:

Renderers need to support it
- DX
- atlas
Do we want scrolling to be bifurcated everywhere? That seems SO boilerplate-y and awful
How do we make the cursor moving out of the viewport scroll the viewport?
Storing this as a scroll offset, a min width, and a visible width seems redundant, but not sure one can actually be removed.
Selection is all fucky, assumes that the viewport is at x=0.
- Probably everything does
RenderData::GetViewport should absolutely be GetVisibleViewport because that's just a footgun waiting to happen
we need to actually plumb a setting through, rather than hardcode it
the scrollbars obv aren't initialized correctly
Something seems wrong about resizing still. Not sure what.

@zadjii-msft commented on GitHub (Jul 5, 2023): 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. <hr> _implementation notes here_ _wip branch: [`dev/migrie/f/1860-this-is-literally-what-less-is-for`](https://github.com/microsoft/terminal/compare/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. * `ControlInteractivity::UpdateScrollbar` only handles vertical scrolling. * `_internalScrollbarPosition` * the `ScrollPositionChanged` event * the throttled `_updateScrollBar` func Other stuff to do: * Renderers need to support it * [x] DX * [ ] atlas * Do we want scrolling to be bifurcated _everywhere_? That seems SO boilerplate-y and awful * How do we make the cursor moving out of the viewport scroll the viewport? * Storing this as a scroll offset, a min width, and a visible width _seems_ redundant, but not sure one can actually be removed. * Selection is all fucky, assumes that the viewport is at x=0. * Probably everything does * `RenderData::GetViewport` should absolutely be `GetVisibleViewport` because that's just a footgun waiting to happen * we need to actually plumb a setting through, rather than hardcode it * the scrollbars obv aren't initialized correctly * _Something_ seems wrong about resizing still. Not sure what.

claunia commented

@o-sdn-o commented on GitHub (Jul 5, 2023):

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).

@o-sdn-o commented on GitHub (Jul 5, 2023): > 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. ```c++ 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).

claunia commented

@jm903 commented on GitHub (Jul 6, 2023):

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.

@jm903 commented on GitHub (Jul 6, 2023): > 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.

claunia commented

@j4james commented on GitHub (Jul 6, 2023):

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.

@j4james commented on GitHub (Jul 6, 2023): > 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.

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2023):

@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"¹. That's relevant not just for emoji, but really any language that's not just using latin characters.

you can see how that doesn't roll off the tongue as easily 😝 ↩︎

@zadjii-msft commented on GitHub (Jul 6, 2023): @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 😝

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2023):

, 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.

@zadjii-msft commented on GitHub (Jul 6, 2023): > , 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.

claunia commented

@j4james commented on GitHub (Jul 6, 2023):

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.

@j4james commented on GitHub (Jul 6, 2023): > 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.

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2023):

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 on GitHub (Jul 6, 2023): 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.

claunia commented

@zadjii-msft commented on GitHub (Jul 13, 2023):

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:

@zadjii-msft commented on GitHub (Jul 13, 2023): 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](https://github.com/microsoft/terminal/assets/18356694/1fd0ae3f-13c6-4ea4-a274-e92035b0cb17)

claunia commented

@j4james commented on GitHub (Jul 13, 2023):

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.

@j4james commented on GitHub (Jul 13, 2023): > 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.

claunia commented

@bigvzhang commented on GitHub (Oct 1, 2023):

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?

@bigvzhang commented on GitHub (Oct 1, 2023): 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?

claunia commented

@AloisKraus commented on GitHub (Oct 2, 2023):

@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.

@AloisKraus commented on GitHub (Oct 2, 2023): @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.

claunia commented

@zadjii-msft commented on GitHub (Oct 2, 2023):

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.

@zadjii-msft commented on GitHub (Oct 2, 2023): 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.

claunia commented

@larioteo commented on GitHub (Oct 2, 2023):

I personally can't await this feature
...

@larioteo commented on GitHub (Oct 2, 2023): I personally can't await this feature ...

claunia commented

@simonjha commented on GitHub (Oct 25, 2023):

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.

@simonjha commented on GitHub (Oct 25, 2023): 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.

claunia commented

@BerndHme commented on GitHub (Jan 24, 2024):

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

@BerndHme commented on GitHub (Jan 24, 2024): Please add word wrapping. Like the VS output console can. There is a toggle button.

claunia commented

@karunkrishna commented on GitHub (Feb 9, 2024):

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.

@karunkrishna commented on GitHub (Feb 9, 2024): 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](https://github.com/microsoft/terminal/assets/2157606/4f05cb8f-3b9d-4396-bdce-254d06b1f4f3)

claunia commented

@thisismygitrepo commented on GitHub (Feb 10, 2024):

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.

@thisismygitrepo commented on GitHub (Feb 10, 2024): Until this is implemented, please use a scroller utility (pager or whatever you call it). This one works fine [data scroller](https://github.com/baogorek/datascroller) I switched to `wezterm` and its the same problem so it seems that this is the way to go.

claunia commented

@cesar-o9 commented on GitHub (Feb 20, 2024):

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.

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

@cesar-o9 commented on GitHub (Feb 20, 2024): > 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](https://private-user-images.githubusercontent.com/2157606/303796327-4f05cb8f-3b9d-4396-bdce-254d06b1f4f3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDg0NDk1NzksIm5iZiI6MTcwODQ0OTI3OSwicGF0aCI6Ii8yMTU3NjA2LzMwMzc5NjMyNy00ZjA1Y2I4Zi0zYjlkLTQzOTYtYmRjZS0yNTRkMDZiMWY0ZjMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDIyMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAyMjBUMTcxNDM5WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NzNlMDg2YjBmODY4ZGYxMmJhZThkOWEwOWU5NDJlMDY2NDNlN2VjMDYxZTJlZWRiZDgxMTI3MTc3YzI4MzM4MyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.m-FsAHgWhRqhPSxpbm-D3Q0dUsALhWdDB7KoeeSxyUw) You can try "tput rmam" (remove auto margin). that works for me. to reset it "tput smam" to set it again.

claunia commented

@zehawki commented on GitHub (Mar 31, 2024):

Yup here is another example of unreadable madness:

@zehawki commented on GitHub (Mar 31, 2024): Yup here is another example of unreadable madness: ![image](https://github.com/microsoft/terminal/assets/8095144/041c6126-32ce-46fb-a991-393e20b5fff7)

claunia commented

@Cremesis commented on GitHub (May 8, 2024):

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!

@Cremesis commented on GitHub (May 8, 2024): 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!

claunia commented

@marbaa commented on GitHub (May 9, 2024):

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

@marbaa commented on GitHub (May 9, 2024): Someone would not believe that it is 5 years, since request was made...

claunia commented

@Cfun1 commented on GitHub (Jun 9, 2024):

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

@Cfun1 commented on GitHub (Jun 9, 2024): 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

claunia commented

@scharnyw commented on GitHub (Jul 18, 2024):

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

@scharnyw commented on GitHub (Jul 18, 2024): 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`

claunia commented

@mcdonamw commented on GitHub (Aug 22, 2024):

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 on GitHub (Aug 22, 2024): 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.

claunia commented

@mcdonamw commented on GitHub (Aug 22, 2024):

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

keyword: add

@mcdonamw commented on GitHub (Aug 22, 2024): > One of the biggest requests we had for Windows 10 was to add support for wrapping to the traditional/legacy console! keyword: add

claunia commented

@lynnewu commented on GitHub (Oct 3, 2024):

PowerShell table-formatted output often exceeds the horizontal width of even my full-width monitors. My current solution is to snap the window open a couple monitors wide (or more) to see everything. Wrapping output results in an [visually] unparseable mess. Definitely want a horizontal scroll bar (or even just the ability to scroll horizontall with a mouse h-scroll wheel).

@lynnewu commented on GitHub (Oct 3, 2024): PowerShell table-formatted output often exceeds the horizontal width of even my full-width monitors. My current solution is to snap the window open a couple monitors wide (or more) to see everything. Wrapping output results in an [visually] unparseable mess. Definitely want a horizontal scroll bar (or even just the ability to scroll horizontall with a mouse h-scroll wheel).

claunia commented

@emanueol commented on GitHub (Oct 13, 2024):

This is a must, as database engineer, sql output in CLIs (snowsql, snow, sqlplus etc) wraps results table.

I may wonder whats the rationale here, but I suspect windows terminal maintainers don't have this SQL execution use case, or otherwise I'm sure they would fix this.

Please:

add wrap on appearance options.
which when true adds horizontal scroll bar.

@emanueol commented on GitHub (Oct 13, 2024): This is a must, as database engineer, sql output in CLIs (snowsql, snow, sqlplus etc) wraps results table. I may wonder whats the rationale here, but I suspect windows terminal maintainers don't have this SQL execution use case, or otherwise I'm sure they would fix this. Please: - add wrap on appearance options. - which when true adds horizontal scroll bar.

claunia commented

@emanueol commented on GitHub (Oct 17, 2024):

I found an easy workaround for at least linux-like shells (gitbash, based on cut):

$ <whatever your commands> | cut -c -$COLUMNS

Interestingly enough, resizing "Windows Terminal" updates $COLUMNS.
Here anim gif showing trick in gitbash and wasl2>ubunto shells:

But the ideal is not to cut, and have a horizontal scroll bar available.
Is this the correct thread to push-vote-up for this to happen?

@emanueol commented on GitHub (Oct 17, 2024): I found an easy workaround for at least linux-like shells (gitbash, based on cut): ```shell $ <whatever your commands> | cut -c -$COLUMNS ``` Interestingly enough, resizing "Windows Terminal" updates $COLUMNS. Here anim gif showing trick in gitbash and wasl2>ubunto shells: ![Image](https://github.com/user-attachments/assets/477643db-b9eb-4e7f-9a7e-b4ddd4879311) But the ideal is not to cut, and have a horizontal scroll bar available. Is this the correct thread to push-vote-up for this to happen?

claunia commented

@GMW247 commented on GitHub (Nov 3, 2024):

just gonna be honest terminal is pretty cool and a genuine reason to not DESPISE windows 11. but its sort of a shame it word wrap cant be turned off. would love it if it could.

https://github.com/microsoft/terminal/issues/1860#issuecomment-1622136376. it says that this might work but the last work on it was a year ago, despite it sort of working.

is there anyway i could get copy from that branch to compile windows terminal and see if the changes work?

@GMW247 commented on GitHub (Nov 3, 2024): just gonna be honest terminal is pretty cool and a genuine reason to not _**DESPISE**_ windows 11. but its sort of a shame it word wrap cant be turned off. would love it if it could. https://github.com/microsoft/terminal/issues/1860#issuecomment-1622136376. it says that this might work but the last work on it was a year ago, despite it sort of working. is there anyway i could get copy from that branch to compile windows terminal and see if the changes work?

claunia commented

@sw3zeg commented on GitHub (Jan 4, 2025):

This method does not add a horizontal scrollbar, but it will remove the annoying text wrapping.

You need to put a large negative number in a "padding-right" property in the settings.json file.

It is located on the path:

C:\Users\<username>\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

Or you can open it by clicking on the "open JSON file" button in the Windows terminal settings (in the lower left corner).

You need to overwrite the "padding" property in the profiles:default section as follows:

"padding": "0, 0, -10000, 0"

@sw3zeg commented on GitHub (Jan 4, 2025): This method does not add a horizontal scrollbar, but it will remove the annoying text wrapping. You need to put a large negative number in a "padding-right" property in the settings.json file. It is located on the path: ``` C:\Users\<username>\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json ``` Or you can open it by clicking on the "open JSON file" button in the Windows terminal settings (in the lower left corner). You need to overwrite the "padding" property in the profiles:default section as follows: ``` "padding": "0, 0, -10000, 0" ``` ![windows_terminal](https://github.com/user-attachments/assets/f7b68859-8b8c-4d70-88cc-57d0dc44d503)

claunia commented

@donatomartin commented on GitHub (Jan 27, 2025):

Word wrapping is an essential feature, I don't even care about horizontal scrolling.

There are some apps that return way too wide outputs were you only need the first column identifiers and it gets too hard to visually parse it. In case of no horizontal scrolling, an optional keyboard shortcut to toggle would be very much appreciated too.

I feel like opening VS Code integrated terminal or redirecting output to a file every time I need this feature is not the greatest user experience.

@sw3zeg workaround is great and I don't mind having a personal script to pipeline my output to if I needed word wrapping. Just a quick script that reads my terminal size and cuts short each line.

The annoying part is that I can't have this workaround enabled on my default terminal profile because it just breaks the default size on startup. I can not live with that.

@donatomartin commented on GitHub (Jan 27, 2025): Word wrapping is an **essential feature**, I don't even care about horizontal scrolling. There are some apps that return way too wide outputs were you only need the first column identifiers and it gets too hard to visually parse it. In case of no horizontal scrolling, an optional keyboard shortcut to toggle would be very much appreciated too. I feel like opening VS Code integrated terminal or redirecting output to a file every time I need this feature is not the greatest user experience. @sw3zeg workaround is great and I don't mind having a personal script to pipeline my output to if I needed word wrapping. Just a quick script that reads my terminal size and cuts short each line. The annoying part is that I can't have this workaround enabled on my default terminal profile because it just breaks the default size on startup. I can not live with that. ![Image](https://github.com/user-attachments/assets/8ce11e11-f814-4272-a3ef-915673da78a9)

claunia commented