Posts tagged vim
Posts tagged vim
One of the best plugins I’ve found for vim is CommandT. It lets you open files in a very speedy and intuitive way, making it very simple to search files and open them in tabs, splits or vertical splits. Or so it should be. On OS X, opening a file on a new split doesn’t really work. You should be able to do it using the Ctrl-S shorcut but it just doesn’t work.
Today I decided to go after this problem. Looking around the net, I found an article explaining the reason:
I found a related tip indicating that by default, Terminal.app reserves Ctrl-S for old-fashioned XON/XOFF flow control.
Ok, so the Terminal app doesn’t allow us to use Ctrl-S because it’s a reserved shortcut. What to do?
Simple, just add the lines below in your ~/.bashrc
stty -ixon -ixoff
It will disable the above behavior and free Ctrl-S and Ctrl-Q for use in terminal apps!
Reminder: Just adding that to your bashrc won’t change the settings in the currently open terminal windows. Type the command above on the terminal so you can have the benefits right now, or reopen all your sessions.
Development Environment: tmux+vim
add “set fileencodings=iso-2022-jp,euc-jp,cp932,utf8,default,latin1” to your ~/.vimrc and use “:e ++enc=<encoding_name>” to reload a buffer with a specific encoding.
The fun, instructive (and long) version:
I work for a japanese company in Tokyo and working a japanese language environment, with japanese comments in the source code is something you get used to.
However, one big problem I used to have was dealing with the many possible encoding we have for japanese on vim.
On the top of my head, these are the most used encodings around here:
Real life example:
One day I had to edit this piece of code on the server, that renders UTF8 to the browser but the file itself is all in EUC-JP.
I open it as always on vim and what I see is a bunch of gibberish where the comments from my fellow japanese developer should be.
What should we do here?
Vim has a very intuitive option, called “encoding”, so we are very prone to just do
But all we get is a bunch of weird characters. Definitely not what we were expecting.
So we go through the documentation on the “encoding” option to find out that
NOTE: Changing this option will not change the encoding of the existing text in Vim. It may cause non-ASCII text to become invalid. It should normally be kept at its default value, or set when Vim starts up. See |multibyte|. To reload the menus see |:menutrans|.
This option cannot be set from a |modeline|. It would most likely corrupt the text.
Hmmm. It seems that “encoding” actually changes vim’s interface encoding and not our file’s encoding and we also get a last line telling us that it’s only gonna corrupt our text.
Ok, as we’re already here, let’s go on reading the documentation to see if we find anything interesting…look!
The character encoding of files can be different from ‘encoding’. This is specified with ‘fileencoding’.
So let’s check the docs for “fileencoding”
Sets the character encoding for the file of this buffer.
When ‘fileencoding’ is different from ‘encoding’, conversion will be done when writing the file. For reading see below.
Ok. This means that setting “fileencoding” lets us define the resulting file’s encoding. Not what we’re displaying on the screen. However we’re getting close!
Let’s get some more doc love :)
When reading a file ‘fileencoding’ will be set from ‘fileencodings’. To read a file in a certain encoding it won’t work by setting ’fileencoding’, use the |++enc| argument.
Ok. I know this is not the clearest piece of documentation ever but we’re really there! (almost)
So, when reading a file we should either set “fileencodings” or use the option “++enc”. So we jump to our keyboards and frantically type
And yes it doesn’t work.
(I know you must be getting impatient here, like “wtf, why can’t he just give me the f***ing answer?” but calm down, take a deep breath and enjoy this trip through vimdoc.)
from the “fileencodings” docs:
This is a list of character encodings considered when starting to edit an existing file. When a file is read, Vim tries to use the first mentioned character encoding. If an error is detected, the next one in the list is tried. When an encoding is found that works, ‘fileencoding’ is set to it. If all fail, ‘fileencoding’ is set to an empty string, which means the value of ‘encoding’ is used.
Now we know why it didn’t work. This sets the list of encodings that will be checked when we open a file.By the way, if you add the line below to your ~/.vimrc you’ll most probably not have any problems with open japanese files again:
(See! Something useful!)
But what do I do to reload a buffer I’m already editing? Simple, the docs mentioned something about an option “++enc”, right? All you gotta do is:
Strictly speaking, you’re opening for editing (:e = :edit) the same file (as none was specified) and overriding the default “fileencodings” values by using the ++enc option.
Et voila. It works!
By the way, if you’re curious about what are the supported encodings in vim and how they’re called, check the page below: