vi display is garbled #165

@bitcrazed commented on GitHub (Feb 16, 2018):

From @danieltanfh95 on April 13, 2017 3:49

I tested this. I do not have this problem.

@bitcrazed commented on GitHub (Feb 16, 2018): _From @danieltanfh95 on April 13, 2017 3:49_ I tested this. I do not have this problem.

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @zadjii-msft on April 13, 2017 16:29

@raymod2 Is this consistently repro'ing for you? I can't seem to replicate that behavior.

Is it possible that you made any changes to something like your .inputrc, infocmp or your TERM?

@bitcrazed commented on GitHub (Feb 16, 2018): _From @zadjii-msft on April 13, 2017 16:29_ @raymod2 Is this consistently repro'ing for you? I can't seem to replicate that behavior. Is it possible that you made any changes to something like your `.inputrc`, `infocmp` or your `TERM`?

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @raymod2 on April 14, 2017 14:14

Yes, I can reproduce it consistently. I didn't touch any of those files or environment variables you mentioned. I did install a few packages including gvim-gtk3 that might have changed something.

@bitcrazed commented on GitHub (Feb 16, 2018): _From @raymod2 on April 14, 2017 14:14_ Yes, I can reproduce it consistently. I didn't touch any of those files or environment variables you mentioned. I did install a few packages including gvim-gtk3 that might have changed something.

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @zadjii-msft on April 17, 2017 16:33

@raymod2 I tried installing vim-gtk3 and i still couldn't get this behavior to repro. Do you have any vim plugins installed that might be causing this?

What does your .vimrc look like?

@bitcrazed commented on GitHub (Feb 16, 2018): _From @zadjii-msft on April 17, 2017 16:33_ @raymod2 I tried installing vim-gtk3 and i still couldn't get this behavior to repro. Do you have any vim plugins installed that might be causing this? What does your `.vimrc` look like?

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @raymod2 on April 20, 2017 15:54

set lines=40
set columns=108
set nobackup
set nowritebackup
set whichwrap=      " do not wrap to next/previous line when using arrow keys
set nu              " show line numbers in the left column
set autoindent      " autoindent to the same level as the previous line
set copyindent      " autoindent copies structure of previous indent (prevents TABS)
set guioptions+=a   " selecting text automatically places it in the clipboard
set incsearch       " incremental search (find nearest match as you type search term)
set hlsearch        " highlight search terms
filetype plugin indent off  " suppress cindent and comments settings
set tags=./tags;    " search for 'tags' in parent directories of current file
" If only one tag matches jump directly to it, otherwise present a list of tags
map <C-]> g<C-]>
" Suppress pop-up dialog when file changes outside of VIM (print to status bar instead)
autocmd FileChangedShell * echohl WarningMsg | echo "File changed shell." | echohl None
" jump to the last position when reopening a file
autocmd BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif

@bitcrazed commented on GitHub (Feb 16, 2018): _From @raymod2 on April 20, 2017 15:54_ ``` set lines=40 set columns=108 set nobackup set nowritebackup set whichwrap= " do not wrap to next/previous line when using arrow keys set nu " show line numbers in the left column set autoindent " autoindent to the same level as the previous line set copyindent " autoindent copies structure of previous indent (prevents TABS) set guioptions+=a " selecting text automatically places it in the clipboard set incsearch " incremental search (find nearest match as you type search term) set hlsearch " highlight search terms filetype plugin indent off " suppress cindent and comments settings set tags=./tags; " search for 'tags' in parent directories of current file " If only one tag matches jump directly to it, otherwise present a list of tags map <C-]> g<C-]> " Suppress pop-up dialog when file changes outside of VIM (print to status bar instead) autocmd FileChangedShell * echohl WarningMsg | echo "File changed shell." | echohl None " jump to the last position when reopening a file autocmd BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif ```

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @raymod2 on April 20, 2017 16:3

The .vimrc does seem to be related to this issue. I started with a fresh Windows installation and ran 'sudo vi /etc/sudoers' and there were no issues. Then I created the .vimrc as above and ran the same command. Now I am seeing issues similar, but not identical, to the above description.

@bitcrazed commented on GitHub (Feb 16, 2018): _From @raymod2 on April 20, 2017 16:3_ The .vimrc does seem to be related to this issue. I started with a fresh Windows installation and ran 'sudo vi /etc/sudoers' and there were no issues. Then I created the .vimrc as above and ran the same command. Now I am seeing issues similar, but not identical, to the above description.

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @raymod2 on April 20, 2017 16:20

On another note, it seems bizarre that a command named 'visudo' would use 'nano' as the default editor instead of 'vi'! I noticed that installing vim-gtk3 changes the default editor in 'visudo' from 'nano' to 'vim'. But vim-gtk3 is not necessary to reproduce this issue if you use 'sudo vi /etc/sudoers' instead.

@bitcrazed commented on GitHub (Feb 16, 2018): _From @raymod2 on April 20, 2017 16:20_ On another note, it seems bizarre that a command named 'visudo' would use 'nano' as the default editor instead of 'vi'! I noticed that installing vim-gtk3 changes the default editor in 'visudo' from 'nano' to 'vim'. But vim-gtk3 is not necessary to reproduce this issue if you use 'sudo vi /etc/sudoers' instead.

claunia commented

@bitcrazed commented on GitHub (Feb 16, 2018):

From @raymod2 on May 22, 2017 20:53

@zadjii-msft - Were you able to reproduce this?

@bitcrazed commented on GitHub (Feb 16, 2018): _From @raymod2 on May 22, 2017 20:53_ @zadjii-msft - Were you able to reproduce this?

claunia commented

@j4james commented on GitHub (Apr 1, 2018):

I was able to reproduce this issue by setting my console width to 100 and using the .vimrc settings given above. But I'm assuming this isn't actually a bug - it's just a matter of the columns property (set to 108) not actually matching the width of the display (set to 100 in my case). If I remove the columns setting from the .vimrc, or change my display width to match, then everything looks fine.

@raymod2: Could that have been your problem?

@j4james commented on GitHub (Apr 1, 2018): I was able to reproduce this issue by setting my console width to 100 and using the .vimrc settings given above. But I'm assuming this isn't actually a bug - it's just a matter of the _columns_ property (set to 108) not actually matching the width of the display (set to 100 in my case). If I remove the _columns_ setting from the .vimrc, or change my display width to match, then everything looks fine. @raymod2: Could that have been your problem?

claunia commented

@raymod2 commented on GitHub (Apr 1, 2018):

@j4james - It sounds like you might be on the right track. I didn't mention it in the problem description but I do set my console window width to 100 columns. I still think this is a bug. The columns setting in .vimrc is used to set the default size of new gvim windows. It should never conflict with the actual window size. If you resize a window or the .vimrc is applied to a vim instance running in an existing window then the columns setting should adjust to the actual size.

@raymod2 commented on GitHub (Apr 1, 2018): @j4james - It sounds like you might be on the right track. I didn't mention it in the problem description but I do set my console window width to 100 columns. I still think this is a bug. The columns setting in .vimrc is used to set the default size of new gvim windows. It should never conflict with the actual window size. If you resize a window or the .vimrc is applied to a vim instance running in an existing window then the columns setting should adjust to the actual size.

claunia commented

@j4james commented on GitHub (Apr 1, 2018):

@raymod2 - I did a bit more testing on a Linux box, and I think I see now what's happening. Some of the GUI terminal emulators automatically resize their window to match the number of columns specified in the .vimrc file. The Linux virtual console obviously can't do that, so it has the same kind of issues that you see in Windows.

In order for this to work as expected (assuming you're expecting the window to automatically resize), Windows would need to support a certain private escape sequence that vi is relying on to resize the screen.

ESC [ 8 ; <h> ; <w> t

Where <h> is the height of the screen (the number of rows), and <w> is the width (the number of columns). The only documentation I could find for this sequence was on the invisible-island website (search for "Window manipulation"). This is just one of a number of window manipulation sequences listed there.

I'm somewhat surprised vi isn't smart enough to detect that this sequence isn't supported, and if so reset the columns to the actual screen width rather than the requested size. But maybe it's more complicated than that.

@j4james commented on GitHub (Apr 1, 2018): @raymod2 - I did a bit more testing on a Linux box, and I think I see now what's happening. Some of the GUI terminal emulators automatically resize their window to match the number of columns specified in the .vimrc file. The Linux virtual console obviously can't do that, so it has the same kind of issues that you see in Windows. In order for this to work as expected (assuming you're expecting the window to automatically resize), Windows would need to support a certain private escape sequence that vi is relying on to resize the screen. ESC [ 8 ; <h> ; <w> t Where `<h>` is the height of the screen (the number of rows), and `<w>` is the width (the number of columns). The only documentation I could find for this sequence was on the [invisible-island website](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html) (search for "Window manipulation"). This is just one of a number of window manipulation sequences listed there. I'm somewhat surprised vi isn't smart enough to detect that this sequence isn't supported, and if so reset the columns to the actual screen width rather than the requested size. But maybe it's more complicated than that.

claunia commented

@DHowett-MSFT commented on GitHub (Feb 6, 2019):

It looks like \e[8;<h>;<w>t actually works now, so I'm gonna close this. Sorry for the delay, and thanks for the report!

@DHowett-MSFT commented on GitHub (Feb 6, 2019): It looks like `\e[8;<h>;<w>t` actually works now, so I'm gonna close this. Sorry for the delay, and thanks for the report!

claunia commented