[PATCH] remove hacking code for old IM

[lilydjwg]

Hi,

I find some hacking code in src/mbyte.c preventing correct behaviours
for the input method "fcitx", a popular IM among the Chinese and able to
input in other languages, under actively developing. And Google tells
the "Ami" Vim is hacking is outdated and few people mention it.

The wrong behaviour is, for fcitx, there is an interface to control it
from a socket. So there is a plugin for Vim to make the IM inactive when
from insert mode back to normal mode, and activate it again on re-enter
insert mode. (http://www.vim.org/scripts/script.php?script_id=3764)

The problem is, without my patch, and with pre-edit enabled, the IM
context is destroyed and re-created, making fcitx tries to activate
the former destroyed IM context.

I suggest to remove those code, because:

1. Google tells me that making Vim work better with fcitx benefits much
more people.
2. the code is "hack"; the problematic IM should be fixed instead.

--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

[Bram Moolenaar]

lilydjwg wrote:

> I find some hacking code in src/mbyte.c preventing correct behaviours
> for the input method "fcitx", a popular IM among the Chinese and able to
> input in other languages, under actively developing. And Google tells
> the "Ami" Vim is hacking is outdated and few people mention it.
>
> The wrong behaviour is, for fcitx, there is an interface to control it
> from a socket. So there is a plugin for Vim to make the IM inactive when
> from insert mode back to normal mode, and activate it again on re-enter

> insert mode. (http://www.vim.org/scripts/script.php?script_id=3D3764)

>
> The problem is, without my patch, and with pre-edit enabled, the IM
> context is destroyed and re-created, making fcitx tries to activate
> the former destroyed IM context.
>
> I suggest to remove those code, because:
>
> 1. Google tells me that making Vim work better with fcitx benefits much
> more people.
> 2. the code is "hack"; the problematic IM should be fixed instead.

Before I include this I would like to hear from other IME users,
especially in different languages, if this works for them.


--
hundred-and-one symptoms of being an internet addict:
133. You communicate with people on other continents more than you
do with your own neighbors.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Yukihiro Nakadaira]

I agree to clean that code.

I am using Ubuntu and ibus-anthy.

Currently ":set imdisable" doesn't work immediately.

1) :set imdisable
2) Enter insert mode
3) Press IM activate key => Input Method is activated
4) Leave insert mode with <Esc>
5) Enter insert mode again
6) Press IM activate key => Input Method is not activated for 'imdisable'

With your patch ":set imdisable" never work.

Normally I don't use :set imdisable. But I just noticed it.

There seems no other problem for me.

--
Yukihiro Nakadaira - yukihiro....@gmail.com

[Yukihiro Nakadaira]

Your patch removes the code to inactivate Input Method by using
'imactivatekey' settings. I don't use 'imactivatekey' because it
doesn't work in my environment. But removing it is safe?

[Yukihiro Nakadaira]

On Tue, Jul 17, 2012 at 8:46 PM, Yukihiro Nakadaira
<yukihiro....@gmail.com> wrote:
> Your patch removes the code to inactivate Input Method by using
> 'imactivatekey' settings. I don't use 'imactivatekey' because it
> doesn't work in my environment. But removing it is safe?

s/inactivate/activate/

[Yukihiro Nakadaira]

On Tue, Jul 17, 2012 at 9:10 PM, Yukihiro Nakadaira

<yukihiro....@gmail.com> wrote:
> On Tue, Jul 17, 2012 at 8:46 PM, Yukihiro Nakadaira
> <yukihiro....@gmail.com> wrote:
>> Your patch removes the code to inactivate Input Method by using
>> 'imactivatekey' settings. I don't use 'imactivatekey' because it
>> doesn't work in my environment. But removing it is safe?
>
> s/inactivate/activate/

And I think that it is not safe to remove the feature to inactivate IM
when leaving insert mode. Although I myself don't care about it.

[Yukihiro Nakadaira]

Sorry, I misunderstood your suggestion. I understood you suggested to
remove hack for Ami. But you suggested to remove hack for IM control
feature. Right?
I think that it is slightly problematic. Although I don't know how many
user depend on it.

[lilydjwg]

On Tue, Jul 17, 2012 at 11:39:33PM +0900, Yukihiro Nakadaira wrote:
> Sorry, I misunderstood your suggestion. I understood you suggested to
> remove hack for Ami. But you suggested to remove hack for IM control
> feature. Right?
> I think that it is slightly problematic. Although I don't know how many
> user depend on it.

Yes, it's not a good solution. ibus won't become inactive when back into
normal mode. I'll dig deeper and try to make out another solution later.

The option 'imactivatekey' never works here too, only to make the state
strange.

[mattn]

