Vim: Mac vs. Linux ^M Problem - windows

I use Vim and GIT to develop my project on a Linux/Ubuntu machine. In the past, I used to use Windows, which means line ends were DOS format. Now after moving to Linux, I always see ^M confusing/annoying characters at the end of the line. Some people here:
How to convert the ^M linebreak to 'normal' linebreak in a file opened in vim?
suggested that I should make a find/replace or use tools like dos2unix. These are good suggestions, but with a version-controlled project it means I have to add unnecessary commits for the files after change, and it is a big task anyway that is not worth spending time on it. So:
Is there anyway to make Vim tolerant for this? That is, if the file is DOS line-ended, it keeps it like this, and use its formatting for new newlines, and so on.

I have added this line to my .vimrc file.
set fileformats=unix,mac,dos
If you don't know what a vimrc file is, it's simply the file that configure (and allows you to customize) your vim. By default vim will be looking for a file called .vimrc (notice the dot at the beginning) in the user's home folder. If it cannot find it, it will source it from /etc/vimrc.

Yes, you can set the following in vim to say it's a dos format file:
:set ff=dos
And, likewise:
:set ff=unix

The best answer I found is #Keith answer in the comments:
"With subversion you can set a property svn:eol-style=native that will cause it to convert line endings to.. native type for all platforms automatically. I don't know if git has that feature, but you might look into that first. It probably does."
And these links might be useful link is how to set:
http://help.github.com/dealing-with-lineendings/
http://git-scm.com/docs/gitattributes

Related

Globally Map "Escape Key" to "jj" in vim (mac)

I have been using vim for awhile but I have not been able to figure out how to map the escape globally - every time I open a file, I have to map the escape key to jj like this:
:imap jj <Esc>
Is there a way to change the runtime defaults so that Esc is already mapped to jj?
I found the default.vim file, but you cannot edit it on a mac (with standard mac software). Should I download something to edit this file? Is there another easier way?
Any help is much appreciated!
The place for your local changes is called .vimrc and you typically create one in your home directory with the commands you want to execute on startup.
Run vimtutor on the (system) command line and spend a few minutes learning how to use this editor. Then dig into the facilities provided by :help in Vim. E.g. run :help vimrc in Vim.

make reports "command not found" for an executable on my $PATH

I'm working on a project that requires me to convert a c++ program (prog1.cpp) to a unix text file. I'm using the command
dos2unix prog1.cpp
However, the files that my makefile makes aren't working as they should. make all is supposed to make an executable file hantow which is does, but upon executing hantow the shell reads:
-bash: hantow: command not found
My code is okay, no errors there. I can see there is a file called hantow in the directory and I've already ran
chmod 755 hantow
I wanted to ask if that's the only step you're supposed to take ie.dos2unix or are there any followup commands as well?
well, text-files are pretty universal with one big (or minor) issue: line-endings.
traditionally, text files use different line-endings on differents systems:
CRLF on W32
LF on Un*x
CR on MacOS
Luckily Apple switched to the proper Un*x line-endings when they moved to OSX (a while ago). So these days you will only find two different line-endings.
In the meantime, virtually any decent text-editor will handle text-files of any line-ending convention (I think the big exception is notepad.exe which still can only handle CRLF).
Also any C/C++ compiler will not care at all about the actual line-ending.
So there is no real need to convert a "c++ program to unix text file".
OTOH, I still prefer working with native line-endings whenever possible, and dos2unix is a perfect tool for that. (though modern VCSs will automatically handle line-ending conversion for you, so there is less demand for dos2unix these days).
Finally: your problems with hantow are not related to this.
To answer your specific question: dos2unix should usually be enough to convert the line endings of a file from CRLF to LF. There may be other reasons that the code does not execute, for example if the code uses some other OS-specific functions that are not available in your environment. Also make sure that your Makefile and other input files have the correct line endings. You can call file on the file, to see whether it outputs something like ..., with CRLF line terminators, in which case you might want to run dos2unix on them, too.

zsh tab completion messes up command line formatting

I'm running zsh with oh-my-zsh on OS X. Every time I use zsh's awesome tab-completion, formatting on the current command line prompt gets really screwed up. For example:
I'll be typing cd fo and try to tab-complete for the 'foo' directory; zsh prompts for completion but changes the command line to cd fo cd fo while it's waiting for me to complete. It's not a big deal but very annoying. Any suggestions?
I had the same issue on PopOS and Arch linux. I tried a bunch of solutions from various places but the only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
The solution is to make a copy of the .zsh-theme file of whatever theme you're using in oh-my-zsh and surround all non-ASCII characters (like emojis) with %{%G<CHARACTER>%}
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
solved the issue for me.
I have faced the same problem before, my solution was disabling some zsh plugins. The second probability is that your colour theme may contain a bug which causing this.
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
This is the final version of my plugin section in the ~/.zshrc file. Any other plugin between parenthesis may be the reason of your situation.
If your problem still continues you need to post your ~/.zshrc to let us check what is in there.
I had the same issue. Interestingly, I saw the problem only iterm2 while the prompt is correctly displayed in the standard terminal of OS X (after reverse-i-search/tab-completion). The reason seems to be that iterm2 defaults to Unicode (UTF-8) default encoding, which however is not correctly interpreted if the corresponding language variable is not set in the shell.
Solution: add the following to your .zshrc
export LC_ALL=en_US.UTF-8
The prompts will be displayed correctly.

