I want to use GVim as a merge tool for TFS 2010.
I can't figure out the Arguments for GVim.
Specifically the argument %4, when I use it I get an empty buffer for it. if I don't use it I get an error message that I must use it.
This may not be exactly to your liking, but here's how I use GVim for a merge tool.
I set it up to do a two-way merge: it has the 'source' on the left (where I'm merging from), and the merge file on the right (starts off as what my destination branch has for information).
I set it up like this:
command: C:\Program Files (x86)\Vim\vim73\gvim.exe
argument: -c "vert diffsplit %1 " %4 -c "wincmd l|0read %2 |diff"
What this does is as follows:
Reads in the 'source' file on the left, and splits the window (-c "vert diffsplit %1")
Opens up on the right side the merge result (%4)
Runs a quick script which:
Moves over the right window (wincmd l)
Reads in my existing changes in the branch (0read %2)
Re-runs the diff algorithm (diff)
This lets me "diff" my work against the incoming merge, and saving the right hand side will resolve the merge.
Your screenshot suggests you are using Vim 7.3 . According to Vim site:
http://vim.wikia.com/wiki/Running_diff
At some point, the MyDiff function provided by the "Vim without Cream"
installer has been modified. As of Vim 7.3.138 it is still broken.
However, You can try the following verbose-mode parameters
command : gvim
argument: -V -od %1 %2
Related
this is a continuation of the following stack overflow question: Perforce diff for excel files
I'd like to use the solution proposed by domalb, which is to use SSCL. I've downloaded the SSCL solution and am able to successfully diff excel files when using the cmd prompt. However, I'm having trouble getting the arguments to work correctly in Perforce.
In perforce, I go to Edit -> Preferences and select "Diff" from the left menu. I then "specify diff application by extension (overrides default). I set the extension to .xlsx, set the application to sscl.exe, and set the arguments to %1 %2 -d="C:\Program Files (x86)\Microsoft Office\Office16\DCF"
However, this does not work. When I turn on verbose logging in the argument list, I see the following error message:
How can I resolve this error when passing in the SSCL arguments? It looks like it cuts off the directory at the first space, so it is not respecting the double quotes? Thanks for your help!
I frequently send files to Vim from Visual Studio. I have it set up as an external tool with the following parameter:
"+call cursor($(CurLine), $(CurCol))"
However, I also want to be able to call my own function as well. When I'm editing a file from VS I want the window to be large, so I expected to be able to do something like this:
"+call cursor($(CurLine), $(CurCol)); +call Embiggen()"
However, that doesn't work. I've tried a few variations (e.g. , call Embiggen(), etc).
Obviously I could write my own PlaceCursorAndEmbiggen function, but I don't really want to do that. Is there any way to call multiple functions on Vim startup?
Eureka!
Simply pass two strings:
"+call cursor($(CurLine), $(CurCol));" "+call Embiggen()"
Maybe the solution would have been easier to find had you used the alternative, more commonplace syntax: -c "cmd" instead of "+cmd". According to :help -c, you can pass up to 10 of these.
These exact commands can be combined into one using pipe symbol:
"+call cursor($(CurLine), $(CurCol)|call Embiggen()"
. There are much more that can be combined this way, but some like :normal can’t, use #Ingo Karkat’s or your own answer for them. If you are short* on +commands and still don’t want to create a .vim file you can use either :execute
vim -c "execute 'normal! 1' | execute 'normal! 2'"
or (bash/zsh) -S with process substitution:
vim -S <(echo '
normal! 1
normal! 2
')
. Though most of time it is better to just create a .vim file.
* You can pass up to 10 + or -c (they are equivalent and they are not counted separately) and 10 other --cmd, though letter is less useful.
As vim doc said, I can use the -b option to open a binary file.
-b Binary mode. File I/O will only recognize <NL> to separate
lines. The 'expandtab' option will be reset. The 'textwidth'
option is set to 0. 'modeline' is reset. The 'binary' option
is set. This is done after reading the vimrc/exrc files but
before reading any file in the arglist. See also
|edit-binary|. {not in Vi}
I use this command to open vim:
$ vim --cmd 'set et' -u NONE -b
I type this command to view options:
:set et? bin?
expandtab
binary
The et(expandtab) option wasn't reset. Why?
Thanks for your help!
Well the issue is, simply, that --cmd -c or +cmd arguments are executed after processing the other flags. This makes sense, as it would not effectively do anything otherwise.
:verbose set et?
would tell you exactly that. In case you need a workaround for your particular sample vim +'set binary' (unlikely since et != binary)
You are right on the docs for --cmd. So it comes down to the order in which command line flags are interpreted, which is basically 'undefined'. Although
This is done after reading the vimrc/exrc files but before reading any file in the arglist
could be taken to imply 'before processing other command line arguments'.
Note The '+' commands essentially go with specific files and are (AFAICT) processed in the order in which they appear, even when intermixed with filename arguments.
I'm using VIM 7.1 on Debian. I have 9 plugins that I load via pathogen.vim. It takes around 8 sec's to load which is quite slow since this is in non-GUI/xterm mode. I ran vim -V and it shows that each module is being searched for in multiple directories.
Initially, ftoff.vim, debian.vim and other "system" related .vim files are searched for in ~/.vim/ and then in /usr/share/vim/vim71/ - I fixed this by moving my .vimrc to .vim/vimrc and: export VIM=/root/.vim, within .vimrc i did a set runtimepath=/usr/share/vim/vim71
But now, when the modules load, they alter this runtimepath and when pathogen loads it's even worse. Is there a way to specify a hash of module-name to dirPath so that this error prone lookup is avoided? Or a way to manually specify runtimepath on a per module basis within vimrc?
Here is an example of my runtimepath after pathogen loads my modules. Obviously, any further loading of a module invovles searching all those pathnames before locating the right path.
runtimepath=~/.vim,~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bu
ndle/The_NERD_Commenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/pathogen,~/.vim/bundle/vim-addon-mw-utils,
/.vim/bundle/tlib,~/.vim/bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist
~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bundle/pathogen,~/.vim
bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist,~/.vim/bundle/The_NERD_C
mmenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/tlib,~/.vim/bundle/vim-addon-manager,~/.vim/bundle/vim-add
n-manager-known-repositories,~/.vim/bundle/vim-addon-mw-utils,/var/lib/vim/addons,/usr/share/vim/vimfiles,/u
r/share/vim/vim71,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/bundle/snipMate/after,~/.vi
/after,~/.vim/bundle/snipMate/after
I use vim-addon-manager and have 33 paths in rtp, but it takes around 0.7-0.8 seconds to start and immideately close vim (with vim -c 'qa!'), so the problem is either one of the plugins or your system. To check how long it takes to load each plugin, try the following script:
vim --cmd 'profile start profile.log' \
--cmd 'profile func *' \
--cmd 'profile file *' \
-c 'profdel func *' \
-c 'profdel file *' \
-c 'qa!'
You will get all timings in the profile.log. Table with function timings will be
present at the end of the file, to get per-script timings, use the following
script:
" Open profile.log file in vim first
let timings=[]
g/^SCRIPT/call add(timings, [getline('.')[len('SCRIPT '):], matchstr(getline(line('.')+1), '^Sourced \zs\d\+')]+map(getline(line('.')+2, line('.')+3), 'matchstr(v:val, ''\d\+\.\d\+$'')'))
enew
call setline('.', ['count total (s) self (s) script']+map(copy(timings), 'printf("%5u %9s %8s %s", v:val[1], v:val[2], v:val[3], v:val[0])'))
This will open a new file containing just the same table as at the end of
profile.log, but 1) for scripts, not for functions, 2) unsorted.
If problem is your system, you may try the following:
When computer starts create a ram disk and mount it to ~/.vim, then copy all plugins there.
Try merging plugins into a single file, see :h scriptmanager2#MergePluginFiles() (vim-addon-manager must be activated)
Upgrade your computer
Try creating a hardlinks to all plugins in ~/.vim:
cd ~/.vim/bundle;for d in *;do cd "$d";for f in **/*.vim;do t="$HOME/.vim/$(dirname "$f")";test -d "$t"||mkdir -p "$t";ln "$f" "$t";done;cd ..;done
it might not be related, but for me the variable DISPLAY makes a big difference in the time it takes to start vim (even when I have vim compiled without gui).
Try with
DISPLAY= vim
and
DISPLAY=:0 vim
and see if you notice a difference.
http://pastebin.com/R6E4czN7
I've pasted the output of vim -V to pastebin (should be valid for 1 month). It's self explanatory. There are a gazillion searches(414 search lines - most of them are useless). I need to reduce the number of incorrect searches.
1297651453.71068: Searching for "/root/.vim/bundle/pathogen/autoload/scriptmanager.vim"[J
1297651453.71456: Searching for "/root/.vim/bundle/snipMate/autoload/scriptmanager.vim"[J
1297651453.71846: Searching for "/root/.vim/bundle/SuperTab/autoload/scriptmanager.vim"[J
1297651453.78737: Searching for "/root/.vim/bundle/surround/autoload/scriptmanager.vim"[J
1297651453.79179: Searching for "/root/.vim/bundle/taglist/autoload/scriptmanager.vim"[J
1297651453.79684: Searching for "/root/.vim/bundle/The_NERD_Commenter/autoload/scriptmanager.vim"[J
1297651453.80756: Searching for "/root/.vim/bundle/The_NERD_tree/autoload/scriptmanager.vim"[J
1297651453.83: Searching for "/root/.vim/bundle/tlib/autoload/scriptmanager.vim"[J
1297651453.86193: Searching for "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.8662: line 3: sourcing "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.88259: finished sourcing /root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim[J
I prefer to edit in one large file rather than many independent files, but due to limitations in languages, source control, and the preference of team mates I need to output to many files.
What I'm looking for would recurse through all the files in a source directory and generate a single file to edit in VIM, with special file seperator markers. On save it would save the the changes to the correct file(s) ideally in a smart manner, based only on changes made.
Does something like this exist?
shar
Well, you could use shar(1), but it puts an X in front of each line that you will probably find annoying. (Shar came with my Mac but on my Linux systems you need to add a package.)
Shar is just, itself, a short shell script, so you could modify it easily enough to work without the X.
You might try copying /usr/bin/shar to /tmp and applying this diff with patch(1).
--- /usr/bin/shar 2009-07-13 22:26:18.000000000 -0700
+++ /tmp/shar2 2010-12-24 19:05:34.000000000 -0800
## -65,8 +65,8 ##
echo "mkdir -p $i > /dev/null 2>&1"
else
echo "echo x - $i"
- echo "sed 's/^X//' >$i << 'END-of-$i'"
- sed 's/^/X/' $i
+ echo "cat >$i << 'END-of-$i'"
+ cat $i
echo "END-of-$i"
fi
done
It reminds me of vimballs format. However, it's meant to expand files into the user runtimepath directory.
In other words, you can list all the files you want join and apply :MkVimBall (here is an example).
Then, for the extraction, you will have to momentarily (i.e. save and restore its value after the extraction) set &runtimepath to the root directory of your project before extracting with :so %.
You'll also have to play with various options like the &filetype, etc.
It's a dirty hack, but well ... it shall do the job.
Instead of dumping several files into one, processing this one and then separating stuff apart again, you could use bufdo or windo to repeat a command on all opened buffers: open the buffers to be processed, then cast the bufdo command and it will work on every opened file: http://vimdoc.sourceforge.net/htmldoc/windows.html#list-repeat