Why does vi reset the "lines=" parameter after a shell escape?

Do you have the following set in your ~/.vimrc file?

set lines=55 columns=160

I have my Terminal profile set to columns: 90 rows: 30. I have the above single line ~/.vimrc directive set to my column and row values. Any number of shell escapes within vim do not change these settings when queried from within vim. I am also declaring the terminal as xterm-256color in the Advanced tab of the Terminal profile.

El Capitan 10.11.3. Default OS X vim.

This does not happen for me, and I live in Vim both at home and at work. I NEVER "set lines=n" NOR "set columns=n" in my .vimrc files. Vim always just uses whatever the terminal is set to. And I frequently have Vim execute shell commands for me.

What happens if you start Vim with

vim -u NONE -U NONE file.name

:!man date

does the Terminal session reset its size? The -u and -U option prevent Vim from reading .vimrc and .gvimrc initialization files. If the problem does not occur, then there is a good chance it is one of your Vim initialization files doing this to you.

You can use vim -V20 to get very verbose output as Vim starts up and processes all your .vimrc initializations.

PS. Here is a Vim trick for fetching man pages inside of Vim

Add the following to your .vimrc file

runtime ftplugin/man.vim " give you :Man [n] manPageYouWant support inside of Vim

map K :Man <cword><CR> " Lets Capital K fetch the man page for the command/function under the cursor

Using ":Man date" or placing the cursor over the word 'date' and using Capital-K will split the screen and put the requested man page in the upper half of the screen. You can then navigate through the man page using regular Vim commands and search strings. Control-W Control-W will toggle between the different halves of the screen, and you can use regular Vim copy and paste operations to move information between the halves.

You close the Man page half of the screen by using ZZ or :q when the cursor is in that half of the screen.

:Man 2 read

notation will get the 'read' man page from section 2, and not the default section 1, if you need to get something from a specific man page section.

The use of Capital K is of course up to you. I use K because that is how it was recommended to me. I do not think Capital M has a default mapping, so if it makes it easier to remember, use Capital M in the map command.

Bob,

I wasn't experiencing the OP vim issues either, and the .vimrc syntax that I offered has been in that config file for eons, though like my appendix, apparently is unnecessary. I noticed that omitting the .vimrc on start, and hopping out to the shell, and back had no impact on my lines and columns, as they continued to reflect the Terminal settings. You are also using iTerm2 are you not?

VikingOSX wrote:

I wasn't experiencing the OP vim issues either, and the .vimrc syntax that I offered has been in that config file for eons, though like my appendix, apparently is unnecessary. I noticed that omitting the .vimrc on start, and hopping out to the shell, and back had no impact on my lines and columns, as they continued to reflect the Terminal settings. You are also using iTerm2 are you not?

For the purposes of testing wap042's issues, I fired up Terminal so that I was using similar technology. And I am also on El Capitan 10.11.3, like wap042. And I made sure I used /usr/bin/vim, and not my own compiled copy.

But "Yes", on a daily basis I use iTerm2, and my own compiled copy of Vim 7.4 vs Vim 7.3 in El Capitan 🙂

Oh yea, I "Love" xterm-256color support. I only found it recently (like in the last year), and because of that I have almost totally stopped using gvimdiff and switched to wide terminal screens and vimdiff. Much faster when the system is 2,000 miles away and trying to use X11 across that link. For typically syntax coloring, the regular 8 colors is fine. But with vimdiff you want some software lighter pastels to indicate changed, removed, and new code that does not interfere with the normal syntax coloring. xterm-256color gives me that.

Anyway, maybe the vim -V20 will help decode the problem (although if there is a lot of vim initialization going on, it can be tedious to wade through).

Or wap042 can take the easy way out and hardcode lines=55 columns=160 in .vimrc (which would have its own secondary annoying behavior).

I just noticed the effect of :sus, and fg this morning for longer spells outside of vim and then resume the editing session.

I am using MacVim/mvim which will notify on new updates, and then update in place. Current with 7.4 - 1553. Otherwise, I use the OS X vim.

When I start a shell session from Vim, I have my .bashrc modify my shell prompt to remind me I have a Vim session waiting

I have gotten caught forgetting the Vim session lots of times, so this way my shell prompt has been changed to remind me Vim is still waiting.

I just test for ${VIMRUNTIME} in .bashrc and if it exists I assume Vim is my parent process, and I adjust my prompt accordingly.

xterm-256colors comes in handy for coloring prompts too 🙂

I mostly use MacVim with the Firefox "Its all text" plugin

<https://addons.mozilla.org/en-US/firefox/addon/its-all-text/?src=search>

that makes every Firefox simple text box editable via MacVim (after you configure it to launch MacVim that is). The text box gets a little (edit) button in the lower right corner, and if you click it the exiting text gets put into a MacVim session. Every time you save the text changes in MacVim, the Firefox simple text field gets updated. NOTE: Does NOT apply to discussions.apple.com reply boxes, as they are not simple text fields 😟, however, I have to file out lots of simple text boxes when doing code reviews, and other web based forms at work, such that it makes it very handy to be in a Vim session, as my code review comments can be rather lengthy.

I think you can also hook Xcode into using your own editor, and MacVim can be the target for that (played with that many years ago, but just could not get into Xcode enough to stick with it).

My building my own Vim mostly came from the late '90's when I first discovered Vim and it was not available to Tru64 UNIX, so I had to build my own and make sure it has cscope support compiled in. Later, I had to build my own, because I wanted new Vim features, but at the time was staying on Snow Leopard on my iMac at work, taking the approach "If it ain't broke, don't fix it" vs the "If it ain't broke, fix it until it is broke" 😁

Now that OS X Terminal.app supports 256 colors, I use tput to give myself access to extended colors. I use a black terminal background, and my terminal prompt is set:

Bluebld="$(tput bold; tput setaf 63)", and White=$(tput bold; tput setaf 15)" — with PS1='\[$Bluebld\]\h\]: \w\$ \[$White\]'

To get all 256 colors displayed in the Terminal, I use a Perl script from here that shows the hex and decimal color codes in their actual colors.

VikingOSX wrote:

To get all 256 colors displayed in the Terminal, I use a Perl script from here that shows the hex and decimal color codes in their actual colors.

I had to modify the perl script to get it to display colors. I must have lost something when I did copy & paste of the script.

I had to modify 2 lines to include \e (escape)

print "\e[38;5;", $num, 'm';

...

print "$arr[$num] \e[0m";

After that it worked fine.

I had been using my own shell script for the 8 basic colors, but it displays each color on each background, bold, and reverse video. All those combinations made the output longer than the perl scripts you pointed at. I would shutter to think how long each 256 color on each 256 background would display 🙂

My basic 8x8 combinations is 64 lines. 256x256 would be 65536 lines. I do not think I'll write that script.