I use emacs in terminal mode (i.e., launched with the -nw option) in screen. When I quit or suspend emacs, instead of getting back my terminal with the history of previous command and outputs of these commands, I see a blank terminal with only the current prompt showed (*).
This is not the same thing as what would happen with the option altscreen off, as all content from emacs disappears from the terminal.
Things that seem strange to me:
- This does not happen when I run emacs outside of screen
- This does not happen with other full-screen apps such as vim or less
- This does not happen on other computers with the same .screenrc, .bashrc, etc.
The computer on which the problem occurs runs scientific linux, Screen version 4.00.03 and Emacs 23.1.1.
I have no problem on two computers running debian, Screen version 4.00.03jw4 and Emacs 23.2.1.
What could be the reason for this?
(*) Note that what I see is not equivalent to a terminal that has been cleared, as the prompt does not appear on the first line of the terminal but on the line it should be if the history of previous commands and outputs had not been erased, i.e. I see several blank lines, then the prompt.
Related
I am using a terminal inside vim (in a split window). I run my code there using vim-slime.
I love it, except for the fact that the terminal "falls behind": if I run 1000 lines of code, the terminal only shows the output of the first few. I have to manually scroll down (or change to the terminal window and press G) to go to the bottom of the outputs again.
Is there a way to force the terminal to behave as a normal (non-vim) terminal and simply keep up with the last outputs?
Numerous sources indicate that running a "bang" command such as :! wc % will display the results in Vim below the editor window. (For instance, this tip sheet states that as the expected behavior.)
Specifically, I'm following along with this Vimcast tutorial on Tim Pope's Fugitive plugin, and in that Drew Neil states that running the :Git command will allow the user to run any arbitrary git command from inside Vim--and the output of the command will be displayed within Vim at the bottom of the screen.
This is not the behavior I am experiencing. Instead my Vim session is in essence sent to the background, and I'm popped back to my terminal to see the output. It's all very disorienting--specifically because I lose the useful visual context provided by my Vim session including the "bang" command that generated the output.
I'd love it if Vim actually did display the externally generated output in Vim below the editor window. I found some similar types of questions, but in all of them the user wanted to output the content to a new buffer rather than just see it momentarily printed at the bottom of the editor window. In other words, I've not found anyone else describing the behavior I'm seeing.
I was able to get the desired behavior in gVim, but gVim isn't always a viable option, so I'd like to know whether there is a broader solution that will allow the expected behavior in terminal-based Vim.
I'm using Vim 8.0 on Ubuntu 16.04. My terminal is gnome-terminal with the zsh shell. I tried some other terminals on my machine and the bash shell, and I'm experiencing this behavior regardless of which combination I use.
Here are two screenshots that demonstrate the behavior I'm seeing. On the left is a terminal-based Vim, and on the right is gVim. Notice how running :! wc % has the expected/desired behavior in gVim on the right, but not in regualar Vim on the left.
Screenshot before running command:
Screenshot after running command:
Is anyone else experiencing this? Does anyone else get the desired behavior from their terminal-based Vim? (Perhaps this is all some kind of documentation oversight and terminal-based Vim was never expected to behave in the desired way?)
Thanks!
It's GVim (or MacVim) that shows the output of external command at the bottom of the window because it comes with a very minimal terminal emulator. Plain Vim is incapable of doing that.
You could emulate that behavior with tmux via any of the many Vim plugins that provide tmux integration or, since you are using Vim 8.0, the new built-in :help :terminal emulator.
For your example:
:term wc %
An alternative that I stumbled across is to use AsyncRun from this plugin. It acts as alternative to the shebang command, runs the command in the background, and sends the output to the quickfix window.
While I still think the accepted answer is the right one (i.e. that a TUI Vim always outputs to the terminal shell instead of the internal shell), someone else coming across this thread might find AsyncRun to be a better alternative to "that's just how it works".
I'm using SBT 0.13.6 on Windows 7, and I'm running it using Cygwin (bash shell). I have a problem with the arrow keys: Arrow-up moves the cursor up, whereas I want it to cycle through the command history (and I think that's what it should do by default).
The problem seems to be what's printed in the terminal. When I press: [arrow up] [enter], it does execute the previous command. But what I see in the terminal is the cursor moving up one line, and after the enter, it prints the previous command and execute it.
It should, of course, print the previous command immediately after I hit arrow-up, and it should not move the cursor (not vertically at least)
The command-line in SBT is handled by JLine 2. Running JLine in trace mode I can see that it does recognize the key-presses and it has mapped the arrow-up to "previous-history", but the terminal is not updated correctly.
I also had the problem that I had to manually insert an end-of-line character for a command to be entered, which was fixed by adding the following option to my SBT start-up script:
-Djline.terminal=unix
I have tried the other options as well (win, auto, off, etc). I have put the following lines in a file jline.inputrc in my home directory, but it doesn't help:
"\e[A": previous-history
"\e[B": next-history
And in fact I didn't think it should help, because I can see that the key-presses are recognized correctly and mapped to the right command.
The behaviour does not depend on which arrow keys I use (the ones on the numeric keypad or not).
A work-around is to run SBT directly from the Windows command shell (cmd.exe).
Does anyone know of a way to fix this, so that command-history cycling works as expected in Cygwin?
When I enter a shell command via vim -- e.g., :!rake routes -- I'll get some output and then:
Press ENTER or type command to continue
If I press anything at that point, I am always taken back to the main vim UI. How do I stay in that shell mode for a bit longer, specifically I can scroll back to see all the output of the command?
For terminal vim scrolling is provided by terminal emulator (or terminal multiplexer like tmux/screen if you use it). I.e. if your terminal scrolls when using <S-PageUp> it must also scroll with Vim’s !. Same for mouse wheel (it works for me even if vim was configured to handle mouse on its own).
If have terminal vim and you need to view output after you pressed <CR> then you can use <C-z>/:susp. Both these capabilities will be spoiled with incorrect configuration of either vim or terminal (terminal multiplexer) (i.e. terminal configured not to support alternate screens (which is normally issue for terminal multiplexers rather then terminal emulators: screen requires altscreen on in .screenrc) or vim setting telling vim what to output to the terminal on startup/resume and shutdown/suspend was spoiled).
If you have GUI vim your options are very limited. It is better to follow link provided by #glts or #EricAndres advice in this case as I do not use GUI vim.
:r! [shell command] will read the output from the command into the buffer. So if you open a new buffer then use that command, you can search and scroll through it all you like. See Vimcasts episode 57 for more information.
I want to see the original contents of screen after quitting vim
as they were before opening a file , as of not my file quits but the original display is not there
THanks
The feature of returning screen contents after running a full screen application vs, leaving the contents there, is not specific to vi, but to your terminal emulator. The feature you want to turn on to return to the previous text is often known as 'altscreen'. If you are using xterm as your terminal emulator, this behaviour is default. However if you are running GNU Screen inside of an xterm (or other terminal), you need to add the line
altscreen on
to your ~/.screenrc file. Other terminals that support this feature will have other mechanisms to turn it on and off.
Instead of quitting, you can put vim into the background by typing control-z. This restores the previous screen, but leaves you the editor running 'stopped' with the current file. To get vim back, enter the command
fg %1 at the shell prompt. This brings vim back to the foreground again - at least assuming you only have one stopped job. The command jobs will give you a list of stopped jobs, which you can access by number.
So the work sequence becomes edit, save, control-z, compile, test, fg...
This works on linux, and Mac OS X - YMMV on other Unix variants.
If you are using xterm, then see :help xterm-screens, or ... read that anyway as it describes that your problem should be related to some terminfo setting - probably.
HTH