Loading ...
Sorry, an error occurred while loading the content.

Re: multibyte input

Expand Messages
  • François Thunus
    ... YES :-) ... I work under Linux (stock RH 6.2 with some modifications for unicode, ie gazillions of fonts, patched xterm, etc). ... that would be brilliant.
    Message 1 of 9 , Aug 9, 2000
    • 0 Attachment
      Ron Aaron wrote:
      > Francois' problem is a little different. He wants vim to interpret his
      > 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.

      YES :-)

      > Moreover, one needs to install 'support' for these languages in Windows in
      > 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.

      I work under Linux (stock RH 6.2 with some modifications for unicode, ie
      gazillions of fonts, patched xterm, etc).

      > In my opinion, a much better solution is to use the inherent key remapping
      > 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.

      that would be brilliant.

      > The problem is vim has to know that an 'alpha' is Unicode 0x03b1 but an 'a'
      > 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'
      > ...etc...
      >
      > 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.

      I was not even dreaming of getting that too, but if it is possible to
      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', English
      > 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.

      definitely. This is exactly what I need/want, I am very glad to see that
      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.

      Cheers

      François
    • François Thunus
      ... This seems to be the way to go. ... make sense ... I am not sure this does matter, in the sense that as long as the user can produce his own keymap,
      Message 2 of 9 , Aug 9, 2000
      • 0 Attachment
        Bram Moolenaar wrote:

        > 2. Add a good way in Vim to enter special characters, which works on any
        > system. This makes it possible to enter the characters in the same way, no
        > matter where you are using Vim.

        This seems to be the way to go.

        > Right, the idea of 'langmap' is that your keyboard is producing characters in
        > 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.

        make sense
        >
        > > 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
        I am not sure this does matter, in the sense that as long as the user
        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?
        > It's important for languages with accented characters.
        you bet

        > > This 'alternate' keyboard would be switched with the 'standard', English
        > > 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?

        I am not sure how those two work, I need to examine this closer.

        > More comments?

        I am obviously more than ready to help if I can, now that my problem
        seems to be understood :-)

        Cheers

        François
      • François Thunus
        ... user-definable ? :-) set keymapperbuf=0 or set keymapperbuf=true Cheers François
        Message 3 of 9 , Aug 9, 2000
        • 0 Attachment
          Ron Aaron wrote:


          > One question -- I can see where I might have an English document and a Hebrew
          > document. It would be nice I think if the keyboard were mapped on a
          > per-buffer basis. Thoughts?

          user-definable ? :-) set keymapperbuf=0 or set keymapperbuf=true

          Cheers

          François
        • François Thunus
          ... I have done that. It does tell me that I can switch to an alternate kanji input method, but not where to find the doc to configure the one X is using to
          Message 4 of 9 , Aug 9, 2000
          • 0 Attachment
            Bram Moolenaar wrote:

            > > Now my question is: what is XIM ? how do I use it ? and alternately,
            > > 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
            I have done that. It does tell me that I can switch to an alternate
            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, 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.

            Yes, Aaron's suggestion is exactly what I am looking for. Obviously, we
            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

            Cheers

            François
          Your message has been successfully submitted and would be delivered to recipients shortly.