In Vim, is there a way to select a block of text and use undo to only undo changes to that block of text?
Let's say I rewrite a function, then go and make some changes elsewhere in my file. Afterwards, I realize that my first function implementation was indeed better. I'd like to undo the changes I made in that function, but leave my subsequent additions intact.
I don't know if this is even possible, but I often find myself wanting this feature.
Currently... No. Vim 7.3 has undo branches that you can traverse but as far as I know Vim does not pay attention to any selected text during an undo.
Maybe this:
http://sjl.bitbucket.org/gundo.vim/
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
https://github.com/tpope/vim-pathogen
Related
I installed Latex-Suite for Vim, and I like it very much, but I'd like to be able to customize the environment mappings that came by default, and add new ones. For example I want to edit the equation environment that appears typing EEQ and move around some elements, like the \label{} command. How can I do this? I've been scanning everything inside my /usr/share/vim/vimfiles/ftplugin but I can't find a way to do it (or I just don't understand what those files are).
You want to check out the documentation on Macro Customisation, specifically the Tex_Env_{name} bit.
In short, if you want your theorem snippet to look like
\begin{theorem}
<++>
\end{theorem}<++>
then you want a line like
let g:Tex_Env_theorem = "\\begin{theorem}\<CR><++>\<CR>\\end{theorem}"
in your vimrc.
Note the backslashes to escape carriage-return, and double-backslash for normal backslashes.
The <F5> functionality (press F5 after typing an environment name, i.e. figure<F5>) should work out of the box, but you may need to refresh the three-letter code. This is more hassle than it needs to be, but something like
autocmd BufNewFile,BufRead *.tex call IMAP('EFI', g:Tex_Env_figure,'tex')
will do the job.
The answer to the question you asked comes with a caveat, which is that Latex-Suite is an enormous amount of code that is very hard and annoying to modify, and which does not play nicely with other plugins. This falls into Latex-Suite's philosophy that it's the only plugin you need for editing latex within vim.
That said, you want to look in /path/to/ftplugin/latex-suite/envmacros.vim. Searching for EEQ will lead you on the path to understanding the set of calls that latex-suite performs. I would like to reiterate that many functions are deeply intertwined.
On the other hand, there is a very easy way to have very easily customizable environments, which are snippets. See the UltiSnips page for a good example of how this works. These are designed for customization and extremely easy to write.
Let's say I make 3 changes, C1, C2, and C3.
Then I undo X3. Then I redo X3. I'm back where I started.
Then I undo X3 again, but then I accidentally type ifoo<Esc>. What can I now do to recover change #3?
Vim is special in that it not just stores a linear history of edits (and undo), but actually all branches! You can use the g- and g+ commands to move through them, and the :earlier command to move to text states by count, seconds, minutes, etc. See :help undo-branches and :help usr_32.txt for details.
Plugin recommendations
Because that kind of navigation is still mentally taxing (and one doesn't want to get lost in a potentially huge undo tree!), the undotree.vim - Display your undo history in a graph and Gundo - Visualize your undo tree plugins provide a much better visualization, including diffs to see what changed in each state.
Given that sequence, you should be able to type g- (g-) one time to get back to change 3. You might want to open another instance of Vim and test it to verify it does what you want.
Type :h undo-branches for more information.
Recently when I tried to use the ctrl+n or ctrl+p to auto-complete, when there are multiple alternatives, tapping the enter button will insert a new line instead choose the alternative I want.
This did not happen before, maybe because I installed too many plugins and caused the conflicts. It would be horrible to check all these plugins' shot cuts and find out the source. So mapping the built-in auto-complete to some other keys could be a solution, but I don't know how to do that.
This is not a big problem but really made coding not "smooth". Anybody has met this situation before and how did you deal with it.
Short answer: You don't need to use <cr> to accept a match.
Snippet from the vim help :h popupmenu-keys
The behavior of the <Enter> key depends on the state you are in:
first state: Use the text as it is and insert a line break.
second state: Insert the currently selected match.
third state: Use the text as it is and insert a line break.
In other words: If you used the cursor keys to select another entry in the
list of matches then the <Enter> key inserts that match. If you typed
something else then <Enter> inserts a line break.
I would suggest you use <c-n> and <c-p> to switch to the correct mapping and then continue on with your typing. Typically this means I type a space or some other punctuation key and the menu closes. I never use <cr> to select a menu item. If however you really want to accept a match use <c-y>. Think "yes" to the selected menu item.
I just fixed a very similar problem caused by the vim-autoclose plugin by replacing it with the Auto-Pairs plugin. I doubt that yours is exactly the same culprit but it's actually not too bad hunting down the guilty party if you use pathogen for your plugins - just move half of your plugins from ~/.vim/bundle (or wherever they are) into a different folder, restart vim and test the autocompletion. If it works as expected, you know that one of the plugins you have moved out is responsible, so you can do the same again until you have narrowed it down.
Before that, you can also try running vim -u NONE which ignores your .vimrc file - it may be that you've snuck something in yourself and this is the fastest way to rule it out.
Good luck anyway. This took me about ten minutes and after probably a year of occasional annoyance I wish I had taken the time earlier.
I have a Vimscript function which is called on BufWritePre to check the integrity of the file. Typically this involves trimming whitespace and checking that the fold structure is "valid" (according to my company's conventions).
My problem is that if I edit a file and then save it, the undo tree contains the edits made by the checking function. Is there a simple way to say that I don't want a function to modify the undo tree? Or can I save its state at the start of the function and restore it at the end?
With :undojoin, you can join your changes with the last changes done by the user (though I would find that more confusing than having them separate). In general, undo is sequence of steps; you cannot simply omit steps in the middle, that would both be unintuitive and also difficult to implement in the undo engine.
Anyway, what's so bad about including your automatic reformatting in the undo history? As I understand it, it'll be re-applied on the next save when the user undoes his last edits.
If your BufWritePre action is performing manipulations that ultimately leave your file unchanged, you can:
:wundo <tmpfile>
...Make changes leaving file the same afterwards...
:rundo <tmpfile>
This will leave you with your undo history prior to the temporary change, however if the file doesn't match it's previous state you'll get the error File contents changed, cannot use undo info.
If you wish to make the changes done during the BufWritePre impossible to undo, you can:
:set noundofile
.. Perform changes ...
:set undofile
However, this will lose all history prior to the BufWritePre
Is there a VIM absolute (registers, marks, undo history, tags) bar or tree toggle ?
I mean, like the tag-bar, but with subsections. Having the primary sections to be the followings, custom marks, custom registers, custom records, undo history (as the Gundo plug-in). So undo the bar, we can go to a mark, execute a record, yank or paste a register, etc.....
If there is not, would anyone like to help me build it??? Or just, help me with good starting tutorials for vim plug-in building, since it'll be the first one that I'll make.
No, there's nothing like that, what would be the point of such a monster?
Aren't :marks, :registers, :changes, :undolist… enough?
Anyway, you should start by getting familiar with Vim's built-in documentation: :help eval contains all the raw info you will need.
Steve Losh's Learn Vimscript the Hard Way is a really great third party ressource and the Vim Wiki can be useful, too.
Though plugins like tagbar and Gundo efficiently display information in a side bar, like IDEs, this is mostly a concession to what today's users are used to, but not a fundamental way to use vi(m). Marks and registers are meant to be memorized by their names (a..z), with the :marks, :registers, etc. commands to provide you a refresher after a long break / the next day.
There are many plugins (e.g. for automatic mark management and visualization), but I would recommend to use them sparingly. It's definitely a "smell" if you want to turn Vim into a full-blown IDE. Please don't.