I started using Vim actively and as any Windows user I came across problem subconsciously pressing CTRL + S which freezes the screen for some time (at least it seems so). I read different pages on how to exit this mode. It seems that CTRL + Q or CTRL + S help, but it's not a solution. I read that there's a possibility to disable this mode at all, but most of the suggestions concern Linux. How do I do it on Windows?
This has nothing to do with programming or Linux or Windows or even Vim, which doesn't even handle that key combination to begin with.
CTRL-S is usually handled by your terminal emulator for flow control and if that's the case, CTRL-Q as well. If you want that feature disabled, you will have to do it at a lower level, either in your terminal emulator's options or in your shell config file but you didn't mention your terminal emulator or your shell so you are on your own, now.
Related
I am just getting started using Vim and came across :set mouse=a which I've found really useful for navigating a file, however for some reason when I try and scroll now it scrolls the whole terminal window and not just the vim window.
Then I scroll up and can see the terminal outside Vim
Any ideas on how to fix this? I've tried resetting mouse= and exiting and re entering vim.
The problem was that I had accidentally disabled Allow Mouse Reporting in error.
Checking Menu > View > Allow Mouse Reporting or Cmd + R has fixed it!
I think the cheap answer to your question is that you should be navigating through files in vim using motion commands, Ctrl + d, etc. It might seem slow at first, but it really becomes more natural down the line.
That said, if you are on Mac and using Terminal, you might need to hold the Fn to temporarily disable mouse support. (Check this out for reference: OS X Terminal Mouse Support
Also, you can always try MacVim, which supports mouse scrolling out of the box.
If neither of those solutions work for you, some more information would be helpful for troubleshooting, e.g., your operating system, recent changes to your vimrc, etc.
When working in GUI we do alt-tab (or cmd-tab in mac) to switch between multiple programs, for example I am writing a text file in a text editor and then I do alt-tab to switch to already running browser to google up something then I alt-tab again to come back to keep editing.
How do you perform such "switch between" programs in command line interface - for example working with a ssh command line shell?
EDIT: I forgot to mention it, I am using ssh to connect to my university's server, and they don't have screen & tmux installed, and my account have no right to install any new apps... Is there any built-in functionality to perform this task, or any work around? For exmaple can I "minimize" running proggram and come back to regular shell interface, do some work, then display the "minimized" process again?
Another workaround: use the shell's job control, eg if you're editing a file, CTRL-z pauses the editor and brings you back to the shell, where you can compile, see manpages, browse the web or whatever -- and of course you can background the browser or anything else.
Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.
As a crude workaround, run multiple terminal windows on your computer, and alt-tab between them.
Incidentally, at the Linux console, you can switch virtual terminals with ctrl+alt+F for at least F1 through F6, commonly F8 or more (depends on how the distro sets them up). Not your case, I know, but in case future visitors should benefit.
If you are comfortable in Emacs, it allows you to run multiple independent ansi-term buffers.
You can also use "GNU screen" to emulate multiple terminals in one terminal.
I am aware that the mousefocus option is only supposed to work in gVim. But I was wondering, if it's possible to have the console Vim switch to different windows in response to mouse clicks, would it be not possible to easily add following mouse movement to it, too?
I'm an xmonad user, I love the focus following the pointer feature, I do a lot of pdf viewing and browsing while writing in Vim, and I'd be so much happier if I didn't have to keep mentally switching back and forth between two different types of focus changing.
If that's completely not possible, I guess opening new Vim windows (as with :split) in new instances of the terminal is no easier to do?
It would not be at all simple to add this. Using the mouse within the terminal works by vim sending control codes to the terminal requesting that mouse actions be sent as part of the input stream. Terminals only report clicks not changes in the pointer position, so vim has no way of knowing where the mouse is.
With major changes it would likely be possible for a vim with X support to get pointer activity directly from the X server, but that would likely be reported by pixel rather than by character so further work would need to be done before it could determine which vim window is currently under the pointer.
set mouse=a
should do the trick but it will probably depend on your terminal emulator. See :help 'mouse'.
This works for Windows 7/Cygwin 32bit mintty/vim 7.3: (I DO NOT use gvim!)
Having installed this: http://ehiti.de/katmouse/, I can scroll the window under my cursor without having to have clicked to select a window, click-selecting of single vim-windows works, too. It does not pull the vim window to the foreground, if another window overlaps it, if that is what you desire. Still it can be scrolled without click-selecting it first.
So:
Check if there exists a software paket for your distribution, that implements your desired mouse behavior on the OS level. When this works for my self-compiled vim in cygwin, it might very well work with console vim on linux, too.
This post here serves as evidence, that it is possible at all, that is the reason this was not made a comment. When I am on linux again I will investigate this further and update this post, but that might take a while.
On set mouse=a: The vim help states you a need a terminal capable of handling mouse inputs, further information can be found here. :help ttymouse might also be helpful, i.e. if you have a xterm-compliant console, but :help term is set to something else.
UPDATE: (Freshly installed Fedora 19 with packages, no self-compiled stuff.)
Fedora 19 + se mouse=a = scrolling in single console vim window with several buffers opened next to each other independently works, too. Window manager used is LXDE.
I'm trying to use xdebug with vim on linux. I follow the instructions to install xdebug and after that I can see the information about xdebug if I call phpinfo() from a file inside the apache server.
After open a file in vim, it is supposed that when I press F5 it should show something like "waiting for a new connection on port 9000 for 10 seconds...", but it doesn't show anything..
Any idea?
I would recommend you look at a new vim debugger plugin, called vdebug: https://github.com/joonty/vdebug -- it is actively developed and seems very capable.
I had the same sort of problem, it turned out that my terminal emulator was capturing the keypress and not sending it to vim (I think). Remapping the functions to different keys solved the problem.
It could actually be his/her keyboard. If the keyboard has mult-media functions as well as F1-F12 on them... then there is, usually a "F-Lock" key next to the row of function keys that will turn on/off the function key behavior. Really annoying, IMHO, for the new keyboards sold these days.... and rarely does the keyboard have a light to indicate the ulterior operation of said function keys.
I say this cuz, that is exactly what happened to me just now.
The man page says vim -X disables clipboard and window title operation. Is that all we get for vim connecting to X?
I find it a bit surprising, since the default settings slow down vim's startup significantly for me, and I've never needed the clipboard/window title behavior.
This is not gvim, by the way.
My educated guess would be, that it's because most people nowadays use terminal emulators in graphical environments, so it would be useful to behave like nice citizen of such an environment, providing more of a consistency in how various applications look or work.
As a bonus it's more vim-like to use * register for interrogating clipboard.
And more foolproof. I remember graphical terminal emulators where the only way to select text was the old fashioned mouse selection. Given that vim buffer in terminal would not scroll when you selected part of the terminal (as technically selection occurred outside vim in the realm of terminal emulator, and vim was not even aware it's currently taking place) it would not be possible to copy to clipboard anything spanning more than screen could currently hold. And even then it might not work the way you'd want depending on line wrapping settings.
But that is not the problem if editor has connection to system clipboard. Just copy any text you like to * register in the vim-way, and then you have it in system clipboard.
It's still just my speculation.