[Uim] surrounding text

[Etsushi Kato]

On 10/8/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> At Sun, 8 Oct 2006 04:11:51 +0900,
> ek.kato at gmail.com wrote:
> >
> > On 10/7/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > Please review the patch attached to. Though I said you about an
> > > unified interface for these text acquisitions, I separated
> > > string input as an independent interface to simplify internal
> > > implementations after some considerations.
> >
> > I've checked the patch and it is great enough!
>
> Thanks for appreciation. Could you implement this?

I've finished a preliminary implementation in the GTK+ bridge except
for filtering paste event.  In your scenario example in the previous
mail, #1, #2, and #4 should work with the implementation (but GTK+'s
surrounding text seems to support at most 2 lines of text).  I didn't
examine scenario #3, and need some consideration I think.


Here is the details and problems.

1) For text acquisition in UTextArea_Primary, it supports
UTextOrigin_Cursor, UTextOrigin_Beginning, UTextOrigin_End for the
origin value, and UTextExtent_Full, UTextExtent_Line, and non-negative
extent is supported in former_len and latter_len.

2) For text acquisition in UTextArea_Selection and
UTextArea_Clipboard, I made it fails upon UTextOrigin_Cursor origin
since its meaning is unclear for me.  For the text extent, it support
non-negative numbers and UTextExtent_Full.  Since the meaning of
UTextExtent_Line in this case is unclear for me, I just assume it as
UTextExtent_Full.

2') In GTK+'s clipboard on X11, a text acquired with
GDK_SELECTION_PRIMARY with UTextArea_Selection doesn't mean it is the
text on the target application.  I think this may cause some problems.
 Possibly some other way to get a selected text on a widget may exist,
but I'm not sure.

3) For text deletion, it support UTextArea_Primary and
UTextArea_Selection text_id. And doesn't support UTextArea_Clipboard
since it is meaningless.

3') For text extent of deletion in UTextArea_Primary, it only support
UTextOrigin_Cursor because of the restriction of
gtk_im_context_delete_surrounding(), and it is needed to explicitly
assign the length of former text and latter text.

3'') For deletion in UTextArea_Selection, I just set the function
delete_selection_text() empty and return success since I'm not sure
how to delete selection text in GTK+, and I think it will be replaced
newly committed text in the scenario #3.

On 10/7/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> Please review the patch attached to. Though I said you about an
> unified interface for these text acquisitions, I separated
> string input as an independent interface to simplify internal
> implementations after some considerations. This API is supposed
> to work as follows.
>
> scenario #1: acquiring surrounding text
>   1) Having a text "predecingIfollowing" on the textarea ("I" denotes cursor)
>   2) (im-acquire-text c 'primary 'cursor 12 12)
>   3) uc->acquire_text_cb(uc, UTextArea_Primary, UTextOrigin_Cursor, 12, 12)
>   4) Returns result of (ustr-new '("preceding") '("following"))
>   5) Split 3) into characters if needed
>
> scenario #2: acquiring full text for Japanese morphological analysis
>   1) (im-acquire-text c 'primary 'end 'full 0)
>   2) uc->acquire_text_cb(uc, UTextArea_Primary, UTextOrigin_End,
>                          UTextExtent_Full, 0)
>   3) Returns result of (ustr-new '("full text of the primary textarea") '())
>   4) Analyze ustr-former-seq of 3) to select dictionary, or tune
>      internal conversion parameters (assuming uim-anthy or uim-prime)
>
> scenario #3: reconversion of selection text by uim-anthy
>   1) Select a text region by mouse
>   2) Input a key that matches against anthy-reconversion-key?
>   3) (im-acquire-text ac 'selection 'end 'full 0)
>   4) uc->acquire_text_cb(uc, UTextArea_Selection, UTextOrigin_End,
>                          UTextExtent_Full, 0)
>   5) The bridge returns selected text
>   6) Returns result of (ustr-new '("text to be reconverted") '())
>   7) (im-delete-text ac 'selection 'end 'full 0)
>   8) uc->delete_text_cb(uc, UTextArea_Selection, UTextOrigin_End,
>                         UTextExtent_Full, 0)
>   9) The bridge deletes selected text
>   10) Reconvert ustr-former-seq of 9)
>
> scenario #4: insert a text read from clipboard into preedit by uim-skk
>   1) Convert a text and fall into word-registering mode
>   2) Look up the kanji-word of 1) by a dictionary application
>   3) Select the kanji-word 2)
>   4) Re-select the textarea 1)
>   5) Input a key that matches against skk-yank-from-clipboard?
>   6) (im-acquire-text sc 'clipboard 'end 'full 0)
>   7) uc->acquire_text_cb(uc, UTextArea_Clipboard, UTextOrigin_End,
>                          UTextExtent_Full, 0)
>   8) The bridge acquire the text of clipboard copied at 3)
>   9) Returns result of (ustr-new '("the kanji-word") '())
>   10) Yank the kanji-word into the preedit to be registered
>
> scenario #5: insert a pasted text into preedit by uim-skk
>   1) Convert a text and fall into word-registering mode
>   2) Look up the kanji-word of 1) by a dictionary application
>   3) Select the kanji-word 2)
>   4) Re-select the textarea 1)
>   5) Paste the kanji-word by mouse
>   6) The bridge filters the paste event
>   7) uim_input_string(uc, "the kanji-word")
>   8) (input-string-handler id "the kanji-word")
>   9) Yank the kanji-word into the preedit to be registered

> > BTW, is there any reason to use such sequence pattern
> > in text-extent-alist? :)
>
> They are low-active bit flags. And it is intended to be used for
> capability detection if needed, although currently not being
> used.
>
> UTextExtent_Unspecified = -1,  /* ..1111 */
> UTextExtent_Full        = -2,  /* ..1110 */
> UTextExtent_Paragraph   = -3,  /* ..1101 */
> UTextExtent_Sentence    = -5,  /* ..1011 */
> ...
>
> enum UTextExtent
> bridge_text_acquisition_capability(void)
> {
>   /* low-active OR */
>   return ~(~UTextExtent_Full | ~UTextExtent_Line | ~UTextExtent_Paragraph);
> }
>
>
> /* low-active input AND */
> if (~bridge_text_acquisition_capability() & ~UTextExtent_CharFrags) {
>   ...
> }

I think these text acquisition capability value may change depending
on whether requested area is primary, clipboard, selection.

Cheers,
-- 
Etsushi Kato
ek.kato at gmail.com