On 04/10/10 11:50, esquifit wrote:
Thank you both Tony and Kyungjoon for the detailed explanation. I
understand that setting 'encode' globally is recommended (or rather
the right thing to do) and so I did it. I've also set fileencodings
as suggested y Tony. This seems to works fine.

The whole set of options (encoding, fileencoding, fileencodings),
the different way to set them (set, localset, globalset) and the
various possible places at which the setting can be done (vim config.
files, filtype.vim, etc) makes the subject very difficult to handle.
More over, the different treatments depending on the platform (unix
vs. win32, terminal vs GUI, win32 native vs Cygwin, GTK or not,
etc.).  I couldn't find any reasonable explanation of what each
setting means in each context; the vim helps is more of a dictionary
than of a tutorial, so it is difficult to find a natural path. Some
statements seems to be done implicitly assuming a unix system, some
other seems related to terminals but it is not that clear whether the
same is relevant for GUI. Fundamentally I'm missing a high level
description of which encodings and which conversions come at which
moment into play (vim startup, loading from memory, input from user,
writing to disk, internal representation, whatever)

Did you read the Vim Tips Wiki link I gave you? http://vim.wikia.com/wiki/Working_with_Unicode and in particular http://vim.wikia.com/wiki/Working_with_Unicode#What_the_above_does

Vim is largely cross-platform, but the various OSes have different idiosyncrasies, and in particular, different customs about setting locales: for instance, under Linux I see en_US.UTF-8 as my locale, but under Windows it used to be French_Belgium.1252, which means an fr_BE locale using the Windows-1252 charset. For some reason Windows requires the charset part of the locale to be numeric (the "code page" for Unicode is 10646 IIUC, and I'm not sure whether that means UTF-8 or UTF-16le). Vim will use UTF-8 internally if 'encoding' is set to some variant of UTF-16 or UTF-32, because these use a lot of null bytes as part of the words or doublewords representing non-null codepoints, and that is incompatible with the null-terminated C strings used by Vim; but if 'fileencoding' is empty, Vim will use the actual value of 'encoding' even if that means converting between UTF-8 (used internally in place of something else) and, let's say, UTF-16le (used on disk).

So Vim for Linux will often work in Unicode "out of the box" because that's what the OS had already set, while Vim for Windows has to set it explicitly. But a common vimrc will, in this respect, work for both (it did for me, when I was running double-boot W98 and Linux).

About the differences between :set, :setglobal and :setlocal, see
        :help set-option        " (the whole list of commands)
        :help set-verbose
        :help local-options
        :help :setlocal
        :help :setglobal
        :help global-local

With Vim, everything is in the help, but sometimes you get a kind of needle-and-haystack feeling out of it. See the first 150 or so lines in :help helphelp.txt about how to domesticate that feeling.


On a related note: is it possible to set different fonts in
different vim windows/tabs within a single application window? (I
could define an autocommand to restore the default font, but there is
another situation in which this would not be a solution).


No. In gvim the 'guifont' option is global, and in Console Vim the font is set by the underlying terminal to a single font for the whole screen. You could define mappings (for gvim, not for Console Vim), but beware that different versions of Vim (different GUI "flavours") require different 'guifont' formats (see http://vim.wikia.com/wiki/Setting_the_font_in_the_GUI ) so your mappings would have to be different for, say, Windows, GTK2 or Motif, and in console mode you wouldn't define them.


Best regards,
Tony.
--
You buttered your bread, now lie in it.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Reply via email to