problems on inline input on Mac

problems on inline input on Mac

[Kazu Yamamoto]

Hello,

Recent CVS Emacs provides "inline input" on Mac.

Without this, we Japanese have to type Japanese (Hiragana) in another
small non-Emacs window, convert it to what we want (Kanji), then
insert the completed string to an Emacs buffer.

Thanks to the inline input, we can directly input Hiragana in an Emacs
buffer and convert/complete it in the buffer.

Other inline input mechanisms (like "tamago") makes use of buffer
itself. I guess many people agree that this approach is good.

Unfortunately, the inline input of Mac makes use of overlay instead of
buffer. This approach causes some problems:

* Even if the target buffer is read-only, we can input Hiragana and
  Kanji. Read-only errors occur just after we complete strings (ie
  inserting the completed strings from the overlay to the buffer).

* Since Hiragana and Kanji are hold in an overlay, text properties of
  the buffer is not inherited during input. Of course, after
  completing strings, the properties are inherited by the strings.

  My presentation tool called Goby let users to input large letters.
  With other inline input, we can see large Japanese letters while
  inputing them. With Mac's inline input, small Japanese letters
  appear during input and large letters are shown only after
  completing them.

So, I would like to ask to change the implementation of inline input
on Mac from using overlay to using direct buffer.

--Kazu Yamamoto

Re: problems on inline input on Mac

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 28 Jul 2006 12:58:20 +0900 (JST), Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp> said:

> Other inline input mechanisms (like "tamago") makes use of buffer
> itself. I guess many people agree that this approach is good.

It would be helpful to think the TSM support (including inline input
support) on Mac corresponds to the XIM support on X11 rather than
Emacs-level input methods such as tamago and leim.  Then I think
you'll naturally understand its behavior.

> Unfortunately, the inline input of Mac makes use of overlay instead
> of buffer. This approach causes some problems:

> * Even if the target buffer is read-only, we can input Hiragana and
>   Kanji. Read-only errors occur just after we complete strings (ie
>   inserting the completed strings from the overlay to the buffer).

The use of overlay strings is intentional and has some reasons.

  * Since TSM support corresponds to XIM, it is natural not to change
    the buffer contents until the user confirms the text.

  * Some keyboard layouts require to show unconfirmed (preedit) text
    even when we input some ASCII characters such as "`".  There may
    be some key binding including "`" that is also allowed to operate
    on read-only buffers.

Moreover, you cannot tell in general not only whether the target
buffer is read-only but also which is the target buffer at the stage
of passing input events to TSM using SendEventToEventTarget in
XTread_socket.

> * Since Hiragana and Kanji are hold in an overlay, text properties
>   of the buffer is not inherited during input. Of course, after
>   completing strings, the properties are inherited by the strings.

They are inherited from those just after the (empty) overlay.  You
cannot tell whether the user wants to inherit them from those before
or after it.

> So, I would like to ask to change the implementation of inline input
> on Mac from using overlay to using direct buffer.

I've made some email exchanges with Hashimoto-san (the author of
"inline-patch") on the above issues in Japanese.  I will send you some
of them if he agrees.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: problems on inline input on Mac

[Miles Bader]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> The use of overlay strings is intentional and has some reasons.
>
>   * Since TSM support corresponds to XIM, it is natural not to change
>     the buffer contents until the user confirms the text.

Doesn't XIM have a mode in which it cooperates via some protocol with
the application so that intermediate (pre-lookup) characters during
input appear "in" the app (not overlayed), but are still converted by XIM?

AFAIK, that mode is more complicated, so Emacs doesn't use it, but I
think firefox does, for instance.

-Miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: problems on inline input on Mac

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 28 Jul 2006 14:49:47 +0900, Miles Bader <miles.bader@necel.com> said:

>> * Since TSM support corresponds to XIM, it is natural not to change
>>   the buffer contents until the user confirms the text.

> Doesn't XIM have a mode in which it cooperates via some protocol
> with the application so that intermediate (pre-lookup) characters
> during input appear "in" the app (not overlayed), but are still
> converted by XIM?

I think you mean on-the-spot, which is not supported by Emacs
currently.  Anyway, overlay strings are not displayed in an overlaid
fashion, but serialized.  Also, thanks to overlay strings, we don't
have to do anything special about undo.

I'd like to show preedit/unconfirmed text even in a read-only buffer
for the reasons I mentioned in the previous message (the current XIM
implementation behaves like that, and we need that for some keyboard
layouts).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: problems on inline input on Mac

