> On Wed, 24 May 2023 02:30:21 +0600 > Enan Ajmain <[email protected]> wrote: > > On Fri, 5 May 2023 22:18:07 +0600 > > Enan Ajmain <[email protected]> wrote: > > > On Fri, 05 May 2023 16:28:27 +0100 > > > Bram Moolenaar <[email protected]> wrote: > > > > It's much more complicated than that. E.g. search for > > > > "cterm_ansi_idx" in src/term.c, this is used specifically for > > > > MS-Windows. Thus if you use an MS-Windows console and ssh to a > > > > Linux system this mapping is missing and the colors are likely > > > > messed up. > > > > > > Thanks. Just a closing correction: the colors on > > > vim-that-is-actually-on-Linux-but-using-over-ssh-in-Windows is NOT > > > messed up. It shows perfectly. 'ctermfg=7' shows the proper color > > > that's set in the terminal emulator. It's the native Vim on Windows > > > that shows unexpected (or what I think is considered unexpected). > > > > > > But anyway, thanks. > > > > There has been a development: > > https://github.com/microsoft/terminal/issues/15408 > > A comment from j4james (a collaborator for MS Terminal): > > > If it were up to me, I'd dump their current win32 code, and replace it > > with the whatever they're using on Linux, since that clearly already > > works in Windows Terminal when vim is run from WSL. It's probably a > > little more complicated than that, but there really should be no need > > for them to be using this weird mix of legacy console APIs interspersed > > with VT sequences. > > This is not to put responsibility on Vim devs. This is just to let the > Windows users among Vim devs (Yegappan perhaps? He picked up my half > baked bugfix for 'shellcmdflag' for powershell last year and polished > it for final merge) know that maybe we can use unix logic for win32 as > well. Maybe. If someone wants to look into that. > > (I'll investigate some and share my findings, but I know nothing about > terminal stuff so can't say I'll be useful.)
The Vim code has quite a few assumptions about how things work on MS-Windows. The code to use a terminal is currently not included in the MS-Windows build, only the GUI and console support is. Also including the terminal support should be possible, but it will be a bit of a puzzle to adjust the #ifdef's to include the code and then to decide (at runtime) which code is active. We already have the VIMDLL macro, with the gui.in_use flag, this would be an addition to that. It should be doable, but it will be quite a bit of work to "get it right". We also need to keep in mind that this third way of using Vim on MS-Windows can be expected to require maintenance for a long time, thus it should not be a "quick hack". -- Don't drink and drive. You might hit a bump and spill your beer. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20230608154601.3593C1C0642%40moolenaar.net.
