I've got a computer with windows 7 in which I've recently installed Git (with Vim inside the Git directory). I tried installed pathogen and apparently it is installed correctly since there are no error messages with pathogen in autoload. My _vimrc is located in Users/Username which is $HOME and it the following is relevant to pathogen.
execute pathogen#infect() //_vimrc starts with this line
call pathogen#helptags()
syntax on
filetype plugin indent on
the path to autoload and bundle is:
C:/progra~1/git/usr/share/vim/vim74/autoload(and vim74/bundle)
When I clone a plugin (ex. NerdTree) to bundle, the following message appears when I open Vim.
Error detected while processing /usr/share/vim/vim74/bundle/nerdtree/plugin/NERD_tree.vim:
line 16:
E15: Invalid expression: exists("loaded_nerd_tree")^M
line 211:
E171: Missing :endif
I also start a session in vim and use
:help NERD_tree.txt
but it returns "Sorry, no help for NERD_tree.txt"
Does anybody know what is causing the problem and has the solution?
First
All your configuration is supposed to happen in $HOME/.vim/ (plugins, colorschemes, etc.) and $HOME/.vimrc (options, mappings, etc.). Note also that, since Vim 7.4, it is possible to have your vimrc directly inside $HOME/.vim/, which makes managing your configuration even easier.
Whatever you did in /usr/share/vim/ should be reverted ASAP.
Second
But your issue is caused by line-endings: the cloning process changed the ones used by the author — lf — to the standard ones on Windows — crlf. Because Vim only accepts lf it was unable to source your plugin.
The cause is most likely the value of core.autocrlf in your Git settings.
The command below should prevent Git from converting lf to crlf upon checkout/clone/pull/etc.:
git config --global core.autocrlf false
Related
I am trying to build some code in Linux and I am getting the error:
'\r': command not found
Now I know this question has been asked in general before and I have already read the answers to them. In this question I am asking for a clarification for my particular situation.
In those questions, the reasons for that error has already been explained: The existence of an invisible character that gets interpreted as a command.
One suggested solution has been to modify the files to eliminate those characters. This solution is not feasible in my case for two reasons:
It is impractical to go and modify all the files involved
It has been expressly ordered to me that I cannot modify the files.
One solution recommended here and here suggest to modify the EOL behavior in Cygwin by setting an option to ignore CRs:
The problem is that this igncr option has so few documentation that I couldn't find details on this. Is this option available for linux systems too?
(For reference I am working on a git bash in windows to manage the repository but I build the code after transferring it to a linux workstation inside a docker container)
The other possible solution I found was this one in which it was suggested to modify the git settings in order to configure Git to not convert line endings on checkout:
How does this config works? In the linked answer it says
git config --global core.autocrlf input
when I do git config --list in my windows machine I get
core.autocrlf=true
Should I change the config and clone my entire repository again??
I am looking for clarifications on these two possible solutions but any other solution (that does not involve modifying the files) is fine too
Just for reference
I git manage locally a repo on a windows machine. Once finished I transfer the code to a remote linux machine and I build the code there. There is where the problem with \r appears
First, for reasons explained in "What is the correct core.autocrlf setting I should use?", make sure to add:
git config --global core.autocrlf false
Second:
try and fix your partical file eol (dos2unix or other commands), and
add in a .gitattributes file a myfile eol=lf directive to force said file to keep the right end-of-line sequence.
I have a git cli wrapper that I use from inside a nodejs application, and I recently noticed that when I try to add files which have a name with non ASCII characters in it, like tèst.ò, those files are simply not added. No errors are generated. If I try to add a file which does not exist, an error is generated.
I created the very minimal test case, which consists of just a line inside a bash script:
#!/bin/bash
git add "èè.md"
and it fails as well. Note that on a couple of Linux boxes I own, it works.
What is happening?
git is 1.7.x, OSX is 10.9.3.
The problem is with git < 1.8.5.x
Any other git version works. Solved upgrading git.
I have Solarized installed via pathogen and it's been working fine in both terminal and MacVim on my Mac. Today, I tried setting up an Ubuntu box on Linode. I just cloned my dotfiles and symlinked to my .vim and .vimrc folders (this is the same setup as I use on my local machine.
Whenever I try to run vim on the Ubuntu box I get an error
Error detected while processing /root/.vimrc:
line 43:
E185: Cannot find color scheme solarized
Press ENTER or type command to continue
I can tell my .vimrc is being loaded because all other setting like line numbers are working.
The related lines in .vimrc are the following:
" settings needed for solarized colorscheme
syntax enable
set background=dark
let g:solarized_termcolors=256
colorscheme solarized
This is the setup of my .vim/bundle directory (incase you suspect I don't actually have solzrized in there!):
~ ls .vim/bundle
ack coffeescript liquid snipmate vim-colors-solarized vim-jst zencoding
closetag html5.vim nerdtree surround vim-javascript vim-rails
One other thing, running echo &t_Co in vim on the ubunto box gets me 256.
Any ideas?
I was running into this problem just now, too. I had my call pathogen#infect() line in my .vimrc just fine, but was getting the
E185: Cannot find color scheme solarized
error, like you. I moved my call pathogen#infect() up to the top of my .vimrc and all is swell now. Try that if you're still having problems!
I know that it is kind of obvious, but did you check the contents of ~/.vim/bundle/vim-colors-solarized? Just in case you are running in the same issue described in Vim: Pathogen not loading
:colo[rscheme] {name} Load color scheme {name}. This searches 'runtimepath'
for the file "colors/{name}.vim. The first one that
is found is loaded.
You should put solarized.vim in ~/.vim/colors/.
This is what I did;
cp ~/.vim/bundle/vim-colors-solarized/colors/solarized.vim ~/.vim/colors/
I just ran into this problem myself on a new CentOS box where 'vi' was mapped to a version of VIM without syntax support (ie. -syntax) and was giving the E185: Cannot find color scheme solarized error, while 'vim' mapped to a version with syntax support and worked fine with solarized.
Aliasing 'vi' to 'vim' resolved the issue.
For reference:
To check if the version of vim that you are running has support for syntax highlighting, run :version from within vim. -syntax means no support, +syntax means it has support.
To create the alias, append alias vi='vim' to your ~/.bashrc or ~/.bash_profile
To re-source, type source ~/.bashrc or source ~/.bash_profile, whichever is appropriate for your setup.
One step you might be missing is to add
call pathogen#infect()
to your .vimrc file.
Src: http://www.vim.org/scripts/script.php?script_id=2332
I was getting this problem and I fixed it by issuing
cd ~/.yadr
git pull
rake update
I fix it ;)
Found this bug:
https://github.com/altercation/vim-colors-solarized/issues/104
cp ~/.vim/bundle/vim-colors-solarized/colors/solarized.vim ~/.vim/colors/
As Ryan Ransford said:
With the new version of vundle (Vundle.vim),
it appears as though "colorscheme solarized" must
come somewhere after "call vundle#end()".
This works for me!
I have the same issue and resolve it after moving color setting after call vundle#end() in ~/.vimrc
...
Plugin 'jnurmine/Zenburn'
Plugin 'altercation/vim-colors-solarized'
call vundle#end() " required
filetype plugin indent on " required
if has('gui_running')
set background=dark
colorscheme solarized
else
colorscheme zenburn
endif
I have a remote SVN repository and a local git repository. Using git-svn I have linked git to SVN and am successfully using git svn rebase, git svn dcommit to pull and push to the remote SVN repository.
However, when other people check out my previously-git-edited files with SVN and try to open them in VS2010, they receive a dialog telling them the line endings are inconsistent.
I've read a few things about the core.safecrlf option in git config, but would that fix my issue? I have a number of other people checking in, but we're all running windows - I figured the line endings would be the same?
Would setting core.safecrlf preserve the same type of line ends on checkout and on commit?
I have been dealing with this same issue lately. By default, Git on Windows sets core.autocrlf = true. What happens is that your files are checked out from the SVN repo with CRLF line endings, but are committed with unix-style (LF) line endings. When you dcommit those changes, I believe the files are pushed to the SVN server with the unix-style line endings as well. Now when someone checks out those files using SVN, no line ending conversion is performed.
You can set core.autocrlf = false so that no conversion is done. If you are all working in Windows, you shouldn't have any problems. If you are sharing the SVN repo with *nix users, then it is likely that you'll start having inconsistencies. This is the reason for the autocrlf option. The repos should remain consistent, and since Linux doesn't like to play nicely with CRLF, this autocrlf should be set to true.
Line endings problem is a well-known headache of git-svn. I would recommend to use SmartGit to work with your repository. I respects svn:eol-style value to use correct EOL in Git (translating to it to a corresponding .gitattirbutes value). You may also control svn:eol-style value on pushing to SVN by appropriate changes .gitattirbutes.
If you have an access to the server another approach is possible: just install SubGit into your SVN server. Then a linked Git repository will be created on the server such that every push to it will be automatically translated to SVN and vice versa. It also translates svn:eol-style to .gitattirbutes.
So I would recommend one of these solutions, but not git-svn that is (as I know) painfully slow on Windows.
Here is a GitHub article that describes your choices for handling end of line characters in Git:
https://help.github.com/articles/dealing-with-line-endings
Essentially Git helps convert EOL on different OS's. SVN has similar functionality. You will need to ensure that they are set in a consistent manner.
Im new to Vim and am having trouble installing the sparkup plugin found at https://github.com/rstacruz/sparkup. I've copied the contents of the zip into the ftplugin folder and have tried to expand the div tag by pressing command e but appears.
Im stumped, any assistance would be appreciated
Make sure you have filetype detection enabled. That was the issue I ran into a while back on sparkup, with similar symptoms.
Try adding the following to your ~/.vimrc:
filetype indent plugin on
Most of the time, vim plugins come with specific help files, it does not seem to be the case for that one...
You can check the following things :
This a "file type" plugin : so it will only trigger when you are editing a *.html file. So make sure you're not doing your test on a new buffer but on a previously saved .html file.
Regarding your installation and the path of the sparkup files, make sure than sparkup.py and sparkup.vim are in ~/.vim/ftplugin/html (and not something like ~/vim/vim/ftplugin/html) or it won't work
Type :scriptnames it will list all loaded plugin : so somewhere in that list you should see sparkup.vim, if not it means it is not correctly installed or detected by Vim.
Regarding the shortcut to invoke sparkup, it seems to be <CTRL>e.
You can use vim version of Sparkup tailored for easy installation https://github.com/pyp/vim-sparkup.
With Pathogen
cd ~/.vim/bundle
git clone 'https://github.com/pyp/vim-sparkup.git'
With Vundle. Add this to .vimrc:
Bundle 'pyp/vim-sparkup'