While I'm working in vim, I often suspend the vim process with ctrlz so I can access my bash shell. I'm on Ubuntu 14.10.
I have plugins such as syntastic loaded which take action after actions like file writes.
Something that happens all-to-frequently is that I will save a file and immediately want to do something on the shell, such as a git operation.
If I do this too fast though (save and then immediately suspend the vim process) my shell get's in a weird state where the blinking cursor is gone and half the screen needs to be repainted.
Then, when I fg back into the vim process it too is messed up visually and I need to redraw the screen (with ctrll).
I understand I can "fix" the problem by forcing the redraw but any suggestions on how to avoid getting in this state?
Perhaps something like a mapping to wrap ctrlz and kill all plugin execution before the suspend occurs?
The first step in debugging vim is to follow the instructions in How do I debug my vimrc file?.
In this particular question, the problem could also reside in the terminfo configuration. A typical example of such a problem is when $TERM is defined in .bashrc to a value that is not compatible with the used terminal.
Related
I like elscreen for the idea of screens / workspaces (pretty much reminds me of
i3).
I'm also using elscreen-persist to save configs between sessions.
However, I'd like to define some default shells, but this information is not being saved.
Does anyone have an idea how it would be possible to save shell-mode state?
Actually, most importantly is of course the fact that now it starts in *scratch* after loading (rather than in its old shell), while I'd like it to start a shell with the prompt at the part where it ended.
Simple question: Is there a way to run a script in the background with out terminal running?
More detail and background: I had an app that read an apps .log file and puled information from it, then provide information and statistics from the information in the log.
An update to the app changed the way the .log file was written and delete information and duplicates the log in a manner that i have been unable to predict.
the app that was designed to interface with the log was not coded to check for such changes. so when it attempts to gather information after the log change it stops working.
A "hack" has been devised to run a tail -f, then hexed the app to point at the new file.
(The "hack" works)
I would like to run the tail in the background so that the user doesn't interrupt it... breaking it...
-sorry for the (possibly) longer than needed description. BUt i figured a more detailed question would get me a precise answer.
Thanks in advance!
~¥oseph
The answer depends on if you need to be able to re-connect to the process after exiting the shell. If the process is non-interactive and can simply be left alone, then "nohup program &" should do the trick. But that won't let you continue to interact with the program after you've closed the shell.
If it's a interactive program, then your best bet is to use screen or one of the other terminal-multiplexers. You start "screen" which gives you a new shell, in this you start whatever program you want, the usual way, say "nano myfile.txt".
When you want to close the shell, but leave the program running, you press C-a d ('Detach') to detach from screen. it keeps running, but in the background, and will keep running even if you log out.
When you then later want to reconnect to screen you open a new shell and type "screen -r" (reconnect), this leaves you right where you where.
Screen also lets you run several different shells in a single terminal-window and is a neat tool overall. Check it out.
I want to view the output of a bash command in a vim split window :split. To this end I installed "Conque Shell" which displays bash in a split window upon :ConqueTermSplit bash. I can then run my shell command and watch the output in insert mode. However, to return to the other window I need to type <CTRL-W> <Up> in command mode, so I need to leave insert mode. Hence the display of the command output freezes and continues only if I return to this window and enter insert mode. So how can I leave "Conque Shell" without leaving insert mode.
Note that other ways of viewing the bash output in a second window might solve my problem as well. However it should update while I am working in the other window and allow me to signal e.g. <CTRL-C> to the application.
The ConqueTerm documentation says:
3.1.5 Keep updating terminal buffer *ConqueTerm_ReadUnfocused*
If set to 1 then your Conque buffers will continue to update after you've
switched to another buffer.
Note: Conque buffers may continue to update, but they will not scroll down as
new lines are added beyond the bottom of the visible buffer area. This is a
limitation of the Vim scripting language for which I haven't found a
workaround.
>
let g:ConqueTerm_ReadUnfocused = 1
AFAIK Vim has no support for asynchronous sessions, so this is more of a response to your request for potential alternative options.
The way that I currently get around this issue is by using tmux, which is described as:
a terminal multiplexer: it enables a number of terminals (or windows),
each running a separate program, to be created, accessed, and
controlled from a single screen.
So, basically, instead of splitting your screen in Vim you would split it using tmux, and then in one window run Vim and in the other run whatever other program you want which will update completely independently of Vim. And just like Vim you can switch between the windows (or panes as they are called in tmux lingo) using a couple of key strokes.
There is another terminal multiplexer available called GNU screen, which is also quite popular. And the reason I mention that is because I like to have options, and also there are two plugins for Vim that allow you to send output directly to an attached screen or tmux session. For GNU screen, slime.vim, and for tmux, tslime.vim.
Using VIM and ConqueTerm you can use CTRL + W and UP / Down to change windows in split mode.
Just click on ESC first to exit the insert mode.
It works well on my side.
I started using vim for my programming projects (mostly Ruby) and mostly everything works just as I want but I have a problem with compiling.
Lets say I am working on a Ruby script and I want to run it. I type :ruby sometging.rb (mapped to some other key). Then vim opens a new cmd.exe window and runs 'ruby something.rb'. Then it waits for me to press ENTER to close the window and continue working on the script.
Is there a way to configure vim on windows so that it always runs the script I'm working on in a separete window (always the same one, if none exists => open one), and not ask me to confirm with enter?
Don't know about gvim, but in normal vim you could put something like
map R <ESC>:tabnew<CR><ESC>:;%!ruby filename.rb<CR>
in your ~/.vimrc which would execute a Ruby file in a newtab when pressing R in command mode.
I've not used Ruby, but for I've found Dr Chip's RunView plugin really useful for running other interpreted languages.
Once it's installed, you can enter:
:RunView! <interpreter>
(where <interpreter> is presumably 'ruby' in your case) and it will open a (vertically if you include the !) split window with the output from passing the contents of the current window to the interpreter. Each time it is run, a new result log is appended to the end of the file (with a date and time stamp separating them).
If you have any issues with it, I'd recommend you contact Dr Chip via the Vim mailing list: he's very helpful (in fact he wrote the original version of RunView in response to a request I made on the mailing list).
This isn't exactly perfect but I use this to launch Python scripts.
command -nargs=* PY3 !start cmd /K Python.exe "%:p" <args>
It starts up a window that stays alive and doesn't interfere with my VIM window. Unfortunately it doesn't load it into an existing window.
I'm running MATLAB (command line version) from a shell script, and I'd like it to preserve shell behavior where if you press Ctrl-C it exits. But instead it wants to keep control of the terminal and I (or my poor users after me) have to type quit(1) to make it quit and tell the shell it failed.
You can't intercept Ctrl-C with a try/catch block... any other ideas? Anything I could do from the shell side to intercept the keystrokes before they get to MATLAB?
onCleanup seems like an option, but then I'd have to make the whole script thing into a function (it's already a dynamically generated try/catch block thing in a Makefile). But if that's the only thing that will work, then I'll do it...
Use onCleanup:
I wanted to do the same thing but after I read this thread I used onCleanup successfully. My problem was I had a server in Matlab that when pressing CTRL+C would keep listening on the port it was started on -> second run I would get a bind error.
You can try:
stty quit ^C
but I have no matlab to test it.