Re: multibyte input
- Ron Aaron wrote:
> Francois' problem is a little different. He wants vim to interpret hisYES :-)
> keyboard input as now English, now Greek, now French. In other words, he
> wants to switch his input encoding on the fly. XIM might do this generically,
> but the Windows IME only does this for Far East languages.
> Moreover, one needs to install 'support' for these languages in Windows inI work under Linux (stock RH 6.2 with some modifications for unicode, ie
> order to remap the keyboard at Windows' level. If you don't have the Windows
> install CD when you decide to e.g. input Spanish, you have to fake it.
gazillions of fonts, patched xterm, etc).
> In my opinion, a much better solution is to use the inherent key remappingthat would be brilliant.
> that's already in vim (langmap). However, as far as I can tell, 'langmap'
> doesn't do what the documentation says. Specifically, it doesn't remap INSERT
> mode at all, only NORMAL mode (5.7 and 6.0e on Linux, 6.0e on Win32).
> This way, one might have a 'language' menu or command that would switch vim
> from English to e.g. Greek input mode. Similarly, we might define an entire
> set of 'languages' based on the standard keyboards for these.
> The problem is vim has to know that an 'alpha' is Unicode 0x03b1 but an 'a'I was not even dreaming of getting that too, but if it is possible to
> is Unicode 0x0061, and an 'alef' is Unicode 0x05d0. We should be independant
> of the 'input method' used on the OS (for example, on DOS how does one enter
> greek on a us keyboard?). Therefore, a remapping table is in order, to be
> loaded for each language ("keyboard"). It should specify a translation from a
> raw key ('a') to a translated key ('?') for a particular encoding.
> For example, a keymap for iso-8859-8/utf-8 might be something like:
> a,0xf9,0x5e9 " a on the keyboard maps to the 'shin' character
> b,0xf0,0x5e0 " b --> 'nun'
> Similarly for all the encodings. This means that when the user wants to (in
> this case) enter Hebrew, he would tell vim to use a Hebrew mapping, which
> would enter the characters as above (in utf-8, the wide characters would be
> used, in single-byte mode, the -8 encoding would be used).
> This gives an easy way to accomodate all systems, and encodings which are not
> well supported. The 'rightleft' issues are a separate thing, and are already
> adequately supported in vim I think.
reverse the direction for Hebrew and Arabic (which rae the only two I am
interested in at the moment), that is even better than I thought.
> This 'alternate' keyboard would be switched with the 'standard', Englishdefinitely. This is exactly what I need/want, I am very glad to see that
> keyboard via ^_ (or a user mapped key) just like it currently is for Hebrew.
> In this manner, one can switch quickly between English and an alternate
> language. The keyboard mapping should be able to be swtiched in on the
> command-line as well, so searching for arbitrary text is facilitated (like
> the current Hebrew support).
> Sorry for rambling, but I think it is important to make this work
> independantly of OS support, since it is possible, and will make vim more
> useful to more people.
other people have given it a thought as well. I will see what I can do
with this keyboard mapping option you mention. maybe that is the
beginning of a solution for languages which are not very far from plain
ascii (I'm thinking mostly polish, french, etc). I was not even aware
that Hebrew was already supported by vim. I have been using unix for a
long time, and Linux since 1.2.4, but since I was switching constantly
between Linux, System Vr4 and Solaris, I limited myself to core vi
functions, and did not really care about what vi I was using, since they
were pretty much all the same to me. But now I'll be using Linux only
and I need unicode support, which is why I jumped on vim. Knowing that
there is also a win32 version is of utmost interest because some people
in the company do use windows as well, so if we can standardiuze on vim,
that would be nice.
Thanaks for the help.
- Bram Moolenaar wrote:
> 2. Add a good way in Vim to enter special characters, which works on anyThis seems to be the way to go.
> system. This makes it possible to enter the characters in the same way, no
> matter where you are using Vim.
> Right, the idea of 'langmap' is that your keyboard is producing characters inmake sense
> your special language, thus in Insert mode nothing needs to be done. But in
> command mode you need to type keys like "x", which requires translation of
> your special language to ASCII.
>I am not sure this does matter, in the sense that as long as the user
> > This way, one might have a 'language' menu or command that would switch vim
> > from English to e.g. Greek input mode. Similarly, we might define an entire
> > set of 'languages' based on the standard keyboards for these.
> This sounds reasonable. The question is how to handle the situation where
> there are more characters needed than you have keys on your keyboard. Perhaps
can produce his own keymap, (s)he'll just put on it the characters (s)he
uses most, and figure out some way to enter the rest.
> digraphs need to be used then?for example, yes.
> As I said, I was thinking of adding a whole list of standard digraphs (and mnemonics).I am not sure this is needed, but why not.
> One problem is the handling of dead keys. Would we also want to support that?you bet
> It's important for languages with accented characters.
> > This 'alternate' keyboard would be switched with the 'standard', EnglishI am not sure how those two work, I need to examine this closer.
> > keyboard via ^_ (or a user mapped key) just like it currently is for Hebrew.
> > In this manner, one can switch quickly between English and an alternate
> > language. The keyboard mapping should be able to be swtiched in on the
> > command-line as well, so searching for arbitrary text is facilitated (like
> > the current Hebrew support).
> Setting an option to the translation table to be used sounds reasonable.
> Will this replace the existing 'hkmap' and 'fkmap' options?
> More comments?I am obviously more than ready to help if I can, now that my problem
seems to be understood :-)
- Ron Aaron wrote:
> One question -- I can see where I might have an English document and a Hebrewuser-definable ? :-) set keymapperbuf=0 or set keymapperbuf=true
> document. It would be nice I think if the keyboard were mapped on a
> per-buffer basis. Thoughts?
- Bram Moolenaar wrote:
> > Now my question is: what is XIM ? how do I use it ? and alternately,I have done that. It does tell me that I can switch to an alternate
> > where do I find the doc about it ? I tried man XIM, man xim, the XF86
> > website, the X website and nowhere did I find a clue as to what I need to
> > do.
> In Vim:
> :help xim
kanji input method, but not where to find the doc to configure the one X
is using to allow me to introduce greek char in the middle of an english
text. similarly, man xim or XIM does not exist, and man X does not point
to anything useful. Mind you, I am not bashing, just stating that the
existing information does not allow me to do anything concrete. The
moment I find out what to do, I'm more than willing to write a patch for
the doc and send it to you.
> > I need to be able to change language in the middle of a text.Yes, Aaron's suggestion is exactly what I am looking for. Obviously, we
> Yes, I understand that. Until now Vim didn't include the translation from
> ASCII (or whatever your keyboard produces) to special languages. I was hoping
> that a system function could be used for this. See the message from/to Ron
> Aaron about an alternative.
have the same preoccupations :-)
Let me know if there is anything I can do to help. While I may not be
able to code much, I can certainly test and check/write docs