When I edit multiple files I oftentimes want to go back and forth between the last edited files. I know about :bn(ext) and :bp(revious) to switch between buffers but they don't keep the history of the last used files. Instead they use the order in which the files were opened. E.g., if I opened the files in this order
A, B, C
an my navigation history would be
A, B, C, B
then :bprevious in the last buffer (B) would send me to A. Is there a command or plugin that would send me to C? I know of Ctrl-6, but this only switches between the last two buffers. I would like to go back and forth multiple buffers.
I have been wanting the same functionality for quite some time now as well. Your question inspired me to finally do something about it. Have a look at bufsurf, a small plugin that provides the required functionality. It provides the user with two commands:
:BufSurfBack
to navigate backwards in history, and similarly:
:BufSurfForward
to navigate forwards in history. For each window or tab a separate navigation history is kept in memory. Please let me know if you experience any problems, I did not have the chance to test this extensively yet.
Check out the lustyjuggler buffer plugin. It's awesome for this. It keeps the buffers in last used order and maps them to the home row keys so you can very quickly go back/forth between them.
http://www.vim.org/scripts/script.php?script_id=2050
You can see it demoed toward the end of my most recent vim screencast were I go over buffers:
http://lococast.net/archives/185
Related
(Documenting this here because I couldn't find a good answer online.)
When using UltiSnips, the documentation says (2:12 in this screencast) that writing the .snippets file is enough to cause an automatic reload of the snippet. However, this doesn't work for me. What's happening?
I had this question myself, as frequently updating my own .snippets files and not having them immediately available is unpleasant. After some experiments I discovered the answer:
:call UltiSnips#RefreshSnippets()
In case you are curious, I found it by typing :call <C-d> (a very long list, by the way).
However, this command does not update the autocompletion list of YouCompleteMe (which is mostly irrelevant, but sometimes you might want to browse through your options with description next to it).
Looks like the UltiSnips reload applies within a vim instance. So make sure to open & save the snippets file within the vim instance that you want the changes to take effect in.
To help with this, the command :UltiSnipsEdit will open the .snippets file corresponding to your correct file. You can configure how the snippets file opens using this command:
g:UltiSnipsEditSplit Defines how the edit window is opened. Possible
values:
|normal| Default. Opens in the current window.
|tabdo| Opens the window in a new tab.
|horizontal| Splits the window horizontally.
|vertical| Splits the window vertically.
|context| Splits the window vertically or
horizontally depending on context.
Sample usage in .vimrc: let g:UltiSnipsEditSplit="context"
Note that this doesn't work as well if you'd like to make the changes in a different snippets file (e.g. you're working on a cpp file and you want to add a snippet for all c files (and your cpp.snippets file does extends c). If you're in this situation and you're editing your snippets frequently, consider keeping that snippets file open in a tab/pane.
Other suggestions / input welcome!
(from Documentation)
I haven't been able to find a satisfactory answer to this either. Until somebody can post something better, I recommend just using
:e!
This reloads the current window to the most recently-saved file. I know it's not much, but it's what I'm using until I find a better way to do it.
The short version of the question: how can I get icicles to search usefully for files in directories and subdirectories, even if only given a partial match of the filename?
EDIT: The short answer is to use icicle-locate-file in the top level of your directory and use S-Tab (shift-tab) to begin completion rather than plain tab. More details in this answer.
Just as an addendum, I gave up on icicles after this as it took about 10 seconds to find files in the (large) directory tree in question each time I used icicle-locate-file. There may be a way round this delay, perhaps by creating and sets of files 'gathered' by icicles, but I began to feel that the potential benefits were being eroded by the up-front costs of working this out and by the costs of keeping the file sets updated. As the author of icicles points out below, access to *nix's locate command would allow me to use icicle-locate, which is quicker than icicle-locate-file. However, I run on Windows and the Everything utility doesn't work for me. So, back to copious use of IDO and bookmarks that expand to dired buffers.
==========
The longer version... As Emacs (24.3.1) is now my main development environment I have been exploring ways of improving my efficiency, particularly regarding filename completion for some time now. Several excellent answers to this question pointed me to ido-mode and dired-x, both of which I am now using.
Another great recommendation was Emacs' bookmarks. In particular, defining dired buffers as bookmarks and jumping to them using C-x r b mybook1 or even calling C-x r b from the C-x C-f minibuffer (this page was helpful) are two very useful strategies.
A couple of people mentioned anything and its successor helm. I have been unable to get the file location part of either package working on Windows 7. Apparently they depend on the command line version of Everything but this fails for me, as detailed in this question, to which there were some helpful responses but no definitive answers. It seems that it works smoothly on *nix but there's not much discussion of helm-locate etc on Windows. So that counts out helm and anything for filename completion.
Which brings me to icicles. In a question about making find-file search in subdirectories the asker commented that they had taken a look at "ido and icicles, but they seem to work shallowly, only within current directory".
In response to this came a comment on icicles: "you can search for any file on your system, if you want, matching any part of the file name and path" with a pointer to a page on Icicles file name input. While I appreciate the considerable effort that has gone the help pages for icicles, I didn't find this one very useful because it consisted largely of a list of descriptions of icicles functions. What would be useful to me is a tutorial that walks you through finding files.
Let's assume the following.
I am running a Windows 7 installation of Emacs 24.3.1.
I have a top-level directory containing some files and folders. In this case it is c:/iciclestest/.
I know there's a file somewhere in this section of the tree that has "grob" as part of the filename.
I want to use icicles to find this file. I have put (require 'icicles) and (icy-mode 1) in my init file.
So, off we go. Start Emacs in the scratch buffer. Hit C-x C-f. I get a File or directory prompt, with a purple plus sign to the left that I think indicates that this is one of icicles' multi-commands.
Hitting tab gets me this mini-frame, showing me the contents of the current directory.
I hit tab on the folder1 subdirectory and icicles shows me the contents of that, as one would expect.
You can see a couple of files with "grob" in the name.
Right, C-g to clear everything then C-x C-f again. Enter 'grob'. I get a "no prefix completions" message. This surprised me a little because I expected icicles to have some kind of whizzy fuzzy matching like ido-mode.
Okay, maybe I need a different command. Let's try M-x icicle-locate-file, which gives me this prompt:
If I enter 'grob' and hit confirm I just get a new file, as per below.
To recap: what I'd like to be able to do is enter a string and have icicles go and look for files or folders containing that string. My main dev folder has many dozens of directories and thousands of files so a quick find within Emacs would be a godsend.
I realise that the locate command doesn't exist on Windows so functionality will be in some ways limited, but I would have thought a recursive search of files and subdirs from the current dir based on a user-entered string would be straightforward. What am I missing? Am I going about this the right way? Can this be done in icicles?
You need to read the Icicles doc a bit more: use S-TAB instead of TAB for apropos (regexp or substring) completion. That is apparently all you want here: match grob as a substring. (No need for any fuzzy matching for that.)
Since you want files matching grob anywhere under that directory, use icicle-locate-file. Give it that directory as the starting point. (And since you want to match grob anywhere in the file name, use S-TAB for completion.)
Icicles does provide "whizzy fuzzy matching like ido-mode" (in fact a lot whizzier). Ido's "flex" matching is the same as Icicles's "scatter" matching.
You can set the kind of completion you want to be one of the fuzzy-matching types. In the minibuffer, C-( cycles among the prefix-completion methods. M-( cycles among the apropos-completion methods. True fuzzy matching is a prefix completion method. Flex/scatter matching is a poor man's fuzzy matching, and it is an apropos completion method (so use M-( to cycle to it). To change the default matching, so you need not cycle to get the ones you prefer, customize option icicle-S-TAB-completion-methods-alist or icicle-TAB-completion-methods.
In addition to the answer about icicle-locate-file, you can find files that are in marked Dired subdirectories, and their marked subdirectories, etc. recursively, using M-+ C-F (command icicle-visit-marked-file-of-content-recursive), if you use both Icicles and Dired+.
This answer provides the details.
One thing I like about Sublime Text is that you can drag any folder in the left panel and this folder can be expanded independently from the others. How can I achieve the same functionality in Vim?
I'm currently using NERDTree which currently supports a single root. When you open another folder it replaces the current hierarchy. So I wouldn't mind dropping this plugin in favor of another solution.
The netrw plugin that ships with Vim allows to open multiple, different splits to different locations, e.g. vertically with :Vexplore.
To make it show a recursive tree, use:
:let g:netrw_liststyle=3
I don't know any plugin that does this, but from my brief forays into NERDTree's source code, I know that modifying the plugin to do what you want is not out of the question. It would involve delving into the logic and modifying / commenting out the parts that search and re-use the current NERDTree buffer. If you're familiar with Vimscript, not a huge challenge. (Maybe you could even introduce a configuration setting for it and send it to the author for inclusion.)
It took me a while, but I managed to work something out.
I made it into a separate plugin: Vimpanel
I put a lot of other usefull things in there, apart from the "killer feature" of being able to have multiple roots.
Let's say I'm at state A in my document. I then make changes B, C, and D (in order).
Is there a way I can keep changes B and D, but skip C?
Or, let's say I'm at state A in my document. I make change B, undo it, and then make changes C and D (so Vim has an undo tree with two branches). I then change my mind and decide I want to use B and D but not C.
How can I do this in Vim? I have the gundo.vim plugin installed, but I haven't used it that much.
Well, I'll take a stab at this and say: No, I don't think there's a way to do exactly what you want with vim.
gundo.vim adds a nice interface to vim's undo, but doesn't change its core capabilities. So I took a look at the official vim docs to see if there's any hints to whether it is capable of this:
vim docs: undo
User manual page about undo
Nothing about merging two branches together. I think ewh and ZyX are right: to get a general solution for merging B with D, vim would need either for
Bram to add it as a separate feature in a future version
someone to implement it in a plugin by integrating with something that can already do merges (like git/hg)
You can of course try to do it manually by having files with versions B, C and D as well as a few diffs open.
Note: If I misunderstood and you weren't wondering about a general solution and are looking for help with a specific instance of this, let me know and I'll see what I can do :)
Is there a way I can keep changes B and D, but skip C?
You're at state D. :w file.ext_D
Backtrack to state C. :w file_ext_C
Backtrack to state B. :w file.ext_B
:!kdiff3 file.ext_B file.ext_C file.ext_D
This gives a 3 way merge of the differences, but still you'd have to manually go in and choose every red line in D for each merge conflict. Not exactly an easy solution.
If instead you do
:!kdiff3 file.ext_C file.ext_B file.ext_D
Then the merge happens automatically (except for individual lines with multiple changes)
For more complicated scenarios it gets tougher.
Note: I'm not sure how a revision control tool is much help. You're basically doing something like creating a patch between B and D, and then subtracting the patch from C to D from it. It seems to me that revision control systems are usually designed to manage merges between different sources of changes, not changes along a single branch.
kdiff3 is available at: http://kdiff3.sourceforge.net/
I am thinking of installing a buffer explorer for vim. Both minibufexpl and bufexplorer have very good rating. Can anyone explain the differences or the pros and cons between them. Or is only a matter of taste?
Thanks!
I've used both of those plugins. I used minibuf explorer for a long while (couple of years) and it was pretty good except in situations where you have large numbers of buffers open. Then it just becomes confusing and starts to take up alot of screen space.
buffer explorer doesn't give you a constant view of what buffers you have open but it's actually a much more solid (less flaky) plugin and when you switch into buffer explore mode it lets you quickly delete buffers you're not using etc. I like it much more now.
Basically, I'd say minibuf if you don't regularly edit more than 8 files. Buf explorer if you edit tonnes of files at once.
i've used both but moved to fuzzyfinder. minibuf gives you a little window to easily switch between buffers and bufexplorer gives you a window you can invoke to call an open buffer.
Now let me sell you on fuzzyfinder, you invoke the window and start typing to match the name of the file that's open. Could be the buffer id or any part to the full path of the file including the file name. Fuzzyfinder also works with your tags file so you can easily jump to any tag within your project. Also works with directories, markers, and most recently used files. It can also open in a split window, tab, or the current window.
I think that using MiniBufExplorer with a lot of files (more than 8-10) is probably not very efficient since it takes a lot of screen space unless you have a big monitor.
I ran into some issues using MiniBufExplorer with multiple buffer splits open at the same time, and I modified the plugin to get around these limitations.
The part that made the plugin unusable was the fact that there was no indication of what buffer the cursor was currently active in, and it was very easy to get lost while switching buffers. I use H and L to move to the previous/next buffer.
I also updated the plugin so that it always reflects the current buffer's state, wether it's unmodified or modified, without having to switch buffers for the plugin to update.
I think these changes really make MBE much more usable, both in terms of the sheer number of open buffers as well as moving between them, which is important.
You can find the updated changes here: https://github.com/fholgado/minibufexpl.vim
I have tried them both and I prefer minibuf. The fact that you have all your buffers and their numbers at a glance allows you to switch to the buffer you want with:
N CTRL-^
where N is the number of the buffer you want to open.
I haven't found any other buffer explorer as fast. However, as Benj said, if you often work with many files you'd better choose something like bufexplorer or selectbuf (a kind of bufexplorer more customizable).
You also can try 0scan plugin. Just press 0b and select buffer or enter tags like dir name or extension of part of the file name to reduce selection list size.
If you selected buffer but it wasn't the only one from the list you can select next or previous after with keys 0j and 0k. Good if you need to switch between buffers from certain dir or with certain extension.
I first tried minibufexpl but noticed some strange characters would show up while in insert mode, like repeating characters when typing a space character or using navigation arrows or hjkl. Then uninstalled and tried BufExplorer, which I like better and the issue of strange charaters was resolved for me. I use vim on both my mac and ubuntu; and had the strange charater issue on both until I removed minibufexpl. My vim setup is here: https://github.com/pixelhandler/vim-config