BUG: terminal vim 9.0.1506 x64 window 10

[Robert Solomon]

I use JPSoft's take command as by command interpreter.  Now at version 29.  When I start vim in the terminal, it does not update the screen correctly.

Contents from longer lines remain on screen when the file has shorter lines.

This makes terminal mode Vim unusable for me.  I've seen this in several terminal mode versions, and I just tried updating to the newest version to see if it's been fixed. 

It hasnt'.

The GUI version works fine.

[Bram Moolenaar]

> I use JPSoft's take command as by command interpreter. Now at version 29.
> When I start vim in the terminal, it does not update the screen correctly.
> Contents from longer lines remain on screen when the file has shorter lines.

I don't know the "take command". Is this a kind of shell? Or is it
like a console window, that you start Vim in?

There is no good standard terminal on MS-Windows, all off them have
their individual issues. We try to support at least the good-old
Windows console and the newer Windows Terminal, since these are widely
used. Making it work with all kind of alternatives is a struggle. And
when you run Vim, the extra features that the alternative offers are
usually irrelevant. Please consider using a standard terminal to run
Vim in. Otherwise, report the problem to JPSoft. Since Vim works fine
in a standard terminal, the problem very likely is on their side.


--
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable. No engineer can walk away from an unsolvable problem
until it's solved.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Robert Solomon]

Which program do you mean when you say the good-old windows console and the newer windows terminal?

Others are reporting that vim does not work correctly in the current windows terminal.  I just read in the JPSoft forum that the screen is scrambled upon exiting vim when called from windows terminal or cmd.exe.  However, this sounds like a bug I reported ~2 yrs ago that was fixed relatively quickly.

--rob solomon

[Bram Moolenaar]

> Which program do you mean when you say the good-old windows console
> and the newer windows terminal?

The Windows console is what was originally the console in MS-Windows.
Perhaps people refer to it as command.com or cmd.exe.
AFAIK this is available on every MS-Windows installation without
additional downloads or apps.

Windows terminal is a very recent development that aims to replace the
console. It is actively being improved.
https://apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701
AFAIK this is intended as a replacement for the console and is
officially supported by Microsoft.

> Others are reporting that vim does not work correctly in the current
> windows terminal. I just read in the JPSoft forum that the screen is
> scrambled upon exiting vim when called from windows terminal or cmd.exe.
> However, this sounds like a bug I reported ~2 yrs ago that was fixed
> relatively quickly.

JPSoft has its own terminal, right? There must be dozens of alternatives.
Vim can't possibly add code to support each peculiarity of each of them.
I'm not sure what generic problem exists that is not terminal-specific.

--
hundred-and-one symptoms of being an internet addict:
109. You actually read -- and enjoy -- lists like this.

[aro...@vex.net]

> Vim can't possibly add code to support each peculiarity of each of them.
> I'm not sure what generic problem exists that is not terminal-specific.
>

The early days of Unix coincided with a Cabrian explosion of physical
terminals. This led to the development of a database of terminal
attributes and controls, (the termcap file, if memory serves me
correctly). Reading this table was entertaining. The included comments
reeked of late-night struggles and triumphs over frustration.

> hundred-and-one symptoms of being an internet addict:
> 109. You actually read -- and enjoy -- lists like this.
>

Subscribing to this list is worth it just for access to Bram's signature
file. :-)*

[Robert Solomon]

Of course vim can't possibly support all possible terminals

My point is different.  It's isn't working correctly on ANY of them.

see https://github.com/microsoft/terminal/issues?q=vim+in%3Atitle+

[rob]

And 

https://jpsoft.com/forums/threads/incompatibility-of-tcmd-30-and-vim9.11517/unread?new=1

-- 

  rob

  r...@drrob1.com

--

--

You received this message from the "vim_use" maillist.

Do not top-post! Type your reply below the text you are replying to.

For more information, visit http://www.vim.org/maillist.php

---

You received this message because you are subscribed to the Google Groups "vim_use" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/b1375c2a-a441-4c1a-8c78-63f5a7bfe7een%40googlegroups.com.

