I use perforce for my revision control, when I hit 'p4 change' it always opens up the list on emacs, and we all know the pain of deleting text in it. How do i change it to gedit or vim or anything else? My default text editor is gedit.
On the command line, set P4EDITOR either as an environment variable or in the P4CONFIG file.
From the command line,
p4 set P4EDITOR="C:\File Editor\editor.exe"
You can test that this was successfull by running the following command after, which should launch your desired editor.
p4 workspace
I had similar problem on my Windows system.
It always used to open clumsy notepad.
I am more comfortable with TextPad, so to change default perforce editor, I made following changes:
I opened System Properties and added new environment variable as following:
Name: `P4EDITOR`
Value: `C:\Program Files (x86)\TextPad 4\TextPad.exe`
After that open a new CMD and there you go !!!
For Notepad++ I needed to use this command -multiInst to trigger edits.
p4 set P4EDITOR="C:\Program Files (x86)\Notepad++\notepad++.exe -multiInst"
Try setting the EDITOR environment variable. Also, the command line p4 should have an option to specify an editor. Also, the .p4config file might have something as well.
Also need to check if EDITOR/P4EDITOR path is correct. If path is wrong, perforce will choose previously working editor.
In the case of WSL, likely your p4 binary is provided for Windows platform as the path and operations are most compatible there, so it's p4.exe most likely. Then simple wawy of setting editor in P4EDITOR is not just enough, we have to convert input argument of filepath which is provided in Windows-based into Linux path.
This solution dated back 19 years ago still works
The concept is to
Create a bash/shell script that accept the argument.
Then in the script we can use wslpath $1 to convert Windows path into Linux path.
The script can be just
#!/bin/bash
vim `wslpath $1`
I thought I might not be able to use Vim to edit change, or client spec of perforce and have to end up using whatever provided like Notepad (not against it, but I just want to use Vim). This solution works for me.
Related
I am trying to learn how to use Vim. Apparently I have failed at the first hurdle since Vim (certainly on my computers) cannot open files from within itself. I know this must somehow be a mistake on my part since how can Vim still be around with such a flaw??
Anyway I have searched for the last day or so with no solution.
I have tried:
:e .
And Vim helpfully tells me that: "." is a directory. I was under the impression that this command would open a file browser in current directory, but it doesn't.
Similarly I have attempted other commands:
:Ex
:Explore
:Sexplore
:Sex
:Vexplore
:Vex
:Hexplore
:Hex
I have tested these from How do you open a file from within Vim? but nothing suggested there works.
All of these produce: E492: Not an editor command: <insert any of the above commands here>.
I am left with the conclusion Vim can't open files unless Vim is called from the terminal and the file is passed as an argument or the files happen to be in the current directory (where ever that may be) and you know the file's name.
Can someone help? I would like to be able to open files in other directories and list them but for the life of me nothing is working despite every guide I have read saying it would.
Thanks.
At the request from Zaffy this question has been solved.
At Robby Cornelissen's prompting I checked the MX's Linux's package manager and found that vim-common was installed but weirdly not vim. Once I'd installed vim :e . worked and I can now navigate the filesystem.
I have no idea the difference between vim-common and vim or the reason for the separate packages; Robby Cornelissen suggests that vim-common is probably a minimal or tiny version of vim.
I'm trying to configure OpenSwan, an open source IPsec solution written in C.
I have a script to download a configuration file ipsec.conf on an Amazon Linux EC2 that was created on my Macbook and uploaded to S3.
When I start the ipsec service, it segfaults.
Curiously, if I open the configuration file with VIM, make no changes, and simply write/quit, it works. This lends me to believe somehow the file has some weird characters/formatting.
I know of dos2unix, which I ran on the configuration file but that did not prevent the segfault.
I'm wondering what exactly VIM is doing when I write/quit. I could script that operation on my configuration file after pulling it. Or anything else that would help me understand what's going on.
First, try to open the file with vim, then exit vim (:q) without having saved the file before. If vim says File modified since last complete write; write or use ! to override., this means that this is not something that vim does when write/quit that changes your file, but that this is something that vim does when it opens the file. And this is the most common case.
Vim parses the input file depending on the locale, and if some characters can not be understood according to the locale, vim may forget them. So, when saving the file, those characters will be removed.
Now, use vim to save your file as ipsec-ok.conf.
And run the following command:
bash -c 'diff <(od -xa ipsec.conf) <(od -xa ipsec-ok.conf)'
This will display the differences between the original file and the one that works with OpenSwan. In ascii and hexadecimal formats. This way, you will find the unsupported characters that make OpenSwan dump a core.
I have a multitude of commands I'd like to run not in the current directory, but in the project root directory. i.e. going up directories until I reach some indication of a root, like .git directory for example.
For example running vimgrep -r (recursive) on all my project, or running tags generation recursively on whole project.
How do I get that path? The only close indication I found is this:set tags=./tags;~/Projects
But that just saves the string as it is into tags. Assigning something similar but for the use case described, gets me the string verbatim.
Any help is greatly appreciated!
Thanks!
Avoid the idea of "changing the working directory" or distinguishing between "working directory and project root", because almost no tool is prepared to properly handle those concepts.
The only tools that do (e.g. git) are those that don't care about the current directory to begin with.
Otherwise, it's madness to try to get everything working without bad side effects. "Working directory" is a concept too fundamental to even attempt to change within a running program.
The best approach is open a new Vim sessions inside directories where you want to do "local" things - and switch back to the "project" session to run project commands. Vim will protect you from accidentally overwriting changes in another session.
The alternative is to wrap commands in shells so they can have their "own" working directories, e.g.:
:!cd ../../..; ctags -R
(Which would allow you to regenerate tags file for the project, and not just the current dir)
or:
:!cd ../../..; grep -r foo **/*
But any output with file names would be relative to that root directory, and not the current one.
So you may prefer to do:
:!cd ../../..; vim
which creates a new Vim session within the current one, but in the context of the root directory.
Or, you may prefer the reverse (assuming Vim is running in the project root):
:!cd $(dirname %); vim
Which lets you work in the directory of the current file - and you'd have to exit to the main session to run project-wide tools again.
So instead of "changing" directories, you're "changing vim sessions" (either by having 2 sessions or "nesting" one in another like above).
I use a local_vimrc plugin to set project related variables. Then, I use (/write) plugins that rely on (buffer/project)-local variables to do stuff. (Unfortunately, most plugin out there rely of global variables which is not the best choice to specialize their behaviour to the current project in multi-projects sessions)
Regarding ctags generation, in use lh-tags that requires a few variables to be set.
Regarding grepping, as other, I usually start from the current directory which is often the root directory of my project. But you could also easily have a plugin/command that would run something like:
exe "vimgrep -r ".pattern." ".
\ map(file_extensions,
\ string(lh#option#get('project_root_directory').'/**').'v:val')
EDIT:
If you don't want other configuration files, and if the .git/ directory is enough to identify your project root directory, then, you can have this kind of function to get your project root directory:
function! ProjectRootDirectory()
return fnamemodify(finddir('.git', '.;'), ':h')
endfunction
Then when you'll run ctags, you'll have to execute ctags from the result of this vim function. I don't know which plugin you use to run ctags, at this moment. My lh-tags doesn't support functions through its configuration variables. It can easily been added if need be.
However, I don't see a simple way to configure &tags once from the .vimrc in order to configure this setting on a per project basis.
I personally like to keep it simple and have my current directory be my project root. I can use % to represent the current file in commands, e.g. :!git add %. Along with % you can use filename modifiers, e.g. :e %:h/foo.txt. See :h filename-modifiers.
However you mentioned that you use CtrlP and you like the way it changes the current directory. This means you need to be a bit more creative.
Here is what I would recommend:
Update your tags via git hooks. See Effortless Ctags with Git
If your tags are in .git/tags fugitive.vim will automatically setup these tags for you.
Use :Ggrep which uses git grep so it already know about your project root directory and as a bonus is much faster than :vimgrep.
Running arbitrary commands from the root is trickier. I use projectionist to manage my projects. Projectionist provides the command, :ProjectDo, which does exactly what you want.
Now a word of caution: Vim has no understanding of a "project". The closest thing to is 'exrc' option (See :h 'exrc') which is pretty lame.
In Vim, is it possible to change the default location of the user vimrc file, i.e., from $HOME/.vimrc to some other location ?
Another solution might be to create a symlink to you preferred location. I have my .vimrc in $HOME/.vim/.vimrc and symlink to it. This way I can have it in a git repo and backup it.
You must start vim with the command vim -u ./path/to/your/vimrcfile
vim -u NONE is a good way to start Vim without any plugin or customisation.
See :help starting.txt for more information.
The VIMINIT variable is my preferred method. The problem with aliasing vim with the -u flag is that if vim is opened in some way other than from the shell command your configuration won't get pulled in. Setting $VIMINIT does not suffer from this drawback. Check this out for more information.
export VIMINIT='source $MYVIMRC'
export MYVIMRC='~/.vim/vimrc' #or any other location you want
Note that Vim normally sets the MYVIMRC variable, though I'm not sure exactly what it's used for. Based on my testing, using VIMINIT in this fashion will result in it not being automatically set on startup as it would normally be. This is why I'm setting it myself.
This works for neovim too!
On Windows, I have the _vimrc that's in my home directory contain one line, source c:\path\to\my.vimrc.
I have not yet worked out a good way to move the entirety of my vimfiles folder, but that's less critical as it's all stuff I've installed from elsewhere. I.e., it'd be easy to restore if I lost it. (I know that I can change runtimepath but my problem is more coming up with a "good" way to do so.)
Update
After six years I extended slightly from what I mention in the comments below; as I put stuff into 'after' and wanted to just keep rtp clean I got something that has been solid for a while now. Today in my %USERPROFILE%\_vimrc I do hardcode the actual paths to things and it changes on every machine I use (and I basically do the same thing on *nix) but this gets copied around mostly-manually when setting up a new PC. I also have a version which I can use to launch Vim on another connected machine on the network, e.g. a co-worker's machine, so I get my config and all that, but the gist is:
set runtimepath^=E:/dotfiles/vim
set runtimepath+=E:/dotfiles/vim/after
set runtimepath-=~/vimfiles
set runtimepath-=~/vimfiles/after
runtime vimrc
and then %USERPROFILE%\_gvimrc just has one line:
runtime gvimrc
(Both vimrc and gvimrc are in the /dotfiles/vim folder and also on Bitbucket.)
I see two options, depending on your needs.
Have ~/.vimrc import the other location
create an alias in your bashrc alias vim="vim -u otherlocation"
I edited
C:\Program Files\Vim\_vimrc
and changed both the runtimepath and sourced my own .vimrc.
I also use these settings in Cygwin (and have them version controlled). So it's this in practice (added at the bottom of the _vimrc file):
let &runtimepath = 'C:\cygwin\home\cygwinaccount\.vim,' . &runtimepath
source C:\cygwin\home\cygwinaccount\.vimrc
Bliss ! :)
In linux:
You can edit .bashrc or .zshrc startup script and add the following lines to change the default location of .vimrc file
export VIMINIT='source $MYVIMRC'
export MYVIMRC='~/.vim/.vimrc' # Note the . (dot) before vimrc. If that is what you have called it.
I feel like the simplest solution is to just have a single line in ~/.vimrc that loads the vimrc from the other location, i.e.:
source PATH/TO/OTHER/LOCATION/.vimrc
I don't want to type /cygdrive/c/path/to/stuff, especially when using tools that don't know anything about cygwin. Is there a way to configure cygwin to autocomplete "c:\path\to\stuff" or even "c:/path/to/stuff"?
For tools that can't understand cygwin paths, you'll need to convert them to windows paths. The cygpath utility can do this for you:
notepad $(cygpath -w /cygdrive/c/path/to/stuff)
You can probably create aliases or wrapper scripts for commonly-used windows executables.
Autocomplete should be working after the /cygdrive/c bit. Make a symlink for "/cygdrive/c/" to something else, like "ln -s /cygdrive/c /c". Also, make sure your inputrc is set up correctly.
Windows itself can autocomplete paths, with some minor registry tweaks. Or am I missing something in this question?
use alias:
Open the .bashrc file already copied in your home directory and type (I use "vi" editor for this but you can use "pico" which is a bit easier):
alias C="C:\Documents\ and\ Settings\Administrator"
you can use any path here. Save the .bashrc ("Ctrl+X" in pico I think, and :wq in "vi") and close the terminal. After restarting this console, typing "C" and pressing enter will send you automatically to "C:\Documents and Settings\Administrator"
To know which alias you have, just type "alias" in your terminal and all your alias will show up.