The screen buffer after opening any file in any editor (vi/nano) is not cleared and the command prompt is on the last line. Its not crashing or harming anything, but looks a COSMETIC concern to me. Because in any other flavor of linux/unix, the screen buffer is cleared and prompt on the screen location from where we fired the command (i.e. vi abc.cpp) But, in case of gentoo i have observed after opening any file in any editor the command prompt always comes at last time. Reproducible: Always Steps to Reproduce: 1. Use "clear" to make sure that prompt is on first location of the screen. 2. Open any file in vi / nano or any editor. 3. Close the file, the shell prompt will be at last line of the screen. Actual Results: The shell prompt is at last time of the screen. Expected Results: comparing with other flavours of unix i believe it should not be at last line, rather the very next line from the orginal place where editor command (i.e. vi abc.cpp) was fired I am running gentoo on virtualbox, may be this is reason for this, as I haven't tried gentoo without virtualbox, so this point should be considered as well.
Created attachment 262299 [details] gentoo screenshot showing the problem
Created attachment 262301 [details] ubuntu screenshot for the same in ubuntu screen buffer is cleared (of the editor) and shell prompt is on the next line from where the command was fired.
In Gentoo, you're running the editor on the console, right? That is, you're not running it in a terminal emulator (xterm, urxvt, gnome-terminal...) through some window manager? I think that's the reason for this. You can try switching to the virtual console on Ubuntu with Control-Alt-F1 to confirm. The reason is that, when you run an editor on a real console, the editor actually prints everything out to it, using up lines. For example Emacs might print out the menu line, a bunch of blank lines, and then the status bar at the bottom. At that point, your "position" in the console is on the last line because Emacs just printed 24 lines of stuff. The same problem doesn't exist when run through a terminal emulator.
On a gnome-terminal in Ubuntu the buffer is restored. On a tty in Ubuntu the buffer is NOT restored (as you say is Gentoo's problem). In rxvt-unicode on Gentoo the buffer is restored. In screen under ssh in rxvt-unicode on Gentoo the buffer is NOT restored. I could go on. It's unclear what should be fixed here. I don't actually even see a bug here, but you could perhaps elaborate on that when you find the universal fix for this problem. BTW, is that a konsole screenshot you named "gentoo.jpg"?
Yes, the statements you made are correct and it happens exactly same way in real console on ubuntu also. The gentoo real console file is named as Gentoo.jpg But, still I think even in real console somehow the buffer should be restored. I am not very sure about its feasibility but I am looking on to the code for this as of now. In case could find anythin. What you suggest on the feasibility of this? screen emulators do it and thus some workaround should be there to put this thing in real console also. Suggestions are welcome.. thanks (In reply to comment #4) > On a gnome-terminal in Ubuntu the buffer is restored. > On a tty in Ubuntu the buffer is NOT restored (as you say is Gentoo's problem). > In rxvt-unicode on Gentoo the buffer is restored. > In screen under ssh in rxvt-unicode on Gentoo the buffer is NOT restored. > I could go on. > > It's unclear what should be fixed here. I don't actually even see a bug here, > but you could perhaps elaborate on that when you find the universal fix for > this problem. > > BTW, is that a konsole screenshot you named "gentoo.jpg"? >
While I know next to nothing about programming the ttys, I think that terminal emulators can do this by virtue of being emulated. In an emulator, none of the "console" output is written to a tty. Instead, it's stored in a buffer somewhere in memory, and drawn on the screen in a window that's decorated to look like a tty. That allows the emulator to restore what was on the virtual screen after a program ends. In a real console (as far as I know...), the output is stored in a buffer only until it's flushed to screen. Once it's flushed to the screen, it's on there for good, so I don't think there's any way to restore "what used to be on the screen" in a real console.
(In reply to comment #6) Yes, one would have to hack on the Linux console driver to get that alternate-screen capability which makes the screen restore possible. So this is not really something vim maintainers will be able to fix.