[Bram Moolenaar]

> Of course vim can't possibly support all possible terminals
>
> My point is different. It's isn't working correctly on ANY of them.
>
> see https://github.com/microsoft/terminal/issues?q=vim+in%3Atitle+

That search results in several issues, which one is this about?

This is about one product, I don't see the relation with "ANY" here.

--

hundred-and-one symptoms of being an internet addict:

112. You are amazed that anyone uses a phone without data...let
alone hear actual voices.

[Christian Brabandt]

On Sa, 03 Jun 2023, Robert Solomon wrote:

> My point is different. It's isn't working correctly on ANY of them.

That is hardly correct. I haven't heard from many complaints about using
Vim terminal in neither Windows nor Linux.

> see https://github.com/microsoft/terminal/issues?q=vim+in%3Atitle+

I guess, if those were Vim issues, they would have been reported (or at
least linked) to Vims issues. So that doesn't necessarily prove
anything.


Best,
Christian
--
Wir sollten Teile von Behörden für ein Jahr schließen und hinterher
fragen, ob es irgend jemand gemerkt hat.
-- Helmuth Frahm

[Robert Solomon]

I've been away.

I was having trouble w/ the console version of vim 9 in windows terminal and cmd.exe as well as take command.

I also posted on the forum for JPSoft's take command.

I got a response there that was helpful.  Interesting, none of the responses here were helpful.

I learned there that vim is known to dislike non-standard terminal sizes. 

So I made the terminal windows smaller and it started to work.

I'm following up w/ my last post, to say that it's been fixed by making the terminal window size smaller.  This fixed the same issue whether it was cmd.exe, windows terminal, or TakeCommand.

I was having trouble in ALL of the windows terminal programs.  The same solution worked for all of them.

--rob solomon

[jr]

hi,

On Fri, 16 Jun 2023 at 15:54, Robert Solomon <drro...@gmail.com> wrote:
> ...

> I learned there that vim is known to dislike non-standard terminal sizes.

?? why do you write this[*], when followed by:

> So I made the terminal windows smaller and it started to work.

> ...

> I was having trouble in ALL of the windows terminal programs. The same solution worked for all of them.

genuine question, am puzzled.

[*] not a .. rumour I had heard of.

--
regards, jr.

You have the right to free speech, as long as you're not dumb enough
to actually try it.
(The Clash 'Know Your Rights')

this email is intended only for the addressee(s) and may contain
confidential information. if you are not the intended recipient, you
are hereby notified that any use of this email, its dissemination,
distribution, and/or copying without prior written consent is
prohibited.

[Susan McElheny]

I have used VI on Unix for over 30 years and now have to use it in Windows where it works much differently.  If I open gVim 9.0 in a GUI session, how do I open another file without having to go to the top with my mouse and select File, Open?  At the command level I can just :vi "filename", but I've been having issues working with VI at the command level - maybe be because it didn't like that I made the window larger as people have just mentioned.

Hopefully a simple question for you experts!

Susan McElheny
Senior Analyst, Data Operations
703.536.0923 direct
703.536.0500 main

--

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/e112e94e-32a3-4ada-8e9c-185bc122314dn%40googlegroups.com.

[jr]

hi,

On Fri, 16 Jun 2023 at 17:28, 'Susan McElheny' via vim_use
<vim...@googlegroups.com> wrote:
>
> I have used VI on Unix for over 30 years ... how do I open another file without having to go to the top with my mouse and select File, Open? At the command level I can just :vi "filename", ...

I've used Vim on Linux (Linuces ?) for .. several years, but, I've
never used ':vi "somefile.txt"', only ':e somefile.txt' , which
works for me. hth.

[rwmit...@gmail.com]

I use :tabedit FILE

[Robert Solomon]

Quick experimentation indicates that console mode vim fails when width >= 250.  But not every time.

I don't think height matters.

On Sat, Jun 17, 2023, 9:59 AM Bram Moolenaar <Br...@moolenaar.net> wrote:

Robert Solomon wrote:

[...]