On Wednesday, July 18, 2012 1:39:09 AM UTC+9, Xuetian Weng wrote:
> On Tuesday, July 17, 2012 10:39:33 PM UTC+8, Yukihiro Nakadaira wrote:
> &gt; Sorry, I misunderstood your suggestion. I understood you suggested to
> &gt; remove hack for Ami. But you suggested to remove hack for IM control
> &gt; feature. Right?
> &gt; I think that it is slightly problematic. Although I don&amp;#39;t know how many
> &gt; user depend on it.
> &gt;
> &gt; --
> &gt; Yukihiro Nakadaira -
>
> Hi, I&#39;m the developer of fcitx, let me organize the problem here..
>
> The problem is Lily create a vim plugin for switch the input method status via the interface of input method itself, the implementation use InsertEnter and InsertLeave, the problem is, the IMContext is switched to another context after the status change finished, so the plugin doesn&#39;t work properly.
>
> Well, as for this patch, it remove too much things.. I think only the last im_shutdown() need to be removed, I don&#39;t see the purpose for doing that.

I make sure that some IM is work fine with following patch.

https://gist.github.com/3135370

* ibus
* uim-anthy
* uim-skk
* uim-xim with skk
* uim-xim with anthy

vim goes to normal mode even though IM is active. This patch fix this problem.
But some problems remains even if this patch isn't applied.

* Caret position is broken in some times.

I know this problem occur with uim-skk.

* Don't work with 'cfX' (X is multi-byte)

Type cf and trigger of IM, and type preediting characters for multi-byte
character that I want to commit. But vim treat the preediting characters as
following of 'cf'.

lilydjwg, yukihiro, How do you think?
I'm thinking we've better to include this.

Thanks.

[mattn]

> * ibus
> * uim-anthy
> * uim-skk
> * uim-xim with skk
> * uim-xim with anthy

I make sure following IMs are works fine.

* ibus-skk
* ibus-anthy
* ibus-mozc

[mattn]

On Wednesday, July 18, 2012 7:37:57 PM UTC+9, mattn wrote:
> &gt; * ibus
> &gt; * uim-anthy
> &gt; * uim-skk
> &gt; * uim-xim with skk
> &gt; * uim-xim with anthy

>
> I make sure following IMs are works fine.
>
> * ibus-skk
> * ibus-anthy
> * ibus-mozc

I updated patch.

https://gist.github.com/3135711

> * Caret position is broken in some times.
>
> I know this problem occur with uim-skk.

I fixed this problem.

[mattn]

On Wednesday, July 18, 2012 8:33:52 PM UTC+9, mattn wrote:
> On Wednesday, July 18, 2012 7:37:57 PM UTC+9, mattn wrote:

> &gt; &amp;gt; * ibus
> &gt; &amp;gt; * uim-anthy
> &gt; &amp;gt; * uim-skk
> &gt; &amp;gt; * uim-xim with skk
> &gt; &amp;gt; * uim-xim with anthy
> &gt;
> &gt; I make sure following IMs are works fine.
> &gt;
> &gt; * ibus-skk
> &gt; * ibus-anthy
> &gt; * ibus-mozc

>
> I updated patch.
>
> https://gist.github.com/3135711
>

> &gt; * Caret position is broken in some times.
> &gt;
> &gt; I know this problem occur with uim-skk.
>
> I fixed this problem.

I updated patch once again.

https://gist.github.com/3135784

Fixed:

> * Don't work with 'cfX' (X is multi-byte)

Someone, would you please try this patch.

Thanks.

[mattn]

> I updated patch once again.
>
> https://gist.github.com/3135784
>
> Fixed:
>

> &gt; * Don&#39;t work with &#39;cfX&#39; (X is multi-byte)

>
> Someone, would you please try this patch.
>
> Thanks.

Ooops. Latest patch does not work with xim-skk.

Please try previous patch.

https://gist.github.com/3135711

Sorry about my many posts.

[Yukihiro Nakadaira]

On Wed, Jul 18, 2012 at 7:22 PM, mattn <matt...@gmail.com> wrote:
> I make sure that some IM is work fine with following patch.

> ...

I think your patch does not fix Lily's problem because it still uses
im_shutdown() and xim_init() to re-create im-context.

We need both "activate" and "inactivate" feature to control Input Method.

In my humble opinion, it is not bad idea to remove the code for IM
control feature so that we can use workaround implemented with VimL
plugin, if no one complains about it. Current implementation seems
insufficient to support the feature and its code is a bit hacky because
gtk does not have API for it,

[mattn]

On Monday, July 16, 2012 7:38:53 PM UTC+9, 依云 wrote:
> The problem is, without my patch, and with pre-edit enabled, the IM
> context is destroyed and re-created, making fcitx tries to activate
> the former destroyed IM context.