[Kazu Yamamoto]

Hello,

> > Other inline input mechanisms (like "tamago") makes use of buffer
> > itself. I guess many people agree that this approach is good.
> 
> It would be helpful to think the TSM support (including inline input
> support) on Mac corresponds to the XIM support on X11 rather than
> Emacs-level input methods such as tamago and leim.  Then I think
> you'll naturally understand its behavior.

I don't know this area well. But my point is that the previous
implementation of inline input by Hashimoto-san was perfect to me.
And the current code is not. 

I'm sticking to the privous implementation on the Mac environment at
this moment.

--Kazu Yamamoto

Re: problems on inline input on Mac

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 28 Jul 2006 15:50:39 +0900 (JST), Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp> said:

> I don't know this area well. But my point is that the previous
> implementation of inline input by Hashimoto-san was perfect to me.
> And the current code is not.

I didn't adopt the method used in "inline-patch" because it contained
a timing problem.  It may usually work, but not always.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: problems on inline input on Mac

[YAMAMOTO Mitsuharu]

山本様、

千葉大学の山本です。

>>>>> On Fri, 28 Jul 2006 14:19:03 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I've made some email exchanges with Hashimoto-san (the author of
> "inline-patch") on the above issues in Japanese.  I will send you
> some of them if he agrees.

この件について、橋本さんから同意が得られましたので、関連する部分を送付
致します。

＃すみません。まとめられるといいのですが、今はちょっとその気力がありま
＃せん。さらに英語で、となると…。

					山本 光晴
				mituharu@math.s.chiba-u.ac.jp

To: taiichi2@mac.com
Subject: Re: TSM support on Carbon Emacs
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Date: Mon, 29 May 2006 23:54:30 +0900 (JST)

>>>>> On Mon, 29 May 2006 22:59:37 +0900, 橋本 泰一 <taiichi2@mac.com> said:

> 希望: 1. Emacs の Input Method との連携mode-line での状態の表示や
> toggle-input-method での IM の切り替えを可能にしてほしい．同時に自動
> 的に IM と状態の同期を とってほしい．僕は，XTread_socket のループで毎
> 回チェックして，同期を とるようにしています．

> 2. isearch での入力1. の Emacs の Input Method が起動すれば，
> isearch- x を使って入力できるようになると思います．

> 3. 条件によって，入力を Input Method に渡さないように制御 してほしい．
> ことえりでは，"C-SPC" で全角空白が入力されます．このよ うにシステムに
> 渡したくないショートカットを設定できるようになるといいと思 います．ま
> た，C-x の入力後の入力やread-passwd時も無視して ほしいですね．

2の isearch は確かにそのままではうまくいきませんね。調べてみます。

1と3についてですが、希望は分かるのですけれども、「あるキー入力イベント
を Lisp 側で処理する時点での Lisp interpreter の状態」を、
XTread_socket の時点で知ることは原理的に不可能です。橋本さんのインライ
ンパッチでは mac_pass_key_to_system でそのようなことをされていますが、
Lisp 側で処理をしている最中にキー入力が連続してやってくると矛盾が起こる
可能性があります。もしそれを真面目に対処しようとすると、生のキーイベン
トに近いもの(EventRefが再現できるもの)を Lisp 側に渡し、そちらで現在
XTread_socket でやっているような処理を行うということになります。すなわ
ち、input method を (XTread_socketから見てではなく) Lisp 側から見て完全
にバックエンドにするわけです。しかし、この方法は現状のコードに対して大
きな設計変更が必要な上に、他のプラットフォームでの入力イベント処理と全
く異なる形のイベント処理になるため、リリースが近づいている現状ではでき
ません。想像するに C-g の処理は十分に気をつけて設計しないといけなくなる
でしょう。このようなことを考えて、この手の機能はすっぱり諦めました。

また、今は付加的な機能はとりあえず置いておいて、まずは足元をきっちり固
めることに注力しようと思っています。


To: 橋本 泰一 <taiichi2@mac.com>
Subject: Re: TSM support on Carbon Emacs
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Date: Tue, 30 May 2006 17:49:48 +0900

>>>>> On Tue, 30 May 2006 10:21:21 +0900, 橋本 泰一 <taiichi2@mac.com> said:

> このあたりは，僕も頭を悩ませて，アドホックな解決をしています．何 かよ
> い解決方法があればよいのですが．

