以下は TODO ばかりではなく、実装に至るかどうか分からないアイディアも含
みます。

* 入力機能

** skk-kcode.el をインライン表示対応にする

** 「バッファに挿入する文字列」と「画面に表示する文字列」の区別

例えば変換モードでの「▽」や「▼」それに▼モードでの確定前の候補などは、
本来「表示すべきもの」ではあるが、「バッファに挿入すべき」ものでは必ず
しもない。これらを「表示するがバッファに挿入しない」実装にすることは
overlay を使えば可能ではある。こうすることで、余計な文字列をバッファに
挿入することに伴う undo 情報の乱れを防ぐこともできる。ただし、表示され
る column のズレなどを気にする場合もありうるので、まだ現在の実装から変
更する目途はたっていない。

また、これら "変換アンカー" を、別の文字 (記号) にしたり、色を付けたり、
画像使ってカスタマイズすることもアイデアとして示されている。

** 手書き入力

** 変換領域の定義とその活用 (可能性の検討を要する)

*** 複合語の入力支援

[http://mail.ring.gr.jp/skk/200512/msg00012.html]

* 変換機能

** JIS コード変換

skk-kcode.el で JIS コードによる文字の選択ができるのだから，
skk-abbrev-mode で区点コードを文字に変換する機能があってもいいかもしれ
ない．

** 任意の外部コマンド検索機能

非公式には既に存在する。

** 複数辞書サーバ検索

複数のサーバに並行してアクセスできるようにすべきとのアイデアが示されて
いる。

間接的だが上記「任意の外部コマンド検索機能」を利用することでも可能。

** skk-search-prog-list の拡張

skk-search-prog-list の要素は現在、

 (skk-search-jisyo-file '("/usr/share/skk/SKK-JISYO.L" . euc-jp)
                        10000)

 (skk-search-server "/usr/share/skk/SKK-JISYO.L" 10000)

のように記述し、そのまま eval できる仕様になっている。もしこの設定を
plist をも許容して

 (file :file "/usr/share/skk/SKK-JISYO.L" :coding euc-jp :limit 10000)

 (server :host "localhost" :port 1178)

という指定を可能にできないか。この方法だと、複数サーバへの対応も自然な
形で実装できそう。

** 「属性」付辞書 (SKK-JISYO.notes) を利用した変換性能の向上

三田さんにより作成された、単語 (候補) の属性をアノテーションとしてもつ
辞書がある。

http://openlab.ring.gr.jp/skk/skk/dic/SKK-JISYO.notes

SKK-JISYO.notes の属性情報を利用し、次のような機能を実装する。

1. その属性の内容により、変換の際に候補の絞り込み条件を指定できるよう
   にする。その際、絞り込み条件はユーザーの任意に変更できるようにする。
   (活用形の利用に関しては後述)

2. 候補に最終の変換時刻などを属性として持たせ、辞書のメンテナンスに利
   用する(一定期間アクセスのない候補を個人辞書から削除するなど)。

*** 「活用」の情報を利用した送りあり変換

[http://mail.ring.gr.jp/skk/200511/msg00006.html]

ユーザが「泣く」などの変換をした場合、 skk-henkan-okuri-strictly ない
しは skk-henkan-strict-okuri-precedence の環境下では送り仮名「く」が次
回変換から優先される。その際に、その他の活用形
(「泣か」「泣き」「泣い」「泣け」「泣こ」) の優先度も上げられたら便利
である、という提案がある。

これを実現するには

o あらかじめ動詞などの活用の情報を辞書などに埋めこんでおく
o ユーザの入力時に動的に、その単語のすべての活用形を推測する機能を実装
  する

という方法が考えられるが、後者はかなり大変だと思われる。幸い、
SKK-JISYO.notes が三田さんにより作製され、ここの送りありエントリにある
活用の情報を用いれば、前者の方法にて実装できるものと思われる。

注意点として、この機能が実装された場合にそれなりの副作用があることがあ
げられる。とくに種類の異なる品詞、ないしは異なる活用の種類をもつ同種の
品詞について、そのいずれかの活用形の優先度を下げてしまう場合があり、そ
れはユーザの好みと合わない可能性がある。

(例) 「泣く」を確定 → 「無き」「無い」などの優先度が下がる

現在の機能とこの新機能との公約数的機能が実装できれば都合がいいかもしれ
ないが、「原則的に単語変換」という制限の中では難しいものがある。結局、
ユーザオプションで新機能と旧来の機能を選択できるようにするのがいいのか
もしれない。


* 学習機能

** 「この辞書からは学習しない」設定ができるとよい


* 補助機能

** 多段階の確定アンドゥ

[skk 7193] http://mail.ring.gr.jp/skk/201007/msg00000.html


* 辞書の取り扱い

** アノテーションの仕様をもっと明確に策定し記述する

より良い注釈の付け方について議論し、辞書に反映させていくべき時期に来て
いるかもしれない。

 http://openlab.jp/skk/wiki/wiki.cgi?page=annotation

上記サイトにおいて annotation の規格化が図られている。
(ただし、これを L 辞書に適用する過程は恐らく機械化できないので、そのた
めに必要な労力が問題となる。)


* コーディング

** エラー処理

error ではなく message で充分なところは message に置きかえたほうがいい
かも。

** OOP (Object Oriented programming) 採用の可能性

FLIM (http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/elisp/FLIM/)
に含まれる luna という Emacs Lisp で OOP を可能にするプログラムがある。

著名どころでは、Wanderlust や Emacs-w3m の Shimbun ライブラリが luna
を利用している。

DDSKK は Emacs のバッファに直接読み込む辞書、サーバ経由の辞書、Lookup
とのゲートウェイによる辞書など沢山の辞書があり、また、キーボード入力に
も TUT-Code や NICOLA など色々な種類をサポートしてる。

luna を利用することにより、これらのそれぞれの機能のために、それぞれ個
別に書かれた処理を一元管理することができるようになるのではないかと考え
られる。

** 変換モード毎に異なる動作をするコマンドの統一的な記述

* ドキュメント

** skk.texi の現行コードへの追従をなるべく

この点は SKK ML メンバーの協力により改善しつつある。
DDSKK 14 においては特に入江さん、北本さん、定家さん。

** 英語版ドキュメントの整備

チュートリアルはある。それ以外の部分でも、 SKK の存在価値を世界にアピー
ルしていけるように。

** package対応 【済み】

| MELPAでtexiファイルを扱うようにpull-requestして受理されましたが、
| package.el管理下のtexiファイルの挙動は未確認。
| 今後対応の必要があるかもしれない。

MELPA サーバ側で makeinfo が実行され、skk-info* 及び dir が生成される。
package.el を利用してインストールするパッケージ (手元のPCの ~/.emacs.d/elpa に
溜るファイル) には、前述の skk-info* 及び dir が含まれている。
シンボル Info-directory-list に "~/.emacs.d/elpa/ddskk-xxx" が追加されるので
特に設定することなく M-x info で閲覧できる。

* Emacs の枠を超えた SKK 全体の議論

** サーバにできることと、クライアントにしかできないことを明確にする

SKK 全体の将来について見据えた提言。

[skk 5754] http://mail.ring.gr.jp/skk/200504/msg00026.html

要点のみ上記から転載すると、まずサーバのあり方については

・複数辞書の検索
・辞書の再読込
・電子辞書(EB)の検索
・外部プログラム(MeCab・PRIMEなど)の呼出
・曖昧検索
・高速化(CDBやcacheなどによる)
・接頭辞・接尾辞自動変換
・かな見出しによる数値変換
・ユーザ辞書の管理

などの機能のうち一つか二つを持ったサーバが多数あるよりも、それらを一通
り全て持ったサーバ (スーパー・サーバ) が一つある方が、一般的な利用者に
とってもクライアントの開発者にとっても遥かに便利になるのではないか。

そしてクライアント開発、サーバ開発の役割分担とバランスについては

・各種機能をできるだけ少数のサーバに集約する、または
・複数のSKKサーバに問い合わせる機能を持つメタサーバを作る
・サーバとクライアントのどちらにでも実装できる機能は、サーバに実装する
・全てのクライアントは可能な限り早い段階でサーバとの通信機能を実装する

という方向性が望ましいか。

** プログラム変換機能をどの SKK からも利用できるようにする

SKK は候補が S 式の場合にそれを評価したものを挿入できる。しかし現在、
SKK は elisp だけではないので、elisp 以外の共通語を用意するか、どの
SKK からも呼び出せるプログラムを用意するかしてプログラム変換機能を共有
できるようにすれば...


* 報告された、または確認されているバグ (未修正)

** ccc.el と multi-tty 対応

[skk 7641] 笠原さんからのご報告

[...]
> 具体的には、X で emacs -q -f server-start 等で emacs server を上げて、
> 別のターミナルから emacsclient -t し、カーソルを1つ動かすなどすると背景
> が白で塗り潰されると思います(ターミナルが白地だとわかりにくいですが)。
[...]
> 逆に emacs -f server-start -nw や emacs --daemon で X 無しで起動してか
> ら emacsclient -c で X に frame を貼ると、ccc-setup が呼ばれないので
> SKK を起動してもカーソルに色がつかない、という事になりました。私は普段
> そういう使い方はしていないですが…。

前半の問題は tty な frame で色を設定しないようにすることで回避しうる
(bug fix 確認中)
後者の問題は、カーソル色だけでなくフォント設定なども問題になると思われ
るので、Emacs 側の対応を見極めていくのがいいと思われる。

** skk-isearch と transient-mark-mode

transient-mark-mode が有効なとき、isearch は通常領域を維持して続けられ
るが、skk-isearch に入ると 1 文字以上入力した時点で領域が無効になる。
原因は調査中。

** skk-henkan-show-candidates の数値変換有効時のバグ

http://mail.ring.gr.jp/skk/200602/msg00030.html

小畑さんからのご報告

> すっきりした対処法が分からなかったので ML に投げます。
> 
> 手元の環境で、/1 のように変換すると候補一覧表示状態でループになって
> しまいました。
> skk-search() や skk-henkan-list-filter() した結果として、その回での
> 表示対象 henkan-list が nil になると問題があるようです。
> 
> 一応再現用のコードをつけておきます。
> 
> ;; emacs -q として
> 
> (progn
> 
> (setq skk-init-file "")
> 
> ;(setq skk-show-annotation t)
> (setq skk-update-jisyo-function #'ignore)
> 
> (defun from-private ()
>   (skk-num-compute-henkan-key skk-henkan-key)
>   (if skk-use-numeric-conversion
>       (list "#4" "#2" "#5" "#1")
>     (list "一")))
> 
> (defun from-server ()
>   (if skk-use-numeric-conversion
>       (list "#1" "#3" "#2" "＃;number" "#0" "#4" "#5" "#9")
>     (list "１" "一" "壱;「一」の大字" "弌;「一」の異体字" "壹;「壱」の旧字" "ワン" "one")))
> 
> (defun from-eb ()
>   (unless skk-use-numeric-conversion
>     ;; from かなり古い通信用語の基礎知識
>     (list "Ｑ")))
> 
> (setq skk-search-prog-list
>       '((from-private)
> 	(from-server)
> 	(from-eb)))
> 
> )
> 
> ;; skk-search-server が追加されるので、
> ;; SKK 起動後に再度 skk-search-prog-list を設定しなおす

ものの見事に無限ループしている。確かに簡単に解決するのは難しいか。
henkan-list が nil のとき skk-henkan-list-filter() を呼ばないようにし
ただけだと、候補数が 7 ヶより少なくなってしまう。

** dcomp 候補複数表示時の face

skk-dcomp-multiple-activate を t と設定し、実際に dcomp 候補を複数表示した
際に、現在は候補群の右側1カラムの face がデフォルトに戻ってしまう。

これは、補完候補が背景のテキストの face 属性を引き継ぐのを防ぐために、
故意に候補群の右側1カラムの face を剥ぎ取っている。

箇所:
  skk-dcomp.el (skk-dcomp-multiple-show):
    (setq base-ol (make-overlay (point) (1+ (point))))
    (overlay-put base-ol 'face 'default)
    (push base-ol skk-dcomp-multiple-overlays)

参考:
 [skk 6938] http://mail.ring.gr.jp/skk/200804/msg00019.html
 [skk 6941] http://mail.ring.gr.jp/skk/200804/msg00022.html

将来的にはもっとスマートな解決法が求められる。

** Cocoa Emacs に固有の問題

*** ツールティップにおけるフォント・フェイスの指定

現状 Cocoa Emacs でツールティップ表示すると可変幅フォントのまま変更で
きない (Carbon Emacs では X の場合のように Emacs のフォント設定ができ
た)。


Local variables:
coding: utf-8
mode: outline
end: