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>.
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.
I am trying that in the editor vi, limit the number of characters per line you can do. Once you reach those x characters, break the line with a carriage return. For example: limit 50 characters.
I have not seen that there is any command (like :set nu to write the numbers of the lines in editor vi) or something similar to activate it.
I know that in order for it to take effect I have to create the file ~/.vimrc but there I don't know how to edit it so that when I later create a file, I restrict it.
Are you really using vi? You are probably using vim. If so, :help will answer most of your _I don't know_s. From there, you can also jump to specific parts of the help following the links (you recognize them as they are likely colored, bolded, or highligthed somehow) by hitting Ctrl+] (and yes, you can also enter :help ctrl-] to see the help on the key combination I've just mentioned).
In order to do what you want, it is enough that you put set textwidth=50 or set tw=50 in your ~/.vimrc file (note that a value of zero for tw means that the option is disabled, or if you prefer, that tw is infinite). If you want to look at the description of this option, enter :help textwidth.
This setting (:set tw=50), however, won't change already existing lines; in order to change all the already existing lines according to the current setting of tw, you can do gggqG, which moves to the first line (gg) and then formats the lines (gq, for info enter :help gq, which will also reveal the reason why this command will have an effect even if tw is 0) till to the last line (G moves to last line of file).
Is there something like % (that represents the whole buffer in Vim command line) for the current selection, so that I can do something like: :# sort (Imagine # represents the selection).
EDIT:
Sorry, I missed to mention that I am requesting for a way to operate on block selections not on ordinary selections that can be operated using ranges '<,'>.
Yes. Example:
:'<,'>!sort
The range :'<,'> represents the visually selected lines.
:* is shorthand for :'<,'>
If you hit : while in visual mode it will start the command with '<,'>
For more help see:
:h '<
:h v_:
:h range
You are probably looking for the marks '< and '>:
:'<,'>sort
If you just select a few lines and hit : to enter the command line these marks should appear automatically.
As others have already remarked, the visual selection is represented by the '<,'> range (there's also the :* short form). However, as all ranges, this always covers entire lines, even if the selection is only characters or a block.
Most Ex commands (like :sort) only operate on full lines, for :substitute, you can limit the effects to the visual selection by including the special \%V atom in the search pattern, cp. :help /\%V.
The idea to make Ex commands handle blockwise selections is old, but unlikely to be tackled any time soon.
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'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. :-)