How this work with fcitx?

gtk_im_multicontext_set_context_id(
xic, gtk_im_multicontext_get_context_id(xic));

This should work as set off to active status of IM.

[lilydjwg]

On Wed, Jul 18, 2012 at 05:07:23AM -0700, mattn wrote:
> Please try previous patch.
>
> https://gist.github.com/3135711

I tried this patch. Unfortunately, I don't see any difference.

(I finally find out that) the problem I have is, Vim will shutdown the
IM when entering and leaving normal mode. This will make my autocmds
handling at the wrong IM context.

My patch simply makes Vim lose the control of IM, which is undesired
when without a more precise IM controlling plugin.

So, my suggestion is to use an option to let Vim not control the IM (those
codes in #ifdef USE_IM_CONTROL) (maybe in addtion to cleaning up the old
code). Is this ok?

[mattn]

On Thursday, July 19, 2012 8:36:43 PM UTC+9, 依云 wrote:
> On Wed, Jul 18, 2012 at 05:07:23AM -0700, mattn wrote:

> &gt; Please try previous patch.
> &gt;
> &gt; https://gist.github.com/3135711
>
> I tried this patch. Unfortunately, I don&#39;t see any difference.

>
> (I finally find out that) the problem I have is, Vim will shutdown the
> IM when entering and leaving normal mode. This will make my autocmds
> handling at the wrong IM context.
>
> My patch simply makes Vim lose the control of IM, which is undesired
> when without a more precise IM controlling plugin.
>
> So, my suggestion is to use an option to let Vim not control the IM (those
> codes in #ifdef USE_IM_CONTROL) (maybe in addtion to cleaning up the old
> code). Is this ok?

Then, How about new option 'imactivateexpr' ?
If imactivateexpr is set as user function, vim don't shutdown IM, and call the function.

function MyImActivateExpr(active)
" something to switch activate of IM
endfunction

set imactivateexpr=MyActivateExpr

[lilydjwg]

On Thu, Jul 19, 2012 at 09:15:46AM -0700, mattn wrote:
> On Thursday, July 19, 2012 8:36:43 PM UTC+9, 依云 wrote:

> > [...]

> >
> > So, my suggestion is to use an option to let Vim not control the IM (those
> > codes in #ifdef USE_IM_CONTROL) (maybe in addtion to cleaning up the old
> > code). Is this ok?
>
> Then, How about new option 'imactivateexpr' ?
> If imactivateexpr is set as user function, vim don't shutdown IM, and call the function.
>
> function MyImActivateExpr(active)
> " something to switch activate of IM
> endfunction
>
> set imactivateexpr=MyActivateExpr

I like this idea! Will someone implement it?

[lilydjwg]

On Thu, Jul 19, 2012 at 12:40:43AM +0900, Yukihiro Nakadaira wrote:
> I think your patch does not fix Lily's problem because it still uses
> im_shutdown() and xim_init() to re-create im-context.
>

> [...]

Hi, please refer me as lilydjwg; I don't have an English name yet.

[Yukihiro Nakadaira]

Here is a quick hack to try out.

[lilydjwg]

On Fri, Jul 20, 2012 at 07:48:25PM +0900, Yukihiro Nakadaira wrote:
> Here is a quick hack to try out.

Hi, I can't try out your example_ibus.vim because when I import ibus
from Vim it says "ImportError: /lib/libpyglib-2.0-python2.so.0:
undefined symbol: _Py_ZeroStruct" (It's ok outsite Vim). I wrote another
script using the 'imactivefunc' and it works just as I want!

The following is for fcitx (version 3.6+):

function! ImActivateFunc(active)
if a:active
call system("fcitx-remote -o")
else
call system("fcitx-remote -c")
endif
endfunction

set imactivatefunc=ImActivateFunc

PS: I forgot to Cc two other lists in my last message... The patch file
can also be accessed from https://groups.google.com/group/vim_dev/tree/browse_frm/thread/27413424bf10600b/8db95107645f31e8
and I hope more people can try this out!

[Bram Moolenaar]

So, what is the conclusion about this patch? Is it really an
improvement and does not break IME for any language?

--
Hear about the guy who played a blank tape at full blast?
The mime next door went nuts.

[Yukihiro Nakadaira]

Attached files is latest patch.

This patch adds 'imactivatefunc' and 'imstatusfunc' option.

This patch does not break IME because it does nothing when the option is
not set.

This is only yet another workaround for IM control feature. But it
slightly better than 'imactivatekey' because some IM have API to control
enable/disable state and we can implement IM specific method with this
option.

In im_get_status() function, it is not always safe to invoke user
defined function. I added checking code to avoid crash I saw. But it
might still have problem.