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.
Related
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.
I recently migrated to Vim.
But I am having diffuculty making use of "hjkl" keys for navigating because of my existing muscle memory of arrow keys.
1. Is there a way to effectively use other keys like "ijkl" ( near
to Arrow key layout ) without causing much conflict to other
functionality in VIM
, For ex: http://vim.wikia.com/wiki/Use_ijkl_to_move_the_cursor_and_h_to_insert
and http://ergoemacs.org/misc/on_vi_keybinding.html
2. Is it worth the efforts to retrain the muscle memory with "hjkl" ? But the problem is, I have to use arrow keys again with
Web-Browser, Outlook, and word processors ( So,the shift is causing the conflict) .
Can you suggest ( More interested to know about #2) , How did you deal with this ?
I have been using Vim for five years (after many more years of computer usage) without ever doing any conscious or unconscious effort to use HJKL for navigation.
I don't touch-type so the "home row" means nothing to me.
Even if I did, jkl; would make a lot more sense anyway.
I hit the arrows with the side of my right hand so there's not much cost in "reaching for the arrows" for me.
hjkl are just as bad as the arrows because both only move character-by-character and line-by-line unless you use modifiers (numbers for hjkl and Ctrl/Shift/Alt/Cmd for the arrows). Vim has vastly better means of transportation than either hjkl or the arrows and that's what you should spend time learning:
wW jump to next word/WORD
bB jump to beginning of word/WORD
eE jump to end of word/WORD
fx jump to next x on the line
tx jump to character just before next x on the line
Fx jump to previous x on the line
Tx jump to character just before previous x on the line
/foo<CR> jump to next foo
?bar<CR> jump to previous bar
} jump to next blank line
and so on… :h navigation will blow your mind.
So my answer is: don't bother forcing yourself to use hjkl, it's not worth the hassle.
It's a good idea to train your hand for hjkl. You could try playing rogue for a while on a daily basis until it's comfortable. It comes pretty quick.
Arrows are awful for taking your hand so far out of position. Even <Enter> is too far. I usually get away with Ctrl-J instead (a comfortable Ctrl is really important too!).
Using custom overrides for hjkl will only "help" your vim, but not other vim-like tools. In vim, remapping i will cause other issues, like what to use instead of i/I, which are very common. And you might not want to take over ; for this since right-pinky is prime real estate which I (and I think many others) map to the very frequent : (at the OS level so as not to ever be confused).
Learning hjkl will also help when you're in other places: You probably want to start using vi-mode in bash (or hopefully zsh). Gmail/mutt will be more natural. REPLs with readline support also support vi-mode. Maybe you'll do less word processing if you can replace it with text editing in vim.
Sometimes it's useful to remap things, but it's rare and often to more obscure keys/sequences. It can cause problems when you work in multiple environments, and can make sharing/pairing difficult. It can break macros and other mappings, and make recipes and articles harder to interpret. Try learning the vim-native ways first, and then deviate with experience when really justified.
Here on the video you can see a feature of jumping between found patterns. The algorithm is really different from vim default behavior.
Using vim you can find some pattern /pattern<CR> and jump to next n or to previous N. The disadvantage is: you should jump many-many-many times to get to proper position or write long pattern to reduce hits amount. Yes, you can apply something like 10n to jump over next 10 hits but it is also inconvenient because you can not count large amount of hits at first glance.
In the video you see a better approach: text editor gives a short name to each hit so you can jump in two or three keystrokes.
I do not believe that nobody implemented the feature as a vim plugin but I failed to find something relative. Is it such plugin anywhere? May be something even better is implemented?
Haha.
The very first implementation of that idea was AFAIK a Vim plugin (PreciseJump), with the second implementation being another Vim plugin (EasyMotion) that got a lot more traction than the first and itself spawned many other implementations in many other contexts (editors, browsers…).
This is possibly not a good question for SO, but it's been bugging me for years, and Google didn't know, so let's give it a shot, as it does affect my programming work on weekly basis:
I often find myself in situation where one char is missing, like "=" instead of "==", a missing space, surrounding something with quotes/brackets, etc.
So, why doesn't vim have a proper command to insert a single character? By proper I mean, supports count and repeating with ..
What is the rationale, and what is the correct usage pattern that I am missing, which makes this feature unnecessary? I seem to need the all the time, so there must be some reason it has not been added to original vi already.
I know adding a simple basic keybinding like :nmap <Space> i_<Esc>r is easy enough, but when doing just a quick edit in a new environment, that's rather inconvenient, and this simple version does not work quite properly anyway.
PS. If there in fact is a default binding to insert just one char with total two keystrokes and remain in command mode, similar to r to replace one char with two keystrokes, I promise a bounty of 100 to the first answer which tells me what it is.
To me, i <Char> Esc (3 keystrokes without modifier keys) is pretty short and built-in. You've already discovered custom mappings that reduce that to two keystrokes; I also started with yours and over time made it more advanced to suit my needs, and added mapping variants to insert a single space at or after the cursor position.
Presumably, there's no built-in command because the key space (especially for single unshifted keys) is very limited, this one doesn't justify such prime space, and any multi-key alternative (like the Vim ones that start with g) would be worthless in terms of efficiency.
No. There's no default keybinding for that (do :viusage for a complete list of normal mode commands).
If you want to know why, you'll have to ask Bram Moolenaar or Bill Joy, I'm afraid.
But here is an idea: r and s work on the character under the cursor. What they do is fairly limited and one dimensional but how would your command work?
Would it work like i, inserting that single character before the current character or would it work like a, inserting that single character after the current character?
Because "inserting text" can happen before or after the current character, we have i and a and, rather obviously, we need two commands for quickly inserting a single character.
Which makes the problem a little more complicated.
What keys should we use since all the alphabetical keys are already taken? <C-something>? <C-i> is taken, and <C-a> is also taken. <C-S-i> and <C-S-a> are both non-practical and not guaranteed to work everywhere so what? <M-something>? It won't work everywhere as well. Maybe a two-characters mapping? But which one and following what mnemonic logic?
I also struggled with this question and I found somewhere on the internet (I can't remember where) someone who did this:
:nnoremap s :exec "normal i".nr2char(getchar())."\e"<CR>
It is not perfect because it doesn't support count but it can be repeated with . I use that now so maybe other users will be satisfied with that too.
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.