The d{motion} command seems to work inconsistently:
d1j " deletes 2 lines to the bottom
d1l " deletes 1 character to the right
Is it expected behaviour?
When you start a motion and you are in operator pending mode, your motion will be either inclusive or exclusive, and either characterwise or linewise (linewise motions are always inclusive).
j is a linewise inclusive motion. Probably you want to try dvj or dgj (the latter one works with screen lines).
See :help operator. You can force motions to be linewise, characterwise or blockwise with V, v or CTRL-V respectively.
It is not actually inconsistent. I guess you were looking for
delete one line: dd (which is a command)
delete one line down: d1j (or short dj). This is an operator with a motion)
The remaining surprising bits are due to vim's notion of linewise, blockwise and characterwise motions, which are really just abstractions to allow Vim to Do The Right Thing or Do What You Expect when operating on selections.
Like #Benoit said, d is operator that takes a motion.
2j being linewise, it will move two lines down, covering 3 lines.
Note how, if you would like some visual clues with that, you can set the rn option
:se relativenumber
This will cause relative linenumbering to be shown in the left 'gutter' of the editor. These numbers can be used as 'addresses' and do what you expect when you do 'd12j' or 'd12k'
I recommend getting acquainted with the text object motions before getting used to this, by the way. Many times, text objects are much more precise (and often work in character mode, only degrading to linewise selections in appropriate conditions)
Related
In vim, I've always been curious why pressing the esc key causes the cursor to go back by one character (usually). For example if I've typed:
This is |
With the cursor being the |, after I have finished typing and press esc, the line will look like:
This is|
And to re-type from where I left off I would have to press a instead of i. Why is this the expected behavior in vim?
I found the following answer in this question on the Unix & Linux Stack Exchange:
In insert mode, the cursor is between characters, or before the first
or after the last character. In normal mode, the cursor is over a
character (newlines are not characters for this purpose). This is
somewhat unusual: most editors always put the cursor between
characters, and have most commands act on the character after (not,
strictly speaking, under) the cursor. This is perhaps partly due to
the fact that before GUIs, text terminals always showed the cursor
on a character (underline or block, perhaps blinking). This
abstraction fails in insert mode because that requires one more
position (posts vs fences).
Switching between modes has to move the cursor by a half-character, so
to speak. The i command moves left, to put the cursor before the
character it was over. The a command moves right. Going out of
insert mode (by pressing Esc) moves the cursor left if
possible (if it's at the beginning of the line, it's moved right
instead).
I suppose the Esc behavior sort of makes sense. Often,
you're typing at the end of the line, and there Esc can
only go left. So the general behavior is the most common behavior.
Think of the character under the cursor as the last interesting
character, and of the insert command as a. You can repeat
a Esc without moving the cursor, except that
you'll be bumped one position right if you start at the beginning of a
non-empty line.
Credits to the original author.
If you would like to edit this behavior, you could follow the advice from #ib. in this answer:
Although I would not recommend changing the default cursor mechanics,
one way of achieving the behavior in question is to use the following
Insert-mode mapping.
:inoremap `^
Here the Esc key is overloaded in Insert mode to
additionally run the `^ command which moves the cursor to the
position where it had been the last time Insert mode was left. Since
in this mapping it is executed immediately after leaving Insert mode
with Esc, the cursor is left one character to the right as
compared to its position with default behavior.
Unlike some other workarounds, this one does not require Vim to be
compiled with the +ex_extra feature.
When programming/writing I heavily use word-wise commands, for example "move to the left/right by one word", "delete next/last word" by pressing Ctrl (+left,backspace...).
The problem I have is, when the text I am editing contains symbols which will not be recognized as words, therefore ctrl + right will jump over a sequence of symbols AND a regular word after that.
Ideally I want to be able to set the delimiting characters for word-wise operations to space, tab, newline and opening and closing brackets - maybe also arithmetic operators (similar to how Eclipse handles it).
I am using Linux. Do you know any way how to change my settings system-wide or alternatively for xterm and (g)vim individually to achieve this?
Most likely, system-wide won't work. VIM is easy, you can set the characters that define the identifier using the iskeyword setting. In your case, there is too much in it, and you need to remove the ones you do need, or redefine it by adding the ones you do want. eg: :set isk=9,32,50-51
This will set keyword detection to spaces, tabs and parentheses.
However, in VIM you can jump based on word and WORDs, where the first is defined by the abovementioned iskeyword setting, while the latter will jump over all non-blank characters. Maybe, that's the motion you want. You can read more about this in the help (:help w).
Instead of holding down the control key and pressing the left/right cursor keys, why not use Vim's normal mode word motion commands?
w/W - move to start of next word/WORD
e/E - move to end of next word/WORD
b/B - move to beginning of previous word/WORD
ge/gE - move to end of previous word/WORD
You can read up on the difference between a word and a WORD by running :help word.
I've used the Windows version of Vim in the past, but am
new to MacVim. In MacVim, when I switch to visual mode, use the $
motion (highlighting from my cursor to the end of the line), and yank,
when I paste the copied content, it includes the carriage return,
bumping everything after the paste point down to a new line.
This behavior seemed unfamiliar (not to mention annoying) to me. Is there any way to change this behavior to match the Windows version, where the newline is not included in the yank?
Is just copying the text until the end of the line inappropriate? y$ will just copy from your current cursor until the end of the line, without the newline.
There's a little-known motion that serves this need regardless of configuring Windows behaviors and can generally be useful in other contexts: g_. Quoth :help g_:
g_ To the last non-blank character of the line and
[count - 1] lines downward |inclusive|. {not in Vi}
Personally I don't tend to use this for yanking because I avoid the extra visual mode keystroke and use y$ (which doesn't copy the newline, as #zigdon suggested). Or better yet, nnoremap Y y$ so that Y works consistently with C and D.
I do however often use g_ with surround.vim where the mappings to add surrounds are often harder to remember for me than using visual selection. If you want to select until the end of the line and surround with parens, for instance, it would be ys$), which isn't bad but I tend to forget the ys mnemonic. v$S) seems natural but has the same problem as your question: it includes the newline, and that's a total mess when adding surrounds. vg_S) is exactly what you usually want.
One nice thing about doing it visually is that you can correct mid-selection: I still tend to hit v$ by muscle memory a lot, but if you see that you've overshot before acting, you can still hit g_ and fix the selection.
You may try Du. Effectively it does exactly what you want and it is more finger-friendly if you intend to use it in raw editing.
I discovered that the option that was causing the behavior I'm used to seeing is behave mswin, which I believe is on by default in GVim for Windows.
Using macvim, when I copy a text selection, it always includes the character under the cursor.
For example, if the cursor is at the far left and I press shift-down arrow, it selects the entire line plus the first character of the next line (since the cursor is sitting over the next line's first character).
Is there a way to configure macvim to not include the cursor character in text selections?
Take a look at the selection option. By default it's set to inclusive, but you can change it to exclusive to make text selections act the way you want:
:set selection=exclusive
You can also set it to exclusive with the behave command:
:behave mswin
This also sets several other options, however, which may or may not be what you want. See the Vim help for the specifics.
:help :behave
:help 'selection'
I am guessing that shift-down arrow activates visual character mode, and moves the cursor down a line. If you are trying to select entire lines, you would be better off using visual line mode, which is activated from normal mode by pressing V (shift-v). This will select the current line in its entirety. You can then extend your selection to include the lines above and below using the k (or up arrow) and j (or down arrow) keys.
When using Vim, I think it is better to go with the grain rather than to fight against it. Don't expect it to work the same way as other text editors. Accept that the Vim way is different.
I use MacVim (and gvim) a lot. I'm familiar with and use a lot of the basic movement commands (b, w, $, 0, G). However, for a lot of things—such as selecting particular lines on the screen or jumping to a particular column in a different line—I use the mouse (sometimes in concert with my left hand on the keyboard). It also helps that my mouse has a scroll wheel and buttons for changing tabs.
I also need to admit... I use the arrow keys on my keyboard rather than hjkl.
I think that my speed (and posture at the computer) will be improved by not having to escape from insert mode, and from keeping both hands on the main part of the keyboard.
What convinced you to abandon the mouse? What are the most helpful shortcuts for moving quickly between lines and columns, scrolling, etc.?
This question is inspired by this recent post
I think that my speed (and posture at
the computer) will be improved by not
having to escape from insert mode
No, you must escape from insert mode right after you typed what you want. It quickly becomes a reflex, so you don't really lose time (I sometimes even press escape after completing a web form...). Normal mode isn't just for moving around, it's used to perform most operations (save from typing): for instance deleting or moving sections of text. You also benefit from entering insert mode with the appropriate key: o to start a line, S to replace a line (while keeping indentation), A to move to the end of the line, c+motion to replace a few words or until a given character... All of these save keystrokes.
The mouse seems fast, but in reality it isn't precise, so you lose time (in addition to the constant back and forth with the keyboard). ViM has a long list of moving commands (see :help usr_03) which, when mastered, are faster than the mouse in most situations.
Use search the most you can (/, ?, *, #, f, t...). I personally use Ctrl+(d,u,f,b) a lot. Also, Ctrl+(o, i) and `` are really useful to go back where you were before a search or something else.
h, j, k, l are there to place your right hand near to useful commands (i, u, o...): I always have my fingers on them. The arrows force you to move your hand a lot.
Try to look at a few commands in :help, then use them a lot, and you'll get habits about what you should use to move according to the situation. Nobody uses ViM the same way.
The more I used the keyboard movement in vim, the less I wanted to use the mouse. It doesn't help that extended periods of time where I'm constantly moving from keyboard to mouse can take a toll on my wrist.
If you want to force doing things the vim way, unplug your mouse for a while! The more you use the keyboard, the more you will love it. This worked for me.
For moving between lines, I usually just use jk but I often skip to lines using :line_num. Getting to a specific column in a line, I typically use wbe^0$ and put modifiers in front of w, b, or e if I'm skipping through several words. And there is also the shifted versions, WBE which also come in handy often.
I have to admit that I often use the arrow keys for specific movement in vim.
I rarely use hjkl. However, I find that most of my navigation is done with other commands such as w (skip a word forward), b (skip a word backwards). Combine this with modifiers such as 3w (3 words forward). : skip to a specific line.
I've never really had to abandon the mouse since I never really started with it. All I can say is that attempting to use editors without all the keyboard shortcuts that vim has can feel quite painful.
I'd run vimtutor from the command line (Terminal.app in OS X). It runs vim with a tutorial document. That document was what really made me realize the power of some of the commands. You'll pick up some that are most useful to you and gain more over time. Eventually you'll find yourself using the mouse less and less.
One command that will really improve your movement speeds is f. f plus a character will jump to the first occurrence of that character on the current line. Pressing ; will jump to the next occurrence. Of course this can be used in combination with other commands. So, for example, removing all characters up to and including the first closing parenthesis is achieved by pressing d+f+).
You can seriously revolve your life around jk in hjkl.
nnoremap <c-k> ddkP "move current line up one
nnoremap <c-j> ddp "move current line down one
vnoremap <c-j> dp'[V'] "move visual block down one
vnoremap <c-k> dkP'[V'] "move visual block up one
"These may be a bit more esoteric to me"
inoremap jj <esc>o "Insert mode can move to next line (works mid line)
inoremap kk <esc>O "Insert mode new line on previous line
also for the desktop gui (ion3 and gnome)
winj - next window
wink - prev window
(This beats alttab if your editing in vim all day)
also read :he motion.txt in its entirety using j and k to scroll up and down as you do.
I learned vi so for me the mouse has never been something to use with a text editor.
I don't use hjkl except when the machine/network/keyboard/whatever-in-between is not comfortably configured.
Use the mouse where it makes sense. It often does (copy/paste to and from other gui applications).
To answer your question, though: Once you start using vim as a tool for transforming text bits with macros, the movements will all start to fall into place ;)
I think you're wondering if there's a quick way to move around while in insert mode (without using the mouse or arrow keys) but unfortunately there isn't; you have to escape out of insert mode. However I know that jumping all the way to your Esc key can be really annoying, which is why I've gotten into the habit of escaping with Ctrl+c, it's much faster.
I almost never use hjkl because it's too tedious. I usually try to jump right to where I want to go. There's a great cheat sheet out there (a Dvorak version is a available also (although it's in PDF)) that you can stare at and imagine the possibilities.
Mostly I use f, F, t, and T, and sometimes they're enhanced by typing a number up front like d2t) will delete up to the second close paren. Sometimes I use search. A lot of the time I use w, W, b, B, e, and E. They're all fantastic.
When I see vim users arrowing all over the place in visual mode just to delete text it makes me shudder, because there are so much easier ways (and hjkl only make you move your arm less, they don't change the number of button presses).
Something I did that I don't know if it's common or not is remapped my arrow keys to be <Esc><Up> and so on. For whatever reason I started out always arrowing around and assuming I'd be back in normal mode, so I just made it do that...
The biggest bummer about Vim is that now when I edit anything anywhere else I hit escape all of the time and type :w after every change...