> I learned there that vim is known to dislike non-standard terminal sizes. 
>
> So I made the terminal windows smaller and it started to work.

Strange, I had not heard this before.

> I'm following up w/ my last post, to say that it's been fixed by making the
> terminal window size smaller.  This fixed the same issue whether it was
> cmd.exe, windows terminal, or TakeCommand.

Is there a specific maximal size?  If yes, then please tell us.


--
A bad peace is better than a good war. - Yiddish Proverb

[Bram Moolenaar]

> Quick experimentation indicates that console mode vim fails when width >=
> 250. But not every time.
>
> I don't think height matters.

OK, so what reproduction steps are required? I tried this:

- start "vim --clean"
- :set columns=260
- :term
- vim --clean somefile
- ?

I could not make this show any problems. This might be because I'm
using Linux. Or:

- What would be the content of "somefile"? I tried some long (wrapping)
lines and a few short lines.
- What commands do you use once "somefile" is loaded? Move the cursor,
join/split lines, etc.?

I hope you can give an example that is simple and reproduces the problem
consistently.

--
I thought I was eating a crab salad. It turned out to be a crap salad.

[Robert Solomon]

To be clearer:

Windows 10

My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 

After setting the window  size, I start vim using my _vimrc as I usually do.   I did not change anything from within vim.

[Steve Martin]

I'm puzzled by this, and have to believe this must be either a terminal problem or some vim plugin interaction with that terminal.

I just used Windows Terminal (Preview to be exact) set to max screen size (2560x1440) and set the font to 6pt. 

That results in terminal Lines x Columns=134x585. Five hundred and eighty five characters across. My old eyes had problems seeing that. Still, nothing untoward happened in VIM. I edited some large files and tried various "command type" things. No problems.

I'm really curious what problems people are having and what is causing it for some and not for others.

BTW: vim v9.0.1637, as I tend to build vim nightly for my regular use. Windows 11.

[Steve Martin]

> - start "vim --clean"
> - :set columns=260
> - :term
> - vim --clean somefile
> - ?

Wait, are we saying that we're setting the internal vim 'columns' to something other than the terminal's size? Because if that is the case, I can clearly see an issue is going to be caused when the Terminal does not resize when asked by vim. This definitely does cause problems in Windows Terminal. The window is corrupted and even exiting vim the window has issues as it is still the same size, but the shell reports ColumnsxLines=NEWColumnsxLines and nothing works well after that.

--- 

Should my CPU be smoking?

[Enan Ajmain]

On Fri, 16 Jun 2023 12:27:59 -0400

"'Susan McElheny' via vim_use" <vim...@googlegroups.com> wrote:

> I have used VI on Unix for over 30 years and now have to use it in Windows
> where it works much differently. If I open gVim 9.0 in a GUI session, how
> do I open another file without having to go to the top with my mouse and
> select File, Open? At the command level I can just :vi "filename", but
> I've been having issues working with VI at the command level - maybe be
> because it didn't like that I made the window larger as people have just
> mentioned.

Confusing post on two angles:
1. What has opening file got to do with this thread which is about
console corruption in Windows?
2. Where did you find the command ":vi"? I'm guessing it was
available in Vi (not Vim) 30 years ago, but that seems unlikely.

--
Enan

P.S. Upon closer reading, I see that you thought increasing window size
might have had something to do with it, so that explains posting on this
thread. I can say that in Windows GVim, resizing the window shouldn't
cause any problem, specially not problems like removing ex commands.

[Tony Mechelynck]

On Fri, Jun 16, 2023 at 6:28 PM 'Susan McElheny' via vim_use <vim...@googlegroups.com> wrote:

I have used VI on Unix for over 30 years and now have to use it in Windows where it works much differently.  If I open gVim 9.0 in a GUI session, how do I open another file without having to go to the top with my mouse and select File, Open?  At the command level I can just :vi "filename", but I've been having issues working with VI at the command level - maybe be because it didn't like that I made the window larger as people have just mentioned.

Hopefully a simple question for you experts!

Susan McElheny
Senior Analyst, Data Operations

