I have been using MacVim for a while. It has always been the non-terminal version. Recently I started using tmux and I would like to be able to use vim inside a tmux session. Only when I started to tweak my settings, I realised that the terminal experience will not be as smooth as the standalone MacVim one.
I am not talking about speed issues etc, it is mostly things like key mappings behaving differently etc. I already gave up trying to get the Option (Alt) key working, but at least I would like to have things stable in general.
For example a key mapping such as that works perfectly in the non-terminal vim suddenly becomes , CTRL is no more a modifier? Discrepancies like that just make things extremely hard.
What are the most important configuration options that might improve MacVim's stability when running in the terminal?
In fact, the answer is in focusing on various aspects individually and finding solutions for those. The first major issue is with the way keys are interpreted by the terminal application. In most cases, the terminal emulator will not be able to distinguish between CTRL-F10 and F10. So in cases where F10 is performing action_A, SHIFT-F10 is performing action_B and CTRL-F10 is performing action_C, there will be a confusion between action_B and action_C if CTRL key code is not interpreted correctly. I now know that iTerm2 is capable of broadcasting specific ESC sequences to the running process. I will focus on those.
Related
This only occurs when I am using vim on Linux (it's Kali Linux to be precise, though I haven't tested it on other distributions). I am using a standard German keyboard layout.
Sometimes when I type in vim (it often happens when I exit insert mode or when I use :w, maybe only on one of these since I often do one after the other), the cursor randomly jumps elsewhere, usually about 100 lines upwards (I don't have an exact number). At the same time, the next number in the line my cursor was in is decremented.
I suspect that this happens because I hit some sequence of keys to quickly, since this, on my Linux distribution, can cause some special characters to be inserted due to one of the keys modifying the other. For example, if I type "yt" quickly with this keyboard, it becomes "yŧ" (with a second bar on the t)
This by itself is somewhat annoying to me so if someone knows a way to turn that off on Linux while still retaining the basic keyboard layout, this would solve my problem, but telling me the exact command I accidentally executed so I can avoid/remove it will also help.
As far as I can remember, this problem only occurred when I was editing .texfiles, but that is also what I have been using vim the most for recently, so I wouldn't assume that it only happens there.
Still, I can post my list of plugins and my .vimrc if necessary. Just in case it has something to do with only LaTeX files, the only vim plugin I have for that is vimtex.
The command you are looking for is mapped to control + x by default. It decrements the next number on the given line.
When I'm writing a program for use on the command line, I notice that there's some limitations. For instance, I can't draw a 1-pixel-thick horizontal or vertical line like tmux does when it separates panes in a window. I can only move the cursor down, not up like VI seemingly does. I can't refresh information on the top of the page if the cursor is at the bottom.
So, when programs like tmux and vi do this, I have to wonder if they are:
drawing the screen from top to bottom every update (which I think is highly unlikely because otherwise I could scroll up in my terminal and see each redraw)
using some library that enables graphics in the terminal, like SDL, which I also think is unlikely.
using some standard syscall I don't know about
or finally
taking advantage of some feature of Linux/Unix of which I'm completely unaware.
So, how do these programs generate such a rich UI in such a seemingly limited shell? So long as the answer gives me just enough fodder to go on a Google rampage, I'll be happy.
I'm also assuming that these programs use some common method to do these things, but if that's wrong let me know.
A typical terminal emulator has a lot more features than are immediately apparent.
Essentially a program just needs to output short sequences of bytes that represent various commands such as move cursor (up|down|left|right), change color, scroll region, erase region, etc.
These commands typically begin with the escape character (the same character that is generated when you press the esc key while typing in a terminal) followed by various other characters, depending on which action is desired.
A good starting point for understanding how it works would be the Wikipedia Article about ANSI escape codes
You can do it by hand by putting the terminal into raw mode and writing directly to the terminal using low-level operations but the standard way to do it is to use the ncurses library.
On linux, console applications have the ability to format their output. They can set font color, set background color and can place signs everywehre on the console. Using that it is, for example, possible to implement a tetris game right into the console.
I´m wondering how one can do that. I think they use a output markup language or something else. Can anyone tell me where I can learn more about this?
Thanks very much!
Most console applications involving a lot of motion or color are built using the ncurses library. Some very common examples would be irssi (IRC client), mc (Midnight Commander, the console file browser), mutt (POP3/IMAP mail client)
It seems like you are already aware of the escape codes used to modify console colors. A good list of console color escape sequences (for Bash) can be found here.
You obviously need to get a hold of those every-popular Unix video games, rogue, srogue, larn, hack, and/or nethack. They have a long and venerable history.
Notably, these all use the standard curses — or more recently, ncurses — library. Here’s a screen shot.
Since they have no joystick, motion is with vi commands. They are hands-down the very best way to hone your vi motion skills ever invented: no more two-finger typing for you! You stop thinking about motion; it just becomes a part of your fingers’ muscle memory. You really have to play them to get a feel for the awesome “Zen” state you can get into playing them:
After enough practice, it feels as though your fingers themselves remember how to play the piece. You don’t even watch them. They've a job to do, and once they’ve learned it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world, so that the program becomes the dominant reality, is what a musician would call “finger memory”. (You might have heard athletes or dancers refer to it as muscle memory, but when we’re talking about using the computer, it really is the fingers that count.)
[...] Of course, that's not really what’s going on; it only seems to be. Your fingers don’t really remember. But a part of your brain that controls them does, even though “you” don’t realize it. What’s happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you’ve trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. [...]
[...] There’s no question that, for certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn’t want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse‐and‐menu interface instead of a keyboard one would slow you down by at least two orders of magnitude.
The rogue family of video games are also notable for showing how to write a video game for a regular terminal like a vt100 or an xterm, which I believe is what you are looking for. I’d probably use a more modern language than C these days, but all the same principles still apply. Both Perl and Python have good interfaces to these standard libraries.
It's not so much a markup language as a series of escape sequences that trigger the terminal viewer to format in a certain way.
You can send ANSI escape sequences before your output to indicate that the following output should be a certain color, weight, background. You can also send sequences that jump the cursor to specific locations to continue writing output.
If you are going to do a full blown app you should consider using some library such as ncurses which makes these manageable.
I consider myself somewhat familiar with Vim,
hate the arrow keys (let alone the mouse),
regularly look up tips and plugins to get the most out of this tool,
use it daily to manage my cloud servers, etc.
However, I always find myself doing the same mistakes probably inherited from the GUI-world:
too often switching to visual mode to see what piece of code I'm about to manipulate,
undoing changes to retrieve lost statements because I forget to utilize registers (and pasting code on temporary lines just to grab it after other edits),
relying on Ctrl-C & Ctrl-V when working with operating system's clipboard,
keep pressing j button to browse through lengthy files to find certain functions.
Probably my Hungarian keyboard layout prevents me from being faster as most of the special characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
Given this specific situation, what pieces of advice could you give me? Have you faced similar bad habits when you were a Vim-novice? I'd like to see my productivity skyrocket (who wouldn't?). Thanks in advance.
I've found a simple, effective strategy. Choose one action, one task or one set of keys that you think is unnecessarily slow. Figure out a better way of doing this using the vim manual or googling or a plugin etc. Force yourself to use this every time. Rinse, and repeat. The path to efficiency is one-by-one elimination of the slow parts.
I'd also recommend just reading the vim manual from time to time - even if you don't remember everything, knowing something's out there is very helpful.
This probably applies well beyond vim, but
something that worked for me was finding a specific feature that I knew would
be more efficient and concentrate on using that for a week or two.
Just one feature at a time, and possibly using it excessively.
After a couple of weeks it becomes automatic and you can move on to the
next thing.
I learn programming tricks the same way. eg. I'll have a month of using lambda expressions for everything, then a month of mapping and filtering.
(not on production code though)
Probably my Hungarian keyboard layout prevents me from being faster as most of the special > characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
I'm sitting in front of german keyboards all day long and know this problem very well. Some keyboard layouts are simply not very suited for programming / using vim. I think its safe to assume that most programming languages and keyboard shortcuts were designed with the us-layout in mind.
My advice: reset your keyboard layout to us-english and practive touch-typing on that layout (typing without looking at the keys). It won't matter that the keyboard labels are wrong and you'll be much more comfortable using vim hotkeys.
The only problem that still remains for me is to produce language specific characters (german umlauts such as ä,ö,ü) wich i assume will also be a problem for hungarian. For that I use a combination of vim-digraphs, linux window manager digraph-key and windows layout-switching hotkeys.
just keep using it. The more you use it, the better you become at it. VIM isn't too bad. The main thing is you just have to remember that it isn't always in edit mode.
I've been aware of Steve Yegge's advice to swap Ctrl and Caps Lock for a while now, although I don't use Emacs. I've just tried swapping them over as an experiment and I'm finding it difficult to adjust. There are several shortcuts that are second nature to me now and I hadn't realised quite how ingrained they are in how I use the keyboard.
In particular, I keep going to the old Ctrl key for Ctrl+Z (undo), and for cut, copy & paste operations (Ctrl+ X, C and V). Experimenting with going from the home position to Ctrl+Z I don't know which finger to put on Z, as it feels awkward with either my ring, middle or index finger. Is this something I'll get used to the same way I've got used to the original position and I should just give it time or is this arrangement not suited to windows keyboard shortcuts.
I'd be interested to hear from people who have successfully made the transition as well as those who have tried it and move back, but particularly from people who were doing it on windows.
Will it lead to any improvement in my typing speed or comfort when typing.
Do you have any tips for finger positions or typing training to speed up the transition.
I actually don't swap control and caps and just make caps ANOTHER control key. I can't think of a single time in my life when I have ever hit caps-lock on purpose, so I haven't missed it.
That way, you get used to using it, but if you slip up and use the old control, things still work. It's worked out very well for me.
There's a .reg file to do this here.
I've done it for quite a while now, and it's natural to me, even though I'm not an Emacs user either (I'm in the Vim camp of that particular war :) ). In fact, it's so natural that moving to other machines (coworkers, family members, etc.) causes me grief because Ctrl isn't where it 'ought' to be.
For emacs ctrl should be at caps lock - for vim the escape key should be on the caps lock. I really feel that the caps lock button should be renamed "free parking" and OSes should make a system tray utility to quickly change the free parking button from escape, to control, to anything you need to type over and over again.
I ended up taking the advice in Zach's answer, but I also made Caps Lock behave as an ESC key if it was held and released on it's own using the AutoHotKey script in this gist: CapsLockCtrlEscape.ahk
I also bound Ctrl+Shift+Caps Lock to Caps Lock for the rare occasions when I might need it using this AutoHotKey script:
#IfWinActive
^+Capslock::Capslock ; make CTRL+SHIFT+Caps-Lock the Caps Lock toggle
return
I switched the Caps Lock and Ctrl keys a couple of months ago and after the initial learning period, ~ 1 week, my biggest problem is when I use a computer that hasn't switched the keys.
I first did some registry hack but I can't remember where I found the information on how to do it. Now I'm using a small utility called Remapkey which is included in the Windows Server 2003 Resource Kit Tools even though I think I'm using an older version.
I had no problem making the transition. I use keyboards with both configurations without issue. Perhaps having it as a hardware solution (and the labels properly printed) makes it easier than doing it through software and having to remember how each machine/keyboard is setup.
I think what's best to put on caps depends on your physical keyboard.
At home I type on a Kinesis Ergo Elan where my ctrl keys are under my thumbs, along with 2*alt, space, enter, backspace, delete, pgup, pgdn, home and end; the rest of the keyboard is fairly normally laid out, except the board is split.
With the ctrl keys ready at hand, it really makes the most sense to put escape on caps lock (and caps lock on esc, for the few times I need it). Even if you're an emacser, hey... it doubles as a spare "prefix alt key", and you probably ask your browser to stop what it's doing a few times every day.
On the other hand, if I'm typing on my laptop where the lower left corner key is Fn rather than ctrl (ffs...) and I can't hold down shift+ctrl with one finger, it might make sense to put ctrl on caps (such that I can hold them with a single finger). At least if you're not a vi'er, or you don't mind the escape key being further away (or have some crazy system).
What's really interesting is putting some funky key on shift+shift (yep, both shift keys). This can be done with xmodmap fairly straightforwardly; I put my compose key there. If you don't need compose, you may want to put something else (like, say, esc).
Copy the following code into a file called caps-ctrl-swap.reg, execute the file, agree to allow registry to be changed, log out and back in and your caps-lock and left-ctrl keys will be swapped. I've used this script for whatever version of Windows was current in 2005 and every version in between. I needed it today since Windows 10 updated overnight and it still works great.
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,1d,00,3a,00,3a,00,1d,00,00,00,00,00