I'd like to be able to map the vim commands :tabnext and :tabprev to CTRL+TAB and CTRL+SHIFT+TAB respectively. Unfortunately, I seem to be running into the problem where PuTTY eats these character combinations.
I've tried searching for information, but to no avail. I'm pretty sure this is a PuTTY thing but there doesn't seem to be any sort of help/reference area for the application.
I am curious if anyone here has any experience or suggestions for figuring this out.
#rmeador: try mapping the key combo within vim.
I have attempted to do this, but it doesn't appear like vim is getting the combo. I'm not certain if this is related to the term settings or an issue with PuTTY.
PuTTY doesn't send anything when you press Ctrl+Tab.
You can patch PuTTY as it is described here: Using Ctrl+Tab in GNU Screen over PuTTY
I believe that at this time, using Ctrl+Tab is not possible with PuTTY, because PuTTY does not allow you to configure specific translations for keys. Here is a decent article that shows how you would set this up if PuTTY did support this feature:
http://www.staldal.nu/tech/2009/01/10/how-to-use-ctrl-tab-in-gnu-screen/
If you use (or would consider using) a hotkey/macro program like Autohotkey, you could emulate this behavior yourself. For example, this Autohotkey config script would do exactly what you want:
#IfWinActive PuTTY
^Tab::Send :tabnext
^+Tab::Send :tabprev
#IfWinActive
(Note that this example is just looking for any window title starting with PuTTY, so you'd have to adjust based on your title configuration.)
Related
I have several cpp source files in tabs in vim. I would like to have another tab with command prompt in order to run make. I open net tab , run sh and now I have console. But how to move from this console to other tabs? If I press ctrl+page up I have garbage in console and no tab change. How to move to another text tab when staying in console tab?
As I said, vim 8 or neovim both have an terminal emulator in it.
Since you are using vim 7 here are some other ways:
Tmux as #wizzup mentioned is perfect for this use-case. I think it is the most used Terminal-Multiplexer and extremly mighty. It is complex in comparison but since you are using vim, a steep learning curve should not be a killer point. However there are a few cavehats but you will find thousands of articles to solve them.
GNU Screen is an alternative to tmux, I have no experience with it, but should be usable pretty good with vim too.
With them you can use something like this Plugin which allows you to use the terminal in vim itself. However I haven't tested it but it seems to be rather groomed.
everyone.
I use PuTTY and I am wondering if it's possible to open an emacs text file in split screen with the terminal window.
I looked everywhere for the answer, but all I've found is how to have two emacs windows open, and I would like to be able to see and switch between the terminal window and an emacs file.
Thanks.
You could use the region feature in screen rather than using the split screen within emacs... but then you might want to rebind the escape key in screen.
I made a text editor and I want to port it to Linux such that I can use it remotely via SSH. I don't know much about Linux terminals, so maybe I'm missing something obvious, because I just can't believe that in 2013 there's still no way for a remote terminal to distinguish between Ctrl+M and Enter, or between Ctrl+H and Backspace, or even get any events at all for Ctrl+Left/Right/Up/Down, and so on. I tried ncurses and libtermkey to no avail. The question is, is there any effort or discussion in the Linux community on modernizing or replacing the linux terminal protocol(s) to something that supports full keyboard and mouse interaction and possibly full color, i.e. something that would allow for text user-interfaces without huge usability compromises?
As far as I know, the Linux console terminal just doesn't support this, full stop. If you want to try raising a patch, you could have a go at implementing the full CSI-encoded reporting scheme. It is documented here.
libtermkey will recognise the key sequences if sent, but the fix has to go into the terminal first of all to send them in the first place.
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.