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

3 XIM issues: imactivatekey, iminsert, and OnTheSpot

Expand Messages
  • Steven Mueller
    I m using kinput2 for Japanese input into GTK gvim 6.0av on my debian-sid x86 system. When I start vim, imactivatekey is unset. However, I can still use
    Message 1 of 3 , Sep 11, 2001
    • 0 Attachment
      I'm using kinput2 for Japanese input into GTK gvim 6.0av on my
      debian-sid x86 system. When I start vim, imactivatekey is unset.
      However, I can still use shift-space or ctrl-o to enter mbyte input
      mode if I do so during the first input session. Once I've hit
      i<esc>i, I can no longer activate XIM. However, if I do
      i<s-space>nanika<space><CR><esc> (ie, don't switch out of XIM mode
      between inserts, I can switch in and out of XIM as long as I'm within
      input mode). Now, if I set imactivatekey, I can reliably activate XIM
      regardless of the mode, but only with s-space or c-o, regardless of
      the seting of imactivatekey.

      Also, I don't quite understand the documentation in :help 'iminsert'.
      It is unclear as to what the affect of setting iminsert should be,
      especially since it seems to have no affect at all in my compile. Two
      interpretations of "Specifies whether :lmap or an Input Method (IM) is
      to be used in Insert mode" come to mind: 1) When set to 2, XIM will be
      active upon entering insert mode, or 2) When set to 2, XIM is able to
      be activated while in insert mode, otherwise it is disabled. Right
      now, it seems to do neither, though it seems that 1 is the proper
      interpretation. If I set it to '2' and enter insert mode, XIM is not
      active. But when I hit <esc>, iminsert is once again set to 0. When
      it is 0, though, I am still able to use XIM in insert mode, as long as
      imactivatekey is set. But if I am in insert mode with XIM active and
      hit <esc>, then imi=2, but upon entering insert mode again, XIM is not
      active. Maybe better wording might be "Specifies whether :lmap or an
      Input Method (IM) will be active when entering Insert mode."

      Finally, the documentation for input styles doesn't seem to be
      accurate (unless it's just my misunderstanding of what's going on).
      In the GTK version, XIM seems to be doing OnTheSpot editing, whereby
      vim is taking part in pre-edited input placement and formatting.
      However, under :Help xim-input-style, it is stated that "Currently,
      GUI Vim support three style, |OverTheSpot|, |OffTheSpot| and
      |Root|." On a more featuristic side-note, it would be nice if there
      were another hilighting group for pre-edited text that has not yet
      been set by hitting enter. It's still not visually clear as to
      whether hitting shift-space is going to clear what was just typed
      because you forgot to hit enter first. I believe Mozilla handles this
      by underlining pre-edited text in red (as well as setting the
      background of that text to white, though that may just be a stylistic
      oversight).

      These are just some issues I've been seeing for a while and wanted to
      get cleared up before 6.0 comes out of beta. Thanks for listening!

      Steve

      --
      Steven Mueller
      diffusor@...
    • Steven Mueller
      Apparently I was a bit too hasty... I now understand that imactivatekey does not control which key activates XIM, but rather makes vim aware of what key
      Message 2 of 3 , Sep 11, 2001
      • 0 Attachment
        Apparently I was a bit too hasty... I now understand that
        imactivatekey does not control which key activates XIM, but rather
        makes vim aware of what key sequence to pass to X in order to activate
        XIM. This seems somehow less usefull to me. :) I was hoping for an
        easier way of getting out of the "ctrl-o starts XIM instead of letting
        me input a command!" connundrum, short of translating the canna
        documentation for myself.

        However, my comments regarding OnTheSpot still stand. The docs for
        imactivate key seem pretty clear, though. It was just my hopes
        getting the best of me that seem to have made me confuse what
        specifies the activation key and what accepts it. If anyone could
        tell me how I could deactivate <c-o> starting XIM, I'd be glad to hear
        about it. I'd imagine it's just some function call I need to add to
        my /etc/canna/default.canna...

        With apologies,
        Steve

        On Tue, Sep 11, 2001 at 01:54:24AM -0700, Steven Mueller wrote:
        > I'm using kinput2 for Japanese input into GTK gvim 6.0av on my
        > debian-sid x86 system. When I start vim, imactivatekey is unset.
        > However, I can still use shift-space or ctrl-o to enter mbyte input
        > mode if I do so during the first input session. Once I've hit
        > i<esc>i, I can no longer activate XIM. However, if I do
        > i<s-space>nanika<space><CR><esc> (ie, don't switch out of XIM mode
        > between inserts, I can switch in and out of XIM as long as I'm within
        > input mode). Now, if I set imactivatekey, I can reliably activate XIM
        > regardless of the mode, but only with s-space or c-o, regardless of
        > the seting of imactivatekey.
        >
        > Also, I don't quite understand the documentation in :help 'iminsert'.
        > It is unclear as to what the affect of setting iminsert should be,
        > especially since it seems to have no affect at all in my compile. Two
        > interpretations of "Specifies whether :lmap or an Input Method (IM) is
        > to be used in Insert mode" come to mind: 1) When set to 2, XIM will be
        > active upon entering insert mode, or 2) When set to 2, XIM is able to
        > be activated while in insert mode, otherwise it is disabled. Right
        > now, it seems to do neither, though it seems that 1 is the proper
        > interpretation. If I set it to '2' and enter insert mode, XIM is not
        > active. But when I hit <esc>, iminsert is once again set to 0. When
        > it is 0, though, I am still able to use XIM in insert mode, as long as
        > imactivatekey is set. But if I am in insert mode with XIM active and
        > hit <esc>, then imi=2, but upon entering insert mode again, XIM is not
        > active. Maybe better wording might be "Specifies whether :lmap or an
        > Input Method (IM) will be active when entering Insert mode."
        >
        > Finally, the documentation for input styles doesn't seem to be
        > accurate (unless it's just my misunderstanding of what's going on).
        > In the GTK version, XIM seems to be doing OnTheSpot editing, whereby
        > vim is taking part in pre-edited input placement and formatting.
        > However, under :Help xim-input-style, it is stated that "Currently,
        > GUI Vim support three style, |OverTheSpot|, |OffTheSpot| and
        > |Root|." On a more featuristic side-note, it would be nice if there
        > were another hilighting group for pre-edited text that has not yet
        > been set by hitting enter. It's still not visually clear as to
        > whether hitting shift-space is going to clear what was just typed
        > because you forgot to hit enter first. I believe Mozilla handles this
        > by underlining pre-edited text in red (as well as setting the
        > background of that text to white, though that may just be a stylistic
        > oversight).
        >
        > These are just some issues I've been seeing for a while and wanted to
        > get cleared up before 6.0 comes out of beta. Thanks for listening!
        >
        > Steve
        >
        > --
        > Steven Mueller
        > diffusor@...

        --
        Steven Mueller
        diffusor@...
      • Bram Moolenaar
        ... The imactivatekey option tells Vim the key that your XIM is using. It s not for changing that key. ... This sounds like a bug. When you set iminsert
        Message 3 of 3 , Sep 11, 2001
        • 0 Attachment
          Steven Mueller wrote:

          > I'm using kinput2 for Japanese input into GTK gvim 6.0av on my
          > debian-sid x86 system. When I start vim, imactivatekey is unset.
          > However, I can still use shift-space or ctrl-o to enter mbyte input
          > mode if I do so during the first input session. Once I've hit
          > i<esc>i, I can no longer activate XIM. However, if I do
          > i<s-space>nanika<space><CR><esc> (ie, don't switch out of XIM mode
          > between inserts, I can switch in and out of XIM as long as I'm within
          > input mode). Now, if I set imactivatekey, I can reliably activate XIM
          > regardless of the mode, but only with s-space or c-o, regardless of
          > the seting of imactivatekey.

          The 'imactivatekey' option tells Vim the key that your XIM is using.
          It's not for changing that key.

          > Also, I don't quite understand the documentation in :help 'iminsert'.
          > It is unclear as to what the affect of setting iminsert should be,
          > especially since it seems to have no affect at all in my compile. Two
          > interpretations of "Specifies whether :lmap or an Input Method (IM) is
          > to be used in Insert mode" come to mind: 1) When set to 2, XIM will be
          > active upon entering insert mode, or 2) When set to 2, XIM is able to
          > be activated while in insert mode, otherwise it is disabled. Right
          > now, it seems to do neither, though it seems that 1 is the proper
          > interpretation. If I set it to '2' and enter insert mode, XIM is not
          > active. But when I hit <esc>, iminsert is once again set to 0. When
          > it is 0, though, I am still able to use XIM in insert mode, as long as
          > imactivatekey is set. But if I am in insert mode with XIM active and
          > hit <esc>, then imi=2, but upon entering insert mode again, XIM is not
          > active. Maybe better wording might be "Specifies whether :lmap or an
          > Input Method (IM) will be active when entering Insert mode."

          This sounds like a bug. When you set 'iminsert' to 2, XIM should be
          active when you enter Insert mode. You can switch XIM on/off while in
          Insert mode, and the resulting value should be stored in 'iminsert' when
          you press <Esc>. That appears to work correctly. But activating XIM
          when entering Insert mode apparently doesn't work. Hopefully someone
          knows how to fix this, I don't!

          On the other hand, if you didn't set the 'imactivatekey' option
          correctly, this may be the cause of this problem.

          > Finally, the documentation for input styles doesn't seem to be
          > accurate (unless it's just my misunderstanding of what's going on).
          > In the GTK version, XIM seems to be doing OnTheSpot editing, whereby
          > vim is taking part in pre-edited input placement and formatting.
          > However, under :Help xim-input-style, it is stated that "Currently,
          > GUI Vim support three style, |OverTheSpot|, |OffTheSpot| and
          > |Root|.".

          The documentation needs updating. The code was changed, but not all
          documentation was. I can't do it myself, since I know little about
          input methods. Volunteer?

          > On a more featuristic side-note, it would be nice if there
          > were another hilighting group for pre-edited text that has not yet
          > been set by hitting enter. It's still not visually clear as to
          > whether hitting shift-space is going to clear what was just typed
          > because you forgot to hit enter first. I believe Mozilla handles this
          > by underlining pre-edited text in red (as well as setting the
          > background of that text to white, though that may just be a stylistic
          > oversight).

          Let's first fix the bugs before adding new things.

          > These are just some issues I've been seeing for a while and wanted to
          > get cleared up before 6.0 comes out of beta. Thanks for listening!

          I'm not sure if someone will manage to fix these things soon. I'm
          thinking of disabling the 'iminsert' and associated options, because
          they are causing too much trouble. For someone who needs to type Asian
          characters it may be worth figuring out how to make it work, but for
          most people it should work without any settings.

          --
          hundred-and-one symptoms of being an internet addict:
          84. Books in your bookcase bear the names Bongo, WinSock and Inside OLE

          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
          ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
        Your message has been successfully submitted and would be delivered to recipients shortly.