Apart from the fact that you ought to have started a new thread and not jumped onto any passing thread with an unrelated question:

To open a 2nd (or 3rd, ..., nth) file in a new window in a running Vim or gvim on any OS, just do

     :new filename.ext

or

     :split filename.ext

replacing filename.ext by the desired filename (with path if necessary).

If, instead, you want to _replace_ the file currently being edited by another one in the same window, then do

      :e filename.ext

If the file has modifications, Vim will refuse to wipe it out (unless 'autowriteall' is on, which is not the default): in that case you should either save the file first, or use :e! instead of :e to forget all changes.

See

    :h :new

    :h :split_f

    :h :edit

and also accessorily

    :h 'awa'

    :h ++opt
    :h +cmd

Best regards,

Tony.

[Christian Brabandt]

On Sa, 17 Jun 2023, Robert Solomon wrote:

> Windows 10
>
> My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 
>
> After setting the window  size, I start vim using my _vimrc as I usually do.   I did not change anything from within vim.

So, can you reproduce the issue using `vim --clean` to disable any of
your usual customizations? What exactly is this `take` command. Does it
reproduce without it?

What terminal did you use, you said?

Best,
Christian
--
Wohl dem, der seiner Väter gern gedenkt.
-- Johann Wolfgang von Goethe (Iphigenie I)

[Ed Blackman]

On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> On Sa, 17 Jun 2023, Robert Solomon wrote:
> > Windows 10
> >
> > My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 
>

> So, can you reproduce the issue using `vim --clean` to disable any of
> your usual customizations? What exactly is this `take` command. Does it
> reproduce without it?
>
> What terminal did you use, you said?

Take Command is a replacement shell (and maybe a replacement terminal?) for Windows: https://jpsoft.com/products/take-command.html

I don't know anything about it, but thought I'd interject to clarify.

--
Ed Blackman

[Steve Martin]

Looking at the Take Command website and Googling about it I can find no reference to Take Command as a Terminal emulator anywhere. I am guessing it has very basic, if any, capabilities at all. Thus it probably doesn't heed any ':set columns=' or other vim terminal commands.

[Steve Martin]

To be clear, testing on various terminals on Windows results in the following conclusions.

On Windows Terminal Preview (Windows 11) with Windows PowerShell or CMD as the shell, the 'columns=600' or any other such setting will be ignored and the variable will remain at whatever vim set it to. So nothing happens to the display.

Using the Windows CMD shell under the old CMD terminal, whatever that is called, will result in columns value being changed, but the terminal does not change and has no issues after the setting.

Using RedHat's cygwin bash, which comes with Git-Desktop for instance, inside of Windows Terminal, performing a "set columns=600" will result in a corrupted terminal which cannot be fixed using the standard terminal reset commands (tset(1) or reset(1)). Only closing and reopening the terminal will return a good work session.

Using cygwin bash under the RedHat provided mintty terminal and performing a "set columns=600" will cause vim to resize to the maximum width of the system monitor and set Columns to a number that equates to the new terminal size. This is the only terminal software I found that behaves as one would expect a Linux terminal to work. This was the best terminal I saw on Windows.

Finally, using the GVim provided with VIM for Windows will also change the Terminal size according to changes in the 'columns' setting. Again, vim will change the size of the terminal up to the actual maximum available on the system monitor. The columns variable reflects the proper terminal size like the mintty version does. I don't know what terminal that means is used or even if it can be called a terminal, but clearly it works properly with vim by design.

So my conclusion is that this is a terminal software problem. Some terminals adhere to the resizing commands that vim sends, some ignore it but remain stable, and yet others become hopelessly corrupted requiring that the software be closed and restarted. 

Obviously Bram knows far more than I do, but my recommendation would be to use a Terminal package that behaves like a fully functional soft terminal should or don't resize the window after launching VIM.

Personally I use bash and Windows Terminal when I'm on Windows. It has features I prefer and I don't usually resize my work space after I've got set up. Will Microsoft fix their issues. Not gonna hold my breath.

In the end there are a lot of choices out there, which can be both good and bad.

