トップ 一覧 検索 ヘルプ RSS ログイン

要望の変更点

  • 追加された行はこのように表示されます。
  • 削除された行はこのように表示されます。
SKK の開発に関する意見・要望・アイデアなどを書いてみるコーナーです。TODO.ja のドラフトのような使い方を想定しています。

実装してくださる方、大大歓迎! :-)
// というか、大大感謝です m(_._)m

{{outline}}

!!!関連項目・リンク
*CVS上のTODOファイル――[TODO.ja|http://openlab.jp/skk/skk/main/READMEs/TODO.ja]
*ML提案例――[some ideas(wishlist)|http://mail.ring.gr.jp/skk/200504/msg00018.html]
*フォームへの要望やバグレポートはこちら――[[フォームバグ]]

!!!新機能要望
!!abbrev 関係
!曖昧な abbrev 変換

abbrev の見出しの作られ方には揺らぎがあります。

"" Beethoven /ベートーベン/
"" beethoven /ベートーベン/
"" all-in-one /オールインワン/
"" allinone /オールインワン/

"/beethoven" で検索しても "Beethoven" が(ignore-case)、"/allinone" で検索しても "all-in-one" が(記号類の無視)それぞれヒットするようになっていれば、辞書にどのようなフォーマットで収録されているかを気にせず変換が出来て便利になるのではないでしょうか。

その際、完全に一致したエントリが先に表示されるようになっていると見出しの短い語などではより機能的になると思われます。

*cf. [abbrev-simplify-keys.rb|http://openlab.ring.gr.jp/skk/skk/tools/filters/abbrev-simplify-keys.rb]

!もっと曖昧な abbrev 変換

仮名遣いの揺らぎを吸収してくれる [skk-correct.el|http://openlab.ring.gr.jp/skk/skk/main/experimental/skk-correct.el] という興味深いコードがありますが、これと同様にして abbrev のスペルミスをある程度吸収してくれる機能があると面白いかもしれません。

例えば、"/grammer" でも "grammar /グラマー/" に変換してくれる、など。
どのように補正したのかを何らかの形で表示してくれるとさらに便利でしょう。

"" "グラマー;gramm{e->a}r"

!和英変換・カタカナ化変換

"" compliance /コンプライアンス/

というエントリがあるとして、"こんぷらいあんす" から "compliance" もしくは "コンプライアンス" に変換できると、綴りが思い出せない場合などに便利かもしれません。

辞書を加工することでも実現できますが、コードとして実装した方が .skk で設定したりトリガを押した時だけ実行させたりできて柔軟で効率的と思われます。

*cf. [abbrev-convert.rb|http://openlab.ring.gr.jp/skk/skk/tools/filters/abbrev-convert.rb]

!アルファベット文字列の大文字化・全角化

"" ansi /ANSI/
"" athena /Athena/
"" luna /Luna/LUNA/

のように、アルファベット文字列を単純に大文字化 and/or 全角化するだけのペアが散見されます。

こうした変換が、q によるひらがな列のカタカナ化と同様に1〜2ストロークで出来るようになっていれば重宝しそうです。

(これが実装されれば、辞書からはこのタイプの候補も一掃できます)

これについては、基本的な UI に関わるものなので、仕様をきっちり定めた上で他の SKK 実装にも組み込んでいただけると良いなあと勝手に思っています。

!abbrev の自動ダイナミックコンプリーション

[skk-dcomp-activate|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC70] を abbrev でも使いたいなあ。

----
使いたいなあを通りこしてなんだか凄い機能に変貌した模様。凄い人は凄いなあ。ありがたや。

*ML ―― [dcomp in abbrev mode|http://mail.ring.gr.jp/skk/200511/msg00054.html]


!!数値変換関係
!数値変換のバイパス

"/3rd" と入力しても、内部的には "#rd" として処理されてしまうので

"" 3rd /サード/

にヒットさせることができません。数値変換は、まず入力した通りの文字列で検索した後に # に置き換えた変換を試みる仕様の方が望ましいのではないでしょうか。

----
実装されました。多謝。
* ML ―― [数値変換,etc|http://mail.ring.gr.jp/skk/200511/msg00038.html]

DDSKK以外でも広く実装されているようなので、将来的には仕様を固めた上でこれを標準動作としても良いかもしれません。



!数値入り見出しからのスマートな登録

たとえば、「7けんじん」と入力して「七賢人」を得たい場合に、エントリとして考えられるのは

"" (a) 「#けんじん /#3賢人/」
"" (b) 「7けんじん /七賢人/」

のどちらかでしょう。現状では「7けんじん」と入力すると見出しは常に「#けんじん」となり、(a)の形でしか入力できませんが、この段階で「七賢人」と「#0」などを含まないものが入力されれば、それは(b)の形であると自動的に解釈してくれればスマートかもしれません。

"" tco2 /酸化テクネチウム/TcO2/

のようなものの場合は特に(b)が望ましいでしょう。


!#0〜#3の扱い

"" #にん /#0人/#1人/#3人/#2人/
"" #かい /#1回/#0回/#1階/#0階/#2階/#3回/#1F/#3階/#4階/#2回/

現在、数値変換エントリのほとんどが、一つの助数詞に対し#0〜#3の4つの候補を持っていますが、これは辞書の管理やサイズの上で効率が悪いだけでなく、入力する際にも競合を引き起こしかなりの負担を強いる結果になっています。

ほとんどの人は、#0〜#3のうちのどれか一つをほとんどの場合で使うものと思われるので、一度数値変換を使う(もしくは skk-numerative-preference などとして設定する)と、原則としてそのタイプの候補が常に先頭に並ぶ仕様になっていると便利なのではないでしょうか。

たとえば、#3を選好する人に対しては、辞書が

"" #にん /#3人/#0人/#1人/#2人/
"" #かい /#3回/#3階/#1回/#0回/#1階/#0階/#2階/#1F/#4階/#2回/

であるかのように振舞うわけです。

*cf. [complete-numerative.rb|http://openlab.ring.gr.jp/skk/skk/tools/filters/complete-numerative.rb]


!ローマ数字変換

"" `#8'
"" 
"" タイプ 8。ローマ数字変換。`1789' を 'MDCCLXXXIX' に変換します。

「るい#せい /ルイ#8世/」があれば "Rui16sei " から 「ルイXVI世」が得られるというわけです。


!全角・半角を自動で切り替えるアラビア数値変換

横書きの文章にアラビア数字を交える時には、それが1桁であれば全角、複数桁であれば半角とすると活字の慣行に近い見映えになります。これを#0と#1の中間的な数値変換の一種にするというのも面白いかも。

本来は、入力ソフトでなく(*TeXのような)出力ソフトの仕事ではありますが。


!数値変換スロットの拡張

#0〜#9 では使い切ってしまうのは時間の問題です。#0などの直後に半角数字が来ることは考えにくい(少なくとも現在のところそのようなエントリは存在しません)ので、数値変換の種類を指定する番号は複数桁であっても良いことにすると拡張性の問題は解消できそうです。

"" 「#さつめ /#21冊目/」

と、半角数値が続く限りそれは数値変換の指定番号と見做すわけです。


!小数の入力

「3.8万人」「平均1.4頭」のような、小数を含むものは数値変換では扱えていないようです。数値の直後に入力された"."キーは「。」などにならず直接入力されるようにした上で、"."も数値の一部として扱うようにすればこうした状況を救済できないでしょうか。

"" "Heikin L1.4 C-j Atama " → "Heikin Q1.4tou "


!!annotation 関係
個々の要望と実装というよりは、全体的なデザインを考えてゆく必要のあるもののようです。

* DDSKK manual ―― [5.19.10 辞書のアノテーション(註釈)|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC106]

annotation の表示は専らクライアント側に属する事柄なので、DDSKK の仕様に限定されずにクライアントごとに快適な実装を追求していただくのが良いかもしれません。

----

現在、DDSKK MLでは活発な拡張と議論が進行中です。こちらのスレッドをご参照ください。

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


!annotation 表示のカスタマイズ

[skk-annotation-function|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC107] によって、特定の annotation の表示を抑制することができます。これを拡張して、annotation を加工して返したり(t|nil のかわりに加工した文字列を返すわけです)、表示の仕方そのものをカスタマイズできるようにすれば annotation 活用の可能性を高められそうです。

一例として、†のような特定の文字列を含むものだけ tooltip、それ以外のものは minibuffer に表示させるとか。


!annotation の扱いの統一

現状では、最初の4候補(skk-annotation.el)と、それ以降の候補(skk.el)とで annotation の扱いが完全に異っています。たとえば、[skk-annotation-function|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC107] や [skk-show-annotation|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC107] は最初の4候補に対してしか有効ではありません。

これらをシームレスに扱えれば拡張なども施しやすくなりそうです。

!動的な annotation 表示制御

[skk-annotation-function|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC107] や [skk-show-annotation|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC107] の効果は持続的ですが、これをいつでも手軽にオン・オフできるようにすれば便利そうです。

[TODO.ja|http://openlab.jp/skk/skk/main/READMEs/TODO.ja] にもありますが、普段は annotation の存在だけを知らせ、一定時間手を止めるか、特定のトリガを押した時だけ表示するという仕様が実現すればかなり快適そうですね。(特定の文字列を含むものだけはこれをバイパスして即座に表示されるようにしても良いかも)


!ブラウザ連携

annotation に URL(らしきもの)が含まれている場合、何か操作をすればそのページをブラウザ(esp. [emacs-w3m|http://emacs-w3m.namazu.org/index-ja.html])で開くようになっていれば面白い……かな?

----
これは面白いです。SKKがランチャに!

* [http://mail.ring.gr.jp/skk/200601/msg00002.html]

!annotation入力

annotation から特定のパターンにマッチする文字列を抽出して出力させられれば、用途に応じて特殊な変換を実現できそうです。

対義語変換:
"" /⇔([^/(,‖ $]*)/
"" ほごぼうえき /保護貿易;⇔自由貿易/ → 「自由貿易」

略語変換:
"" /\[略語\]([^/(,‖ $]*)/
"" かんくう /関空;[略語]関西国際空港/ → 「関西国際空港」

!annotationを見出しにした変換

"" りずむとけいこうぎょう /リズム時計工業;[企業名]7769/

のようなエントリから、「7769」もしくは「[企業名]7769」で検索して「リズム時計工業」に変換できれば証券コード変換が実現できます。


!skk-annotation-removeの改良

必要ないと感じた(システム)アノテーションは、確定直後に M-x skk-annotation-remove C-m yes C-m とすることで取り除くことができますが、やや煩雑なきらいがあります。「確定と同時にannotationを除去する」というキーバインドがあれば靴が足になじみやすくなるかもしれません。

また、特に okuri-ari の場合、

"" とt /取/撮;写真を-/[った/取/撮;写真を-/]/[って/取/撮;写真を-/]/

のような状態になりますが、この「とt /撮/」に対して skk-annotation-remove する場合には、送った文字列に関係なく全ての「;写真-」を除去する方が良いでしょう。

ユーザ辞書の仕様としては

"" とt /取/撮;写真を-/[った/取/撮/]/[って/取/撮/]/

のように、annotationは先端(「親」?)の「撮」だけにつけておいて変換・表示時にはそれを参照する方がすっきりしているかもしれません。
// 実装上はそうでもないかも


!!その他
!畳語変換

「毎月毎月」のような畳語は、辞書になくても解析して変換してくれるというのはどうでしょう。/^(.{3,})\1$/ のような見出しに対して、\1 で検索して \1\1 を出力するわけです。

!文脈情報を SKK protocol に追加

一語単位の入力を身上とする SKK ですが、それでもそこまでの文脈を利用して変換精度を高めることはある程度可能です。

現在は文脈を SKK server に伝える手段がないので client 側での実装しかできないのですが、オプショナルにカーソル位置直前の一行くらいをサーバに送信できるように protocol を拡張することは可能かもしれません。対応していないサーバでは、単に捨ててもらえば良いでしょう。

早い話、「DDSKK 以外でも [skk-bayesian|http://openlab.jp/skk/skk/main/experimental/bayesian/] を使いたい!」

*cf. [POBoxサーバ - プロトコル|http://pitecan.com/OpenPOBox/server/protocol.html]

!縛りのある入力

漢字・ひらがな・カタカナの使い分けから漢字の送り方まで全てを意のままにできるのが SKK 最大の魅力ですが、不幸なことにどうしても一定の縛りの下で文章を書かねばならない状況というのも存在します。

設定を変えてやることで、常用漢字・音訓以外は自動的にかなに変換したり、送り仮名の本則・例外・許容・非正則を任意の幅に収めたりできるようになっていればより広い需要に応じられる可能性があります。

!辞書からの「穏やかな」削除

現在、候補選択中に X を押すことでその候補をユーザ辞書から削除することができますが、これはskk-ignore-dic-wordとして(直接辞書を編集でもしない限り)二度とその候補が出現できなくするという「強い」ものです。

あまり使わない言葉や人名などを確定してしまって、ユーザ辞書からは消したいけれど、元の順位では出て来てほしいという場合も多いと思うので、単にユーザ辞書から消すだけにする「穏やかな」削除方法も選べると良いのではないかと思います。

*skk-purge-from-jisyoではだめですか?

!候補の出どころ表示

<assoc><geo><JIS3_4>のように、ある候補がどの辞書に収められていたものかを表示できれば入力の一助になりそうです。

!異体字「ごっそり」変換

SKK-JISYO.itaijiと「▽」挿入による異体字変換は一文字単位ですが、これを複数文字に拡張することも考えられます。単語を入力した後で、それをごっそり旧字に変換といったことができれば随分と楽ではないか、と。

cf. [異體字轉交流之塲|http://www.eonet.ne.jp/~kotobukispace/ddt/itaizy/itaizy.html]

!JIS X 0213の面句点コード入力

現在、\キーにで区点コード入力ができますが、これでは面は指定できないので、2面の文字を使いたい時には"C-u \ japanese-jisx0213-2 C-m"と操作する必要があります。「2-90-39」のように、ハイフンが二つ入れば自動的に面区点コードとして扱ってくれればかなりの手間が省けそうです。

----
2010-12-04 の cvs commit で対応しています。
「2-xx-xx」で jisx0213 の2面とみなし、「U+nnnn」で Unicode とみなします。

!!!辞書新設・改編・廃止など


!!SKK-JISYO.huge

ロボットにウェブを巡回させて複合語を拾い集めさせ、片っ端から追加して辞書にしましょう。一定字数以上の複合語なら、kakasi などでも充分読みは当てられそうです。

これは SKK でやる必要はなさそうです。どこかにそういうプロジェクトがあれば、変換スクリプトを書いてありがたく成果のお裾分けに与りましょう。

辞書サイズは恐らく瞬く間に数百MBにはなるでしょう。正直、あまり使ってみたいという気にはなりませんが。可能性だけ示唆。

//こうした辞書が実現した場合、L辞書は人力で編集する最大規模の辞書という位置付けになるわけです。

仕様例:
* L辞書から高頻度(>10000)の二字熟語を抽出しサーチエンジンで検索
* 検索結果から、その熟語を含む漢字列を抽出
* 各漢字列を検索して頻度を調べ、一定数以上あれば huge辞書に採録
(これではかなを含む複合語などは扱えません。形態素解析器の力が必要でしょう。最終的には教師なし学習の問題に帰結?)

cf.
*[sumibi|http://www.sumibi.org/sumibi/sumibi.html]
//*[skk-term|http://sourceforge.jp/projects/skk-term/]

!!SKK-JISYO.pubdic+

pubdic+辞書は残すところ僅か 248 candidates です。不要な語を noregist と wrong に移した上で、残りは全てL辞書にマージして pubdic+ は解消するのが良いのでは。

//ただし、あえてこのファイルを残して Pubdic+ project からの寄与の記念碑にしておくという考え方もあるかもしれません。

!! skk-henkan-okuri-strictly 用データの配布 (dot.skk-jisyo)

ユーザ辞書をある程度鍛えた上で [skk-henkan-okuri-strictly|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC63] や [skk-henkan-strict-okuri-precedence|http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja_5.html#SEC64] を用いることで、「大かった」や「食い尽かれる」などの不自然な候補を排除して変換効率を高めることができますが、これらの情報はもともと文法的に説明できるものなので、最初からある程度「鍛えられた」状態の辞書を配布することもできるはずです。

基本的な語彙についての情報を dot.skk-jisyo のような形で提供し、 skk-henkan-strict-okuri-precedence をデフォルトにすることで、使い始めから快適な入力を提供することができるでしょう。

また、文法的に決定できる以上、現行の[]を用いた方式でなく、notes辞書のようなものを直接読む仕様にしても良いでしょう。

(これをサーバサイドで実現するには protocol の拡張が必要になりそうです)


//!!!バグレポート
//バグは直接 ML に報告なさった方が良いと思われます。

!!!メタ議論
; この項目は書きかけ(stub)です

!!「SKK的」の2つの審級
!ユーザから見たシンプルさ
!実装としてのシンプルさ
!!辞書・サーバ・クライアント
*ML ―― [server and client|http://mail.ring.gr.jp/skk/200504/msg00026.html]
!!仕様と実装