I am using the method described in this screencast to keep my vimrc and plugins synced across multiple machines. The problem I'm running into is that one machine is running ubuntu and the other running win7.
I've found two types of problems so far. The first seems to be with line endings. To get my windows vimrc to be read on the linux box, I had to do :set fileformat=unix and write. But even after doing that, I am getting similar line-ending problems with all the plugins:
jg#jg-VirtualBox:~$ vim ~/.vimrc
Error detected while processing /home/jg/.vimrc:
line 11:
E484: Can't open file /home/jg/vimfiles/plugin/autotag.vim
Error detected while processing /home/jg/.vim/plugin/DrawIt.vim:
line 60:
E492: Not an editor command: ^M
line 62:
E15: Invalid expression: &cp^M
line 1290:
E171: Missing :endif
Error detected while processing /home/jg/.vim/plugin/auto_number.vim:
line 5:
E488: Trailing characters
I could do something like vim ~/.vim/**/*.vim to load them all and then :argdo set ff=unix | w to fix all the files in the same way, but that seems like a poor method, since any time I update the git repo with my vimfiles from one computer and pull it from the other, I'll have to remember to do this file conversion. Is there a better way?
Finally, certain configuration details in the vimrc, such as the location of the location of certain binaries, will be different depending on the OS. What is the best way to handle these differences? Should I be peppering my .vimrc with if statements branching on has("gui_win32"), or is there a better way?
Thanks!
Yes, you'll have to add branches in your vimrc to have machine/OS-specific settings. That's not as dirty as it sounds: a single if/ifelse/endif is enough.
Another approach is to keep your machine/OS specific settings in a separate non-version-controled file: because it is very localized, you don't need to propagate its contents on other machines/OSes.
You could put these settings in ~/.vim/vimrc.local and explicitely add this file to .gitignore or outside of the repo in ~/.vimrc.local and source that file from your vimrc.
Vim has troubles with Windows line endings on Linux but it doesn't have troubles dealing with Linux line endings on Windows. Just use Linux line endings everywhere and you'll be fine.
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.
We have a few work flows where we want to use git repositories mounted on NFS network shares. This generally works well, with the exception of line endings. Obviously, line endings on Linux and Windows differ, so a git status on the CentOS host may show no changes, and a git status in the same directory on Windows shows all files as modified.
Can any of the various git mechanisms to deal with line endings be configured to support this scenario ? We only want Unix-style line endings in our repos, of course, and we don't really care about the Windows SEEING the Unix line endings, but on occasion, a Windows tool will add or accidentally convert files, which we would then not want checked in with those endings.
There are a couple possible solutions here. The best solution depends on whether you care about the endings in the working tree.
If you always want line endings in the repository to be LF, and you don't care about the working tree, you can set the following in the .gitattributes file in your repository (creating it if it doesn't exist):
* text=auto
That will make Git guess whether a given file is binary or text, and if it's text, it will perform conversion to the proper line endings when it's checked out. On Unix, the proper line endings will be LF, and on Windows, usually it will be CRLF (although you can use core.eol to override that).
If you always want line endings in both the objects and the working tree to be LF, then you need to do a little more work. You need to set each individual text file type appropriately with eol=lf:
*.c text eol=lf
*.h text eol=lf
The reason this is necessary is because eol=lf overrides text detection, which means it's not safe to apply to binary files, such as PDFs or JPEG files. If you applied it to all files in your repository, you'd corrupt any binary files that happened to contain a CRLF.
Regardless of which you do, you should do a git add --renormalize . and then a git commit. That will ensure that all of your files in the repository contain LF endings and they'll be checked out with the appropriate endings whenever Git checks them out. That doesn't prevent Windows tools from dirtying the repository with CRLF line endings, but if they do that by accident, only LF endings will be checked in.
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 was looking to get into learning a text editor for programming. However, I've quickly run into a little snag that I can't seem to find a solution to.
I have modified my /home/user/.nvimrc file to add some plugins and I can load it using :source ~/.nvimrc, however, it never loads automatically. :scriptnames shows a list of scripts in /usr/, but mysteriously absent from the list is the .nvimrc file in my home directory. Again, I can load it in the command line, but I'd like to not have to use :so ~/.nvimrc every time I open a file.
I am not using sudo to run vim.
How can I solve this problem? Is this something everybody has to do?
Could be this issue: https://github.com/neovim/neovim/issues/3530
Summary:
New location is ~/.config/nvim/init.vim
To keep ~/.nvimrc you can source it from the new location:
mkdir -p ~/.config/nvim
echo 'source ~/.nvimrc' > ~/.config/nvim/init.vim
Instead of referring to your rc file directly, consider using $MYVIMRC:
:e $MYVIMRC
:source $MYVIMRC
Reference: Learn Vim the Hard Way/Editing your vimrc
:help config lists the paths for each OS:
Unix ~/.config/nvim/init.vim (or init.lua)
Windows ~/AppData/Local/nvim/init.vim (or init.lua)
$XDG_CONFIG_HOME $XDG_CONFIG_HOME/nvim/init.vim (or init.lua)
When I open a file from Windows Explorer using right-click -> Edit with Vim, Vim creates a "Program" folder on the root, and a "Files" folder in the directory of the file I've opened. The Files folder includes Vim/vimfiles/doc. There are no files anywhere, just the directory tree.
This also happens when I run Vim without a file name as an argument.
A DOS Box flashes just before Vim opens, but it goes away too fast for me to read what it's saying.
I've used Vim for years and have never seen this behavior. This is the first time, however, that I've used it on Windows 8.1.
Any suggestions or ideas? I'm getting really tired of deleting Program and Files folders all over the place. Lol!
You could follow the steps on Vim-FAQ 2.5. Some relevant parts follows:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
If the problem does not occur, when only loading your .vimrc file, the
error must be caused by a plugin or another runtime file (indent
autoload or syntax script). Check the output of the :scriptnames
command to see what files have been loaded and for each one try to
disable each one by one and see which one triggers the bug. Often
files that are loaded by vim, have a simple configuration variable to
disable them, but you need to check inside each file separately.
There is additional information on the link if the steps above doesn't solves the problem.