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.
Related
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).
When I'm in VIM insert mode, it wonderfully adds matching end characters. E.g. if I type " it will add another " immediately after the cursor. Similarly for parenthesis, braces etc. when programming.
How can I quickly skip over the inserted character, while staying in insert mode? The best I've found is to use the forward arrow key, but that's not conveniently located.
Accordingly, I either type the closing character, or I <esc>li (exit insert mode, move right one character, re-enter insert mode). This reduces the convenience of the auto-insertion quite dramatically, so I figure I'm missing something obvious.
(Note, for convenience I'm using the handy SPF13 curated collection of plugins and running MacVIM. Edit: This is the autoclose script providing the matching.)
There's basically no way to get out of an autoclosed pair that doesn't involve pressing at least one key.
The standard mechanism provided by all the autoclosing plugins is simple: type the closing character. You can also press <Right> or, if you are at the end of the line, <End>.
Maybe your plugin gives you another mechanism but you'll have to find out for yourself.
Whatever key you press, you'll still do at the very least exactly the same amount of typing as you'd do without autoclosing.
Autoclosing is not about saving typing, the only practical use of that feature is to prevent unmatched pairs. That's all and, I think, the "obvious" thing you are missing.
As you are using a SPF13 and don't know which plugins brought the mapping. There are two things that we can do
1) I usually esc followed by A. This will kept you in insert mode after the closed character if it is the last character. I usually prefer this over the second one.
2) You can circumvent the automatic closing by ctrl - v before the character, for instance ". This will not autoclose the corresponding character and you are responsible for the closing.
I've been using vim for somewhat longer than a year now and during this time I have never feel really comfortable with the way vim works with yanking and pasting text (or maybe it is just me not using it in the most efficient way)
For example, I have the word "World" yanked onto a register, and I want to paste it after "Hello". (Note that there are no spaces on either of the words). So, what I would do is
Hello
|
Place cursor here, and press "p". Then, what I will end up with is
HelloWorld
So, in order to avoid this, I have always to swith into insert mode, insert a espace, and go back into normal mode (or either make sure that the yanked word has a space before it). Be as it may, this is quite annoying behaviour I can't think of a solution for... Am I missing something here?
Suggestions will be appreciated.
Thanks
option zero
just live with what you have now.
option one
create a mapping for your workflow. for example
nnoremap <leader>p i<space><esc>p
option two
:set ve=all
then you could move your cursor to anywhere and paste
option three
you could in insert mode use <c-o> do normal mode stuff or <c-r> to get register values
I recommend option zero
You can use the Smartput : Adjust spaces and commas when putting text plugin for that. It modifies the p / P commands (this can be toggled on / off).
I am trying to get AStyle working with Vim so that I can use the "=" key to re-indent various sections of code. For example, I'd like to be able to type my usual =iB to indent the current block of code using AStyle rather than the built in indenter.
I tried just setting equalprg=astyle in my vimrc, but the problem is that astyle only receives the selected block but thinks that it's receiving a whole file. Therefore, the indentation is completely off when I try to only indent a nested class.
I know that I can always reformat an entire file at once, but is there a way to use astyle in vim which completely replicates the original formatting behavior of vim (all my =-movement commands work - and bonus points for autoindent using astyle as well!)?
Unless there is a version of AStyle that has a partial file formatting option, you'll need to apply the extra indentation after you run AStyle.
I'm not sure how you can do this with motions.
With visual selection, you could grab the indentation from the first line, pass the code to equalprg, and then add that indentation to all of the lines:
vnoremap = <Esc>`<dwgv=`<<C-v>`>I<C-r>"<Esc>
Breaking it down:
vnoremap -- so we can use = for equalprg
<Esc>`< -- stop selecting and go to beginning of line at beginning of selection
dw -- grab the initial indentation
gv= -- reselect and indent as normal
`<<C-v>`> -- block select the selection
I<C-r>"<Esc> -- insert the initial indentation
Maybe you can do something similar with motions?
It only works for formatters that have a partial file formatting option, like idbrii already pointed out. An example of a formatter that does this is clang-format.
One way to integrate this into vim is by using vim-autoformat. Using this plugin you can viB and then press your self-defined format key, like <F3>. This will then only format the selected inner code block.
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. :-)