大幅な変更をしない限りは、どこかに無理が出てくると思います。おそらくこ
ういうことではないでしょうか。橋本さんは Emacs の Input Method に対応す
るようなものを望んでいるが、それを自然に達成するには大幅な設計の変更が
伴う。私が今作っているものはいわば X11版 の XIM サポートに対応するよう
なもので、そのレベルであればコードの変更が少なくて済む。大幅に変更せず
に前者を目指そうとするとどこかで不自然なことをしなければならない。

現在の状況を考えると、当座はコードの変更を少なくして後者を目指すという
のは悪くない選択肢だと思います。前者は例えば mule-ja@m17n.org あたりで
他のプラットフォームとの連携もとりながら、じっくりやっていくという手も
あるのではないでしょうか。ただ、その頃には Cocoa版が Carbon版に取って代
わっている可能性もありますが。:-)


To: 橋本 泰一 <taiichi2@mac.com>
Subject: Re: TSM support on Carbon Emacs
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Date: Wed, 31 May 2006 10:36:03 +0900

>>>>> On Wed, 31 May 2006 10:01:17 +0900, 橋本 泰一 <taiichi2@mac.com> said:

>> 現在の状況を考えると、当座はコードの変更を少なくして後者を目指 すと
>> いうのは悪くない選択肢だと思います。前者は例えば mule- ja@m17n.org
>> あたりで他のプラットフォームとの連携もとりながら、じっくりやっていく
>> と いう手もあるのではないでしょうか。ただ、その頃には Cocoa版が
>> Carbon版に取って代わっている可能性もありますが。:-)

> その意見に多いに賛成です．しかし，現段階ではユーザから見れば多少 不満
> が残るものになってしまうかもしれません．そこで，今作成している山本さ
> ん のものをベースに，僕の改良を加えるような形で Unofficial なパッチを
> 配 布しても構いませんか？あくまでつなぎということ意味です．

はい、実は現実的にはそうなるのが望ましいのだろうなと思っていました。私
も頑固なので :-) 原理原則はできるだけ崩したくありませんし、根本的でない
解決法を本家に入れてしまうと、例えばヨーロッパ圏での使用で思わぬ不具合
が出てしまう可能性があります。しかし、たとえあらゆる場合で完璧ではない
としても、通常の使用で問題がなければそちらの方がいいというユーザも多い
ことでしょう。そのような断り書きを付けて、ユーザにはそのことを納得して
もらった上で使用してもらうのがいいのではないかと思います。

>> 前回のものからの差分の形でパッチを添付します。ちょっと小細工を して
>> isearch のときなどは overlay を使わずに直接エコーエリア に未確定文字
>> 列を表示するようにしました。その場合の候補ウィンドウの位置調整はま
>> だです。やろうと思えばできますが、どうやるのがきれいかをちょっと考え
>> て からにします。

> 僕は，isearch-edit-string で current-buffer を mini- buffer に移して
> います．その方が，カーソルの移動など都合が良かったように記憶していま
> す．  参考になれば幸いです．

これも日本語をメインに使う場合は便利だと思いますが、ヨーロッパ圏などで
アクセント付きの文字を入力する場合などは編集を経ずにすぐに検索に入って
欲しいのではないかと思います。私としては今回はあくまで入力イベントの変
換だけをフロントエンド的に行うということを原則として、その他の部分には
できるだけ手を加えないようにしたいと考えています。もちろん Unofficial
なパッチでそのような機能を付けていただくことは構いません。


To: 橋本 泰一 <taiichi2@mac.com>
Subject: Re: TSM support on Carbon Emacs
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Date: Wed, 07 Jun 2006 09:24:52 +0900

>>>>> On Tue, 6 Jun 2006 18:25:37 +0900, 橋本 泰一 <taiichi2@mac.com> said:

> Mew で，Subject: に入力するときに変換時には色がつかず，確 定後に色が
> つくようです．Goby という Emacs Lisp パッケージでも，文字の大きさが変
> 換 時に引き継がれないようです．

未確定文字列の表示に overlay の before-string プロパティを使っているの
ですが、これはマーカーの直後の face を継承するようです。マーカーの前後
のどちらの face を延長したいかは一般には分かりませんので、あらゆる場合
に期待した動作をさせるというのはできないと思います。ただし、Mew に関し
て言えば、(3.3 で試した限りは) highlight 用の overlay を前後の空白や改
行文字にまで延長することによって対応できるようです。

