[m17n-lib:00117] Re: [Uim] Re: Re: SCIM help for M17N input methods (was: Custom Keyboard Layout Editor/Interpreter for SCIM)

[YamaKen]

Hi Kenichi, sorry for late reply.

Now I've finished urgent work and gotten a time for discussion.

At Wed, 23 Feb 2005 10:32:14 +0900 (JST),
handa at m17n.org wrote:
> 
> In article <200502220908.j1M98aN6006665 at mbox00.iij4u.or.jp>, YamaKen <yamaken at bp.iij4u.or.jp> writes:
> >>  > (4) For loading and saving the customization.
> [...]
> >>  We have not yet implemented (4).  Do you think it's surely
> >>  necessary?
> 
> > I think that selecting better way should be based on user
> > convenience and your own development/maintenance cost.
> 
> Implementing (4) is quite easy in m17n-lib.  Just to recode
> all calls of minput_assign_command_keys and
> minput_set_variable into a plist, and to call a plist
> serializing (into an M-text) function.

Sounds good enough. Then, uim will delegate the load/store
responsibility to m17n-lib via the m17n-lib API.

But as I said before, some customization data for uim-m17n such
as uim-dependent key binding expression may be saved into uim's
own store to override m17n-lib's one.

> I'm also going to implement functions to
> serialize/deserialze a plist to/form XML.  So, it's possible
> to store the customization data in XML.
> 
> But, having such functions only for m17n-lib input methods
> is not that useful for users.  The better is that all of
> m17n-lib, SCIM, and UIM uses the common format and semantics
> of customization data.

Such unification is too early and heavy for uim, at least.

But other projects may prefer your way at now. I know some
scim-prime guys need such specification for their project.

I think that the unified IM API project is appropriate place to
discuss such issue.

http://sourceforge.net/projects/unified-im-api/

> My proposal for the variety of customazation data is as
> below:
> 
> (1) command key customization
> 
> A command is an action of an input method invoked when a
> user types a keyseq assigned to that command.  A command has
> a name, description (and optional detail description), and
> global and local (per input-method) keyseq assignments.
> Multibyte keyseqs can be assigned to the same command, and
> the same keyseq can be assigned to multiple commands.
> 
> There should be a common name and semantics (action)
> definition for each command.  For instance, "commit" command
> is to "commit the currnet preedit text", "first-candidate"
> command is to "select the first candidate of the current
> candidate group".  The file im-cmd.tbl in imtest.tar.gz is
> our proposal for such commands.
> 
> (2) variable customization
> 
> A variable is to control the behaviour of an input method in
> various way, e.g. to select a specific mode, to specify what
> kind of characters to be input, etc.  A variable has a name,
> description (and optional detail description), global and
> local initial value, and optional specification for a range
> of valid values.
> 
> There should also be a comman name and semantics (how to
> control the IM behaviour) as well.
> 
> For instance, isn't it good that a user can customize the
> single variable, say "cjk-punctuation", for all CJK input
> methods to select which kind of comma and period should be
> generated (i.e. ASCII-comma/period, full-width-comma/period,
> or touten/kuten (U+3001/U+3002))?

Thank you for the good abstract.

> Do SCIM or UIM use the other kind of customization data?

uim has some other kind of data, and different model of data
management. So I believe that directing my effort to developing
other things will benefit users better, at least for now.

For example, following issues will not fit to static XML store
and dedicated data interpretation.

- uim sometime generates customization items itself dynamically
  by Scheme code such as enumerated 0..n items of key binding
  rather than read static predefined items

- uim expresses dynamic relations between custom variables by
  arbitrary Scheme codes. Customization groups and items may
  appear/disappear/be activated/be deactivated in accordance
  with states of other variables or operations in arbitrary rule

- uim sometime loads arbitrary Scheme code as customization. For
  example, this is an auto-generated stub IM entry.

  (if (memq 'anthy enabled-im-list)
      (if enable-lazy-loading?
          (register-stub-im
           'anthy
           "ja"
           "EUC-JP"
           "Anthy"
           "A multi-segment kana-kanji conversion engine"
           "anthy")
          (require-module "anthy")))

- uim treats some abnormal key binding expressions that other
  programs will not accept, such as follows:

  ((pkey_jp106_x (chord lkey_Thumb_Shift_R pkey_jp106_bracketleft)) (some_act))

  The key binding expression contains physical keysym,
  unfamiliar logical keysym, and simultaneous out-of-ordered key
  pressing. Standardizing such items will cost us heavy
  discussion and development.

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp