views:

319

answers:

7

I often work in vi, suspend vi, run something on the cli, and then fg back into vi to work on the results. For instance, fixing errors that showed up when I ran the cli command.

However, when I fg vi, vi "wipes" the current terminal buffer and I can't see the "last screenful" of terminal output in the scrollback buffer.

Is there some setting in vi (or screen, I use screen) which would help me here?

I have searched google for a long time with no answers. I also realize that there are other workflows that solve this problem, but they aren't perfect (run from inside vi means no shell completion, etc).

Thanks! Alan

A: 

It is possible that scrolling the screen ctrl-e or ctrl-y might do the trick as well.

Nathan Feger
A: 

Changing your terminal type to ansi could work:

:set term=ansi

But I'm sure there are some negative side effects.

Node
unlikely, if running under 'screen'. It intercepts all curses-style TTY output, and re-sequences the output.
Alnitak
If you do what you wrote, it doesn't help at all. If you set it **before** calling vi, e.g. with `vim -T ansi whaterver-the-other-options-are`, then the problem is partially solved (partially in the same sense of my answer: http://stackoverflow.com/questions/630519/can-you-make-vi-advance-the-screen-when-opened/1783816#1783816 ). But the cure is worst than the problem, because several functionalities will be cripple (e.g. syntax highlighting)
Davide
+7  A: 

If you're using screen, then surely it would make sense to do your editing in one window, and your compiles in the other, and then just use the ^A[n] sequences to flip between your terminal output and code screens?

Alnitak
I agree.Another option is to split the screen, see both at once and ^A<Tab> between them.
Andy
For Vim, the :make command is very useful (especially when bound to a key [combination]).
strager
Thanks for the idea, but as I said in the original post, my mind is already conditioned for "suspend-run-fg" style of working, and I prefer that for certain scenarios anyway. I am looking for an answer that doesn't involve a different workflow. I also want to know how to control the term anyway.
apinstein
+1  A: 

I don't know if this will help but: I use a mac these days, but I used to use NetBSD and Linux at uni. It always bugged me that programs like less, man, vi, etc. would clear the screen when they exited. I could switch it off in less with the -X option, but that wasn't an option (literally) with the others.

I found a config setting in xterm that solved the problem for me. I'm afraid I don't remember the option; it was available through one of the menus and I think through the -xrw commandline option.

Obviously this can only be helpful if you use xterm.

John Fouhy
On the Mac, I set TERM to dtterm to fix this problem. I think he wants to do the same thing, but with screen, something I don't use.
Craig S
Hmm, interesting. Thanks!
John Fouhy
which xterm are you talking about? Hardy Hardon's one - i.e. XTerm(229) does not accept `-xrw`. In addition, `less -X` does not solve the problem on AIX.
Davide
+2  A: 

I'm not 100% sure whether this will help you or not, but vim tries to restore the screen it found when it was started. I like that behavior and spent quite a bit of time to "repair" a vim installation on a machine where this didn't work.

I had to set the t_ti and t_te variables. My hunch is that you should unset t_te.

innaM
I think he's using plain vi, not Vim.
strager
Ouch. I thought that since the question was tagged 'vim'...
innaM
I am using vim. (alias vi=vim, sorry for the mix-up in the question).This approach sounds really interesting... I looked around the help on these 2 items, but it's a bit out of my wheelhouse... I frankly don't know how termcap works etc... what exact commands would you suggest I use?
apinstein
This does not work on my AIX. Looking at that web page, I figured out that I can startup with something like `vim -T ansi myfile` and that partially solves the "screen wiped out" problem. Unfortunately, with ansi all the nice coloring and other features are lost, so the cure is worst than the problem.
Davide
A: 

In answer to your question in your comment on this answer: it seems to actually be the t_ti variable. In your ~/.vimrc add a line that says:

set t_ti=""

You can try it out first from within vim by entering that command at the : prompt.

Dennis Williamson
This has no effect at all on my setup (vim 7.0, AIX 5.3 and $TERM set to aixterm - no way to change anything besides .vimrc). See also: http://stackoverflow.com/questions/1780483/lines-and-columns-environmental-variables-lost-in-a-script
Davide
A: 

This is not a solution, but a nice workaround, that I've just started using. Create the following wrapper script for vi (I placed it in my ~/bin/vim-wrapper) and possibly alias it with something like:

alias vi='~/bin/vim-wrapper'

Content of vim-wrapper (see this answer for details):

#!/bin/bash
LINES=$(tput lines)
for i in `seq 1 $LINES`; do
    echo $i
done
vim $@

This will solve completely the screen wiped out issue. Unfortunately, it does not solve the have to scroll up quite a lot when you edit a long file in vim. But if you set a large enough buffer in your xterm-like (I use gnome terminal 2.22.1) you'd be ok.

Davide