I'm following a tutorial on Uniswap forking (just to learn how this works) and I'm stuck a particular step.
How does one go from:
vim migrations/2_deploy_contracts.js
to
I'm only able to see:
How do I see the folders and directories ?
The user in that particular video is using the NERDTree plugin for Vim. Vim is very powerful and extensible, and it's possible to load a variety of extensions written in Vimscript to customize the interface, add editor features (such as LSP support), or various other functionality.
They're also using a custom colorscheme which is probably based on the Solarized palette. You can also load a custom colorscheme with the :colorscheme ex command.
There is another thing to notice, besides mentioned NerdTree plugin.
I think you are running your command from the wrong place.
vim migrations/2_deploy_contracts.js
This command tries to open the file set by relative path, or creates a new file, if that does not exist. As we see from your screenshots - the file exists in the tutorial, but it does not exist on your machine (the [+] mark after the filename on the second screenshot shows that).
My guess you need to cd to the right directory first (tutorial project root) and then only run your vim command to open the file.
As for your question about seeing the files and directories, you can do it without NerdTree plugin, using built-in netrw. Just type :Ex in vim normal mode.
By default, Vim looks for colorschemes in the <runtimepath>/colors/ directory.
Is there a way to specify a different directory name, or to specify an additional directory that vim can in look for colorschemes?
The purpose of wanting additional directories is for organizing colorschemes from third-party sources.
'runtimepath' actually is a comma-separated list of directories. Each of those can contain the common structure of plugin, autoload, colors, etc. Vim is considering all of those trees for its configuration.
So, to separate third-party colorschemes, you can put them in ~/.vimstyles/colors/ instead of ~/.vim/colors, and augment the runtimepath in your ~/.vimrc:
:set runtimepath+=~/.vimstyles
Package management
If your requirement actually is having a separate directory structure for each colorscheme (or more general: plugin), Vim 8 provides a built-in way for that: :help packages. These are directores below ~/.vim/pack/ that are automatically added to the runtimepath. pathogen.vim has been offering something similar also for older Vim versions.
Plugin managers build on top of that and enable features like automatic updating from various sources, dependency management, and so on.
I need to source some configuration lines after loading a plugin called [utl.vim][1].
The documentation says, I need to put these configurations into after-directory:
[23] NOte that you cannot include this line in your .vimrc because it is
:source'd before utl_rc.vim (which defines g:utl_cfg_hdl_mt_generic).
So either include/change it at <url:config:#r=utl_cfg_hdl_mt_text_directory>
or include it in the after-directory, see <url:vimhelp:after-directory#5.>
I created a file called utl.vim inside ~/.vim/after/ directory.
But this file is not sourced. I verified this using :scriptnames.
How to assure that Vim sources this file after loading utl.vim plugin?
The list of files/directories loaded by Vim is described at :help startup. Despite it lists the plugin directories, it doesn't mentions the after directory, so what you are seeing is the expected behavior.
Usually the after directory is source for filetype plugins, as explained in Vim FAQ 26.3 - "How do I extend an existing filetype plugin?". It is possible that the plugin will run something like :runtime! after/**/*.vim, but if the documentation is unclear will should ask to the plugin author, because it would be probably easier for users to be allowed to set this variable, and them the plugin could append/prepend default values to it
How can I change the location of the .vim folder and the .vimrc file so that I can use two (or more) independent versions of vim? Is there a way to configure that while compiling vim from source? (maybe an entry in the feature.h?)
Why do I want to do such a thing?:
I have to work on project that use python2 as well as python3, therefore I want to have two independent vim setups with different plugins, configurations etc. Moreover, one version has to be compiled with +python, the other with +python3.
You can influence which ~/.vimrc is used via the -u vimrc-file command-line argument. Since this is the first initialization, you can then influence from where plugins are loaded (i.e. the .vim location) by modifying 'runtimepath' in there.
Note that for editing Python files of different versions, those settings (like indent, completion sources, etc.) are taken from filetype plugins which are sourced for every buffer separately, so it should be possible to even edit both Python 2 and 3 in the same Vim instance. (Unless you have some badly written plugins that define global stuff.) So for that, some sort of per-buffer configuration (some :autocmds on the project path, or some more elaborate solution (search for localrc plugins or questions about project vimrc here) might suffice already.
Also note that when the Python interpreter (which you'd only need for Python-based plugins and some interactive :py commands, not for editing Python) is compiled in with dynamic linking (which is the default at least on Windows), you can have both Python 2 and 3 support in the same Vim binary.
I think the easiest solution would be just to let pathogen handle your runtimepath for you.
pathogen#infect() can take paths that specify different directories that you can use for your bundle directory.
So if your .vim directory would look like this
.vim/
autoload/
pathogen.vim
bundle_python2/
<plugins>
bundle_python3/
<other plugins>
Then inside one of your vimrc for python 2 specific stuff you would have
call pathogen#infect('bundle_python2/{}')
and for python 3 specific stuff you would have
call pathogen#infect('bundle_python3/{}')
Since each plugin folder is really just a .vim folder you can place your python specific configuration stuff in a folder of the corresponding bundle and pretend its a .vim.
This structure also has the added benefit that you can change both configurations at the same time if you feel like it by putting common stuff in .vim normally.
You can also pass multiple bundle directories if you feel like to pathogen so you can have plugins that are shared without duplicating files. You just do this by passing multiple paths to pathogen#infect('bundle/{}', 'bundle_python3/{}')
After this is all done you can just create aliases for vim to call the correct vimrc file.
I found a way to do this!
You can just create a fake $HOME, whose contents are simply the .vim folder and .vimrc. Then, when running vim, set the HOME environment variable to that folder, and change it back on VimEnter.
Run vim with:
OLD_HOME="$HOME" HOME="$FAKE_HOME" vim
Add this to your .vimrc:
autocmd VimEnter * let $HOME = $OLD_HOME
On Windows you can use
let $HOME = $HOMEDRIVE.$HOMEPATH
insetead, no need to store the old home.
This works, but if you use $HOME inside your vimrc or any plugins will see the old value, it might affect them somehow. So far I haven't seen it.
Note: I don't really recommend doing this.
If you really really want to recompile vim so that it uses a different vimrc and different configuration directory take a look at src/feature.h
Search this file for USR_VIMRC_FILE. Uncomment it and place the name of your vimrc here. This will change the defualt vimrc file.
So it should look something like this
#define USR_VIMRC_FILE "~/path/to/vimrc"
Inside src/os_unix.h or src/os_mac.h and search for DFLT_RUNTIMEPATH. Change all instance of ~/.vim to whatever folder you want. This should set the default runtime path that vim searches for settings.
How do I specify Vim settings for all files under the current directory?
The ideal solution would be if Vim searched for and read a .vimrc in the current directory before searching for ~/.vimrc, and apply the settings there for the entire tree.
I've seen a plugin, but this means the applied settings aren't transparent since they require the plugin to be installed. In contrast, a modeline is transparent since regardless of a user's vimrc or specific vim invocation the modeline settings will be applied for that file.
Things I tried are
placing a .vimrc in the working directory
:so vimrc in the modeline.
I suppose both don't work for security reasons. I don't need the full power of a vimrc; being bound to settings acceptable by a modeline would suffice. My goal is to make it easier for vimmers to adopt coding standards in a project.
You can put something like this in $VIM/vimrc
autocmd BufNewFile,BufRead /path/to/files/* set nowrap tabstop=4 shiftwidth=4
I'd strongly suggest not using set exrc
Even with set secure, under *nix, vim will still run autocommands, shell, et al, if you own the file. So if you happend to edit a file in that tarball I sent you with a .vimrc containing:
autocmd BufEnter * :silent! !echo rm -rf ~/
you'll probably be less amused than I will.
I'm an advocate of the plugin way.
For several reasons:
Modelines are particularly limited: we can't set variables (that tunes other (ft)plugins, like "should the braces of the for-snippet be on a newline ?"), or call function from them (I don't limit myself to coding standards, I also set the makefile to use depending on the current directory)
DRY: with modelines, a setting needs to be repeated in every file, if there are too many things to set or tunings to change, it will quickly become difficult to maintain, moreover, it will require the use of a template-expander plugin (which you should consider if you have several vimmers in your project).
Not every one uses vim to develop. I don't want to be bothered by other people editor settings, why should I parasite theirs?
It's easier to ask vimmers to install a same plugin, instead of asking them to copy-paste, and maintain, the same lines in their .vimrc
The settings can be saved with the other project files (cvs/svn/git/whatever)
It's really easy to have a configuration file per project -- with the plugin, I have a global configuration file for the coding standards of the overall project, and specific configuration files for each sub-project (which makefile to use, which executable to call, ...)
BTW, sth's solution can be used to source a single configuration file. This is very similar to the plugin approach except the .vimrc has to be parasited with non global options, and it does not support easily multiple/shared configuration files.
This question is old, but it seems like a pretty natural and persistent concern.
My solution is pretty simple. I place a .vimrc file in the root directory of my projects. The first line of the .vimrc file usually sources ~/.vimrc, and then adds the particular configuration I want. I alias tvim='vim -u .vimrc', and use tvim in my personal project directories. "tvim" for "trusted vim," meaning that if I execute it in a directory with a .vimrc file and something goes wrong, I've got no one to blame but myself, since I explicitly said I trusted it. Also, I keep a group of these stored away so that I can sometimes just softlink the one I want for a particular kind of project.
Placing a .vimrc in the working directory actually is supported, only disabled by default. See :h 'exrc' and :h startup for details, setting 'exrc' will enable reading .vimrc from the current directory.
It's also recommended to :set secure when using this. This locks down :autocmd, shell and write commands for .vimrc in the current directory.
Another thing that might be worth looking at is setting up a session (:h session) with a standard view and settings for the project.
All that said, I would probably go with the plugin option detailed by Luc Hermitte myself.
To minimize security risks with ANY "autorun" features for ANYTHING these days, may I advise you to utilize vim's existing features instead of plugins (portability baggage)?
Eg.
My local folder's vimrc file is named "_gvimrc" (on purpose). This reduces the hope for people like phen from amusing himself at our expense. :-)
In my $VIM/.vimrc file, I inserted:
if filereadable("_gvimrc")
source _gvimrc
endif
at the end.
I use "filereadable()" over "fileexists()" as the later has some quirkiness when tortured with opening multiple (10+) files simultaneously, (not sure why).
Of course, you can give your own unique filename to obfuscate potential trouble-makers further. Such as "_mygvimrc", "_gobbledygook", etc. You just need to settle on one standardized name and source it accordingly in your $VIM/.vimrc. Relying on vi/vim internals for this rules out portability issues. BUT, DO NOT name it .vimrc (or _vimrc) to prevent recursive sourcing in case you're editing the $VIM/.vimrc file with vim later.
Been using this since Windoze 98SE, through Windork XP Pro, and now Windorkier 7 (5+ years already). I'll mark a list of .txt files in Explorer and then use "Edit with multiple Vim", resulting in multiple vim windows opening simultaneously. For my work, I do this several times a day, daily. All files got treated with what I set in my local _gvimrc.
Use "editorconfig"
If the kinds of coding standards you would like to enforce are related to indentation style, tab size, file format and charset, then you might want to look into "editorconfig", which is a cross-editor standard to specify this kind of settings in a specific project, and have all editors follow that configuration.
The "editorconfig" specification allows projects to request different settings depending on file extensions or names within the project. (So you can have Makefiles using TABs, your Python scripts using 4 spaces and your shell scripts using 2 spaces for indentation.)
You need a plug-in to use "editorconfig" in Vim. The official website provides one, but personally I'd recommend sgur/vim-editorconfig, which is written in pure Vimscript, so you don't need to worry about external dependencies too much.
Since "editorconfig" aims at cross-editor compatibility, it's quite limited in what it does, so if you want is consistent whitespace, file format (DOS vs. Unix) and encoding (Unicode utf-8, etc.), then "editorconfig" is for you.
Assuming people aren't adding files every few days, you can probably add a modeline at the top of each file. In fact, if your version control system allows it, you could probably enforce a rule that says that each file must have a modeline when it's checked in.
I agree with the plugin approach for security reasons.
There is a very good plugin which has not been mentioned yet. It lets you use a .lvimrc in your project directories.
Try "localvimrc" out:
http://www.vim.org/scripts/script.php?script_id=441
https://github.com/embear/vim-localvimrc
Try vim-localrc
~/
|- .local.vimrc (1)
`- project/
|- .local.vimrc (2)
`- src/
|- .local.vimrc (3)
`- main.c
https://github.com/thinca/vim-localrc/blob/master/doc/localrc.txt
I looked at the plugins that existed and didn't really fancy any of them, so I wrote a simple function that piggy backs on vim-fugitive. The advantage of this is that it knows the root of the project is always the root of the repository, and additionally I can hash the file to keep a trust table. Just put the following in your .vimrc file.
function LoadRepoVimrc()
let l:path = fugitive#repo().tree('.vimrc')
if filereadable(l:path)
let l:sha1 = fugitive#repo().git_chomp('hash-object',l:path)
if !exists('g:SAFE_VIMRC') | let g:SAFE_VIMRC = {} | endif
if has_key(g:SAFE_VIMRC,l:path) && g:SAFE_VIMRC[l:path] ==? l:sha1
execute 'source '.fnameescape(l:path)
elseif confirm("Trust ".l:path."?", "&Yes\n&No",2) == 1
let g:SAFE_VIMRC[l:path] = l:sha1
execute 'source '.fnameescape(l:path)
else
execute 'sandbox source '.fnameescape(l:path)
endif
endif
endfunction
autocmd User FugitiveBoot call LoadRepoVimrc()
set viminfo ^= !
If the ! option is set on the viminfo setting, then the SAFE_VIMRC dictionary will be preserved between runs (note the ^ to prepend the option so it doesn't mess up the n option).