__ 

Should there be smoke coming out of my CPU?

[Enan Ajmain]

On Tue, 20 Jun 2023 22:52:05 -0700 (PDT)
Steve Martin <smart...@gmail.com> wrote:
> [...]

>
> Using the Windows CMD shell under the old CMD terminal, whatever that
> is called

It's Console Host or Conhost in short.

> Personally I use bash and Windows Terminal when I'm on Windows. It
> has features I prefer and I don't usually resize my work space after
> I've got set up. Will Microsoft fix their issues. Not gonna hold my
> breath.

I assume by "Microsoft" and "their issue" you mean the issue in Conhost.
If so, then yeah, it's not gonna get fixed. There are compatibility
reasons for that (which I don't care about), but to circumvent this the
team decided to overhaul Conhost and replace it with the new Terminal.
It'll be the default in the next . . . I donno, year perhaps? Decade?

And just to clarify, resizing MS Terminal window after launching Vim
doesn't cause any problem. MS Terminal should behave like a Linux
terminal emulator. It advertizes itself as supporting all xterm
features. Well, perhaps not all, but most of the oft-used ones.

> In the end there are a lot of choices out there, which can be both
> good and bad.

Before MS Terminal, Wezterm was the best choice. Before that, Cmder and
ConEmu. And the problem with Mintty is that it's not independent. The
reason it behaves so like a Linux terminal is because it's built with
Cygwin or Cygwin-like shells (MSys, git-bash, etc.) in mind. You can't
run Command Prompt or PowerShell on it. You can't even run Win32
version of Vim on it. You'll need a Vim built with Cygwin. That's an
extra hassle in my opinion.

> __
>
> Should there be smoke coming out of my CPU?
>
> On Tuesday, June 20, 2023 at 1:47:23 AM UTC-6 Steve Martin wrote:
>
> Looking at the Take Command website and Googling about it I can find

> no reference to Take Command as a Terminal emulator *anywhere*. I am

> guessing it has very basic, if any, capabilities at all. Thus it

> probably doesn't heed any *':set columns=*' or other vim terminal

> commands.
>
> On Monday, June 19, 2023 at 12:32:07 PM UTC-6 Ed Blackman wrote:
>
> On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> > On Sa, 17 Jun 2023, Robert Solomon wrote:
> > > Windows 10
> > >
> > > My quick testing involved me starting take command and using the
> > > mouse
> to size the window. Take command shows the window size in the
> bottom right corner.
> >
> > So, can you reproduce the issue using `vim --clean` to disable any
> > of your usual customizations? What exactly is this `take` command.
> > Does it reproduce without it?
> >
> > What terminal did you use, you said?
>
> Take Command is a replacement shell (and maybe a replacement
> terminal?) for Windows: https://jpsoft.com/products/take-command.html
>
> I don't know anything about it, but thought I'd interject to clarify.
>



--

Enan

[rwmit...@gmail.com]

Wow, that must have really hit a nerve for you to go into such lengths for a platform that is and has always been subpar, always several years behind everyone else.

[Enan Ajmain]

On Wed, 21 Jun 2023 04:05:52 -0700 (PDT)
"rwmit...@gmail.com" <rwmit...@gmail.com> wrote:
> Wow, that must have really hit a nerve for you to go into such
> lengths for a platform that is and has always been subpar, always
> several years behind everyone else.

Couldn't agree more. On Windows being subpar. Not on my nerve being
hit. I despise Windows. Thankfully my programming laptop is a Linux
machine. I donno what I would've done otherwise.

I also don't know what "length" I went to. I just shared my knowledge
on something I hate. That might sound unintuitive. Why would someone
speak on something they hate? To that all I can say is, you should hear
me rant about OOP.

[Bram Moolenaar]

> Looking at the Take Command website and Googling about it I can find no

> reference to Take Command as a Terminal emulator *anywhere*. I am guessing

> it has very basic, if any, capabilities at all. Thus it probably doesn't

> heed any *':set columns=*' or other vim terminal commands.

If Vim's assumption of the terminal size (which is in the 'lines' and
'columns' options) does not match the actual terminal size, then display
problems are to be expected.

