I'd like to be able to end a run of comments but retain the current indentation. Is this possible either through an existing command or with a function?
I have formatoptions -=o and autoindent so I normally get by using o from normal mode - the cursor is on the next line, the indentation is correct and I'm in insert mode. I'm only worrying about single line comments (eg '#'s - as for shell, python etc).
I'm interested in how I can make this more general (particularly not dependent on my formatoptions). I'd like to have an imap for ;; but I can't seem to find a straight forward way if I want to call a function (for example, to check whether I'm currently on a comment line).
I've played around with <expr> mappings and the expression register but either I lose the indentation (cursor ends up in the first column) or the comment continues. It seems like there might be a better alternative to either reimplementing the autoindent logic or trying to delete the extra comment characters. I've also tried saving/restoring formatoptions while using normal o but leaving insert mode when there's no other content on the line deletes the indentation.
I appreciate suggestions about how I should approach this.
Related
I fairly often find myself in a situation like this:
I'd like to start typing on the line on which my cursor is currently. However, in order to get to the correct indentation level, I'd have to press TAB several times.
Usually I'd press ddO (delete current line and insert a new one above the cursor), which resets my indentation position to the right place:
But that seems like an odd way to go about adding the correct amount of whitespace.
Is there a better way that I'm overlooking?
When in normal mode, you can use cc or its synonym S. If you are already in insert mode, Ctrlf is the default key for this, but that can be changed by altering cinkeys (see :h cink for details).
See also this answer on the Vi/Vim stack
Kevin mentioned some shortcuts, but another method is <C-i> (indent) and <C-d> (dedent) in insert mode.
If I write an if statement in my C program, press enter three times, then write a comment, the below is my output. Notice the two lines between the condition and the comment are completely empty.
if(my_condition) {
<Tab>// My comment here
My issue is that Vim does not insert any tab character(s) between the beginning of the line and the cursor position until a character is typed. This is very annoying for me, because I like to move my cursor up and down the block of code often. Since there isn't a real tab on the two lines, if I moved up one line my cursor would go to the beginning of the line, instead of staying on the same column. I come from Sublime Text and other editors where this has never been a problem.
Is there a plugin or setting such that I can accomplish the following?
if(my_condition) {
<Tab>
<Tab>
<Tab>// My comment here
All help is appreciated. I've looked into using Visual mode, but have had undesirable side effects of enabling it all the time. Certainly there is a simple way to automatically add the tabs when I make a new line?
This is very annoying for me, because I like to move my cursor up and down the block of code often.
Well, as you might have noticed, switching to vim means that you need to change your own editing behavior. And that might be the toughest, more than learning the new commands, because habits die hard!
I'm not saying that you should stop scrolling around your function in an useless manner, though, but that you should stop moving around with the "cursor" keys in insert mode.
When you're doing movements when in insert mode it has the side effect you're exposing as "inconvenient", but it also has the side effect of breaking the "repeat" command (.). After a cursor movement in insert mode, a . will only repeat characters typed after that movement.
So, what you should consider in your editing behavior, is to avoid empty lines, avoid trailing spaces/tabs and never move around in insert mode. Insert mode is for insertion, and the normal mode is for moving around and doing actions on the text.
There are a lot of move commands you can abuse in normal mode (j/k, <C-e>/<C-y>, {/}, …).
That being said, if you get yourself in a situation where you've fscked the indentation, you might want to keep on editing, not caring about the indent, and once you're back in normal mode issue a =i{ that will indent everything within the block following the syntax file (and your indent settings).
I'm going through http://learnvimscriptthehardway.stevelosh.com/chapters/04.html
and the exercise wants me to make in normal mode upcase the current word.
I did:
nnoremap <c-u> mmgUaw`m<esc>
and I'm using a mark (the m mark) to prevent the cursor from moving.
I don't like this solution because what should be a purely functional change ends up changing the global state of vim (by setting up a mark).
Is there a better way to do this, or is there a mark (or a set of marks) that should only be used by commands/mappings and not interactively (because commands/mappings change it/them)?
This is the best I came up with:
nnoremap <c-u> i<esc>guiw`^
to utilize the last position of the cursor in insert mode.
The example from the Vim help uses the s register itself, so your approach isn't necessarily a bad one (i.e. if the mapping is just for your own use then you can just pick a register you don't use for anything else).
Having said that, the special backtick (`) register might be better here, since it's local to the buffer and is meant to store the most recent jump point anyway.
In my .vimrc I've enabled highlighting the searched text (which I find to be a handy feature and wouldn't want to disable it).
set hlsearch
And, following answers to this question, I've made a mapping to be able to clear the highlight:
nmap <silent> ,/ :nohlsearch<CR>
The problem comes with commands which include search. For example, delete to next character 'x':
d/x
This will automatically highlight all the instances of 'x'. To remove this highlight I have to punch ,/ to clear it, which is quite annoying.
The question. Is it possible to enforce :nohl if the search is a part of a preceding command? Maybe, it is possible at least for a selected list of commands (say, d, y and c) before / character is hit?
d/x does not work for me as you describe. (I'm on vim 7.3 here and it can't make sense of the / following d in normal mode, so disregards the d and starts a regular / search.)
If you want to delete to the next x, then dfx or dtx are what I would use (depending on whether you want to also delete the x itself or not).
No highlighting involved.
Hope that helps.
[Following some clarification in the comments.]
I'm thinking that it should be possible to write a custom function to do what you want, and then assign a custom key sequence to call that function.
I played around a little, but am not very well versed in vim functions and couldn't make it work.
Here's what I tried:
function! g:DeleteToSearchAndNohls(term)
:normal d/a:term
:nohlsearch
endfunc
If 'x' is on the same line than the cursor, you can use dtx (meaning delete to x).
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. :-)