4

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).

Sagar Jain
  • 7,475
  • 12
  • 47
  • 83
apinstein
  • 5,105
  • 1
  • 23
  • 22

7 Answers7

8

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
  • 334,560
  • 70
  • 407
  • 495
  • I agree. Another option is to split the screen, see both at once and ^A between them. – Andy Mar 10 '09 at 15:24
  • 1
    For Vim, the :make command is very useful (especially when bound to a key [combination]). – strager Mar 10 '09 at 22:11
  • 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 Mar 15 '09 at 21:57
2

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.

Community
  • 1
  • 1
Dennis Williamson
  • 346,391
  • 90
  • 374
  • 439
  • 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 Nov 23 '09 at 01:57
2

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
  • 47,505
  • 4
  • 67
  • 87
  • I think he's using plain vi, not Vim. – strager Mar 11 '09 at 19:44
  • 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 Mar 15 '09 at 22:04
  • 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 Nov 23 '09 at 02:12
1

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
  • 41,203
  • 19
  • 62
  • 77
  • 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 Mar 10 '09 at 22:00
  • 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 Nov 23 '09 at 15:34
0

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.

Community
  • 1
  • 1
Davide
  • 17,098
  • 11
  • 52
  • 68
0

It is possible that scrolling the screen Ctrl+E or Ctrl+Y might do the trick as well.

Sagar Jain
  • 7,475
  • 12
  • 47
  • 83
Nathan Feger
  • 19,122
  • 11
  • 62
  • 71
0

Changing your terminal type to ansi could work:

:set term=ansi

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

Node
  • 21,706
  • 2
  • 31
  • 35
  • unlikely, if running under 'screen'. It intercepts all curses-style TTY output, and re-sequences the output. – Alnitak Mar 10 '09 at 21:00
  • 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 Nov 23 '09 at 15:41