>
>
> On Aug 15, 1:30 pm, Tony Mechelynck<antoine.mechely...@gmail.com>
> wrote:
>>
>> In Latin1, a-acute is 225, not 255; a-tilde is 227, not 277; other than
>> that:
>>
>> - as Ben said, Vim comments start with a double-quote, not a # mark, and
>> shouldn't be put after a mapping with whitespace betwwen
>> - again as Ben said, if the 'fileencoding' of your vimrc is different
>> from the 'encoding' used by Vim, it should have a :scriptencoding
>> statement near the top, see :help :scriptencoding
>> - to represent characters in a mapping by their decimal value, use
>> <Char-nnn> notation, see :help<Char>
>>
>> So either of the following ought to work, assuming that (if needed) the
>> appropriate :scriptencoding statement is present earlier (maybe much
>> earlier):
>>
>> " ; o to o
>> imap ;<Char-225>o<Char-231><Char-227>o
>>
>> or even just
>> imap ; o o
>>
>
> I assume the problem with your second imap is just that weird google
> groups email interface encoding issue that keeps popping up, and it
> directly maps the special characters.
Well, I typed the a-acute between ; and o and the c-cedilla a-tilde
before the second o. My Sent folder says that I sent them in 8-bit
Latin1 but this time they appeared correctly in the list post that came
back to me (in quoted-printable Latin1, while I got yours in
quoted-printable Windows-1252).
<rant>This is where you see that whatever they say, Google is an Usonian
company (not American: French is used in Québec, Portuguese in Brazil,
Spanish in most of the rest of the Americas, and all these languages use
the accented characters of Latin1): they can't handle properly anything
that isn't in 7-bit ASCII, not even something as common as
ISO-8859-1.</rant>
>
> I want to be sure I understand the<Char> notation. Here's how I think
> it works:
>
> •<Char> notation specifies the character by its numeric value in the
> current 'encoding', as in nr2char()
> • Thus, using the<Char> notation in a mapping allows you to map
> specific charaters in the 'encoding' even if the .vimrc is saved with
> a different 'fileencoding'
> • Thus, if using<Char>, no :scriptencoding statement is required
That is my interpretation too.
> • However, if using the direct mapping you give as an alternative,
> either the 'fileencoding' of the .vimrc must equal the 'encoding' of
> Vim, or :scriptencoding must be used to specify the proper
> 'fileencoding'
Yes, either the vimrc must be encoded in your 'encoding', or a
:scriptencoding command (with the vimrc's 'fileencoding' as argument)
must be present before the mapping is defined.
In addition, neither in this case nor with <Char-nnn> above should the
'encoding' be changed after the mapping is defined. Any such change
could make the mapping invalid.
For instance, you could have a vimrc in Latin1 starting with something like
" Vim configuration script
" ÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
set nocompatible
if has('multi_byte')
scriptencoding latin1
if &enc !~? '^u'
if &tenc = ""
let &tenc = &enc
endif
set enc=utf-8
set fencs=ucs-bom,utf-8,latin1
endif
endif
*followed* (at any distance) by your mappings).
The line of (Latin1) divide-by signs is to make sure that the file is
not in UTF-8 even if (when first created) all the rest of it is in
ASCII; it is placed near the top to speed up the 'fileencodings'
heuristic when you open the file for editing.
>
> Is this all correct? Am I missing some subtlety?
>
Oh, I suppose there are a lot of subtleties, some of which may vary
according to which locale is set in your OS (and please, never change
the OS locale behind a running Vim's back, that's a sure-fire way to get
in trouble).
Best regards,
Tony.
--
The best defense against logic is ignorance.
--
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