I've used vi for decades, and am now practicing using vim, expecting
eventually to switch to it entirely.
I have a number of questions, but I'll start with the one that
troubles me most. Something I have long done in vi is to type
a bottom-line command into the file I am editing, yank it to a named buffer
(e.g., using the keystrokes "ayy) and execute that buffer (using
:#a^M). This allows me to edit complicated commands till they
work right, and to keep commands that I will use many times as I
work in a file. (I have
in my .exrc file a mapping that reduces this yank-and-execute to a
single keystroke; but that isn't relevant to my question.)
I find that in vim, I need a lot more ^Vs than in vi. This
means, on the one hand, that when I have some command-line in a file
that I expect to use this way, I now need to keep it in two
versions, one for vi and one for vim. Also, the requirement of the
extra ^Vs seems inelegant: evidently various special characters
that are interpreted once when the named buffer is executed in vi
are interpreted twice when its is executed in vim -- but why?
As an example, a command of the form
map =f :w^V|e foo^M
(mapping the keystroke-sequence =f to write the current file
and go to the file foo) works this way in vi, but has to have the form
map =f :w^V^V|e foo^V^M
in vim. (Here in both commands, ^V is gotten by typing ^V^V,
and ^M is gotten by typing ^V^M; so typing the first version
involves typing three ^Vs, and the second, seven.) To be
exact: the first version does work in vim if one actually
types it into the bottom line (with the indicated extra ^Vs);
but the latter is required in an executed named buffer.
Any explanation? Anything I can set to fix this? ("compatible"
doesn't seem to do it.) Any hope that it will be fixed in a future
release? (The system I am on uses version 7.0.)
(I should confess that I'm not a programmer; just a user who has
become proficient in vi.)
Personally, I'd stop using ^V completely. In Vim (I've no idea about Vi), there are various key notations that get round the problems you're having. For your specific example, I'd recommend:
map =f :w<bar>e foo<CR>
where <bar> means 'insert the vertical bar here' and <CR> means 'insert a carriage return here'. See:
:help key-notation
for more information. I find the <CR> much easier to understand than ^V^M.
That's an interesting way of using :#, which I hadn't thought of before. I generally just use the command line history when I need to edit complicated commands, and I tend to save common or complicated commands as mappings or commands in my .vimrc (of course, I have a mapping that will pop open my .vimrc in a new tab). But there are certainly benefits to using vim's normal mode rather than command line mode for editing a complicated command.
As I understand it, you not only want to avoid so many <C-V> characters, you would also like to be able to use the same commands in vim and vi. Unfortunately, that would preclude you from using the (preferred in vim) key-notation. I think that you should be able to use the cmdline mode's Ctrl-R Ctrl-R register to help you out (:help c_<C-R>_<C-R>). E.g.
map <Leader>e mm^"ay$`m:<C-R><C-R>a<CR>
mm - mark cursor location so we can return later
^"ay$ - yank current line into register a (ignoring whitespace at beginning and newline at end)
``m` - return cursor to start position
: - enter command line mode
<C-R><C-R>a - place the literal contents of register a onto the command line, which seems to be where your problem with vim versus vi was coming to into play. I think that <C-R>a would give you the same behaviour you are seeing now with :#a.
- execute the whole thing
Using that mapping, I then typed your example of map =f :w^V|e foo^M into a file, placed my cursor on that line, ran my <Leader>e mapping, verified that your =f mapping had loaded correctly, and then ran it. Obviously you'll want to customize it to fit your needs, but I think that playing around with <C-R><C-R> will basically get you what you want.
All of that said, if you can, I'd strongly recommend taking the plunge and forgetting about compatibility with vi. Then you can use the much simpler key-notation and a host of other vim features. :-)
Related
I went to open a log file in vim, but was warned that a swap file had been found. One of the warnings suggested that I might want to open the file using vim -r filename.log. I did that, but now when I 'vim' around in a file, I have to type "GG" (instead of "G") to get it to take me to the end, and "gg" (instead of "g") to get it to take me to the beginning. And when I use j and k to move up / down one line, it highlights part of the line (see blue and green cursors in screenshot below) whereas before there was no highlight. Any clues what could be going on?
Thanks!
I have to type "GG" (instead of "G") to get it to take me to the end,
That's odd... Is it possible that the first G is being consumed by a pending keystroke? For example, if you type gG, that's an invalid command and gets ignored. So you'd need gGG to actually go to the end of the file, since the first G gets ignored... Is it possible that this is what's happening?
Otherwise, is it possible that you have a mapping for G or something using G as a prefix? Does :map G show any mappings defined?
and "gg" (instead of "g") to get it to take me to the beginning.
This is normal. gg is the command in Vim (and in the original vi too) to go to the top of the file.
Are you perhaps thinking of less which goes to the top with a single g?
And when I use j and k to move up / down one line, it highlights part of the line (see blue and green cursors in screenshot below)
This is the effect of the matchit plug-in, which is shipped with Vim (on recent versions of Vim, but I believe it's been shipped with Vim for quite some time.) It's enabled by default, loaded as part of startup.
The matchit plug-in will highlight a matching paren, brace or bracket whenever you have the cursor on its pair. So since you have the cursor on a [, Vim will highlight the corresponding ].
whereas before there was no highlight. Any clues what could be going on?
You might not have noticed the effect of matchit even if it was enabled, since it only gets triggered when your cursor is on top of a bracket. Perhaps this log file is different in that all lines begin with a bracket and that's why it was so salient?
Or you might have different versions or flavors of Vim in your machine and some of them will not load matchit (perhaps you have a "minimal" Vim that doesn't support plug-ins?) Perhaps you have commands vim, vi, view and some of them will load a different version of Vim that behaves differently. In most cases, you tend to use that other version, but this time since you got a message regarding recovering the file and using vim -r explicitly, you ended up using this particular version that does load it?
You can use the :version command to check which version of Vim you're using and which features are available. (In particular, look for "minimal", or check whether the +eval is enabled, if it's listed as -eval it means support for external plug-in files will be for the most part disabled.)
You can also check :scriptnames to see the list of script files loaded by Vim, you can check whether matchit.vim is included in that list.
Relatively new to VIM and having a great time using it.
One very minor annoyance I've been having is command mode character navigation when I want to revise a command. I'm used to using readline shortcuts on the regular (non-vim) command line but these shortcuts don't seem to work in : command mode.
For example, using ctrl + b to go back a character ends up sending me to the start of the line, or using alt + f to go forward a word ends up clearing the line and exiting command mode.
The only way I've found to navigate in command mode is to use the arrow keys, but I'm under the impression you should avoid the arrow keys in vim for max efficiency.
What is the standard way to navigate around in : command mode? Do vim users usually use the arrow keys here? Is there a different way to modify commands?
As a more concrete example, I've been using vimgrep a lot to search through files. I'll do a command like:
:vimgrep /font-family/j my-project/**/*.less | cope
Later, I'll want to use the same search but look for a different property, so I hit : then ctrl + p to access my previous vimgrep. Now here I have to use the arrow keys to navigate backwards to the search string and modify it. It would be much faster if I could use readline to navigate backwards by word then delete by word.
For small edits, Backspace and light use of the cursor keys should be fine. For anything larger, I would advise to use the command-line window:
In the command-line window the command line can be edited just like editing
text in any window.
So, there's no need to mentally switch to readline key mappings; just use the full editing power (including any custom mappings) of Vim!
You can switch via <C-F> from the command-line, or directly enter it (from normal mode) by pressing q: instead of :. All the details can be found at :help cmdline-window.
I like this question. Long time vim user, but new-ish here, so I can't vote it up. But indeed, perhaps unofficially, many vim fans feel that most of the time the goal is to not have your hands leave home row position (fingers move, hands relatively still).
I will admit, when it comes to command mode, I use the arrows. With P being on my pinky finger, I would miss-hit ctrl-P a lot, and it's faster to slide my right hand down (on my Natural keyboard) and find the up-arrow by quick feel, instantly, to do the same thing. Once I'm there, left-right arrows are also easy to find without looking or delay. Also Ctrl-arrows let you skip by word.
One of the great things about vim is the :help. I have easily spent tens of hours over the years reading through it, and it solves 95% of my problems if I have enough time and working-memory to push deep enough into it.
Here is what I found for :help readline:
READLINE readline.vim ft-readline-syntax
The readline library is primarily used by the BASH shell, which adds
quite a few commands and options to the ones already available. To
highlight these items as well you can add the following to your
|vimrc| or just type it in the command line before loading a file with
the readline syntax:
let readline_has_bash = 1
This will add highlighting for the commands that BASH (version 2.05a
and later, and part earlier) adds.
Give it a try! (I am using vim 7.4)
You can see a list of the default key binds with :help cmdline-history (scroll down a bit) and :help ex-edit-index.
You can remap this with cnoremap:
cnoremap <C-b> <Left>
cnoremap <C-a> <C-b>
" .. Probably more
Note that using cmap will probably get you into problems here since the right-hand side is the currently mapped action, whereas with cnoremap the right-hand side it will always use the native Vim action.
I am looking for a way to use f followed by some character to jump to the next uppercase letter.
I ran across this question and want to use the accepted answer, since that did not appear to have any dependencies.
However, after I added the lines into my .vimrc, I cannot figure out how to actually jump to the next uppercase character.
I tried Ctrl-Right and Ctrl-o, and both orderings of them, but I could not jump to the next uppercase letter in the line. I also read the actual vim tip, but that also does not explain how to actually use the commands.
What is the correct sequence of commands, and in which mode, to actually jump to the next uppercase letter?
Does it have to be the find command? What about typing /[A-Z]? It'll find the next upper case character (even if it's on a different line), and it's fast to type. Pressing n will take you to the next one without retyping the command again.
What you found in the other answer was a macro command. VIM has a rich macro language that allows you to define functions. You can run a function by typing a colon and then its name.
Of course, typing :findNextCapitalCharacter is a bit long to type. You can use map to define a key macro that will basically type the letters for you to find the next command. I like prefixing my mapped macros with some character like %, so typing %c will find the next capital character.
Further Explanation
I'm currently just doing /\u, but I still want to know how to use the macro in that answer for my own learning. In the case of those macros, what is the actual means to invoke the macro command?
You're way ahead of me! I didn't know about \u being uppercase.
Looking at the answer, I see they're not defining a macro, but doing key mapping. Here's a quick intro:
In command mode (that's where you can't type in anything into your file, but where you can use commands), type in :map #$ iHello World and press return. Now, still in command mode, type #$. You'll see that VIM typed iHello World for you. The i put VIM into insert mode, so it could type in Hello World That's mapping!
In VIM, you have special map modes depending on the mode you're in. In the original VI, you had two modes: Command and Insert. In VIM, you have Command, Select, Visual, and Command-Pending modes. The different map command depend upon the mode. Type :help mapmode into VIM and press <RETURN> to see about the various map modes and their VIM commands. This will be VIM help manual sections 1.3 to 1.5. Read it thoroughly to understand what the different map command mean.
What the accepted answer is doing is entering the maps three different times, once for each mode. There are two different maps (one search to the previous and one search to the next), so six all together.
The accepted answer is mapping Cntrl-Left Arrow <C-left> and Cntrl-Right Arrow <C-Right> to each of these mappings. Much like I mapped #$ to Hello World.
Setting g:camelcase is setting a global variable called camelcase to a string. If the string is A-Z, it will be for just capital letters. If it's A-Z0-9, it's for capital letters and numbers. You should only define one instance of this variable.
I think you're problem is that you're typing in <C-Left> for the map. What you're suppose to type is ^V^-> where ^V is Ctrl-V and ^-> is Ctrl-Left Arrow. When you type that in, the map command will change those into <C-Left>.
I'm working on a paper using LaTex, and my preferred text editor is Vim. When using the LaTeX plugin from https://github.com/gerw/vim-latex-suite gives me just about everything I need when working with LaTeX.
Sadly there is one thing about the Suite that is driving me nuts. I have a habit when type braces (or quotes) to start by typing the pair (for example \text{}|) and then pressing <esc>i to place my cursor in between them \text{|}. Somewhere in the LaTeX suite there is some script or macro that automatically puts the cursor in between when I type the pair. After my muscle memory that usually leaves me with the cursor infront of the pair \text|{}.
How do I disable this 'feature'?
If I understand correctly (see my comment) you'll need to comment (or remove) from main.vim:
call IMAP ('{}','{<++>}<++>',"tex")
or change
call IMAP ('{}','{}<++>',"tex")
or you can call the line above from ~/.vimrc (or texrc or similar) - in this case the latexsuite's definition will override.
Let's see if I can explain myself.
I use vi-mode in bash, which is really great since I'm used to Vi.
When I'm inside vim and type : (to go to ex mode), since I'm used to the vi-mode from bash, I feel the slowliness of having to use this mode like the "regular" way of using bash.
Question is: is there a way of using vim's ex-mode like bash's (or readline) vi-mode?
Not sure if I understand what you're trying to do, but it might be something like hitting q: in normal mode?
For users that use Vim or vi bindings almost everywhere, including on their shell command line, it really hurts when you leave that environment. If you're used to the vi bindings hyperdrive, going back to chords for skipping words and other manoeuvres is painful and slow. Operating systems also differ on their default bindings so Mac, for instance, supports option-arrow instead of control-arrow, adding to the pain.
But there is one place where this also happens where it's really upsetting: in Vim itself. When working in Vim and entering command mode using : the default readline editing returns. Chords all over again. How to fix this?
Simple: When in "normal" mode, that is, when navigating around, type q:
Vim will drop you at the bottom of a full Vim full screen editing experience, go for your life
Additionally the command history is available on previous lines in the buffer
You can yank and paste lines and edit the commands as much as you wish
To execute a command in "command" or "ex" mode just hit ENTER on the line you want to execute
Hitting enter on an empty line closes the buffer and does nothing
But this is just another buffer so you can quit it as usual with :q as well
Although ESC leaves the "ex" command line, ESC in the buffer will not leave the buffer, because it's an actual buffer
The q prefix is used to introduce macro recording, so the q: variant is perfectly mnemonic for entering recording of an "ex" command line.
Note that q: to enter the buffer editing mode is very similar to :q ! You may have hit that by accident sometimes ;-) Now you know how to get out of it!
Zigdon had this answer a long time ago, of course, but it's pretty darn sparse, but then again, so is the question. If Zigdon adds this extra detail to his answer I'll be happy to delete this answer so that there can be one good answer.