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.
Related
I installed a vim 8.1 on the cluster I am using in my home folder. I also installed a number of plugins including YouCompleteMe. I then made an alias so that I can open the vim easier.
However, I found that my vim cannot delete letters very well. When I am writing I can delete what I just typed. But if I move the cursor to other places, then it cannot delete letters at all, unless I type in something at first.
I am using a Scientific Linux system developed by the Fermi Lab.
How can I solve this problem?
Thanks
This sounds like the default configuration of the :help 'backspace' option. If this doesn't contain start, you cannot remove characters over the start of insertion by pressing Backspace, only what got inserted before. Removal of characters via the x or d commands (:help deleting) should always work - anywhere. Else, you have a serious misconfiguration should inspect your ~/.vimrc and re-add plugins one by one.
If you're new to Vim (and using backspace for deletion in insert mode is a typical approach of people used to other, modeless editors), you should spend 30 minutes on the vimtutor that comes with it (see :help vimtutor). Then, there are several good resources, cheatsheets, and vi / Vim tutorials out there on the net. http://vimcasts.org/ has several short entertaining episodes that go beyond the basics.
Your problem could be fixed by putting
set backspace=indent,eol,start
into your ~/.vimrc. Also have a look at :help defaults.vim; by including that instead, you'll get other goodies and recommended settings as well! (The reason for the odd defaults is backwards compatibility.)
Sometimes when entering :, vim appends .,.+3 to it, preventing me from executing a command. I couldn't find anything about this behaviour online, is there a way to get do away with it? At the moment, I use vim 8.0 (in iTerm2) but it also used to occur in earlier versions.
This happens when you typed a number before the colon. Vim interprets it as the number of lines on which you want your ex command to operate.
If you press 4: you get :.,.+3 which is a range that covers the current line (.) and the three lines below the current line (.+3).
That behavior is old and documented in :help N: (:help :range is an interesting read, too).
If you want to get rid of that range, see :help <C-u>.
When I issue an ex command in the vim command line, e.g. :% s/^I/ /g (replacing all tabs in file with spaces -- the ^I is not carat-capital-i, it's the tab character entered by typing Tab or Ctrl+i), I end up with only the replacement operation affecting the first match within the lines specified.
Then on a hunch what I tried the command without the g flag, :% s/^I/ /
This worked and did the job on all the tabs.
This is backwards!
Why?
I have a ludicrously huge .vimrc, it is 1199 lines as of today, so it's pretty certain that something in it or in the plugins I use is causing this behavior. However, especially now that I have found the way to get the global flag working again, I am certainly not looking to sacrifice any of the plugins or even really attempt to do some kind of manual binary search hunting to blindly narrow down the cause of this, as that would take too long.
If the 'gdefault' option is on, this flag is on by default and the [g]
argument switches it off.
Update:
The 'Feng shui' way to get to this line in the docs is :h :s, then CTRL-] on ":s_flags"
I am using Cygwin 1.7.22 (32-bit) on Windows 8 (64-bit). Within Cygwin, I am using Vim 7.3.1152, which is the default version.
Behavior that seem like bugs:
When I press I to enter insert mode, it does not say -- INSERT -- in the bottom left. In fact, it doesn't say anything. It does behave correctly, though.
When I delete letters using Backspace in insert mode, the letters do not disappear but the cursor does move to the left.
When I use the arrow keys in insert mode, it enters the letters A, B, C, and D, rather than moving the cursor. The arrow keys work normally outside of insert mode.
How do I make Vim behave as I expect?
Create a ~/.vimrc file with the following contents to put vim in nocompatible mode (actually the mere presence of the file is sufficient.)
set nocompatible
The behavior you are seeing is how vi used to behave. These are not bugs.
Take a look at :h nocompatible
In vim compatible mode tries to emulate vi as closely as possible.
--insert-- is not part of vi so it not shown in compatible mode.
I believe vi did a lazy redraw of the screen and didn't update until you exited back to normal mode. Also backspace is only usable also only works on stuff that was entered in the current insert mode. Overall its not very user friendly.
The arrow keys are sent to vim as escape sequences (escape followed by a coupled of letters). Let ^[ be escape. ^[OA is up on my computer its probably something similar on yours. vim sees this as an escape (goes back to normal mode), and O (add a line above the current) and A which is the A you see entered onto your screen. This just means that vim in compatible mode does not interpret the escape characters properly. Most likely because vi did not interpret them (nor was it designed to use them).
set nocompatible fixes problems 1 and 3.
I think set backspace=indent,eol,start should fix problem 2.
This was asked months ago, but I am answering for future reference for anyone else who encounters this problem.
I was just bitten by this issue. All advice listed in this post, and in other posts on this forum (not to mention posts on other forums) does not work, at least for some of us. I finally figured out the real issue.
vim on cygwin, for whatever reason (at least this was the case for me) does not use the .vimrc you put in your directory. Let's say you copy the example one to your working directory, or copy some .vimrc from online. Or maybe you create a new one from scratch, and put all the settings the good people here and elsewhere recommend (set backspace = blahblah, set nocompatible, set this, set that). It doesn't work. Why? Because for whatever reason (at least in my case) vim isn't looking at the .vimrc you just created.
The solution is to FORCE vim to use a particular .vimrc, by passing in -u on the command line like so:
vim -u [/INSERT/PATH/TO/.vimrc]
For the love of all that is holy, DO NOT type square brackets or the words "/INSERT/PATH/TO/.vimrc" verbatim. Use your brain please.
Anyway, this solved my problems and I was able to use the default example .vimrc and get proper delete and backspace behavior while in insert mode, not to mention other goodies.
You might want to alias the vim command in your .bashrc like this:
alias vim='vim -u [/INSERT/PATH/TO/.vimrc]'
Regarding A,B,C,D for arrow keys in Vim, adding:
:set term=cons25
to ~/.vimrc worked like a charm.
source: http://vim.wikia.com/wiki/Fix_arrow_keys_that_display_A_B_C_D_on_remote_shell
Following different answers in this topic I found a simple solution.
$ vi --version | head
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 30 2020 21:54:08)
Included patches: 1-486
Modified by <cygwin#cygwin.com>
Compiled by <cygwin#cygwin.com>
$ vi --version | grep 'user vimrc'
user vimrc file: "$HOME/.virc"
2nd user vimrc file: "~/.vim/vimrc"
So I just created ~/.virc (not vimrc) and it works! The content of the file:
set nocompatible
Probably, if you already have this file you will add the above string in it. Or, as people say above, if you have an empty ~/.virc, nocompatible mode must be already in use (I didn't check it).
Apart of the question, line numbers (that I find very useful) may be shown in vi by adding:
set number
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. :-)