--- mew-highlight.el~	2004-10-26 16:52:55.000000000 +0900
+++ mew-highlight.el	2006-06-07 08:34:06.000000000 +0900
@@ -88,7 +88,7 @@
 		 (forward-line)
 	       (setq key (mew-match-string 1))
 	       (setq beg (match-beginning 0))
-	       (setq med (match-end 0))
+	       (setq med (match-end 1))
 	       (forward-line)
 	       (setq nspec (mew-nspec-by-key key))
 	       (setq key-face (or (mew-nspec-keyface nspec)
@@ -97,11 +97,11 @@
 				  'mew-face-header-marginal))
 	       (setq overlay (mew-overlay-make beg med))
 	       (overlay-put overlay 'face key-face)
-	       (setq overlay (mew-overlay-make med (1- (point))))
+	       (setq overlay (mew-overlay-make med (point)))
 	       (overlay-put overlay 'face val-face)
 	       (while (looking-at mew-lwsp+)
 		 (forward-line)
-		 (setq overlay (mew-overlay-make (match-end 0) (1- (point))))
+		 (setq overlay (mew-overlay-make (match-end 1) (point)))
 		 (overlay-put overlay 'face val-face))))))))))


To: 橋本 泰一 <taiichi2@mac.com>
Subject: Re: TSM support on Carbon Emacs
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Date: Fri, 09 Jun 2006 12:10:17 +0900

>>>>> On Fri, 9 Jun 2006 11:56:41 +0900, 橋本 泰一 <taiichi2@mac.com> said:

> スクリプト変更のパッチは快調です．

ありがとうございます。ちょっと突発的な締切が入ってきたのですぐには対応
できないかもしれませんが、CVS への commit を考えたいと思います。

ただ、emacs-devel へメールを出した後、RMS から「これは Mac での Emacs
を GNU システムでのそれよりも使いやすくするものではあるまいな」(表現は
ちょっと違いますが)というようなメールが来ましたので、あまり派手に機能追
加はできません。一応「これは X11 で言うと XIM サポートに対応するものだ
から」と言ったら納得してくれましたので、その意味でも XIM に対応する位置
付けのものとして作っておいたのは正解だったと思います。

> 個人的な興味なのですが，before-string を選択した使っている のはなぜで
> すか？

XIM に対応するものであるとすると、確定前にバッファの内容を変更しないよ
うにするのが自然だからです。undo や read-only, キーボードマクロのことな
どのことを考えても妥当な選択だと思います。


To: 橋本 泰一 <taiichi2@mac.com>
Subject: Re: TSM support on Carbon Emacs
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Date: Fri, 09 Jun 2006 12:15:44 +0900

>>>>> On Fri, 09 Jun 2006 12:10:17 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> undo や read-only, キーボードマクロのことなどのことを考えても妥当な選
> 択だと思います。

すみません。キーボードマクロの話はこの件とは別だったかもしれません。

Re: problems on inline input on Mac

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 28 Jul 2006 15:52:34 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> 山本様、

> 千葉大学の山本です。

Ooooooooooops, I was not intended to send this message written in
Japanese to emacs-devel@gnu.org.  Of course I can't cancel this, but
please ignore it.

I'm deeply deeply sorry to everyone.  Especially, apology from my
heart goes to Hashimoto-san.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: problems on inline input on Mac

[Stefan Monnier]

> They are inherited from those just after the (empty) overlay.  You
> cannot tell whether the user wants to inherit them from those before
> or after it.

Well, if you assume that the character will be (in the end) inserted at
point, then yes you can, using front-sticky and such kind of information.


        Stefan

Re: problems on inline input on Mac

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 28 Jul 2006 03:23:10 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> They are inherited from those just after the (empty) overlay.  You
>> cannot tell whether the user wants to inherit them from those
>> before or after it.

> Well, if you assume that the character will be (in the end) inserted
> at point, then yes you can, using front-sticky and such kind of
> information.

Yes, unless further fontification is done after insertion.

Because I think the inheritance of face for overlay strings is a task
of face merging in the redisplay code, I'm not doing anything special
about it in the TSM support code.  The redisplay code just behaves
like this (i.e., inherit the face just after one marker of the
overlay).

One idea would be to change the behavior by which property we use,
before-string or after-string.  If we regard an overlay as a modifier
for an interval, it would be natural for before-string (after-string)
to respect the face that is attached to the first (last, respectively)
character of the interval.  Of course, some consideration is needed
for special cases such as empty intervals, and it might not be a good
time to make such a change.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp