> 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
No comments:
Post a Comment