There are two sides: getting and setting the size.

Getting the size is always needed, unless you keep the terminal at the
default 25 x 80 size (which is unlikely). On top of that, Vim would
need to get notified if the terminal size is changed (e.g. by dragging
the border) while it is running, see below.

Setting the size is needed to support ":set lines=123" and ":set
columns=123". Or Vim needs to know that the size cannot be set and it
should give an error message and not change the number of lines/columns
used.

It is not so easy to figure out what happens in what sequence. I'll add
a few log messages to the Unix implementation. Handling the size works
fine there, thus this can be used as an example. But it might be that
for MS-Windows it works differently. E.g., in Unix a signal is used:
SIGWINCH. I don't know if MS-Windows has something similar. Also, the
implementation of term_report_winsize() needs to be checked. This
should trigger the signal in any Vim instance running in a terminal
window, initiated from the Vim instance that has the terminal window.

--
hundred-and-one symptoms of being an internet addict:

196. Your computer costs more than your car.

[Bram Moolenaar]

> On Tue, 20 Jun 2023 22:52:05 -0700 (PDT)
> Steve Martin <smart...@gmail.com> wrote:
> > [...]
> >
> > Using the Windows CMD shell under the old CMD terminal, whatever that
> > is called
>
> It's Console Host or Conhost in short.

There also is mention of "Win32 virtual console", the +vtp feature.
This is currently enabled for all MS-Windows non-GUI versions, thus it
doesn't appear to have an effect on how Vim works. The feature itself
is useful to distinguish from an old Vim version that didn't support
this.

> > Personally I use bash and Windows Terminal when I'm on Windows. It
> > has features I prefer and I don't usually resize my work space after
> > I've got set up. Will Microsoft fix their issues. Not gonna hold my
> > breath.
>
> I assume by "Microsoft" and "their issue" you mean the issue in Conhost.
> If so, then yeah, it's not gonna get fixed. There are compatibility
> reasons for that (which I don't care about), but to circumvent this the
> team decided to overhaul Conhost and replace it with the new Terminal.
> It'll be the default in the next . . . I donno, year perhaps? Decade?
>
> And just to clarify, resizing MS Terminal window after launching Vim
> doesn't cause any problem. MS Terminal should behave like a Linux
> terminal emulator. It advertizes itself as supporting all xterm
> features. Well, perhaps not all, but most of the oft-used ones.

A problem related to this is that Vim was originally made for the
console, not for a generic terminal like on Unix. In the code there are
calls to is_term_win32() and different behavior when it returns true.
That is when 'term' is set to "win32". And it is set to that value in a
few places, some may not be correct. E.g. near the end of
did_set_string_option():

#if defined(FEAT_VTP) && defined(FEAT_TERMGUICOLORS)
if (args.os_did_swaptcap)
{
set_termname((char_u *)"win32");
init_highlight(TRUE, FALSE);
}
#endif

There is a check for Windows terminal in os_win32.c:

wt_working = mch_getenv("WT_SESSION") != NULL;

This flag is then used in several places through the USE_WT macro.

There are several other flags for VTP and CONPTY, with very specific
build versions. I don't know how relevant these still are, It mainly
results in conpty_type to be set to a certain number, which isn't
explained anywhere. Looks like it is only used in libvterm and only the
value "2" makes a difference.

What matters for the original problem is how Vim obtains the size of the
console or terminal. If it is a console then "g_cbTermcap.Info.dwSize"
is used. Otherwise "csbi.srWindow" or fall back to 25 x 80. This is in
mch_get_shellsize() in os_win32.c. But mch_get_shellsize() in
os_mswin.c doesn't do anything, it is not supposed to be used, but is
it? If it is, then doing something similar to mch_get_shellsize() in
os_unix.c would be helpful. Using the MS-Windows equivalent of the
ioctl() calls.

> > In the end there are a lot of choices out there, which can be both
> > good and bad.
>
> Before MS Terminal, Wezterm was the best choice. Before that, Cmder and
> ConEmu. And the problem with Mintty is that it's not independent. The
> reason it behaves so like a Linux terminal is because it's built with
> Cygwin or Cygwin-like shells (MSys, git-bash, etc.) in mind. You can't
> run Command Prompt or PowerShell on it. You can't even run Win32
> version of Vim on it. You'll need a Vim built with Cygwin. That's an
> extra hassle in my opinion.

Can we assume that MS Terminal is included with the distribution, or
installed most widely? If so, then investing time in making this work
properly is well worth it.

--
Some of the well known MS-Windows errors:
ETIME Wrong time, wait a little while
ECRASH Try again...
EDETECT Unable to detect errors
EOVER You lost! Play another game?
ENOCLUE Eh, what did you want?

[Enan Ajmain]

On Wed, 21 Jun 2023 13:41:03 +0100
Bram Moolenaar <Br...@moolenaar.net> wrote:
> Can we assume that MS Terminal is included with the distribution, or
> installed most widely? If so, then investing time in making this work
> properly is well worth it.

Windows 11 comes with MS Terminal and is the default [1]. As for making
this work: it already works fine. You may be referencing a previous
issue I raised about colors [2]. That's a veeery minor issue. And it
only appears when 'termguicolors' is disabled, which isn't the case for
most users.

(after re-reading the earlier emails:)

I see that Rob Solomon wrote:
> I'm following up w/ my last post, to say that it's been fixed by making the
> terminal window size smaller. This fixed the same issue whether it was
> cmd.exe, windows terminal, or TakeCommand.

That's a contradiction between what they and I are experiencing. On my
end, when I resize MS Terminal or Conhost, Vim resizes accordingly. My
system is:

OS: Windows 11 22H2 (Microsoft Windows [Version 10.0.22621.1848])
Terminal: Windows Terminal Preview v1.18.1462.0
Shell: cmd.exe, PowerShell 7, git-bash, msys (tried all)
Vim: v9.0.1640 (built with mingw-w64 toolchain of MSys2/UCRT64)

--
Enan

[1]: https://devblogs.microsoft.com/commandline/windows-terminal-is-now-the-default-in-windows-11/
[2]: https://groups.google.com/g/vim_dev/c/SuVLCni9WCw/m/UtZ2DXLDAQAJ

[Christian Brabandt]

> Am 21.06.2023 um 18:13 schrieb Enan Ajmain <3nan....@gmail.com>:
>
> On Wed, 21 Jun 2023 13:41:03 +0100

> Bram Moolenaar <Br...@moolenaar.net> wrote:
>> Can we assume that MS Terminal is included with the distribution, or
>> installed most widely? If so, then investing time in making this work
>> properly is well worth it.
>
> Windows 11 comes with MS Terminal and is the default [1].

Is this true? I thought I had to manually install it on my win 11 system.

Thanks
Chris

[Stan Brown]

It's true.

I use TCCLE (free version of Take Command) as a command-line shell on my
Windows machine. In an April round of updates, Windows 11 shifted to
opening TCCLE as a tab in a MS Terminal window rather than independently
as in the past. Fortunately, with a published hack I change Windows 11
back to the previous behavior.

Windows Terminal was there before the updates, but Windows didn't try as
aggressively to have us use it.

Maybe you are thinking of the Bash shell in Windows, part of the Windows
Subsystem for Linux? I don't use it myself; but, if I'm not mistaken,
you have to change some settings to activate WSL. Googling for
"bash shell" "Windows 11"
turns up many useful-looking pages. This one seems straightforward:
<https://mspoweruser.com/different-ways-to-run-shell-script-files-on-windows/>

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com

[Enan Ajmain]

On Wed, 21 Jun 2023 19:16:28 +0200
Christian Brabandt <cbl...@256bit.org> wrote:
> > Am 21.06.2023 um 18:13 schrieb Enan Ajmain <3nan....@gmail.com>:
> >

> > ___On Wed, 21 Jun 2023 13:41:03 +0100

> > Bram Moolenaar <Br...@moolenaar.net> wrote:
> >> Can we assume that MS Terminal is included with the distribution, or
> >> installed most widely? If so, then investing time in making this work
> >> properly is well worth it.
> >
> > Windows 11 comes with MS Terminal and is the default [1].
>
>
> Is this true? I thought I had to manually install it on my win 11 system.

Informed by good source. I asked on a PowerShell Discord server. A lot
of MS employees frequent there. One of them said Windows 11 should
include MS Terminal. He also said to tell him or Kayla (for some reason
he thought I know all of them) if I find any edge case.

There is also the link I provided in my previous email. It declares
that Windows 11 will not only come with MS Terminal, it will come with
it as default (which is what Stan Brown talked about in the other reply
to your email).

> Thanks
> Chris
>

[Bram Moolenaar]

> On *Windows Terminal Preview* (Windows 11) with Windows PowerShell or CMD

> as the shell, the 'columns=600' or any other such setting will be ignored
> and the variable will remain at whatever vim set it to. So nothing happens
> to the display.

OK, so this is for when Vim is started directly in the terminal.
It would be good if ":set columns=80" is working here. I often use that
after messing with the window size for whatever reason (I use 80
columns so I can fit several terminal windows side-by-side).

> Using the Windows CMD shell under the old CMD terminal, whatever that is
> called, will result in columns value being changed, but the terminal does
> not change and has no issues after the setting.
>
> Using RedHat's cygwin bash, which comes with Git-Desktop for instance,

> inside of *Windows Terminal*, performing a "set columns=600" will result in

> a corrupted terminal which cannot be fixed using the standard terminal
> reset commands (tset(1) or reset(1)). Only closing and reopening the
> terminal will return a good work session.

Perhaps it sets some environment variable only on startup?

> Using cygwin bash under the RedHat provided *mintty* terminal and

> performing a "set columns=600" will cause vim to resize to the maximum
> width of the system monitor and set Columns to a number that equates to the
> new terminal size. This is the only terminal software I found that behaves
> as one would expect a Linux terminal to work. This was the best terminal I
> saw on Windows.
>

> Finally, using the *GVim* provided with VIM for Windows will also change

> the Terminal size according to changes in the 'columns' setting. Again, vim
> will change the size of the terminal up to the actual maximum available on
> the system monitor. The columns variable reflects the proper terminal size

> like the *mintty *version does. I don't know what terminal that means is

> used or even if it can be called a terminal, but clearly it works properly
> with vim by design.

Vim uses libvterm, a "virtual" terminal that is build into Vim. On
MS-Windows it uses ConPTY or WinPTY. libvterm resembles an xterm and
many programs can work with it.

> So my conclusion is that this is a terminal software problem. Some
> terminals adhere to the resizing commands that vim sends, some ignore it
> but remain stable, and yet others become hopelessly corrupted requiring
> that the software be closed and restarted.

We can try to make it work. For some terminals we may require the
maintainers to make changes. I suppose there is no standard way for
handling size changes, like SIGWINCH on Unix. If there is a terminal
that does this well we can suggest to use it as an example, hopefully we
can then avoid every terminal doing something different.

> Obviously Bram knows far more than I do, but my recommendation would
> be to use a Terminal package that behaves like a fully functional soft

> terminal should or don't resize the window *after* launching VIM.

In the help we can list terminals we know and what works for each of
them. That can function as a recommendation. It will take some effort
to keep up-to-date, but it's worth it.

> Personally I use bash and Windows Terminal when I'm on Windows. It has
> features I prefer and I don't usually resize my work space after I've
> got set up. Will Microsoft fix their issues. Not gonna hold my breath.

I'm sure Microsoft will not fix *all* their issues, but the team working
on the Windows Terminal has been responsive. I hope at least one of
them is using Vim and fixes any encountered problems. That's why Vim
works well in the Chrome secure shell :-).

> Should there be smoke coming out of my CPU?

No, it's bad for the cooling system and shortens life.

--
hundred-and-one symptoms of being an internet addict:

200. You really believe in the concept of a "paperless" office.