How to set my GVim to be feel like IDE?

Currently, I'm using GEdit as my text editor for editing Ruby and Javascript source codes. I would like to give GVim a try to be my editor choice. I have tried to follow https://github.com/akitaonrails/vimfiles and few others instructions, but I don't get any luck, when I source ~/.vimrc, then I always get:
bash: /home/samnang/.vimrc: line 5: syntax error near unexpected token ('
bash: /home/samnang/.vimrc: line 5:call pathogen#runtime_append_all_bundles()'
Could you point me somewhere to get the instruction or configuration?
Environment: Ubuntu 10.10
Edit: If I don't source it, when I type vim or gvim, then I got:
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault
You need to run source ~/.vimrc as an Ex mode command. That is, inside Vim itself, hit : and enter the command:
:source ~/.vimrc
Right now, you're running Bash's source command, which is entirely not what you want to do.
~/.vimrc is the configuration file for vim, and will automatically be read by vim when it launches in order to know how you want it set up. You can add your non-graphical vim commands, such as key mappings, abbreviations to ~/.vimrc/. In ~/.gvimrc you can add commands to set your colorscheme, the default number of columns and rows displayed at startup, etc.
If you aren't familiar with vim itself type vimtutor at the command-line and go through the tutorial.
To start gvim, type gvim at the command-line. To edit a file you can either open gvim, then use :e file/to/load in comman-mode, or do gvim file/to/load at the command-line. gvim supports multiple windows and tabs as does vim, so study those things to make the most use of them.
You can also try integrating Vim with eclipse if you want to bring IDE functionality to Vim (like projects, error highlighting, code completion, etc).
If you're interested check out the eclim project. It supports most of the modern languages, including Ruby, and I highly recommend it.
Try adding a .vim or vimfiles in your $HOME directory. If it still fails, add a file to the .vim directory. I did a
cd
mkdir .vim
cd .vim
touch .netrwhist
chmod g+w .netrwhist
I discovered this while learning about building your own syntax files at vim wikia creating your own syntax files

How do I hide the eol doc chars ^M in VIM

In gvim on windows if I have text with CRLF eol then the text will display ^M at the end of each line.
How do I 'hide' that special char from display?
The :set nolist command """ does not dismiss it.
UPDATE
I did :set fileformats=unix,dos as a list. It didn't work at first, but I closed the file and reopened it again and it worked.
By default I had set fileformats to only unix value.
Thanks for answers.
You may want to set fileformat to dos.
:ed ++ff=dos %
To hide them:
:set fileformats=dos
To remove them (so you can later save the file as a unix file):
:%s/\r//g
While convening on the DOS or Unix format once and for all is of course the preferable approach, sometimes some co-workers just don't care enough about proper source management to make their editors behave.
In those desperate cases, instead of converting the file completely (resulting in a file completely rewritten by yourself according to the SCM, rendering the “blame” function useless), I found it preferable to just pretend that the problem doesn't exist. If the compiler is accommodating, and PHP by all means is, you can have a mixed-EOL file look perfectly cool with the following command:
:match Invisible /\r$/
Or in newer versions of VIM 7.4+
:match Ignore /\r$/
To make things even worse, most GUI editors don't end a text file with a newline, and when a file does end with a newline, they show an empty line at the bottom. Since this is kind of annoying, most people will remove that empty line, which will result in a mixed-EOL file (and the dreadful ^Ms shown in Vim) if the file format was DOS.
If anyone knows how to make Eclipse or NetBeans honor the newline termination without showing the empty last line (as Vim cleverly does), please share your knowledge and you'll make a coder happy here. ;-)
The file format is usually automatically detected. You must have mixed Unix and DOS/Windows lines in your file.
try this to clean it up (where "clean" = unix format):
% tr -d '\015' < old.file > new.file
:0,$ s/<ctrl-v><ctrl-m>//g
:set ff=dos
I'd like to point out that if you are using full blown VIM (at least on my ubuntu 9.10 box) it "does what you want" and auto-hides it, but the stock vi (and vim-tiny) do NOT auto-hide the ^M. If you do a minimal install (or server install) you get vi and vim-tiny only. The fix I found was to install proper vim (apt-get install vim) on my ubuntu box. Hope that helps someone that comes along this topic for the same reason I did :-D
use the command:
:1,$ s/^v^M/ /g
When my neovim showed me these ugly ^M in some files from node_modules, I fixed this by adding following code to BufWinEnter:
if char2nr(getline(1)[-1:-1]) == 13
e ++ff=dos
endif

Resources