SKK日本語入力FEP
SKKFEP - Simple kana to kanji conversion front end processor

ＳＫ拳 ─────

それはシフト空手道と

ローマ字変換をくみあわせた

まったくあたらしい日本語入力・・・

ダウンロード

概要

　SKK日本語入力FEPはWindows用の日本語入力ソフトです。
　インストールするとWindowsのすべてのアプリケーションに作用し、SKK方式による日本語のかな漢字変換入力が可能になります。

これだけ読んどきゃ十分だぜ！

インストール方法

設定方法

主な操作方法

気をつけろ！あとは全部罠だ！ボンソワール？

日本語入力方式SKKについて

　SKKは佐藤雅彦教授により開発されたEmacs用の日本語入力プログラムです。日本語の文法解析を一切行なわないという斬新な設計思想で作られており、シフトキーによる補助操作で語句の区切りを人間側が明示することで、口語や方言、未知の造語といった従来の日本語入力方式が特に苦手とする文に対しても送りがなの誤認識が原理的に発生しないという優れた特性を持っています。
　なお、文法解析がない故に同音異義語が苦手であるといった問題はありますが、それを補うために接頭辞・接尾辞の変換操作やシンプルな学習機能が塔載されており、変換と辞書への追加削除による出現順序の調整といった一連の操作を、日本語入力の操作途中であることを意識せずシームレスに行なえる独特の操作形態を持ちます。
　他にも、他の日本語入力方式では必須だった「入力の確定」操作がほぼゼロで済むという特長も持ちます。日本語で最も出現率の多いひらがな・カタカナが即座に入力でき、漢字変換の操作中でも構わず次の文字を入力できてしまう暗黙の確定操作などの工夫によって打鍵数を確実に減らすことができます。

　現代の日本語入力システムの多くは、複雑な辞書による高度な言語解析を駆使することで、説明不要で誰もが初見で使える『親切設計』が主流となっていますが、SKKはこうした流れとは明らかに一線を画しています。特殊なシフトキー操作は、あたかも乗り物を操縦するかのように熟練を要する、一見『不親切設計』とも取れる作りですが、それ故に文法解析ミスによる無駄な訂正操作や思考の中断のない、流れるような日本語入力が可能となっています。最初は戸惑うこともありますが、『シフトキーを押す』という操作は単純明解であり、それほど時間をかけずに「思った通りに」日本語を入力できている、という実感が得られることでしょう。

　もしSKKに興味が湧いたら、ぜひSKK日本語入力FEPや原作のSKKを体験してみてください。
　さらなる知的好奇心を満たすべく、めくるめくSKKの世界へあなたを誘う魅惑の情報をいくつかご紹介しておきます。

*SKKとは (エスケイケイとは) [単語記事] - ニコニコ大百科♺

SKKへの愛に満ちたすばらしい紹介記事です。ふーん、SKKに興味があるんだ？とりま、これ読み？大丈夫だ、問題ない。ちょっとだけ！先っちょだけ！恐くない痛くない考えるな感じるんだSKKは初めてか？力抜けよ

*SKK Openlab♺

開発終了した本家SKKに代わって開発を行なっているSKK Openlabのページです。SKK辞書ダウンロードやメンテナンス情報、SKKの生い立ちに関する資料など

*SKK - Wikipedia♺

ウィキペディア創設者ジミー・ウェールズからの緊急のお願いです。で有名なWikipediaよりSKKの記事

　他にも、Kanzen♺→SKK♺→Sekka♺という非文法解析型の日本語入力の進化の歴史は試験に出ます。
　

あとはGoogle先生、お願いします！♺

SKK日本語入力FEPについて

　前述の通り、SKK日本語入力FEP(以下SKKFEP)はSKK方式による日本語入力をWindows上で実現するソフトウェアです。
　SKKFEPはWindowsのテキストサービスフレームワーク(TSF)によるキーボード系テキスト入力プロセッサ(TIP)として実装されています。

　SKKFEPは、SKK10系の動作を参考に『SKKの操作感覚』をWindows環境に移植することを目指しており、新規に開発した小規模なプログラムで軽快な動作を実現しています。
　なお、既に同種のソフトウェアとしてskkime♺やCorvusSKK♺などの完成度の高い著名な作品が存在します。SKKFEPは、後発の利を行かしてWindowsアプリケーション自体の利便性を向上させるための独自の機能を備えています。正攻法で攻めるだけでは面白くないので~~色仕掛~~変化球で勝負(ry

UNIX用漢字入力フロントエンド skkfep♺という同名のソフトウェアが存在することが判明したため、名称を「日本語入力システムSKKFEP」から「SKK日本語入力FEP」へと改名することにしました。どちらもSKKによる日本語入力という志を同じくするソフト同士ではありますが、中身は別物ですのでご注意ください。

特長

　SKKの持つ小型・軽量といったメリットを引き出すために再設計を行ない、徹底的にプログラムの軽量化を図りました。実行ファイルのサイズで見ると、フロントエンド部が36.5KB、バックエンド部が10KBとなっており、日本語処理に詳しい方なら一目でその~~異常さ~~特殊さを見て取れるかと思います。SKKならば初期のファミコンゲームほどの小さなサイズで、老舗のジャストシステムやGoogle・マイクロソフトなどの最先端の製品に負けずとも劣らぬ、実用的な日本語入力処理が実現できることをここに実証します。

　ドライバ不要のSandS入力機能を搭載しています。SandSとは、スペースキーを擬似的にシフトキーとして代用する入力方式です。従来のキーボードドライバを用いた方式では適用が困難だった、リモートデスクトップ環境下においても操作可能となっています。

　豊富なシフトキーの代替操作を用意しています。標準では変換キーがSandSとして動作し、また設定によって変換無変換などの特殊キーに自由にSandSや順次打鍵操作(skk-sticky-key相当)を割り当てることが可能です。基本的に外部アプリの支援は一切必要とせず、すべて自力で動作しますが、他の便利なキー操作支援アプリとの連携も可能となっています。

　アプリケーション側でIMEの状態を意識せずに使えるようになります。特殊なキー判定処理を持つアプリケーションに対しても、キー操作情報を極力そのまま渡すことで、常時IME有効で動作するよう工夫を行なっています。IMEの切り替え操作による思考の中断やストレスから解放されていろいろ捗ります。さあ心を無にしてCTRL+J連打だ！S・K・K！S・K・K！

　ローマ字変換ルールをチャットや実況用途向きに改良することで、SKKのモード切り替えを減らし打鍵数を減らします。数字キーの後のカンマやピリオドをモード変換なしでそのまま入力することができ、口語で多用する「あ行小文字」の連続入力や、ネットスラングで多用される全角子音アルファベットを、変換に破綻のない範囲でひらがなモードのまま入力可能となっています。気軽に雑草を生やすこともでき、ｗｋｔｋなどのMicrosoft IMEによる入力を前提としたネットスラングをそのままの形で入力可能です。
　また、SKKIME1.5改と同様、z(またはf,j)キーとアルファベット以外の文字を組み合わせたEgg風の2ストローク記号入力ルールを標準で持っています。SKK標準の入力ルールと後方互換(上位互換)の操作となっています。

　ブラウザや表計算ソフト等の日本語の予測入力欄との親和性が向上しています。SKKの特色でもある「▽」による変換の目印は標準設定では一切表示されませんが、それでも視認性を損わずに入力状況を確認できるよう工夫してあります。

　SKKの操作性を生かしつつ入力速度や操作性を向上させるための他に類を見ない独自の入力支援機能を塔載しています。全辞書領域を対象とした動的補完や単一候補の通知、母音未確定状態でも使える予測変換や英単語の自動認識、学習オフでも使いやすい偽装確定など、次世代SKKへの思いを全力全開でぶつけました。他にも、SKKクローンでは見落とされがちなシフトキー受付期間の拡大やSandSによる高速打鍵時の問題解決などに取り組んでいます。SKK原作ファンの方でも満足できるよう、主要な機能は設定で有効・無効を自由に選択できます。

　辞書を含むインストーラとアンインストーラを完備しています。インストーラはインターネットからの辞書のダウンロード(あるいはローカルファイルのコピー)までを自動で行ない、入力言語の切り替え操作を行なうだけですぐに使えます。最新のCランタイムなしでも動作するので、OSインストール直後にそのままインストールして使うことができます。また、既存のIMEとの共存が可能で、いつでも自由に切り替えることができ、不要の際には痕跡を残さずアンインストールが可能です。

　Windows XP/Vista/7～10で動作します。Windows XPでも動作します(後述)。OSの種類や32ビット/64ビット環境がどうこうといった細かいことを気にする必要はありません。インストーラが全ての環境において自動的に対応します。

宇宙ヤバイ

　SKKFEPでは試作レベルから実用レベルまで、さまざまな機能拡張が試みられています。
　もちろん、SKKの標準機能だけで十分実用になりますので、無理に全ての拡張機能を使う必要はありませんが、
　いつの日か、SKKに慣れ親しみすぎて「壁」に直面した時、きっと役立つことでしょう。

注意: 以下の文書を読むためには、初歩的なSKKの知識と高度な愛が必要です。無理に読む必要はありません。: SKKプラス - 送りがな誤入力の自動補正; SKKGate - SKK辞書処理の拡張手法; SKKNet - 次世代SKKサーバプロトコル

導入

　インストール方法と簡単な動作確認方法について解説します。

インストール(アップデート)の方法

　別のページにまとめたのでそちらを参照してください。

インストール方法

設定方法

操作

　SKKの基本的な操作について解説します。

操作方法

　SKK方式ではローマ字かな変換による入力が基本となっています。以下に基本操作を記します。

これだけ読んどきゃ十分だぜ！

1. CTRL+Jを押すとひらがな入力モードになり、l(小文字のL)で半角英数の入力モードに戻ります。
2. 日本語はローマ字で入力します。入力したひらがなは即座に確定されます。他の日本語入力方式とは異なり、確定操作は不要です。
3. ローマ字の先頭部分をSHIFTキーを押しながら入力することで変換操作の開始となります。

通常の漢字変換

単語を入力してSPACEキーを押すと漢字変換を行います。

　　　　例: UmiharakawaseSPACE → 海腹川背

変換中はSPACEを押すとどんどん次の候補に切り替わります。x(小文字のX)を押すと前の候補に戻ります。

送りがなのある単語の場合

送りがなのある単語を変換する場合は、送りがなの先頭の文字をSHIFTキーを押しながら入力します。

　　　　例: MimeuruwaShi → 見目麗し

送りがなを含む単語の場合、SPACEを押す必要はありません。送りがな部分の入力だけで変換が完了します。別の候補を選択したい場合は、送りがなの入力後、SPACEとxで選択できます。

カタカナ語の場合

カタカナ語を変換したい場合はq(小文字のQ)を押します。(単語が辞書にある場合はSPACEで変換することもできます)

　　　　例: Dwu-cheq → ドゥーチェ

(拡張機能) 上記どの場合でも、文字の入力途中に．を押すと予測変換ができます。SPACEやSHIFTを押すことなく、表示されている候補を即座に入力できます。

4. 変換操作で全ての候補を表示したか、または辞書に候補が存在しない場合は辞書登録状態になります。

文字を入力してENTERで登録完了となり、同時にアプリへの入力が行われます。

(拡張機能) ブラウザ等の他のアプリからCTRL+VやSHIFT+INSERTで漢字や絵文字などをコピペできます。

(拡張機能) 拡張スクリプトがインストールされている場合は行頭でTABを押すとオンライン辞書にアクセスして単語を変換することができます。

5. 操作を間違えた時はCTRL+Gを押すと操作を中断できます。

　SKKの基本はこれだけです。上記で使用した基本操作をまとめてみました。

基本操作
CTRL+J	★ひらがな入力状態へ迷ったらとにかく連打
l (小文字のL)	★半角英数入力状態へ
SHIFTを押しながらA～Z	★編集開始・送りがな開始
SPACE	★変換・次候補
CTRL+G	★中断

(変換中に)x	★前候補
(編集中に)q	★カタカナで確定

　シフトキーを併用して単語の開始や送りがな位置を人間が直接指定できることこそがSKKの最大の特色です。
　人間による変換タイミングの指示ができるおかげで、小型で単純な仕組みだけで作られたSKKが、大規模で複雑な文法解析処理の塊である最新の日本語入力ソフトウェアを相手に「文法解析ミスが原理上発生しない」究極の変換精度で太刀打ちできるのです。

　慣れないうちは、変換開始のシフト押下をつい忘れてしまって

シフトキーの操作を…強いられているんだ！

…などと派手なエフェクトと共に全力で叫びたくなる衝動に駆られるかもしれませんが、楽器の演奏と同じで少しづつ上達を実感でき、慣れてくると自然と指が動くようになります。

キー操作一覧

　SKKFEPにおけるキー操作の一覧を以下に示します。
　何やらたくさん種類がありますが、全てを覚える必要はありません。
　最低限必要な操作は、さきほど説明した5つの基本操作と2つの補助操作だけです。
　これらの主要な操作には星印★を付けてあります。
　とにかく主要な操作だけ理解しておけば、日本語の漢字かな混じり文を自由に入力することができます。

全般
CTRL+J	★確定・ひらがな入力状態へ
q (小文字のQ)	カタカナ入力状態へ
cを押してからq	半角カナ入力状態へ (独自拡張)
l (小文字のL)	★半角英数入力状態へ
CTRL+L	〃 (独自拡張, 既に半角英数ならアプリに操作を伝える)
SHIFT+L	全角英数入力状態へ

SHIFTを押しながらA～Z (変換を押しながらでも可)	★編集開始・送りがな開始
SPACEを押しながらA～Z	編集開始・送りがな開始 (要設定変更)
SHIFT+Q	編集開始
/	英字編集(Abbrevモード)開始
SHIFT+変換	直前の入力・確定を取り消して再編集 (独自拡張)

ENTER, CTRL+M	確定・登録完了
CTRL+G ESC, CTRL+［	★中断
BS, CTRL+H	後退
DELETE, CTRL+D	文字削除
CTRL+A, HOME	カーソル左端移動
CTRL+B, ←	カーソル左移動
CTRL+F, →	カーソル右移動
CTRL+E, END	カーソル右端移動
CTRL+Y, CTRL+V SHIFT+INSERT	クリップボードの文字を貼付

半角/全角, ALT+漢字 ALT+`	入力メソッド(IME)のオン⇔オフ切り替え
CTRL+］	表示方式切り替え (操作時限定)

編集中
SPACE, 変換	★変換 (次候補)
q (小文字のQ)	★カタカナで確定
CTRL+Q	半角カナで確定/全角英数で確定
． CTRL+N, ↓	予測変換で表示されている候補を選択 (独自拡張)
CTRL+F, →	語尾検索⇔全文検索の切り替え (独自拡張, 右端時限定)
＞	接頭辞変換
；	送りがな入力準備 (順次打鍵シフト/Sticky-Shift)
：	単語絞り込み (拡張スクリプト利用時)
/, CTRL+X	日本語⇔英字編集の切替 (独自拡張)
TAB, CTRL+I	補完開始・次補完
SHIFT+TAB, CTRL+U	前補完

変換中
x (小文字のX)	★前候補
SHIFT+X DELETE, CTRL+D	単語削除
＞	接尾辞編集開始
；	注釈の編集 (独自拡張)
CTRL+V	註釈の選択 (独自拡張)
CTRL+Q	学習せずに確定 (独自拡張)
CTRL+E	送りがなの追加 (独自拡張)

選択中
ASDFJKL	候補選択
SHIFTを押しながらA～L (変換を押しながらでも可)	単独候補選択 (独自拡張)

登録中
TAB, CTRL+I	オンライン辞書検索 (拡張スクリプト利用時) またはカタカナ語入力支援 (登録開始直後にTABq) 註釈区切り文字の入力

　異世界ではクリスタルに選ばれしSKK戦士だったはずなのに、記憶喪失になってしまって自分の名前すら思い出せない！とお悩みのアナタも、日本語がわかるなら大丈夫です。とにかく最初はCQCの基本となるCTRL+JとCTRL+Gの使いかたを思い出してください。あとはシフトキーを16連射しながら城の回りでスライム退治でもしていれば、いつの間にかMPが増えて他の呪文も使えるようになります。戦士とは名ばかりの近接格闘型の魔法使いでOK牧場。ガンガンいこうぜ

　ちなみにこの程度のレベルでキー操作が多すぎだ、などと寝言をのたまう連中にはMS-IMEの現実♺を叩きつけてベッドに直行させてやりましょう。SKKがシンプルと銘打つにはそれなりの理由があるのです。

SKK10からの変更・改良点: ひらがなモードへの変更: CTRL+J (カタカナモードであっても常にひらがなに戻る); 半角カナモードへの変更: cを押してからq; 註釈の変更: 註釈を修正したい単語が変換候補として表示されている状態で；を押し、セミコロンの後に註釈を追加・変更; 予測表示されている候補を即変換: ．または ↓ (CTRL+N)

『変換マーク(魔法少女)なんてもういいですから。』

　SKKの特長となっている、編集状態・変換状態における▽▼マークは標準では一切表示されません。これは仕様です。たかがメインマーカーをやられただけなので、操作感覚には微塵の影響もありません。
　なぜなら、SKKでは変換の主導権を握っているのは利用者である人間だからです。そう、▽マークはあなたの心の中に。目に見えていることだけが全てじゃない。考えるな感じろ。フォースがともにあらんことを。

日本語入力モードの切り替え

　SKKFEPを標準の入力方式に選択した状態では、アプリケーション起動直後からSKKに関する操作を受け付けるようになります。(レジストリ設定により、初期状態を変更したり、アプリケーションごとの有効・無効を選択できます)
　アプリケーション起動直後は半角英数モードになっているので、CTRL+Jを押すと日本語入力が可能になります。半角英数モードに戻す場合はl(小文字のL)を、全角英数モードにする場合はSHIFT+Lを押します。
　SKKFEP有効時、標準設定ではCTRL+Jの入力は一切アプリケーション側に渡りません(後述する設定で変更可能です)。従来通り全てのキー入力をアプリケーション側に渡す場合は、半角/全角(またはALT+漢字キー)を押して日本語入力モードをオフにしてください。

SPACEキーによるシフトキー代替操作(SandS - Space and Shift)

　SKKFEPの初期設定ではSandSは無効になっています。後述する設定により、SandS機能を有効化したり、アプリケーションごとに別々のSandSの適用を選べるようになっています。
　一部のアプリケーション(Windows標準ではないリモート制御ツールなど)では、SandSが有効になっているとスペースキーの押下が認識されないものが存在します。この場合、半角英数モードに変更するか、或いはSHIFT、CTRL、変換などのキーを押しながらスペースキーを押すことで、生のキーイベントがそのままアプリ側に渡るようになっています。うまく活用してピンチを切り抜けてください。

変換キーによるシフト・変換操作

　SandSは便利なのですが、やっぱりスペースバーは押した瞬間に反応してほしい…というピュアな心を持つ貴方のために、変換キーでもシフト・変換操作を行なうことができます。SPACEキーのSandS機能が無効となっている状態でも機能するので、ここぞという時に「こんなこともあろうかと」とか言いながら押してください。(セーフモードによるMSWordバグ自動回避時のみ無効化されます)
　なお、代替シフトキーは同時に一つだけ判定が行なわれます。例えば変換と無変換を代替シフトに割り当てた場合、先に押した側がシフトキーとして動作し、他のキーは生のキーイベントがアプリケーションに渡ります。

暗黙の確定

　SKKでは変換操作中に次の語の入力を開始することで、自動的に確定操作が行なわれます。これは「暗黙の確定」と呼ばれるSKKの特長の一つです。標準設定ではCTRL+HやBSでもSKK10同様に暗黙の確定が行なわれます。
　例えば「火曜」の「火」だけを入力したい時に、「かよう」で変換してCTRL+HやBSを押すことで確定と文字削除を同時に行ない素早く入力することができます。単漢字や同音異義語の高速選択を苦手とするSKKにおける重要な操作テクニックの一つとして、覚えておくと役立ちます。
　なお、よく訓練されたSKK使いは、この時脳内に

暗黙の(三戦)…確定(呼)ッ！(すぱーん)

…とエフェクトの効いた必殺技の発動音が響くといわれ、恐れられています。容量用法を守って正しくお使いください。(入力中のｶﾁｬ音やｯﾀｰﾝ！には個人差があります)

補完

　TAB(CTRL+I)で補完モードを開始します。補完中にTABを押すと次候補となります。
　SHIFT+TABまたはCTRL+Uで前の候補に戻ります。
　補完中に文字入力や変換やその他操作を行なうと、補完部分が確定し補完モードは自動的に終了します。
　CTRL+Gで補完モードをキャンセルします。
　……あとはわかるな？

入力例: UmiTABTABTAB

動的補完と短縮入力

　文字を入力した瞬間に補完候補が表示され、変換可能な候補なら外部表示領域にその内容が表示されます。
　この時、．やCTRL+N、カーソルキー↓を押すと表示されている候補を即座に選択します。
　TABを押して補完状態にしてSPACEで変換する操作と完全に等価ですが、一打鍵だけで即発動するというのが最・重・要です。打鍵数が増えがちなローマ字かな変換操作を劇的に短縮する可能性を秘めた最後の幻想なのです。

入力例: Umi．

和英切替操作(雪花方式)

　日本語入力方式「石火(Sekka)」にヒントを得た、和洋折衷の入力操作が可能です。日本語、英語問わず単語の先頭を大文字で打ち込むだけで、途中でCTRL+Xを押せば日本語入力状態と英字入力状態を自由に切り替えられるようになっています。標準設定では日本語入力中は/でもモードを切り替えることが可能です。(設定次第で英字入力中にも受け付けるようにすることが可能です)
　また、入力中に気を利かせて英単語を自動認識し、日本語の読みが存在しない場合は自動的に英単語側に切り替えを行ないます。最初は学習情報もろくに持たないため、ちょっとドジっ子かもしれません。

入力例: Maki/ CTRL+X CTRL+X CTRL+X…

単語の絞り込み

　変換候補が多すぎる！という時に：を押し、他の単語の読みから該当する漢字を検索することができます。例えば「ジュモク(樹木)のジュ」を入力したい場合、「じゅ」で変換すると同じ読みの単語が沢山あるため、すぐに選べなかったりします。その場合、変換前、変換後どのタイミングでも構わないので：を打鍵し、「じゅもく」と入力することで単語を絞り込むことが可能です。絞り込む単語も動的補完や短縮入力が可能なのでうまく活用することで少ないキー操作で候補を絞り込むことができるようになっています。

　バージョンβ0+8i以降で本機能を使う場合はSKKGateによる拡張が必要です。

入力例: Ju：jumoku

クリップボードからの貼付(ペースト)

　単語登録時はCTRL+YまたはCTRL+VまたはSHIFT+INSERTを押すことでクリップボードからの文字の貼付が可能です。標準アプリである文字コード表と組み合わせてお使いください。

註釈(アノテーション)の編集

　SKKFEPは独自の註釈編集機能を持ち、単語の登録時や変換時にいつでも自由に註釈を変更することができるようになっています。
　登録時は特別な操作は必要ありません。単語の登録の際、セミコロンの後に註釈文を続けて記述するだけです。文字列の最後のセミコロンを註釈の区切りと自動的に解釈して単語と註釈の登録が行なわれます。

　以下は註釈の入力例です。

入力内容	単語	註釈	解説
1. 蟹;うま	蟹	うま	セミコロンは通常入力でもTABでもよい
2. (^_^;;顔文字	(^_^;	顔文字	最後のセミコロンの後が註釈になる

　なお、註釈文側にセミコロンを含めたい場合に備えて、TABを押すことで通常の三倍(謎)の赤い特殊セパレータを1文字だけ入力できるようになっています。赤いセパレータが存在する時は、前後のセミコロンの状態に関らず必ずその部分で単語と註釈が分割されます。この説明ではわかりづらいかもしれませんが、赤いセミコロンを見たら「~~ヤツが来た~~ここで分割なんだな」と思えばOKです。

　また、註釈は後からいつでも再編集することができます。註釈を書き忘れたので書き直したい、またはSKK辞書にもとからある註釈を消したり変更したい、という場合に便利です。
　まず、註釈を書き換えたい単語を変換します。変換中、該当する単語が表示されている状態で；を押すと再編集状態になります。

入力例: KaniSPACE；

　註釈のセパレータの文字(セミコロン)は自動的に入力された状態となっているので、あとは続けて註釈文を入力してENTERを押せば編集完了です。なお、既に註釈がある場合は註釈部分をBSで消してENTERを押すと註釈を削除することもできます。
　なお、メイン辞書の註釈の上書きを行なった場合は、単語削除を行なうことでいつでも元の註釈内容に戻すことができます。

入力例: かに登録蟹;umaENTER

　編集後は自分が入力したアノテーションが変換時に表示されるようになり、使い込んでいくことでより分かりやすくなってゆきます。ぜひ活用してください。

接頭辞(プレフィクス)と接尾辞(サフィクス)の変換

　単語変換が基本となるSKKにおいて、同音異義語の高速入力は最重要課題の一つです。SKKではその解決策として、接頭辞・接尾辞の変換機能を塔載しています。ていうか今までこんな機能があるなんて知らなかっ…ぐはー(残響音)
　SKKは接頭辞・接尾辞の変換用の辞書データを持っています。「約～」や「総～」(接頭辞)や、「～的」や「～氏」(接尾辞)のような単語です。接頭辞・接尾辞変換はこの辞書データを明示的に指定する手法です。
　操作は非常に簡単です。以下の例を見てください。

入力例: Chou> AnkokuSPACE >kaSPACE → 超暗黒化

　上記の入力例は三種類の操作によって構成されています。これが勝利の鍵だ。

操作	動作	解説
1. Chou>	接頭辞の変換	変換の時にスペースではなく>を押すと接頭辞の検索が行なわれます。
2. AnkokuSPACE	通常変換	ここは普通の操作です。
3. >kaSPACE	接尾辞の入力開始と変換	変換候補の表示中に>を押すと暗黙の確定が行なわれ、接尾辞の入力開始となります。あとは通常の変換と同様、SPACEで変換することで接尾辞の検索が行なわれます。

　なお、カタカナ語との接尾辞の組み合わせなど、暗黙の変換のない場面ではSHIFT+Q>と操作することで接尾辞を単独で入力することも可能です。

　SKKを使い始めたうちは最小限の操作方法だけ覚えておけば十分なので、いきなりすべての機能を使いこなす必要はありません。
　操作に慣れ、技を極めたくなってきた時に、この機能を駆使して入力の高速化を狙ってみてください。

ローマ字かな変換ルールの拡張

　SKKFEPでは、一般的なローマ字かな変換ルールに以下の拡張を施してあります。このルールは定義ファイルによって自由に編集できるため、後から不要な機能を部分的に無効化することも可能です。

子音確定

　ローマ字ルールから外れた文字を入力した場合にMS-IMEと同じように全角英数でそのまま出力します。一部のMS-IMEを前提としたネットスラングを入力する時、モード変更を行なわず直感的に素早く入力することが可能となっています。ミリ秒単位での反応時間が問われるチャットや実況などの用途において威力を発揮します。外部から行単位で文字出力タイミングを観測された場合でもMS-IMEと違いがほとんどないため、誤字脱字のパターンを含めMS-IME使いであるかのように偽装できるという、地味かつ重要な意味を持っています。

入力例: wktk → ｗｋｔｋ

雑草入力

　wまたはkを連打することでｗやｋを大量かつ高速に入力できます。こうした文字は大抵の場合、チャットにおける語尾として使われます。そのため、チャットの確定であるENTERやCTRL+Jを押すことで(または関係ない文字を入力することで)通常のローマ字かな変換状態に戻るようになっています。
　雑草入力と送りがな変換時の挙動の共存させるため、2種類の変換ルールを動的に切り替えて処理しています。

入力例: uhawwwskkwwwww → うはｗｗｗｓｋｋｗｗｗｗｗ

小書きかな母音入力

　xを押した後の小文字母音はキー連打で連続入力可能です。擬音や感動詞の入力を容易にします。

入力例: uwaxaaaaa → うわぁぁぁぁぁ

記号入力 (現バージョンでは標準設定時は無効)

　小文字cの後に記号を入力することで、その文字を直接入力することが可能です。

入力例: c/c. → /.

数字入力

　0～9のキーを押した直後の，カンマ、．ピリオド、－マイナスは半角で入力されます。
　本来の全角を入力したい場合は、間にCTRL+Jを挟むことで動作をキャンセルできます。

入力例: 12,345.00a. → 12,345.00あ。

記号入力

　SKKIME1.5改同様、かつてSKKが参考にしたと思われるEgg(たまご)の記号入力ルールの一部を採用し、利用頻度の高い記号を二回の打鍵で簡単に入力できるよう拡張されています。z(またはf,j)の後にアルファベット以外の記号のキーを押すことで記号の入力が可能です。この操作はSKK10の完全な後方互換(上位互換)となっています。
　標準ではJIS配列キーボード向けの設定となっています。ASCII配列キーボードの場合は定義ファイルの編集やインストーラの設定GUIを使って設定を変更して使ってください。

最低限これだけ知っておけばとにかく捗る、他のSKK互換入力方式でも使える便利な操作

文字	zSPACE	z，	z．	z／
記号	全角空白	‥	…	・

文字	zH	zJ	zK	zL	zSHIFT+L
記号	←	↓	↑	→	⇒

日本語(JIS)配列キーボードでの記号入力の割り当て

SHIFT＋文字	z！	z”	z＃	z＄	z％	z＆	z’	z（	z）		z＝	z～	z｜
記号	●	▼	▲	■	◆	★	♪	（,【	）,】		≒	≠	〒

文字	z１	z２	z３	z４	z５	z６	z７	z８	z９	z０	z－	z＾	z￥
記号	○	▽	△	□	◇	☆	◎	〔,（	〕,）	∞	～	※	￥

SHIFT＋文字	z`	z｛	z｝	z＋	z＊	z＜	z＞	z？	z＿
記号	〆	【,〔	】,〕	±	×	≦	≧	÷	―

文字	z＠	z［	z］	z；	z：	z，	z．	z／
記号	〃	『	』	゛	゜	‥	…	・

(参考) 英語(ASCII)配列キーボードでの記号入力の割り当て

SHIFT＋文字	z！	z＠	z＃	z＄	z％	z＾	z＆	z＊	z（	z）	z＿	z＋	z～
記号	●	▼	▲	■	◆	★	♪	×	（,【	）,】	―	±	≠

文字	z１	z２	z３	z４	z５	z６	z７	z８	z９	z０	z－	z＝	z`
記号	○	▽	△	□	◇	☆	◎	∞	〔,（	〕,）	～	≒	※

SHIFT＋文字	z｛	z｝	z｜	z：	z”	z＜	z＞	z？
記号	【,〔	】,〕	〒	゜	〆	≦	≧	÷

文字	z［	z］	z＼	z；	z’	z，	z．	z／
記号	『	』	￥	゛	〃	‥	…	・

(参考) 記号入力を使わずに単体でキーを押下した場合の全角文字

文字	，	．	－	～	！	？	［	］	｛	｝
出力	、	。	ー	～	！	？	「	」	『	』

UNICODE拡張文字の入力

か行小書き文字

ローマ字	ひらがな	カタカナ
xka	ヵ	ヵ
xke	ヶ	ヶ
xca	ゕ	ヵ
xce	ゖ	ヶ

わ行濁音

ローマ字	ひらがな	カタカナ
xva	ヷ	ヷ
xvi	ヸ	ヸ
xvu	ゔ	ヴ
xve	ヹ	ヹ
xvo	ヺ	ヺ

アイヌ語仮名

ローマ字	ひらがな	カタカナ	発音(参考)
xku/xcu(xkk)	ㇰ	ㇰ	音節末k 台灣語破裂音k
xsi/xshi(xss)	ㇱ	ㇱ	音節末s
xsu	ㇲ	ㇲ	音節末s(稀)
xto(xtt)	ㇳ	ㇳ	音節末t
xnu(xnn)	ㇴ	ㇴ	音節末n
xha/xfa	ㇵ	ㇵ	音節末h/f
xhi/xfi	ㇶ	ㇶ	音節末h/f
xhu/xfu	ㇷ	ㇷ	音節末h/f
xhe/xfe	ㇸ	ㇸ	音節末h/f
xho/xfo	ㇹ	ㇹ	音節末h/f
xmu(xmm)	ㇺ	ㇺ	音節末m
xra	ㇻ	ㇻ	音節末r
xri	ㇼ	ㇼ	音節末r
xru	ㇽ	ㇽ	音節末r
xre	ㇾ	ㇾ	音節末r
xro	ㇿ	ㇿ	音節末r
xpu(xpp)	ㇷ゚	ㇷ゚	音節末p 台灣語破裂音p

xnse(xche/xtse)	セ゚	セ゚	鼻濁音ce「チェ」(稀) 江戸方言「ツェ」
xntu/xntsu	ツ゚	ツ゚	鼻濁音tu「トゥ」(稀)
xnto(xtwu)	ト゚	ト゚	鼻濁音tu「トゥ」

括弧内は検討中

か行鼻濁音

ローマ字	ひらがな	カタカナ
xnga	か゚	カ゚
xngi	き゚	キ゚
xngu	く゚	ク゚
xnge	け゚	ケ゚
xngo	こ゚	コ゚

送りがなの順次打鍵操作 (ルール設定で変更可能)

　シフトキーの代替操作として、DDSKKでのskk-sticky-keyに相当する操作が行なえます。標準では送りがなの指定操作を；キーで行なうことができます。標準では変換開始の操作はSKKとの互換性と持たせるためQに割り当てられています。これは設定変更によって；キーや変換無変換などのキーに割り当て直すことも可能です。次章の設定方法を参照してください。
　これにより、従来のSKKで多用されていた「シフトキーを押しながらキーを押す」という操作を「;を押した後、キーを打鍵する」という操作で代用できます。この操作はSKK10にはなかった操作ですが、従来の操作を阻害せずに両立させることが可能となっています。

入力例

	入力内容	変換結果
標準操作	ATatteKudaKero!	当たって砕けろ！
送りがな側のみ操作	A;tatteKuda;kero!	当たって砕けろ！
全て順次打鍵で操作	Qa;tatteQkuda;kero!	当たって砕けろ！

次章の設定変更後
全て順次打鍵で操作	変換a変換tatte変換kuda変換kero!	当たって砕けろ！

設定

　SKKFEPは基本的には設定不要でレジストリ類を一切設定せず、インストール直後の状態でもすぐに使えるようになっていますが、設定GUIを使うことでレジストリに設定を書き込んで簡単に挙動を変更することができます。

各種設定方法

　インストーラで設定ボタンを押すと設定変更メニュー画面が出るので、適当に有効・無効をチェックしてOKボタンを押してください。

設定を反映させるには、アプリケーションの再起動が必要です。

裏技

　ちなみに、インストール方法に沿って設定した場合、IMEの動的切り替えショートカットキー操作を行って、いったん他のIMEに切り替えてからSKKFEPに戻すことで、IMEのプログラム部分だけをリロードすることが可能です。この操作を活用することで、アプリを起動したまま設定を読み込み直すこともできます。

　設定に関しては以下にまとめてあるのでそちらを参照してください。
　なお、β版の場合、設定変更内容が、アップデート時にうまく引継がれない場合があります。その場合はアップデート後に設定ボタンを押してOKを空押しして再度設定反映を行なってください。

設定方法

　標準設定とGUI設定だけでも十分実用になるはずですが、SKKFEPは設定ファイルを差し替えることで、大幅に動作を変えることができます。カスタマイズの例として、各種ローマ字かな変換に対応した定義ファイルを用意してあるので参考にしてください。
　以下の定義ファイル内に手動更新スクリプトへのリンクがあります。スクリプトを実行すると設定ファイルを差し替えた特別版の書庫を作成することができます。

汎用ローマ字かな変換設定

AZIK設定

ACT/JLOD設定

TUT-Code / T-Code / G-Code

注意

　以下の説明は過去のものです。設定GUIがなかった頃の古い情報なのでご注意ください。
　現在の版では、設定GUIを実行してもskkrule.txtの内容は変化しません。
　設定GUIで指定した内容はユーザ辞書フォルダ内のskkrule.iniに保存されます。
　このiniファイルとskkrule.txtの内容が合成され、設定がレジストリに書き込まれるようになっています。
　skkruleコマンドは、アプリ別の個別設定が必要な場合や、開発・デバッグといった特殊用途に使います。

　コマンドプロンプト経由でskkruleコマンドを実行することで、設定GUIを通さず直に設定ファイルの内容をシステムに与えることができるようになっています。
　インストーラsetup.jsを起動して「コマンド」のボタンを押すことで、skkruleコマンドを実行できるコマンドプロンプトが開きます。(この時、後述するアプリケーション別の設定が行なわれている場合は、該当するアプリ名の一覧がコマンドプロンプト内に表示されます)

　その後、コマンドプロンプトで

例	skkrule r または		# 設定ファイルskkrule.txtを読み込んでレジストリに保存
	skkrule skkrule.txt

　と実行することで、設定ファイルの内容がシステムに保存されます。
　(キー操作を反映させるには、対象アプリケーションを一度終了して実行しなおすか、システムを再起動する必要があります。動的な反映はまだ行なわれないのでご注意ください。)

例	skkrule rd			# レジストリ設定の解除

　上記を実行することで設定が消去され元の設定に戻ります。

表示形式の設定

　変換マークの表示を変更できます。

例	skkrule pd

　FORTHインタプリタの命令コードをクリアする。

表示領域の設定

　候補一覧や変換中のアノテーションの表示領域の設定を変更できます。

例	skkrule w 最大幅 [影 [透明度 [反発力]]]

最大幅: ウィンドウの最大幅を1～65535の数値で指定します。0の場合は制限なしです。初期値は0です。

影: ウィンドウの影の有無を0～1の数値で指定します。0の場合は表示なしです。初期値は0です。

透明度: 表示領域の透明度を0～255の数値で指定します。値が小さいほど透明になります。標準値は224です。

反発力: 画面端でのばねの反発力を0～128の数値で指定します。値が小さいほど反発力が小さくなります。128にすると常にディスプレイ内に収まるように動作します。初期値は96です。

例	skkrule f

表示領域で使用するフォントを選択します。

例	skkrule wd

　上記を実行することで設定が消去され、元の動作に戻ります。

起動時の変換モード (mオプション)

　標準では半角英数モードになっています。以下から起動時のモードを選択可能です。

m0: ひらがな m1: カタカナ m2: 半角カナ

m3: 全角英数 m4: 半角英数 m5: IMEオフ

md: 半角英数 (標準設定)

例	skkrule m5			# 全てのアプリで起動時にIMEをオフ (お勧めしません)

　コマンドプロンプトで上記を実行すると、他のIMEと同様に起動時オフにすることができます。が、全てのアプリに対して設定が効いてしまうため、かなり使いづらくなりお勧めできません。この設定で使うくらいなら他のSKKクローンに切り替えて使うほうがよっぽどましです。後述するアプリケーション別の設定で個別に設定するのをお勧めします。

例	skkrule md			# 初期設定に戻す (半角英数モードで起動)

　上記を実行することで設定が消去され、元の動作に戻ります。

シフトキー拡張操作 (sオプション)

　標準では日本語入力中のみSandSが有効となっています。以下からSandSの作動範囲を選択可能です。

s0: SandS無効 s7: 日本語入力中のみSandS有効

s31: IMEオン時のみSandS有効 s63: IMEオフ時もSandS有効

sd: 日本語入力中のみ有効 (標準設定)

例	skkrule s31		# 全てのアプリでIMEオン時にSandSを有効化

　コマンドプロンプトで上記を実行することで、SandSの動作を常に有効化できます。

アプリケーション別の設定

　アプリ名を指定して設定を行うことで、アプリケーションごとに別々の設定を行うことができます。
　skkruleで定義ファイルを読み込む際にも、アプリ名を同時に指定することで、指定したアプリだけに設定を適用することができます。

　例えば、emacs.exeのみ起動時にIMEオフ/SandS無効にしたい場合は以下のように設定します。

	skkrule emacs.exe m5 s0	# emacs.exeのみ起動時にIMEオフ/SandS無効 (Emacs側のSKKを使う場合にお勧め)

　個別設定を削除するには以下のように実行します。

	skkrule emacs.exe md	# emacs.exeの個別設定を解除

辞書

辞書について

　本ソフトウェアで利用可能な辞書ファイルは、原作のSKK辞書と同じテキスト形式となっています。
　従来、SKK辞書にはソートの有無という概念がありましたが、もうそんな時代じゃないのでソートの有無に関係なくどんな辞書でも利用できます。送りあり・送りなしエントリの区別も不要です。前時代的な区切りコメントをつける必要もありません。
　辞書の漢字コードはシフトJIS/EUC/UTF-8N/UTF-8/UTF-16LE/SCSU/BOCU-1が利用可能です。SJIS/EUC/UTF-8Nは内容による自動判別、他はBOMによる自動判別が行なわれます。改行コードは1文字/2文字どちらでも認識します。

　そんなこんなで辞書の読み込みに関してはかなりフリーダムなので、辞書は元データをダウンロードしたファイルのまま利用できます。EmacsのSKK10原作や、DDSKK等の各種SKKクローンで利用中のL辞書やユーザ辞書をそのまま流用することもできます。

　さらになんと！MS-IMEやATOK等で使用されている汎用テキスト形式での辞書データもそのまま認識します。「う゛」の表記の揺らぎも自動で吸収します。辞書フォルダ内に、SKK/MS-IME/ATOK向けの異なる方式の辞書ファイルが混在した状態であっても何の問題もなく利用可能です。

　とどめに、Unicode標準圧縮形式であるSCSUとBOCU-1も使えるようになっちゃったぜ！
　拙作のUnicode圧縮・ファイル変換ツール ucを使うと、辞書データを圧縮した状態で使うことができます。例えばskk-dict.txtを圧縮してskk-dict.txt.SCSUとしておくだけでインストーラから認識されます。圧縮の手間が増えてめんどくさいだけだけど、これぞ試作って奴さぁ！

辞書ファイルの場所

　辞書の置き場所は以下の通りです。

SKK辞書(共通辞書)

	C:\Windows\IME\SKK0\DICTS\*

　セットアップで「辞書フォルダ」を押すと、エクスプローラでこのフォルダが開きます。
　ここはシステムフォルダ(OSに保護されている場所)となっているので、内容を書き換えるには管理者権限が必要です。
　例えば、エクスプローラでこのフォルダに辞書ファイルをコピーする場合、管理者として変更を許可するかどうかのダイアログが毎回開きます。また、コマンドプロンプトで作業する場合は、コマンドプロンプトのショートカットを右クリックして「管理者として実行」を選んで起動する必要があります。

ユーザ辞書(学習情報)

	(環境変数APPDATAの示す場所)\SKKFEP\skkuser.txt
	Windows 7の場合は C:\Users\ユーザ名\AppData\Roaming 以下に配置されます。

　セットアップで「ユーザ辞書」を押すと、エクスプローラでこのフォルダが開きます。

辞書の扱い

　SKK辞書は、インストール時にインターネットから最新版のL辞書(SKK Openlab♺)をダウンロードします。
　また、セットアップを起動して「辞書の更新」ボタンを押すことで、いつでも最新のL辞書にアップデートすることができます。

「急に辞書のインストールに失敗した？」「急や」

　もし、インストール時にインターネットに接続できず辞書がインストールできなかった場合は……

1. インターネット接続できる環境に復旧した場合

　セットアップを起動して「リフレッシュ」または「アップデート」ボタンを押すと自動的にインターネットから読み直します。

2. インターネット接続できない環境だった場合

　セットアップを起動して「辞書フォルダ」ボタンを押し、そのフォルダ内に辞書ファイルを手動でコピーしてください。

　辞書のファイル名はSKK-JISYO.L* または skk-dict.txt* としておくと、次回のアップデート時にインストーラから認識されるようになります。

　裏技として、初回インストールでネットワークに接続せずにプログラムと辞書を導入する方法があります。インストーラの書庫を解凍し、解凍したフォルダ内にskk-dict.txtの名前にリネームしたL辞書やM辞書のファイルを置いた上ででセットアップを起動すると、ネットワークには一切接続せずに辞書ファイルがインストールされます。

　辞書は複数同時に利用することができます。インストーラでは便宜上L辞書のみインストールしますが、手動で前述の辞書フォルダを開き、適当に辞書ファイルを放り込んでおくだけでPC起動時にすべての辞書を認識します。

　複数の辞書を扱う場合は、いくつか注意点があります。

辞書を読み込む順序はファイルシステムの並び順――現在のWindowsではNTFSが使われているので、要するにファイル名順――に読み込まれます。名前のつけかたが下手だと凄いことになるので、知恵と勇気と浪漫でうまく切り抜けてください。
辞書はすべてメインメモリ上に読み込まれます。辞書ファイル読み込み後は検索処理におけるディスクアクセスは一切発生しません。この特性のため辞書ファイルをシステムフォルダに放り込んだり削除しただけではすぐに反映されるわけではありません。セットアップからメンテ/リフレッシュ操作を行なうか、PC再起動、ログオン/ログオフを行なうことで再読み込みされます。

ユーザ辞書の更新タイミング

　ユーザ辞書は学習動作(単語の確定・登録・削除)を行なうことで内容が更新されます。
　学習した内容はいったんメモリ上に保持された後、最初の更新から3分が経過すると自動的にファイルに保存されます。
　すなわち、連続して日本語入力を続けている場合は3分おきに辞書が保存されます。
　なお、単語の変換を行なっただけでは学習したことにはなりません。確定せずにCTRL+Gで中止した場合や、CTRL+Qで偽装確定を行なった場合は学習が発生しないので辞書更新とは見なされません。

　現在の学習内容を確実にファイルに書き出しておきたい場合は、ラ○ュタ王のように3分間待つか、セットアップで「メンテ」ボタンを押すか、辞書プロセスC:\Windows\IME\SKK0\skks.exeを手動で実行してください。エクスプローラでダブルクリックすればOKです。実行すると常駐している辞書プロセスに対して辞書保存要求が送られ、辞書が更新されていた場合はユーザ辞書ファイルに反映されます。
　OSをサスペンド・ログオフ・終了した場合も内容が保存されます。

ユーザ辞書の編集

　ユーザ辞書はUTF-16LEで保存されるため、メモ帳などのテキストエディタで直接編集することができます。
　編集したものを再度読み込ませるには、以下の手順を踏みます。

1. セットアップを起動して「メンテ」ボタンを押す (またはタスクマネージャからskks.exeを停止させる)

2. メモ帳などでskkuser.txtの内容を編集 (メンテ中は漢字変換が使えないので注意)

3. セットアップを起動して再度「メンテ」ボタンを押す (またはskks.exeを手動で実行する)

　(他にも、セットアップで「リフレッシュ」ボタンを押したり、ログオフや再起動など行ってもよい)

他のSKKユーザ辞書の流用

　SKKやSKKIMEで使っていたユーザ辞書をインポートして使い続けることが可能です。ていうかインポートという概念すらなくて、単に置いてあるファイルをそのまま読み込んで書き換えるだけの豪快仕様。自分、不器用ですから。
　ちなみに初回インストール(ユーザ辞書が存在しない状態)の時、skkime/SKKIME1.5改を使用していた場合はユーザ辞書を自動的に引き継ぎます。
　インポート後も語句の順序はそのまま保存されます。インポート後、SKKFEPによって更新された辞書はUTF-16で保存されます。まともなSKK処理系であれば、そのままSKK辞書ファイルとして再利用することもたぶん可能です。タブンネ。

　ほかにも、初回インストールを行う前にあらかじめユーザ辞書フォルダにskkuser.txtの名前で辞書を置いておけば認識します。
　あとからユーザ辞書を差し替えたい場合、セットアップで「メンテ」を押し、ユーザ辞書フォルダのファイルを差し替えればOKです。

文字コードの変換

　辞書の文字コードを変換したい時は、以下のツールを活用すべし！

文字コード圧縮・変換ツール uc SKKFEPと同じ文字コード判定処理を持つ、過去のアプリケーションとの互換性維持に特化した文字コード圧縮・変換ツール

文字コード変換ツール cveuc♺ CorvusSKKの作者さまが作成した、EUCに特化した文字コード変換ツール

オンライン辞書との接続について

　拡張スクリプトを導入することで、Google CGI API for Japanese InputやSocial IMEかな漢字変換APIと接続できます。
　詳細はインストール手順の応用編を参照してください。

SKKサーバとの接続について

　SKKNetコマンドを使うことで、SKK辞書サーバの構築・接続が可能です。
　詳細はSKKNetの解説を参照してください。

送りがな補正辞書について

　送りがなの自動補正機能、ニューSKKプラス＋(仮称)の辞書データに対応しています。
　詳細はSKKプラスの解説を参照してください。

ある程度辞書が育ったら…

　原作のSKKには、(skk-henkan-okuri-strictly t)という設定があります。これはある程度送りがな学習結果を溜め込んだユーザ辞書の存在を前提とした、「日本語的に正しくない送りがなを除外する」ことを目的とした変換精度向上のための機能です。
　なお、本機能はSKK10の標準設定に合わせて標準ではオフとなっており、有効にするためには設定変更が必要です。

補足

　その他の情報など

Windows XPをお使いの方へ

　SKKFEPは一応Windows XPでも動作しますが、Windows XPでのTSFはいろいろと不可解で不安定な動作が多く、正直なところ導入はお勧めできません。
　Windows XP環境では、素直にIMEとして実装されているSKKIME 1.5改のWindows XP版を使うことをお勧めします。
　それでも、どうしてもWindows XPで使ってみたいという場合は、以下の注意点を読んで導入してみてください。

インストール時の注意点

　Windows XPの場合、標準設定のままではSKKFEPは動作しません。システムの設定変更が必要です。

　インストール操作の前後どの時点でもよいので、コントロールパネルの「地域と言語のオプション」の「言語」タブの「詳細(D)」ボタンを押し「テキストサービスと入力言語」のダイアログを開きます。
　ダイアログの「詳細設定」タブを開き、「詳細なテキストサービスをオフにする(T)」のチェックが外れていることを確認し、「詳細なテキストサービスのサポートをプログラムのすべてに拡張する(E)」を有効にしてください。この設定を行なうことで、ctfmon.exeというシステムプロセスが動作し、Windows XPでもTSFによる日本語入力処理が利用可能となります。
　設定変更後、不要になった場合は同様の操作でいつでも設定を戻せます。

　もしもこの設定を行なわない場合、インストールを行なっても「テキストサービスと入力言語」の「インストールされているサービス(I)」の一覧に表示されるだけで、IMEとしては選択できない状態となります。万が一こうなってしまった場合でも、上記の設定を後から行なえば正常になりますし、そのままアンインストールしてしまっても問題ありませんので落ち着いて対処してください。

　設定後は、再び「テキストサービスと入力言語」の設定を開き、「設定」タブにある「既定の言語(L)」で「日本語 - SKKFEP」を選択し、OSを再起動することで、標準の日本語入力として動くようになります。

　なお、この設定はWindows XPではあまり一般的ではなく、経験上高い確率でアプリケーションが正常に動作しなくなったり、システムが不安定になったりする可能性があります。利用は自己責任でお願いします。

利用時における問題点

　XPでのTSFの利用は多くが謎に包まれており、ひとまず以下は仕様となってしまっています。他にもいろいろと問題が出ているような気もするのですが超法規的措置。情報求む！

Windows XPではコマンドプロンプトなどの一部のアプリケーション上ではSKKFEPを利用できません。
Windows XPにおいて、言語バーにSKKFEPの状態が正常に反映されない。(起動後に一度言語バーを最小化←→復元の切り替え操作を行なうと直ることもある)
Windows XPにおいて、既存のIME制御ツールで制御した瞬間にアルファベットしか入力できなくなる。(一度ウィンドウのフォーカスを別のものに切りかえてから戻すと直ることもある)
Windows XPにおいて、漢字変換候補の表示が異様に遅いことがある。

　…ま、慣れちゃえばわりとなんとかなる話なんですけどね。こちらの持っている不利な情報はすべて提示しました。あとは任せた。

ご意見・ご要望

　SKKのこんな機能があったら便利、ここに違和感を感じる、という利用者の意見はとても貴重です。どんな些細なご意見でも構いませんのでお知らせください。次回作の参考などにしたいと思います。

　SKKで入力する時の癖や、使いにくい挙動を少しでも緩和するアイディアなどありましたらお気軽にご連絡ください。また、JIS配列ではないキーボードや、原作SKKの標準動作(skk-egg-like-newlineなしとか)で使っている方、SKK原作の使用感について詳しく話を聞かせてください。びっくりするほど誰も乗ってこなかったぞ俺。自分で使ってみるぞ俺。なんか自分好みの操作感だぞ俺。

　つか意見も要望もあんま来ないし好き勝手にやってるだけなんで「この機能が欲しい」とか「それ以上いけない」といった意見があればお気軽にどうぞ。お気軽でない要望なんかも、もうそれこそ大歓迎です。こちらの魂が震えるような熱い要望や本音の不満をぜひともぶちまけてください。亀の歩みではありますが、数直線の遥か彼方を走るMSGoog…ウサギに追いついて虚数軸から友情パワーで必殺技を一緒にたたき込んでみませんか。夢オチで。

更新

更新履歴

　チラシの裏へようこそ(日記はここで終わっている)

開発前夜

2011.09.19

α版公開

2012.01.11

β0版公開

2012.01.20

日本語入力 (問題あり)

ローマ字かな変換ルールskkrule.txtの表記を改良
変換ルールの見直し(SKK10との互換性向上)
変換発動キー変更機能を追加
候補選択キー変更機能を追加
子音置換機能を追加(AZIKなどの表音と異なるキー操作に対応)
標準定義のテーブルサイズを追加情報込みで66バイト削減
処理アルゴリズムの見直しとコード最適化により、上記機能を追加しつつ32ビット版/64ビット版ともに実行ファイルのサイズを0.5KB削減
キー入力関連処理を改良。MSWordにて数字入力回りが正常に動作しないバグを修正
コンポジションが空の時にNo-Break Spaceを反転表示して視認性を向上

設定補助 (影響度大)

母音以外の音素指定を追加
登録できるルールの量を4倍(8KB)に増加
エラーチェックを強化
AZIK定義ファイルskkrule_azik.txtを追加

辞書管理 (安定度向上)

シャットダウン時に辞書の保存が行なわれないバグを修正

2012.01.23

日本語入力

編集開始時に例外的に子音確定の対象を外側に追い出すように改良

　子音確定における暗黙の確定のような感覚で使える。要するに「おｋ把握」とかの入力途中で確定キーを押す必要がなくなった。

シフトキー拡張時、スペースキーとシフトを組みあわせた入力時の反応性を向上。SandSを使わない人でも常時SandS有効のままでも違和感を少なくするよう改良。SPACE押下SHIFT押下SPACE離上文字押下SHIFT離上のようなタイミングが微妙に遅れた時などにスペースキーの入力を認識する。
キー入力関連処理のエンバグでウィンドウフォーカスが切り替わった後の確定などのキー入力に失敗する問題を修正。
サイズが増えてしまった…

辞書管理

他のプロセス探索ツール類からウィンドウハンドルを未使用として認識されるよう改良

2012.01.24

全般

アプリケーション名称を「日本語入力システムSKKFEP」から「SKK日本語入力FEP」に変更

日本語入力 (安定度向上)

レジストリ設定がないと表示スクリプトが破損するバグ(2012.01.20版のエンバグ)を修正
20120123版で増えたプログラムサイズを0.5KB縮小

2012.01.28

日本語入力 (安定度向上)

キー押下イベントだけしか通知されない一部の~~どう考えてもバグってるとしか言いようのない~~ウィンドウ内ではセーフモード(一時的なSandS無効状態)で動作するよう改良。
ちなみに怪奇現象はMSWordの検索窓で発生。MSWordの妙ちくりんな動作も大概にｼｰﾃｸｰﾀﾞｻｰｲ。怒髪が有頂天を通り越してへそで茶を沸かしﾏｰｽ。MSWordの特殊攻撃回避処理がどんどん増えるﾃﾞｰｽ。
なお、WINWORD.EXEでSandSを無効化に設定することでも回避できるようにもなっていますが、無効化したら負けだと思っている。
ちなみにMSWordバグ(…あれ？)を検出できるのは、同じキーを2回押すか、スペース押下後(または押しながら)別のキーを押した瞬間となっています。最初のスペースキー押下時には判定ができず何も反応しないのですが、これは仕様です。大抵、SPACE+文字を入力した瞬間に判定されるので、1回目の変換まではセーフモードになったことすら気づかずに使えるはず。2回目以降？諦メロン
CAPSロックが常時ONでも使いやすいように改良。やっぱりMHz台のプロセッサのニーモニックは大文字に限る。
タイマーではなく状態遷移だけで確実にMSWordバグを検出できるよう改良
変換キーでもシフト代替操作可能とした。SandS無効の時にも機能するのがポイント
半角英数モード時はキーボードモードオフ扱いにする実験開始
abbrevモードの操作を/キーに変更して使っている利用レポートが多いため、デフォルト設定をSKK互換に変更
将来数値変換が利用可能になった時、操作が衝突する可能性があるためデフォルトの再編集操作を；に変更
>キーによる接頭辞・接尾辞の操作を追加「Chou>AnkokuSPACE>kaSPACE」で「超暗黒化」
接頭辞・接尾辞変換コマンド追加により、設定コマンド番号に互換性がなくなりました。過去の版で設定したレジストリ上のルール定義はバージョンチェックで弾かれて無効化されます。定義ファイルの再設定が必要です。前述の通りabbrevモードのデフォルト設定が変更となったので、デフォルト設定のままで問題なければそのまま放置でも問題なし。

2012.01.29

日本語入力

CorvusSKKの顔文字対応が羨ましかったので、顔文字が使えるように改良。注釈のセパレータとして最初のセミコロンが選択されてしまっていたのが問題だったので最後のセミコロンを認識するよう変更
登録操作時にTABキーで1文字だけ入力できる通常の三倍(謎)の赤いセパレータを追加
再編集時の操作性を向上。再編集開始時に行末にセパレータを自動的に追加し、登録時に行末にセパレータがあれば自動的に削除する
変換動作をSKKに近づけ、カタカナで入力した場合も変換するよう改良。「ハレ晴レ」のような入力も可能となった。これでようやくSKKとして一般的な単語が扱えるようになり、辞書サーバと接続する下地が整った

辞書管理

SKKIMEが生成したユーザ辞書など、同一行に同じ単語(異なる注釈)があった場合の補正処理を追加
異常なフォーマットの辞書を読み込むとまれにプロセスが異常終了する問題を修正
複数セミコロンを持つ単語を含む行の辞書フォーマットを極力SKKに合わせた。従来は単語全体をまとめて処理していたが、これはSKKのフォーマットと異なるため注釈の前後を別々にエンコードするよう改良

2012.01.31

日本語入力 (機能追加)

Corvus Solis氏の調査により、ホットキーALT+VK_OEM_3の動作の詳細や歴史的経緯が判明。不要と思ってSKKIME1.5改の時から削除していたが、海外版OSなどの日本語以外のキーボードドライバと併用した時に必要となるため、機能を復活。過去の互換性のためには必要だったのだ…！この条件に該当するユーザは一人もいないかもしれないけど、Windows環境でのSKK普及のためにはCorvus SKKと同じ条件にしておくことが(コードサイズより)重要だと考え採用。
アプリケーションからのIME制御に対応(実験中)。ホットキー動作とは異なり完全にIMEがオフにならないように動作する。標準設定では半角英数←→ひらがなの切り替えで偽装(レジストリ設定で起動時にIME無効に設定しているプロセスのみ、従来のIMEと同等の制御が行なわれる)。ぎまんに満ちた世界で闘う、全ての『サイバー・パンカー』に捧げる

2012.02.01

日本語入力 (問題あり)

Corvus Solis氏の要望を受け、CorvusSKKの目玉機能の一つ、ふりがな情報の出力機能を追加。ただし書き換えるのは変換処理を施した文字列のみを対象としています(例え英語入力モードであった場合でも)。CorvusSKKと異なる結果になって困るという場合は連絡を
実行ファイルのサイズ維持が困難になってきたのでコンポジションの書き換え処理を簡素化…というか今まで無駄にAPIを呼んでいたような気がする。記憶にございません。とはいえものすごい基礎部分の変更をやっちまった気もするので、もしかすると影響の出るアプリがあるかもしれない。そして調子に乗って他もいろいろ簡略化しちゃったてへぺろ❤行くぜ禁断の領域！「それ以上いけない」

2012.02.03

日本語入力 (安定度向上)

やばい。やっぱり処理を削りすぎてた。むしゃむしゃしてやった。今は反芻している。見た目は子供、頭脳も子供。刑事さん…私はやりましたよ。サイズ削減のためなら何度だってやるでしょう。後悔はしていない。
というわけでMSWordやLive Messengerでコンポジションの文字出力が1文字だけの場合に文字がシフトされずまともに文字入力できないエンバグを起こしていたのに気付いて慌てて修正の巻。要するにこの三日間まともに動作してなかったことになる。どうせ誰も使ってないんだろうな…否！MSWordとかと組み合わせて使ってないだけさ！ううん、知らないけど絶対そう

2012.02.04

日本語入力 (安定度向上)

単語編集中に未確定の子音を残してキャンセルを行なうと文字が残るバグを修正。
64ビット版のWindows XP/Server2003専用の初期化処理を廃止し他OSと処理を共通化。
COMのIDチェックを厳密に行なうように改良。

2012.02.05

日本語入力 (機能追加)

英単語入力時(SKKのabbrevモードに相当)の文字表示属性が通常時と同じ色で表示されるバグを修正。要するに表示属性の一つが未使用のままずっと放置されてた。孤独。この機能まったく使わないから気づかなかった。
候補一覧の黒の文字色を黒固定からシステムカラーに変更。該当するカラーは、コントロールパネル→デスクトップのカスタマイズ→個人設定→ウィンドウの色とデザイン→デザインの詳細設定の「指定する部分(I)」の「ヒント」のフォント色となる。ながい…
β0最終版になるといいな

2012.02.06

日本語入力 (機能追加)

現実は非情である。β0最終第二版(ぉ
全ての拡張シフトキーで一定時間押下時にキーリピートを有効化。
表示スクリプトのレジストリ読み込みにもバージョンチェックを追加。rule p系は再設定が必要。

2012.02.08

日本語入力 (安定度向上)

はいはい無常無常。β0最終第三(ry
単語登録時にlを押すと状態がクリアされてしまい半角英数が単語登録できない問題を修正。SKKFEPの特殊動作であるキーボードモードの自動制御関連で懸念された問題をすべて捻じ伏せた。他の入力プロセッサじゃ満足できない機械の体になるためにはこの処理をどうしても乗り越えなければならなかった。長い戦いだった。正直この機能が実現したくて開発していたので僕、満足！
中身が空の辞書データを変換・確定・登録した際、文字入力不可能になるバグを修正。
レジストリの内部バージョンを設定項目別に管理するよう改良。
表示スクリプトの内部バージョンを変更。rule p系は再設定が必要。
単語登録中に註釈部分を別の色で表示し視認性を向上。表示にはこだわってみた。けっこう気に入ってる。
単語登録開始時に入力モードを保存しSKKに操作感覚を近づけた。

2012.02.12

日本語入力 (機能追加)

β0最終第四ｱｯ――！
『うわっ…私の能力、低すぎ…？』いきなりGUI設定ツールの作成に挫折。たかしくんがn回目の挫折を経験した後に無限ループから抜けるまであと何回の試行が必要か求めよ。まだだ、まだ終わ○んよ！で、副産物の設定処理を追加。
改行・コントロールキーのアプリケーションへの通知(skk-egg-like-newlineのないSKKの初期設定に近い動き)を実装。ピーキーすぎて俺によし。でもちょっと癖が強いのでデフォルトではオフにしておく。
BSの挙動を変更可能とし、ローマ字かな変換ルール設定側からのカスタマイズの幅を広げた。
SKKの使い手の生命線であるCTRL+Jの挙動を変更可能とし、操作に不要なキーをアプリケーションに通知するモードも選べるようにした。現在のSKKFEPではCTRL+Jが数値入力や雑草入力の解除操作を兼ねており相性が悪いという理由により残念ながら非推奨設定となる(他にも、SKKの操作感から逸脱してしまい原作の修得が困難となるという危惧もある)。それでもなお、著名なSKKクローンの操作性との互換性は確保しておくべきと判断。移行・併用時の操作感緩和用としてきっと役立つ場面があるはず。
表示スクリプトを10バイト短縮。関連処理64バイト短縮。FORTHェ…
その他細かな修正(単体変換0回でも一覧表示へ移行とか、再編集と削除の開始条件を揃えるとか、キーリピートタイミング指定をミリ秒単位で指定可能にしたとか仮想マーカーの文字コードを16ビット幅で指定できるようにしたとか)。大幅に書き直してるからもう何が同じで何が違うのかよーわからんちん
2012.01.23の子音確定の押し出し処理におけるエンバグを修正。通常確定の時に子音が残った状態でENTERなどで確定した時、子音アルファベットが押し出されてしまう現象が一部のパターンで発生していた。
そして公開直前にFlash Playerプラグインの文字入力欄(要するにニコ動)でコンポジションの書き込みに失敗するバグが発覚し一日延期。旧方式は没としskkimeと同等の処理で確定とキー出力を行なうように修正。これで安定度はskkimeに追いついたはず。
やばい。z［ z］のルールをずっと勘違いしていたことに気付いた。でももう今さら直すわけにもいか…ふんぬ！SKKに合わせて直した。あと、z7のルールがEggと異なっていた(これまた勘違いしていた…あれを使っていたのは相当に昔の話で記憶が曖昧なんで勘弁してたもれ…)のでこれも正しいものに修正。他にも、z｛ z｝は全角ダブルクォートから縦書き用ノノカギに変更。これでいいんだ！自分が信じた道を行く！SKK最強！うぉぉぉぉ
こんだけ詰め込んだけどまだ初期の頃からプログラムサイズは変わってないんよ…サイズ維持するために何度も上位下位階層ごっそり書き直しとかやってるんよ…無駄なこだわりだし強いられてないけどがんばってるんよ…「あのたたかいはむだだせかいはラブアンドピースあんぜんなところにいたガキがおれにそううた(放送禁止)」

全般

誤字修正。ｳﾞｧｲ!

2012.02.13

日本語入力 (機能追加)

β0最終ファンタジー5
2012.02.12版でのエンバグを修正。skk-egg-like-newlineにしていても単語登録中にENTERで確定した時ENTERによる登録が行なわれてしまうバグが混入していた。
z‘の初期割り当てを全角ハイフンから全角ダブルクォート左に変更。全角英数モードと組み合わせることで、シングルクォートの左右、ダブルクォートの左右が入力可能となる。
skk-sticky-key相当の機能を追加。シフトキー操作なしだとかなり操作感覚が異なるというか、本来のSKKとは完全に別物だこれー。かなり癖があるな…DDSKKの機能だし仕方ないか。だがしかし！文字種が6ビット程度に制限された極限状態(スマホとか、MCUのシリアル経由とか)で日本語入力しなければならないような絶体絶命のピンチの局面で「こんなこともあろうかと」とか言いながら有効化すると超気持ちイイかもしれない。そして将来JISかな入力を導入した時にこの状態遷移がきっと役立つはず。

その後発見・修正されたバグなど

日本語入力

オートコンプリート時に内部状態の初期化が不十分で余分にキー操作を要する可能性があるバグを修正。

設定補助

規模の大きな設定ファイルを読み込んだ時に音素と文字の対応がおかしくなるバグを修正。

以上をもって「単独動作可能な世界最小のバイナリサイズSKKクローン」のβ0の開発を完了。

skkimeに反逆せよ

行くぜ虚数空間へ！

β0+i版公開

2012.02.18

β0+i版公開

外部表示領域(候補一覧やアノテーション、単語登録などの表示領域)を実装。
初期設定では文字はコントロールパネル→デスクトップのカスタマイズ→個人設定→ウィンドウの色とデザイン→デザインの詳細設定の「指定する部分(I)」の「メッセージボックス」のフォントのサイズ14を使用。フォントを変更したい場合は「rule f」でフォント選択。

2012.02.23

日本語入力 (機能追加)

擬似石火こと雪花入力方式に仮対応。見た目はSKKっぽいけど中身は液体金属。自分は人間だと思い込み何も知らず平穏に暮らしていたSKKFEPに訪れる転機。
接頭辞変換直後のキャンセルで記号が残らないよう仕様変更。この挙動はSKK10とは異なるが、こちらのほうが自然であるという信念からあえて互換性を外す。外すったら外す。
子音確定の挙動をMS-IME側に近づけた。これによりSKKではモード切り替えが不可避だったふたば系ネットスラング「うｎ」の出力が可能となる。MS-IME同様、直後に疑問符など別の文字を続ける場合はこまめな確定操作が必要。これもSKK10と異なる挙動だが試験的に導入。

2012.02.24

日本語入力 (機能追加)

未確定の子音を残したまま変換を行なった場合は子音の評価を遅延するよう改良。SandS操作字にスペースを早目に操作した場合に発生しやすい操作の前後逆転時に対応。
送りあり変換途中でローマ字かな変換が完了していない状態で変換しようとした場合(いわゆるSKK10で「空の送り仮名で漢字を登録しようとしています」と出て操作がロックされる状況)、SKK同様に操作をロックするよう改良。

2012.02.25

日本語入力 (安定度向上)

送りがな入力中の子音と通常の入力中の子音の表示が区別されるよう改良。
変換中に遅延評価用の子音が残っている場合に状態を提示するよう改良。
2文字以上のローマ字による送りがな入力中に1回目のBS押下の時点で送りがな入力状態が解除されてしまう仕様を変更し、完全に送りがなを削除した時に解除するよう変更。ちなみにこの状況でのBSの挙動はSKKと互換性がない。SKKの動きは直感的ではないため、あえてここは互換性を切ってある。斬って斬って斬りまくる。
子音確定後に送りがな変換を行ないキャンセルした場合に子音の再評価が行なわれないバグを修正。
直接確定による文字入力(数字等)が雪花で処理されていなかったバグを修正。
再帰登録時にスタックに無駄な子音情報を積まないよう処理を最適化。
雪花関連処理と子音遅延評価関連処理を分離。(内部動作のみで操作上は変化なし)

設定補助

rule p系を変更して使っていた場合は再設定が必要です。

2012.02.25

日本語入力 (機能追加)

β0+i初版から試験中だったローマ字かな変換のUNICODE拡張ルールを標準設定に統合。
順次打鍵操作による送りがな指定を標準設定に統合。
送りがな指定操作回りの処理順序を修正。既に送りがなが存在する場合は送りがな入力と通常入力の切り替えを行なうよう改良。遅延評価用の子音を使って送りがな変換が行なえるようになった。送りがなが存在しない場合、二回連続で入力すると対象の文字そのものを入力できるよう改良。
順次打鍵操作中であることを画面に反映するよう改良。BSによる状態解除操作を追加。
順次打鍵操作の後のLの操作は誤操作と判断して無視するよう改良。
子音確定直後に直接入力系を行なうとBSで削除できないエンバグを修正。
遅延評価用の子音が残っている時に漢字変換してBSで暗黙の確定をした時の動きがいまひとつ直感的ではない。子音確定の遅延という意味では正しい動きなのだが動作変更すべきか悩み中。
そろそろβ0+i初版とは見た目も内部動作も別物になってきた…はず。ほとんどの通常操作に関しては関操作感覚をα版から一切変えずに維持しているつもりだが、何か問題がある場合はぜひ連絡を。

2012.02.26

日本語入力 (安定度向上)

ちょっと子音遅延評価についてはやりすぎたかもしれないが反省は絶対にしない。むしゃむしゃしてやった。反芻している。そもそも子音の遅延評価はSandSの押下タイミングやキー誤操作を極力回復するために導入した措置だったはずで、BSで修正される対象としては一番優先度が高い箇所になるはずなのだ。というわけで見た目通りに最優先で削除されるよう変更。
遅延評価対象の子音を残したまま次候補・前候補操作を繰り返していると表示色が通常の子音色ではなく送りがな色で表示されてしまうバグを修正。
順次打鍵操作状態で大文字小文字の区別がついていなかったバグを修正。Lとlの区別がついてないだけでいまひとつ実害はなかったけど修正。
順次打鍵中の誤操作判定はlのみを対象に変更。他のコマンドには影響が出ないよう変更。
通常編集から英語編集モードに移行後文字入力したとき、まれにエラーが発生するバグを修正。
・・・こちら外宇宙探査隊、・・・答願います・・・

2012.02.26

日本語入力 (安定度向上)

そういえば2012.02.25版から定義ファイルの内容が変わった(しかしフォーマットは従来通りなのでデフォルト設定には切り替わらない)ため従来版でルール設定していた人が新機能を有効にするためには定義ファイルの再登録が必要。
コマンドプロンプト(というかconhost.exe)でコンポジションの残像が発生する(というか実体が残る)バグを修正。キーボードモードの変更時にOnCompositionTerminatedを発生しないプロセスが存在するとか…それどこ情報よ…。MSのテキストサービスをベースとして作ったものはこの挙動を残している可能性が高い。とはいえ深刻な問題は起きないので問題なし(現に今までこの挙動が問題になったことなんて一度もなかったし)。
作業用BGM動画のタグに「もう作業しなくていいや」とか書いてあってわろた

2012.02.26

日本語入力 (安定度向上)

接頭辞変換中に母音のみまたは遅延評価の子音と組み合わせて暗黙の確定を行なった時、コンポジション内の送りがなに接頭辞変換用の記号が混ざる不具合を修正。これに加え記号1文字だけの時の特別扱いを廃止。
UNICODE拡張ルールのアイヌ語鼻濁音「チェ」「トゥ」系が、カタカナ出力専用として記述されているにもかかわらずひらがなモード時にひらがなで出力されてしまう不具合を修正。なお、ひらがな側も出したい場合は文字をひらがなで記述することで以前と同じ動作とすることも可能。
遅延評価用の子音が単語登録を中断した時に再評価されない不具合を修正。
発覚した問題点は根性で全部潰した。これで問題がなければ(フラグ)このまま雪花導入後初の安定バージョンとする予定。

2012.02.27

日本語入力 (機能追加)

単語削除操作からのキャンセルで直前の変換状態に戻らないのはSKKと操作感覚が違いすぎて気に入らなかったため、SKKの挙動と同じ動作となるよう変更。さらに、β0の頃のプログラムサイズ縮小の影響で削除時の情報提示方法はいまいちだったのではないか…とずっと思っていたので実際に直してみたら(コンポジション側の表示が変化しないようにして外部領域に読み/単語/アノテーション/削除確認の順に全て表示するようにしてみたら)なんだかひどく冗長に感じるので結局元の表示に戻すことにした。シンプルな表示スタイルに慣れすぎてしまって戻れなくなってしまった。

2012.03.03

日本語入力 (機能追加)

我輩はSKKFEPである。GUIはまだない。ﾜﾚﾜﾚﾊ ALL YOUR BASE ARE BELONG TO GUIェ…
てなわけで(？)謎の新基軸GUIツクール(仮)、爆誕。設定ファイルを書いた人によって未来(GUI)が変わる。SQ4の「カジュアルモードがあった方が、安心してノーマルの難易度を上げられる」という本気な発想に魂を揺さぶられて実装されたカジュアル設定方式となる。これで設定を大幅に単純化…したとでも思ったか？クックック…馬鹿め！残像だ。闇のSKKFEPの裏設定の難易度を光速まで加速するための第一歩。今までの設定ファイル？窓から投げ捨てろ！カジカジ設定の0と1を書き換えるツールを自作せよ！今日から君もG・U・I！G・U・I！――てな感じの他力本願寺で南無三！五七三！夜露死苦！ﾋﾞｷｨ!?
ついでに特殊キー判定も追加。つかこっちが主役のはずだったけど残念だったな！残像だ。ちなみに特殊キー判定はローマ字かな変換シーケンスの途中だろうがお構いなしにホイホイ組み込めてしまうという実は相当に強力な仕組みで当初からずっと実現したかった構想の一つだったりするんだけどざんねん！残像ちゃんでした。…真面目に書いとくと、ローマ字かな変換のフリーダムさに関して『だけ』はskkimeをマッハで追い越したと思ってます。「ね、簡単でしょう(very easy)？」とか言いながらファンクションキー全部にSandSとかSticky Shiftを割り当てたりできます。GUIとかないけどな。難解すぎてわけわかんないけどな。いいじゃねーかよぅたまにはかませ犬にだって虚勢を張らせてくれよぅ…えぐっえぐっ
ALTキー関連に機能割り当てが一切できないのは~~手抜き~~仕様です。SHIFTとCTRLだけでガンバレ！
特殊キー判定処理を追加。スクリプト言語風味のプリプロセス処理を追加。ホットキー割り当て機能追加。SandS割り当て機能追加。未定義のキーコードへの反応追加、確定時の子音優先選択追加、子音確定有効無効機能追加、などなど今までハードコーディングとなっていた箇所の設定変更機能を追加。追加。追加。破ァ！
…てな具合に今までの設定ファイルとの互換性は一見ありそうでまるでないので過去の設定ファイルは一切使えません。AZIKなどの設定ファイルはこれから少しづつ修正していきます。
他にも他にもﾐｻﾜはﾐｻﾜはシフトJISしか文字が扱えない環境下でも設定ファイルを正確にやりとりできるように改良してみたり！(ドヤ顔モーフィングしながら)…でもさ、いまどきSJISしか扱えない環境なんてあるの？…いや…ほらまぁ…ワンチップMCU…とか？(ドヤ顔モーフィング途中のまま毛布に包まって寝てしまう)

2012.03.04

日本語入力 (機能追加)

色設定のレジストリ取得に対応。
全角ベクタのレジストリ取得に対応。
まだレジストリの生成処理がないためよほどのバイナリアンでもない限り設定変更はできないけど、GUIとの連携で必要となる基本処理はこれでほぼ完成。
書き忘れていたけど20120303版からSandSのデフォルト設定を「日本語入力中のみ有効」に変更してある。日本語入力を必要としないアプリケーションで相性問題が起きることを防ぎ、アプリ個別設定に辿りつく前に「使えないプログラム」と早合点されないようにして利用者の間口を広げるのが狙い。
書き忘れていたけど20120303版からテキストサービスCOMの初期化タイミングをActivate後に変更しコンストラクタ軽量化の試験中。
完全改行設定の時、文字数0の特殊な候補を確定した時にキーイベントがアプリ側に伝わらず吸い取られてしまう(かなりどうでもいい)バグを修正。

2012.03.05

日本語入力 (安定度向上)

外部領域の背景色がシステムカラー固定で色設定を変更した際に見栄えが悪かった問題を修正。外部領域の標準背景色(8番)で塗り潰すように変更。
伝説の戦(中略)カラーサンプルを作成。

2012.03.07

辞書管理 (機能追加)

ユーザ辞書に単語の利用順序を正確に保存するよう改良。ユーザ辞書の情報量がようやくSKKに追いついた。初代Playstation風のO(1)ソートを使い、カネ(SRAM残量)は人(プログラマー)の命よりも重い8ビットMCUにも優しい作りとしたので多い日も安心。こんだけ十分な速度が出るなら遅延時間を取らずに毎回即座に保存しても何も問題ないんじゃね？否ァ！ストレージのスタンバイ時間を増やして電池寿命を数マイクロ秒でも伸ばせる可能性があるなら何でもやったるァ！あ、BSOD(ry
内部処理の安定度を検証するため、この版では作業用RAMサイズをあえて4KBまで狭めているので、人間には知覚できない程度の低速動作となっています。PC向け最終版ではサイズを数十～数千倍してさらに高速化するかも(むしろL2を汚さないので今の版のほうが速いかも…)。サイズを数万倍しても痛くも痒くもないとは最高の熱損失だとは思わんかね。あっはっは、見ろ！メモリがゴミのようだ！メモリが、メモリガー！
今回の版は機能上の違いは一切ありません。安定度を求める人は一つ前の安定版を使ってください。お待たせようこそ皆さん。これはただの技術検証用の試作です。利用前に必ずユーザ辞書のバックアップを取ってから使ってください。いのちきけん！
辞書マージ時(同一の読みの追加時)に無駄なメモリ転送が発生しないよう改良。

2012.03.09

日本語入力 (安定度向上)

AZIK等の拡張ローマ字かな変換で使用する子音置換ルールが正常に動作していなかったバグを修正。「Ko+」「KoQ」「KoNq」などが正常に動作するようになったはず。もしかしてこのバグ、当初からずっと抱えてたのかも。

辞書管理 (機能追加)

メモリ確保回数若干増加を犠牲にメモリ消費量を平均24%削減。ROM化用データの場合はもっと刻むことで理論上ほぼ隙間なく詰められるはず。

2012.03.12

辞書管理 (機能追加): ねんがんの　ほかんきのうをてにいれたぞ！; な　なにをする　きさまらー！

SKK10の補完では「個人辞書だけなのは、共有辞書では先頭の文字を共通にする見出し語が多すぎて、望みの補完が行なえる確率が低い」という理由によって個人辞書のみが対象となっているらしいのだが、果たしてこれは本当なのだろうか…？

否！SKKを疑え！

というわけでSKKFEPでは辞書の全領域を補完対象にした。絶対にこっちのほうが便利なはずなんだ！己の信念を貫き通してロケットで突き抜けろ！…今どきの携帯電話ですらROMの全領域を見て補完してくれる時代なんだし。え？予測変換？音声認識？ボク子供だからよくわかんないハーイチャーン(幼児退行)
それにしても、こういう補完処理を入れるとなると外部サーバをあとで結合するとき苦労しそう。ううん、知らないけど絶対そう

2012.03.17

日本語入力 (機能追加): オレは高校生探偵S.KK; 幼馴染で同級生の藍澤光と遊園地に遊びに行って(実写); 黒ずくめの男の怪しげな取引現場を目撃した！; 取引を見るのに夢中になっていたオレは、; 背後から近付いて来る、もう一人の仲間に気付かなかった！; オレはその男に毒薬を飲まされ、気がついたら…; 実行ファイルが　肥大化してしまった――!?

(バタン！)第3.17話　自動推定事件
警告！警告！例によって機能検証版なのでまともに動きません。警告！警告！
自動推定機能の技術検証版。入力途中の段階で犯人最終候補が推定できちゃった場合は外部領域に赤で表示される。たった一つの真実見抜く、見た目は大人、頭脳は子供！その名は瞑探偵シンイ(検閲)脳内で「あれれー？ここ候補が一つしかないよー？(CV.高山みなみ)」と補完するとなおよし。
しかしここで新たな悲劇が！なんと補完候補は二次元の彼方の存在だったのだ。電子の妖精なので触れられません。左手は添えるだけ。究極の寸止めプレイに　さ　あ　、　ふ　る　え　る　が　い　い　！
…ごめ時間なくてテキトー版作ったった。まだ基本機能の一部しかできてないんよ。全国大会が終わるまで待て！次号！
擬似カーソル表示とか登録中の全段同時表示とかいろいろ追加したような気がするけど忘れた。ア゛ー
IE/MozillaやDOSプロンプトで補完対象語が見づらいので伝説の戦(中略)カラーサンプルの設定を変更。
あんまりにも寸止めすぎたのでちょっと反省してCTRL+N(補完+変換)だけハードコーディングで実装。

2012.03.19

かゆう

2012.03.20

うぉォン

2012.03.22

前後

2012.03.26

『みんなSKKFEPを使ってくれるのか…』

「ギャハハハハハ」『えっ』

「ウ・ソ・だ・よ」

「SKKFEPなんていらないよ」

「いらないいらない」

「帰って漢直やろーっ」

『おぉぃ待ってくれア゛―――』

日本語入力 (機能追加)

TABキーによる補完処理を実装。ついに、ようやく、SKK10の操作感覚に追いついた。長い戦いだった。
SKKの世界を変える第一歩になるはずだったのに存在感が薄すぎた雪花機能(地味子)の続編をこっそり実装(アッ○リーン)。日本語編集中に単語を自動判定して入力状態を勝手に変更しちゃう、ちょっとドジっ子なムードメーカー。こっそりついでに編集中のLキーの挙動に関する互換性が一部失なわれた気がするが見なかったことにしよう(超法規的措置)。もちろん設定で1を0にするだけで完全にSKKと互換の動作に戻せるけど、この機能に体が慣れてしまったらこっちじゃないと相当使いにくく感じるはず。そしてもう後に引けないところまで来てしまった己の運命を悟り、独断と偏見でデフォ動作を根本から変更して「あばよSKK！よろしくSekka！」…みたいな展開にしたかったけど、ギリギリのところでなんとか踏みとどまるのであった。そう、少しづつでいい、ゆっくりと蝕むがいいさ…フフ…
などと悪の組織を気取りつつ数値変換機能や外部サーバ対応をまるっとスルーする気満々なこの男、ノリノリである。
ローマ字かな変換処理を単純化しつつ設定自由度を『若干』向上。反動で定義ファイルの互換性が失われたあげく記述が『若干』複雑化しちゃった気がするけど見なかったことにしよう(超法規的措置)。まだまだ行けそうな道筋が見えているので、そのうちまた定義ファイルの互換性が失われる可能性あり。
補完周りのバグを掃討後、安定したら次バージョンへ移行予定。バージョン番号が日付だの虚数だのでかなりいい加減だが主要機能の開発状況のふいんき(略)的に今はバージョン3.0RC2くらいのレベルなのかもしれない。主要機能以外は壊滅的でも人類最強なので気にしない。それならちゃんとバージョンを付けろ？だが断る！

辞書管理 (安定度向上)

補完範囲を正常に認識しないバグを修正。
送りありの接尾辞を送りなしと認識するバグを修正。
skk-henkan-okuri-strictlyとその他不思議機能の技術検証コードを追加(フロントエンド側は未対応)。プロセス間通信フォーマット変更につき、インストール後の再起動推奨。

2012.03.28

日本語入力 (安定度向上)

バッファが消えても英単語の認識中と間違えてしまうバグを修正。単語登録を挟むと忘れっぽくなったりする問題が残ってるけどドジっこ仕様として残しておく。
順次打鍵操作時に補完候補が正常に表示されないバグを修正。

2012.04.01

サクラサク

設定補助 (隠し機能)

標準の16色アイコンはダセェと思ってるんじゃないですか？アイコンを変えるなんてこと、無理だって諦めてるんじゃないですか？駄目だ駄目だ！諦めちゃだめだ！できる！できる！絶対にできるんだから！
というわけで(？)、アイコンデータさえ用意すればどんなものでも(サンプルアイコンのように32ビットの透明色つきでもOK！)いつでも自由に変えられるという安心感の演出と、テキスト入力プロセッサ側のモジュールを一切書き換える必要がないという、ただのOSの設定変更の盲点を突くというローテク感溢れる隠し機能ネタでした。
名前も変えられるので"Microsoft IME"(空白を含む場合はダブルクォートで囲めばOK！)とかに簡単に偽装できちゃうけどダメ！絶対！

2012.04.03

インストーラ (安定度向上)

爆裂言語VBScriptから暗黒言語JScriptに焼き直し。辞書のダウンロード時にIEのプロキシ設定に従うよう改良。イントラネットなどの環境でインストールする際は事前にIEで外部サイトが見れる状態になっているか確認してから使ってください。

2012.04.05

「インストーラがGUI対応するんですか！」

「もう操作で困らないんですか！」

「やった──！」

「…ただのIEじゃないすか！」

「やだ───！」

インストーラ (斜め上)

祝！GUI対応！喋る！
「やめて！私にActiveXするつもりでしょう？IE6みたいに」激しく抵抗したものの、JScriptの卑劣な策略によってマインドコントロールされ従順になっちゃったIE8の運命やいかに！……てな感じで、インストーラは今までの常識を軽く外れた動作をするよう、謎の技術を全力全開で投入してゼロから作ったものなので、もしかすると動かない環境があるかもしれません。むしろ動いてしまうほうが奇跡。動いた、動かなかった等報告もらえると助かります。

2012.04.07

日本語入力 (機能追加)

β0+i最終版への道は遠い
小文字cの直後の記号を直接入力する「記号拡張」設定を追加。変換開始指定の亜種としても利用可能。lでモード変更せずに1文字だけ半角文字を入れたいという場面に役立つはず。もちろん設定オフ可能。
日本語編集中に半角記号をそのまま入力できるようになったことに伴い、「スラッシュ」設定と「ピリオド」設定のデフォルト動作の変更を決断。これにより、SKK10のabbrevモードをlatinの一時入力として使っていた利用者にとっては操作感が変化する可能性がある。設定を戻す場合は設定ファイル「スラッシュ」「ピリオド」の行の値を2にすれば従来通りの動作となる。
OS依存処理の分離が不十分だった箇所を修正。コンポジションに文字が残っていた時の判定処理を簡略化……ん!?まちがったかな……こまけぇこたぁ(ry
シフトキー判定と独立した送りがな入力判定を追加。通常ルールでは使わないコマンドのため少々難解だがAZIKなどの特殊用途での利用のみを想定しているのでこれでいいや。
まだまだ日本語入力時の思考と操作、理想と現実が剥離しすぎている件について。雪花動作はあらゆる辞書が大量にあってこそ輝くはずなのだが、カタカナ語辞書を標準で持たないSKKとは相性が悪すぎる。例えば未学習状態でカタカナ語「フォント」を入力するため"Fontoq"とタイプしようとすると、初期状態では「ふぉん」で開始する日本語側の単語(カタカナ語)が存在しないので4文字目のtを入力した時点でドジっこ判定が発動し英語モードになってしまう(なお、同様の問題は「オート」「ガンガン」などの他の単語でも頻発する。他にも「ウィザード」なんてのも。報告㌧クス！)。「フォント」のカタカナを英語"font"でこれまで思考・入力していた人たちにとってはこの動作は理想的とも言えるわけだが、そうでない使いかたをしていた人にとっては悪夢以外の何者でもない。しかし！これは実は深刻な問題というわけでもなくて、この手の動作を見つけたら即カタカナ語(この場合は「ふぉんと /フォント/」を登録して辞書を強化していくことで簡単に解決する……解決はするのだが……。初心者にカタカナ語登録を毎回やれなんて言うのはかなり「強いられているんだ！」感が漂うのでそれ以上いけない(アームロック禁止)。一刻も早くカタカナ語辞書の扱いについて考えねばならない。「一方ロシアは邪魔な機能をオフにした。」的展開だけはジッチャンの名にかけて回避したい。
問題とその背後関係が見えてきた。SKKの名に恥じぬ程度にシンプルな機構で、面倒な初期設定を一切必要とせず、これらの問題全てを一撃で解決するには一体どうすれば……どうすればいいんだ……。次回、「また仕様変更？」太正桜に浪漫の嵐！

辞書管理 (機能追加)

複数辞書読み込み機能を追加。読み込み順序はファイルシステムに依存するという~~手抜き~~前衛的手法で大胆に解決。これが勝利の鍵だ。

2012.04.08

日本語入力 (機能追加)

あるぇー？(・3・)追加辞書なしでもなんだか解決できちゃった。原理は単純で「変身をあと2回も俺は残している…その意味がわかるな？」方式。もっと気合×3の学習ベースでがんばろうと意気込んでいたけどあっさり単純シンプルすぎる方法で動いちゃってﾜﾛﾀ
これまでの雪花では1回入力状態を切り替えたらそれっきりだったが、今回はそこからあと1回、変身のチャンスがある。これで「Fontoq」「Ganganq」「Wiza-doq」は解決。ほとんどの英単語は子音パターンが日本語と異なるのでこの条件でだいたい解決する(第一条件)。よし、解決！
あとは「Autoq」「Fantaq」のように最後の文字が変換コマンドの時に即変換するように改良。第一条件をすり抜けた単語であっても、その後にqを含むものは殆どないためここで99%のケースを解決できる(第二条件)。ちょっと動作中の見た目が泥臭いのが難点だが、これは「アウト」「ファンタ」のカタカナを登録するかカタカナ辞書を自動生成してやれば(twitterに書いたスクリプトを使うべし)SKK10と寸分違わぬ操作感覚になる。よし、解決！
しかしこの二つの条件をすり抜けるケースもわずかに存在する。簡単に思いつくものだと「Dominiq」「Metaseq」「Veroniq」など。これらはカタカナ語辞書がないと解決できない。しかしカタカナ3文字だけで寸止めして入力したいなんて場面は実運用では皆無だし、もしどうしても必要な時は上記3パターンを手動で辞書登録するだけで解決できる。よし、解決！
というわけでインストーラの複数辞書対応をしようと思っていたが必要なかった。~~なんかもう面倒だよパトラッシュ~~今はまだその時ではない。明日から本気出す。

2012.04.09

インストーラ (安定度向上)

辞書のダウンロード時に漢字コードと改行を変更しメモ帳で直接編集できる形式で保存するように改良。
インストール時に複数辞書の簡易チェックを追加。辞書フォルダを開くボタンを追加。ぽちっとな。

日本語入力 (安定度向上)

子音nで終了するカタカナ語(「Amazonq」など)が正常に出力されないエンバグを修正。

2012.04.11

日本語入力 (安定度向上)

動的補完を無効化できるよう改良。
アルファベット大文字小文字変換操作を入れてみたけどなんつーかビミョー。入力したものを後から修正するというのはSKK操作中の思考の流れと符合しない。次の版で廃止の時間だｺﾞﾙｧ。

2012.04.15

日本語入力 (機能削減)

ビミョーな機能を削除。蛹。

インストーラ (安定度向上)

Vista以降のネットワークドライブ上(管理者権限を持つプロセスから見えないドライブ上)でも最低限インストール・アンインストール操作ができるよう改良。初期のバッチファイル版からようやく一歩前進。

辞書管理 (機能追加)

lisp命令がきちんと除外できていなかったバグを修正。
複雑検索のための技術検証コードを追加(フロントエンド側は未対応)。プロセス間通信フォーマットは広報互換(上位互換)。

2012.04.21

設定補助 (機能追加)

テーブルの最適化をコードサイズを増やさない程度に中途半端に実装。最適化実装に合わせて定義ファイル内容を微調整。標準設定の出力サイズを14バイト削減。本気で実装するとさらに20バイトくらい削減できそうだがサイズがうなぎ登りなので断念。

日本語入力 (安定性向上)

積みゲー遊びまくりでヘヴン状……通信フォーマット変更に対応。

辞書管理 (安定性向上)

補完時に欲張りすぎてバッファが溢れて通信バッファ内で文字の上書きが発生する可能性があるバグを修正。発生してもTABを100回以上叩かないと発覚せず、文字化けだけの実害の少ない動作だったため~~コードサイズ増加するし対応めんどい~~ボスキャラっぽく「どこまでやれるか見てみるとしようぞ」とあえて見逃していたが、終盤で死亡フラグまっしぐらの予感しかしないので蛹のうちに対処。バッファ最大利用効率を1割ほど落とし、バッファ溢れが根本的に発生しないよう修正。安全度が上がったので補完時のランキング最大サイズを拡張。でもってコードサイズ増減なし。プロセス間通信フォーマットがわずかに変更されたためインストール後になるべく再起動推奨。再起動なしでもそれなりに動くけど保証外ってことで。

2012.04.22

設定補助 (安定性向上)

画面サイズが取得できなかった時にウィンドウが画面外に表示される不具合を修正。

2012.05.03

日本語入力 (機能追加): ～伝説から変態へ～; 蝶はその美しい羽根を得るために幼虫から蛹を経て二回も変身するという。そう……それは完全変態。だからSKKFEPの自動切替による変身も二回だけ……なんて決めつけたのは誰だァ！変態がたったの二回じゃ使えない、使いにくい！料理長を呼べ！回数を増やせ！この変態プログラムを作ったのは誰だぁ！……ぁ俺か！俺、参上！というわけで上限二回の制限を撤廃。変態は……億・千・万！まだだ……もっと、もっとだ！変態は……無限大ッ！俺が、俺たちが……変態FOREVER城伝説！ﾌｫｫｫｫｫｫｫ

「教授!!」「これはいったい!?」

『第三の補完だよ』

というわけで二回切り替わった程度で弾切れになるとか、子音が確定するまで補完が動かないとか……なんつーかこー、~~パンツ~~ズボンをはき忘れたような齒痒さというか違和感がどうも拭えず納得いかなかったので処理を全部書き直し。はいてない？それは私のお稲荷さんだ。
操作と表示スタイルはSKKとSekkaを足し合わせて割りそこなったような不思議なユーザインタフェースとなっている。内部は大幅に書き換えたけど今までの操作方法はほぼ変更なし。入力状態の表示情報を増やした版も試作してみたけど、一度に目に入る情報が多過ぎると認識に時間がかかってかえって操作しづらいと感じたため、最小限の表示内容としている。下線赤の時に英語が表示されていたら、その裏には日本語が存在していると考えるとよい。逆もまた然り。見えているものだけが真実ではない。SKKでは変換の主導権は常に人が握っている。そのことを、どうか諸君らも思い出していただきたい。つまり……我々がその気になれば日本語側も英語側も自由に選んで変換できる……ということ……！
一番大きな違いとして、操作ミスで間違った文字を入れてしまってモードが変わった場合でも、BSを押すだけで文字削除だけでなく表示状態すらも一手前に戻せるのが一番の変態…改善点かもしれない。
SKKでローマ字逆変換の処理を実装するくらいならGoogleに魂を売り渡して人間電池になったほうがましという方針で作っているので日本語の候補をTAB補完した時に英語側の探索が日本語側の補完結果とかけ離れた(入力に忠実な)不思議な踊りが見られることがありますが仕様です。べっ別にバグってるんじゃないんだからっ(赤面)
第三世代補完で補完精度がさらに向上。撥音でローマ字の後続が明らかに存在する場合、さらに1手先の文字まで探索することで人間が入力しようとしている内容をより的確に推定する。補完状態への遷移は子音入力中であってもお構いなしに変更可能。補完のランク付けは日本語と英語を同時に評価。

例えば「Mir」と入力した場合の動作は以下の通り。

世代	探索空間	補完結果
第一世代	み	みせ(店) みっか(三日) みらい(未来)
第二世代	み[ら-ろ] みっ mir	みっか(三日) mirror(ミラー) みらい(未来)
第三世代	み[ら-ろ] みっ[ら-ろ] mir	mirror(ミラー) みらい(未来)

第四世代以降はローマ字かな変換の状態遷移の頻度を集計してwuとかyiみたいな利用率の低い候補を除外してみたり、POBox的な未来予測エンジンを乗っけてみたりして(全部冗談だってばさ)、ますますSKKとは違うコムギコカナニカを目指して光の速さで明後日へダッシュだ！SKKって何だ？ためらわないこ・と・さ。Sekkaを見た時に妄想したSKKの未来形の基礎部分を実現できたので、僕、満足！

警告: これはβ0+2iの技術検証用の先行試作版です。安定度を求める人は一つ前の安定版を使ってください。プロセスが突然落ちても泣かない。

2012.05.05

日本語入力 (安定性向上)

子音確定コマンドが何も出力しないエンバグ(過剰全角=1や雑草入力の誤作動を引き起こしていた)を修正。
過剰全角=1のときとことん全角化しすぎてしまって読点や句読点まで記号側を入力してしまうエンバグを修正。ルール定義ファイルを利用していた場合は更新が必要です。
英語入力時の予測変換が正常に動作しないエンバグを修正。
ローマ字かな変換ルールの多重検索が正常に機能しない(AZIKなどのような複雑な木構造のとき発現)エンバグを修正。
文字がどんどん溜まる現象はバッファ上限越えないし面白いから仕様にして放置(ｷﾘｯ
接辞変換の補完結果を英語と誤認識するエンバグを修正。
完全に英語と判定された状態(赤下線の英語表示中)で確定した際に日本語が出力されてしまうバグを修正。

2012.05.06

日本語入力 (安定性向上)

補完確定時に子音表示が消えるエンバグを修正。

2012.05.08

日本語入力 (安定性向上)

英単語を無理矢理日本語側で変換→キャンセルした時、変換直前の状態に戻らないエンバグを修正。
内部処理を大幅に書き直してサイズ軽量化を試みるも挫折。くっ…

2012.05.09

日本語入力 (安定性向上)

編集内容が空の時に推定変換すると動作停止するバグを修正。
ローマ字かな変換のルールに半角英数のみの文字を定義し入力した際、補完結果を正常に表示できないバグを修正。

2012.05.15

辞書管理 (機能追加)

プロセス間通信フォーマットを変えずにフロントエンド側から受け取るパラメータの情報量が実質1ビットだったのを8ビットに増強。これで「この単語や送りがなは学習済みか」みたいなクエリも理論的には可能になった。未対応だけど。

日本語入力 (機能追加)

henkan-okuri-strictly相当の処理を実装。送りがなを含んだ語の検索時の挙動を以下の3種類から選択可能とした。標準設定以外の動作は検索範囲に制限が発生するため、単語登録時は標準動作に自動的にフォールバックする。この動作はDDSKKのhenkan-okuri-strictlyのマニュアルにある動作サンプルと同等の動きとなるはず。多少は違うかもしれないけどこの動きが一番自然で使いやすいはず。

モード0. (henkan-strict-okuri-precedence t)で(henkan-okuri-strictly nil) これまでのSKKFEPのデフォ動作

モード2. (henkan-strict-okuri-precedence t)で(henkan-okuri-strictly t) SKK10でhenkan-okuri-strictlyを設定した時に相当

モード1. (henkan-strict-okuri-precedence t)でユーザ辞書の単語のみ(henkan-okuri-strictly t) AquaSKKのデフォルト動作がこれと同じと推測。(AquaSKKがhenkan-okuri-strictlyにきちんと対応したら消す)

つーかhenkan-strict-okuri-precedenceとhenkan-okuri-strictly、ストリクトなんちゃらで紛らわしすぎ。ずっと感じていた違和感の原因がわかってようやく断言できる。AquaSKKの、メイン辞書側とユーザ辞書側とで挙動が変わるという実装は不自然だと思う。しかしそれでも操作感覚の再現には最大限挑戦したい。よって全て実装する。そ、そうだ！どうせこれはフラグ1ビット比較する処理を追加するだけだから。512バイトのブロック内にコードサイズが収まる限り何の影響もないし。あっ！そうだついでだから、単語登録中のフォールバック動作も実装しちゃおう。たまたま、たまたまついでにコーディングしただけ！なんだかんだでSKKの設計ミス云々と文句を言いまくりだった原作のCTRL+Jの挙動もきっちり完全互換のコードをわざわざ実装したのだってたまたまだし。どれも判定一箇所だけなんだし。こ、これはコードサイズが余ってたからちょっと実装してみただけで、べっべつにMacintoshのことなんか好きじゃないんだからねっ(赤面)うおぉツン期に二言なし！全部やったるぁぁぁぁ！…などと0.03秒くらいで思いついたツンデレネタを思考が追いつく前に書ききってしまえるのがSKKの最強なところ。だいたいコードを書くより操作のドキュメントを書くほうが何倍も面倒で敷居が高いのが一番の問題。丁寧？推敲？反省？退かぬ！媚びぬ！省みぬ！
送りがなの先頭を「n+母音以外」で入力した後BSで削除した時、送りがな表示がみさくら語化してしまうバグを修正。β0+i初期の頃から存在していたものと思われる。文字化けや浜の真砂は尽きるとも世にみさくらの種は尽きまじ――β0時代はMS-Office絡みで散々発生したみさくら語バグ。人類との果てしなき戦いに終わりはあるのか。

2012.05.16

日本語入力 (機能追加)

ASCII/JISキーボード定義を共通化
ACT定義サンプルを追加

2012.05.18

くっ！！

ガッツが　たりない！！

2012.05.26

日本語入力 (サイズ縮小)

内部構造を見直し、実行モジュールのサイズを32/64ビット版ともに0.5KB縮小したテスト版を試作
さすがにもう詰め込みすぎてこれ以上縮めるのは理論的・精神的に無理……っ！

2012.05.27

日本語入力 (サイズ縮小)

……と思ったんだけど気のせいだった。64ビット版の実行モジュールサイズをさらに縮めて通算1KB削減達成してしまった――ﾌｯﾌｩｰ

2012.05.29

日本語入力 (安定性向上)

候補選択時にキャンセルすると英語入力状態になってしまう2012.05.27テスト版のエンバグを修正。

2012.05.30

日本語入力 (機能追加)

送りがなの判定はSKK10に合わせていたが、より曖昧に受け付けるDDSKKの方式も選択できるように改良。デフォルト操作をDDSKK側とする。もしかするとこれはタイプ速度向上に継がる鍵かもしれない。
これにより

「UMya」

「UmYa」

「UmyA」

　はすべて同一の変換となる。

なおSKKFEP側の順次打鍵操作の拡張により、以前から既に

「U;mya」

「Um;ya」

「Umy;a」

　は同一の変換となっており、今回の追加機能と操作感覚が近いかもしれない。

2012.05.31

日本語入力 (機能追加)

20120530版のDDSKK互換の送りがな判定を有効にしたまま使い込んでみた。全てのパターンにおいてSKK10の完全な後方互換(上位互換)操作となっており、違和感なく自然に共存できているように感じる。SKK10からの正当な進化であり、常時有効のままでも何ら問題ないだろう。迷うことなく選択機能を廃止。
DirectX系ゲームやLibreOfficeなどの、コンポジションの座標を正常に取得できないアプリケーションにおいて、skkime原作同様にウィンドウの左下側へ座標を補正する処理を追加。LibreOfficeに関しては、skkime原作の補正を入れたところで根本的な解決ではない。MSサンプルベースで作られたテキスト入力プロセッサとMS-IMEとで何らかの処理の違いがあるものと思われるが、解決するための情報がなく手探り状態。
64ビット版の実行モジュールサイズをさらに0.5KB縮小。また世界を縮めてしまった――

β0+2i版公開

2012.06.01

β0+2i版公開: 地道にサイズを縮めていたのはすべてこのためだったのだ。いったい何が始まるんです？

今までに縮めたサイズ分をすべて消費してUIレスモードへ仮対応。Windows Vista以降の環境においてDirectXアプリ(ゲームとか、ゲームとか、ほかにもゲームとか)でも日本語入力できるようになる……かもしれない。まだ仮対応なので候補選択の時にフルスクリーンだと操作しづらいかも。
UIレスモードへの対応のため、コンポジションの更新処理回りの処理順序が大幅に変更されている。従来はコンポジション出力→外部領域を更新の順だったのが、外部領域の生成→API判定→コンポジション出力の順となっている。
一番変化が顕著なのはコマンドプロンプトかもしれない。候補一覧が著しく見づらくなるが仕様。β0+i以前の挙動に戻す場合はコンポジション操作中にCTRL+］を入力することで互換モードとなる(このキー操作は従来の外部領域の切り変え操作と同じ)。Windows 7であればrule conhost.exe m132とすれば変更可能。
UIレスモード対応として、動的補完中の候補一覧もAPIに知らせるようにしてみた。ちょっとこれはやりすぎだったかもしれん…。すべてゼロから手探りで作っているので、今までの作法だとかMSDNのガイドラインだのMS-IMEなどの作法は全部ガン無視。あくまでアプリケーションとその利用者にとって一番自然になるように作るという方針で突き進む。何か問題があったらぜひ連絡を。
プロセスへ寄生した時、既にキーボードモードがオンだった場合にキーボードモードを維持するよう改良。これにより、Windowsの標準機能(詳細なキー設定)で他のテキスト入力プロセッサからSKKFEPに切り替えた時などに、半角モードに戻らずそのまま状態を維持するようになった。
ちょっと変更点が多すぎて思い出せないのであとで書く

2012.06.02

日本語入力 (機能追加)

候補選択中にIMN_OPENCANDIDATE/IMN_CLOSECANDIDATE/IMN_CHANGECANDIDATEを発行するよう改良。LibreOfficeはこのメッセージをキーにコンポジションの座標を更新しているとの情報がCorvus Solis氏の解析により判明したため対応。ただし、補完表示の時にはこのイベントは「あえて」発行していない。このあたりの挙動についてはATOKやGoogle日本語入力の仕様に迎合したことになる。
なお、現状のLibreOfficeでは表示がかなり残念な感じになってしまうのだが、これはどう考えてもLibreOfficeのコンポジション描画処理のバグであり、コンポジションの座標はIMM系メッセージに関係なく、現在のカーソル位置を正確に返すように処理を修正するのが筋であると考える。どなたかLibreOffice/OpenOfficeのコードを一緒に直しませんか？(中途半端に他力本願モード)
API制御下で候補ウィンドウを表示する標準外の仕様(バグではなくあえてこうしていた)を廃止。テキスト入力プロセッサ側からは、APIを発行しているアプリ側が候補一覧を表示することだけ目的としているのか、それとも日本語の変換処理を目的としているのか見分けがつかない。前者の場合にウィンドウが表示されるといろいろ厄介かもしれないと考えた。逆に後者の場合は候補選択のための操作ガイドが一切出なくなるため、入力しづらくなるという問題もある。悩ましい。ま、悩むくらいならCTRL+］でも連打してろってこった。
というわけで標準の動作と違っても突き進むという信念を速攻で曲げちゃったことになる。くやしい……でも……修正しちゃう(ﾋﾞｸﾝﾋﾞｸﾝ)
再帰辞書登録から復帰した際、API用ページ情報が破損するバグを修正。
API制御通知タイミングと外部表示領域生成タイミングの分離に挫折。しまったMPが足りない！意識を高めてキーを打て！
コードサイズが一気に増えてしまったが、どうせこの後はサイズが増えまくる要素しか残ってないのでもう過去は振り返らない……やっぱりちょっと振り返る。無知故に、β0で24キロバイト程度で動作していた頃が懐しい。だがもうあの頃には戻れない。あばよβ0！よろしく2i！

2012.06.04

日本語入力 (機能追加)

COMのインタフェース構成を変更しサイズ短縮。外部表示領域追加の時点でもはやMSサンプルの骨格すら維持できていないがまた一歩別の物体に進化したことになる。あんま影響ないと思うけど。
IMN_OPENCANDIDATE/IMN_CLOSECANDIDATEのメッセージ送信タイミングを変更し、コンポジションの操作が完了してから送るよう改良。IMN_CHANGECANDIDATEは不要っぽいので廃止。
Googleﾊﾟﾈｪ……どうすんのコレ……。

2012.06.05

日本語入力 (機能追加)

入力開始のシフトキーの受け付けタイミングをより完全にSKK10互換となるよう改良。最初の1文字目にシフトキーを押さなくても、子音の入力途中であればシフトキーを受け付けるよう検出範囲を広げた。
当然、子音確定とも自然に共存する。例えば「okHaaku 」でも「okhAaku 」でも同じ「おｋ把握」になるし、「oKonoMi」でも「okOnomI」でも同じ「お好み」になる。変換開始の判定改良とあいまって、さらなる入力速度向上に貢献するはずだ。
これでSKK10やskkime原作からSKKFEPへ、といった(ハードルの高い)乗り換えであっても、日本語入力UIで一番大切な操作感覚*だけ*は死守してっぞｺﾞﾙｧ！と自信を持って勧めることができる。あー……サーバ対応？数値入力？GUI？ｱｰｱｰｷｺｴﾅｲ

2012.06.07

日本語入力 (サイズ縮小)

前回増えてしまったサイズを根性で0.5KB縮小。COMの回しかたがだいぶ見えてきた。インタフェース取得タイミングなどを大胆に変えてもわりと思い通りに動かせるようになってきた気がする。

2012.06.08

日本語入力 (機能追加)

API分離ﾃﾞｷﾀｰ
内部構造をさらに大胆に変更。コードサイズ・リロケーションテーブル共に縮小。実行ファイルのサイズは変化ないけど書庫サイズを見れば複雑度が減ってるのがわかるはず。一週間前の挫折は無駄ではなかった。
今までは候補一覧のウィンドウが出るまで、アプリケーションがAPI経由でユーザが変換しようとしている候補を読み取ることが不可能だったが、きちんとコードを書けば変換開始した瞬間にいち早く候補一覧を取得できるようにしてみた。もちろんゲーム等で表示処理のみを行なっている従来のアプリには影響がないよう発動順序には気をつけているつもり。
UIレスモードの動作確認にはNyaRuRuの日記♺の「WPF サンプルコード」が利用できる。コンパイル済みバイナリをUILessTest.zipで置いとくのでｼｸﾖﾛ。
あ、この機能を使うにはVista以降の環境が必須です。ゲーム系ならXPでもいける…かも？(報告求む！)
DirectX系のゲームでの動作状況について動作報告や不具合報告があれば歓迎。

果たしてSKKFEPはDirectX系ゲーム(日本語入力がからむってことはほぼ確実にネトゲが主戦場か)のチャットでどこまで通用するのか？！いかんせん、ゲームの数が多すぎて全容を把握するのは自分一人ではどうやったって不可能――

知るか馬鹿！そんなことよりデバッグだ！Diablo3はコンポジション確定処理がバグっててMS-IMEでも毎回確定をいちいち操作しないと入力内容が化けちゃう致命的なバグをなんとかしてくださいっつーかむしろIME回りだけでも自分にデバッグさせてくださいおながいします。

あとレアが出ないなんて言うのはバグではない。レアが出るなどという幻想は甘え。その言葉が忍耐を断ち切る。もっとデバッグする！

2012.06.09

日本語入力 (安定性向上)

API分離ﾃﾞｷﾃﾅｶｯﾀｰ
20120608版だとコマンドプロンプトで候補選択表示が残ってしまうエンバグがあったためAPI有効化のタイミングを調整。

2012.06.10

日本語入力 (サイズ縮小)

バージョンが上がって(Zipの)サイズが順調に縮む。ウィンドウクラスの登録タイミングをスレッドアタッチ時ではなくアクティベート時に変更し、ついでにアクティベート関連処理を一部書き直し。コードサイズが100バイトくらい縮んだ。満足。

2012.06.11

日本語入力 (サイズ縮小)

レジストリ設定が空の時のフォント取得処理まわりを簡略化。というかWindows XPだとエラーが出て実質動作していなかった無駄な部分を除去しつつリファクタリング。→x64版が0.5KBの壁を突破。サイズ縮小成功。
デフォルト設定の表示属性テーブルを眺めていたら0が多いので圧縮できそうな気がしてきた。どうせDLLがロードされた直後に一瞬だけ読み込まれるだけの領域なので圧縮して持っていても問題ないはず。試しにテーブル参照+ランレングスでエンコードしてみたら432バイトが72バイトに――！？来た！8の倍数来た！これで勝つる！→x86版もついに0.5KBの壁を突破。サイズ縮小成功。β0+i版にUIレスモードの機能を追加しつつ、サイズをβ0+i版と同等以下の34KBまで縮小したことになる。

爪に火を灯す思いで命を燃やしてサイズを稼ぎ、ついに獲得した満足感。しかしそれは偽りの平穏に過ぎぬことを誰よりも知っていたのも、またSKKFEP当人であった。足りない。まだ絶望的にサイズが足りない。しかし全てを消費して『奴』に再度、戦いを挑まねばならない。この戦いが終わったら故郷に帰って8ビットMCUに――

2012.06.12

主力部隊ハ　ディナーニ間ニアワナイ

単独ニテ　敵戦略宇宙艦ヲ追撃セヨ

繰リ返ス

単独ニテ　敵戦略宇宙艦(E M A C S)ヲ追撃セヨ

日本語入力 (機能追加)

二つの大きな改良が加わりました。β0の時からずいぶん時間がかかってしまいましたがSKKFEPの初版を出した時、やりたかったけど力及ばず実現できなかった機能をついに塔載しました。
一つ目。第二世代SandSユニット塔載による全モードでのSandS対応。システムのIMEとしてSKKFEPを選択している間、日本語入力モードがオフであっても常にSandSを有効化することが可能になりました。プロセス判定機能と併用することで、特定のプログラムのSandS入力拡張ツールとして使うことが可能です。EmacsやVimなどのSKKがエディタに統合されたIME不要の環境においても、本プログラムを導入することでより良い入力環境を目指すことができます。
なお、本機能は影響範囲が大きいため標準では機能は無効化されています。インストーラsetup.jsから「コマンド」ボタンを押してコマンドプロンプトを開き、"rule s63"と設定することですべてのプログラム・すべてのモードでSandSが動作するようになります(設定後に起動したプログラムにのみ有効となります)。全てのプログラムに適用したくない場合は、例えば"rule emacs.exe m5 s63"とか"rule gvim.exe m5 s63"などとすると良いでしょう。
二つ目。Emacsやminttyなど、β0+i以前のSandS機能と相性が強烈に悪かったアプリケーションにおいて、キー操作まわりの処理を改良しキー反応が遅れる現象を根絶しました。SKKIME1.5改とXKeymacs改で得た技術を元に、キー打鍵自体を再現し互換性の高い操作を実現しています。リモートデスクトップ経由での操作が可能という本来SKKFEPやXKeymacsが持っていた特長はそのまま維持しています。これで通常のEmacsの操作の範囲であればまず問題がないレベルになったと考えていま………ｻﾞｻﾞｯ…………かし、まだラスボス……elispの……入力に問題………ｻﾞｻﾞｰ

〝そして奴等の執拗な追跡を、ことごとく振り切り鯖に転送しようとしたその時！〟

１９３Ｘ年９月１４日　１５時３０分

SKK10「そこまでだ！若憎!!」

2012.06.14

「フッフッフッ…。」

「とうとうこの男(Emacs)とケリをつけなきゃいかんらしいな…。」

日本語入力 (機能追加)

第三世代SandSユニットを塔載。SandSによるシフト操作の際、コンポジションを経由せずキー入力のエミュレーションによって文字を入力す方式に変更。これまでのSKKFEPとは根本的に異なる動作であり、影響範囲は不明。しかしながらアプリケーション側からは従来よりも自然にキー操作されたように認識されるはず。この変更により、ついに、ついにSKKFEPをEmacsのSKKにおいてもSandS入力拡張ツールとして利用可能に。長い戦いに終止符が打たれた。
下方向通過設定時にカーソルキーの操作がアプリ側にきちんと伝わらないバグを修正。これはかなり長期間潜んでいた問題かも。
ReadConsoleInput APIによってキー入力判定を行なっているアプリ(NYAOS等)において、SandSによるスペースキー入力が認識されないという第二世代SandSユニットのエンバグを修正。

2012.06.16

日本語入力 (安定性向上)

第四世代SandSユニットを塔載。通常のプロセスでは第三世代の動作を行ない、整合性レベルの低いプロセスを検出したらキー入力エミュレーションを使わない第一世代の方式に自動的にフォールバックしSandSの操作感覚を限界まで維持するよう改良。ただし整合性レベルの低いプロセスでは、egg-like-newlineなしの動作は(現在のシンプルな実装のままでは)原理的に実現不可能。小型軽量シンプルを信条とするSKKFEPにおいてこれ以上無駄にプロセス構成を複雑化させて他の大規模IMEのように寄生先のアプリに負担を強いるくらいなら人間でいられるうちに死んだほうがましなので、これは仕様とする。
Flash PlayerでスペースキーによるSandS入力を行なった際、セーフモードと誤認されてしまうバグを修正。
セーフモード(SandSを理論的に再現できないキー入力パターン、例えばキー押下だけしか認識できないFM-7サブシステムみたいな欠陥特殊なダイアログなど)を検出した際、一部のキー操作が正常に認識されないバグを修正。一度変身してしまうと元には戻れないと知りつつ、可能な限り普通の人でいられるよう最善を尽くします。

2012.06.18

日本語入力 (安定性向上)

コンポジションの座標が正常に取得できないアプリケーションにおいて、ウィンドウのサイズが大きすぎる場合に外部表示領域が画面外にはみ出てしまう問題を改善。ウィンドウ領域になるべくかからないように位置を決定するという方針はそのままに、領域が画面外なのかどうかの判定回数を二回に増量。ﾏｼﾏｼda。一回目の移動によって画面外に出てしまった場合、ウィンドウと重ねて画面下部ギリギリの位置に表示する。
レジストリ設定なしで動作している時、ウィンドウ生成のたびに毎回フォントを取得していたためクロックが無駄だったので(無意味な誤差レベルだけど)起動時に取得するよう改良。他にもウィンドウ処理まわりを書き直して無駄を改善してちょっとだけサイズ縮小。

2012年6月19日(火)

　偽装確定、つまり「学習せず確定」する操作を追加してみたくなった。QWERTYとDVORAKで問題なさそうな配置というとCTRL+Uがよさそうなんだが、TAB補完の1手戻す(UNDO)と同じ操作なのでとりあえずということでCTRL+Qに割り当てることにした。
　あ、候補一覧の時は…シフト併用すると学習オフにしよう。

　さて、β0の時構想したまま(設定ファイルに未定義と書かれていたのアレだ)ペンディングになっていた絞り込み検索の実装について。いい加減予約コマンドを空けとくのも何だしもうちょっと考えてみよう。
　SKK(DDSKKから？)には何やら絞り込みを行うための拡張が既にあるみたいだけどこれは変換の文字を入力している時に操作を済まさねばならず、操作一覧の時に受けつけないので、つまるところ利用者の事を考えてない使いものにならない実装の典型だ。Corvus Solis氏が以前この機能について語っていた時に思いっきりこの機能のことをディスってしまったような気もするが間違ったことを言ったとは思っていない。普段こういう候補が多い単語に遭遇する時は、大抵スペースキーを押して候補一覧画面を数回出した時ようやく候補の多さに気づいて絶望するものだ。この時キャンセル操作などの手戻りを起こさずに素早く操作を「前に進める」ことができるかどうかが一番重要なはず。もちろんDDSKKの互換でーす反省してまーすというマージメーな姿勢を見せるために互換操作も用意しておく。これはコマンド実行タイミングをずらすだけでわりと簡単に実現できるのでコードサイズへのインパクトは少ないはず。
　表示はもう今の内蔵スクリプトだけで処理するのはキツいというか無理なのでここも拡張しないといかん。
　入力状態を増やすのも無理なので状態管理用の変数を一つ追加しなければならない。

　あ、Qlangeageで和英判定に失敗するバグを発見。キャッシュ的な判定を行なっていたがお節介動作になっていた。処理を削ったのでバグ修正と同時にコードサイズも簡略化できた。すばらしい。

2012年6月22日(金)

　コマンド体系見直し。ついでに内部状態も見直し。今までローマ字かな変換状態の通知に0～3、コマンド通知に0x1000～0x1FFFという不連続な値を使っていたのを、0～3と4～0xFFFの連続した値に変更。

　確定操作に関するメソッドを辞書プロセスとの通信とバッファへの反映の2種類に分離。古い処理のままではサイズが増えるが、偽装確定を入れるとこのほうが格段に小さくなる。
　さらに見直したら確定処理前の状態保存用の変数が不要になってさらに縮んだ。

　偽装確定を部分的に実装。
　DictionaryCTRL+Qの動作がちょっと不自然なことに気付いた。→いいや。放置で。

　GUI実装の時の事を考えていたらなぜかテストコード用ソースを分割しないといけない気がしてきた。ちょっと壮大すぎるけどできることだけでも今やっておく。

内部状態を変更。どうやってもコンパイラ側のstate系のインライン展開を抑制できないことが判明したので極力手動で展開。

　エンバグ発生。暗黙の確定を子音で行なった時の動きがおかしい。現象としては暗黙の確定の時のfix()でNORMALになってツリー先頭に戻ってしまう。原因と思われる修正は以下の通り

ecでnormal化する変更
state系の手動インライン展開で足りていない処理がある

　古いコードで確認してみる。あるぇー？古いコードでもfixでNORMALになってる……でもちゃんと動いてる。ていうかツリー先頭ではなく正しいツリーに移動できている。なぜだ。

　outputでULONGで計算してから符号拡張すると効率悪いコードになってる気がするのでsize_tに変更すべき。→修正

　あ゛ーecでツリー移動してしまったせいでfix内での子音検索がnormalの先頭からになってる。
　ecでツリー移動をしないようにしなくてはいけない。→修正

　偽装確定が選択中にも効いてしまうのは問題。→修正

　again系の処理でregenerateが複数回呼ばれると問題があるようだ。→修正

2012年6月24日(日)

現代のHabitatはこんなにもえろいのに……
おっさんキャラを作ってしまった己を呪う

　PSOでSKKFEPを使って思ったこと

ゲームパッドから手を離してキーボードに手を伸ばして(シフトキーを押しながら)最初の文字を打つのはかなりきつい。こういうタイプのゲームはイージーモードが欲しい。JIS入力対応の時にでもやればいいやと思っていたけど実装優先度を見直すべきだ。物理Undo(直前の文字を覚えておいて間違えてシフトを押し忘れた部分を入力しなおし)も同様。

　あとサンプル用の文字は「じゅ」×「じゅもく」とか「ゆうしゅう」×「ゆうれい」あたりがよさそう。さすがに「かんちょう」なんてのを使うのは聖少女ネタとか混ぜても通じなかった時にいろいろとまずいだろ(笑)

　あと思いついたこと。文字数が少ない時の推測結果はほとんどが無意味なものになっているということだ。利用者の方から「メソッド」と入れようとして「メソポタミア文明」が出て笑ったという書き込みがあったことが発端となっている。これの本質は、カタカナ語辞書が貧相なSKKのL辞書、というかSKKに意地でもカタカナ語辞書を持たせたくないという(特にSKK10よりずっと後の世代からだと思うんだが…。SKK9以前はがんばってカタカナ語を手動で登録して使っていたような記憶があるし、emacs20で現役で使用中の1997年頃のL辞書には「サイエンス」などのカタカナ語が含まれている)歪んだ風潮が徹底されてしまったことに起因すると思っている。歪んだ、というのは誇張ではない。だってカタカナ語を排除したのに漢字+カタカナ語は採用してる、なんてのは歪んでるとしか言いようがないし。とはいえ、これは大した問題ではなくて、以前作ったカタカナ語辞書生成スクリプトを使えば簡単に解決する話。というわけで今回はその問題は置いておく。
　要するに、辞書に日本語の単語が足りていない状態で使う場合(将来、未知の単語が増えた場合など)におい、動的補完を使っていると、操作中に思考していることとまったく関係ない文字列が混ざってしまい本来の思考が阻害されてしまうという可能性を示唆しているのだ。
　どうやって解決するべきだろうか。ユーザ辞書にない単語の場合は表示に時間を置くか、あるいは確定した瞬間ではなく次の1文字が来てから推定してはどうか。つまり「meso」の段階では「mesopota」か「mesoddo」かわからないため推定表示は行なわず、「mesod」か「mesop」の時点で判断するということ。これは実装に手間がかかるがかなり有効なのではなかろうか。表示する・しないの閾値をどうやって機械学習するのか、などの課題を含め、今の版のサイズ制限下では到底実現できないが…。未来の世界ならきっと誰かが解決してくれるに違いない。つーかそこまでして実装するほどの内容じゃないと思うし。

2012年6月25日(月)

　絞り込み操作はだいぶ安定してきたが、まだ表示系に問題があることが判明。
　今までは補完対象があれば必ず変換結果が得られるという前提があったが、絞り込み中は補完対象があっても結果が空という場合がある。今の表示スクリプトでは表現できない。
　どうせスクリプトを直すなら、アノテーション表示制御もスクリプトから移すべきと考えた。
　その場合、プロセスに応じてアノテーション制御なんかもできたほうがいいのかもしれない(プログラムによってはアノテーションがあるせいで動作に問題が出たりするかもしれないので)。これについては良い案が浮かばないので今回は現状維持。
　プロセスに応じた動作については、イージーモードについても切り替えできるようにすべき。DiabloとかPSO2のプロセスだけイージーモード、とかなっていればかなり便利なはず。あと、イージーモードのON/OFFはキーボードでできることも重要だ。CTRL+］の操作をメニュー操作などに拡張すべきか？
　と思ってキーをぽちぽちやっていたら、SHIFT+CTRL+-で普通は入力できないはずのCTRL+_(Unit Separator 0x1F)が入力できることに気付いた。しかもメモ帳だとこの文字は不可視文字扱いになっててなかなか笑える動きになるようだ。CTRL+ENTERでCTRL+J(Line Feed 0x0A)とかCTRL+BSでJIS外デリート(Delete 0x7F)のエミュレーションみたいなものだと思われる。他にもあるんだろうか？0x00と0x1Eがあると嬉しいのだが。

　いや、プロセスごとの設定については早く決めておかないと後からだと取り返しがつかなくなりそうだな。
　今考えておこう。

現在の状況 16ビット中 10ビット使用中残り6ビット
内訳
mode bit7:互換表示モード bit2～0:起動時キーボードモードOFFの時に設定するモード
shift SandS制御 bit5:通常 bit4:半角英数 bit3:全角英数 bit2:半角カナ bit1:カタカナ bit0:ひらがな
　さらにこの後続く2バイトにシステム挙動に関するフラグを割りあててあって、そちらは残り6ビット。ただしこっちは本当に最後の手段用。
現在必要そうなフラグは以下の通り。

COMPATIBLE 互換表示
EASYMODE 簡易操作
PURERESULT API経由で渡す候補に操作情報を付与しない (予備)
NOCONSOLE コンソール自動判定を無視 (予備)

NOCONVERT 変換時のアノテーションを抑制
NOSELECT 選択時のアノテーションを抑制

　前半グループはモード設定の上書きに連動、後半グループはSandS設定の上書きに連動させることにする。どうせSandS無効化して使う場合は一括して無効化するだろうし、アノテーションオフにしたいという人も大抵一括で無効化していることだろう。
　しかし本当は独立したフラグ領域に割り当てたい。というか今ここで一緒にしてしまうのはなんというか「それ以上いけない」フラグ臭がきつい。最後の手段に手を出すべきか。

　その場合はこうする。拡張動作フラグの前半1バイトを上書き可能として1バイト目の設定のうち上書きすると混乱が起きそうなものを後半側に移動させる。
　移動させずに残すべき設定は次の通り。

EX_AUTOMATIC ///< 雪花動作を無効化する (SKK互換)
EX_DYNAMIC ///< 動的補完を無効化する (SKK互換)

　子音確定関連などのキー操作まわりの動作フラグは後半に移す。レジストリから読み込むサイズの最大値は後半部分も含めておき、レジストリ自体には前半部分まで書かないようにすることで、レジストリのバイト数に応じた上書き範囲が決定されることとなり、従来と同じアルゴリズムのままで全ての範囲のフラグを上書き可能にできる。プロセスに応じてBSキーの挙動だの子音確定動作だのが切り替えられてもあんまり嬉しくないけど。

　結局、プランAとBの合いの子で実装。そういや合いの子という単語の言葉狩りはかなり進行しているようだ。ネットで最新の蔑称の動向を把握して簡単に先手を打てるこの時代において、暗黙の差別利得構造の指摘に転用可能な単語(要するに適応範囲が広い蔑称)は生存率が異常なほど低いと感じる。浸透しすぎて消せないものはひらがな語化して馬鹿っぽく見せるテクニックもしっかりと併用する念の入れよう。何十年も昔、逆差別主義者たちが望んだ青き清浄な世界というのはもうとっくに実現されているのだろう。

2012年6月26日(火)

　うほDDSKKの開発メンバーから連絡キタコレ。
　本家にリンクが載ってしまうということは否が応でも知名度が上がるということだ。やばいテンション上がってきた。
　そういやopenlabどうなったんだろう。辞書の提供方法を考えないといけない時期にきたのかもしれない。

2012年6月27日(水)

　振動防止機能を追加したが焼け石に水だったでござる。
　ほぼ完璧に防げる第二世代の構想は考えたが時間がかかりそうなのでまず3iを発表してそれからにする。

2012年6月29日(金)

　あれ…もしかして…0.5KB以内のサイズで全機能実現できるんじゃね？
　構造体の順序を変えて先頭部分だけを別々に転送するコードで大胆に書き換えると…きた！大幅縮小きた！これで勝つる！久々にコーディングの神が光臨した瞬間を見た気がする。

β0+3i版公開

2012.06.29

β0+3i版公開: 日本語入力とは『浪漫』; SKKとは『理想』なんです; 理想が妥協してどうするんですか―― (プログラムサイズ的な意味で)

今やり直せよ。未来(S K K)を。

β0+3iを公開。いろいろ詰め込んだのでまずは機能の概要だけ。
今回の目玉機能、単語絞り込み操作。これは単漢字変換などのように同音異義語が大量にありすぎて通常の選択が困難な場面で、まったく別の単語の読みを使って単語を絞り込む操作。口頭で漢字を説明する時に「樹木」の「ジュ」みたいに説明する場面を想像してもらうとわかりやすいかと。同様の内容をSKKの打鍵シーケンスにするとJu:jumokuとなる。例えば『「潜水艦」の「セン」を変換しようとしたら残り候補が116あったでござる』みたいな状況に気付いて「絶望した！」と叫びたくなった時、そのまま操作キー(標準では：)を押して「せんすい」と打つことで自然に絞り込みが完了する。絞り込みはいつでもキャンセル可能。また絞り込み用の語は動的補完されるので、推定変換(．やCTRL+N等)による選択も可能。
既に原作のSKKにはskk-hintという機能があるけど、こっちは「打鍵前」から入力内容をはっきりと自覚している場合(レアケース)にしか使いものにならないし、入力中のフィードバックもいまひとつな代物で、自分ではあの機能とは「完全に別物」のつもりで実装している。とはいえ一応操作自体(操作中のBSとか)にはある程度互換性をもたせてあるつもり。
次に偽装確定操作。標準設定ではCTRL+QまたはSHIFT+ASDFJKL。これは変換中の候補を明示的に「学習せずに」確定する操作となる。前述の絞り込みを行なった候補や、外部サーバから持ってきた(学習状況を秘匿しておきたい)専門用語など、使用頻度が低い語なのに学習を行なってしったことで変換候補の順序が前に来すぎてしまってかえって入力速度が低下してしまう、といった状況を回避することを目的としている。他にも、普段は学習オフで運用し、この操作の時だけ学習する、という設定も可能。「脳内で学習順序を確実に把握している」スタイルのSKK利用者にも満足できるものとなったはず。
あとはネトゲ向け簡易操作モード。rule pso2.exe m68とやってビット6を1にすることで、単語先頭のシフトキー操作なしでいきなり編集状態となる。これはゲームパッドを使うネットゲームなどにおいて、ゲーム中に素早く漢字かな混じりの単語を発言したい場合に「両手をパッドから離して」「シフトキーを押しながら」「単語の先頭の文字を打ち込む」という操作が困難なシーンが多いため実装した。MS-IMEに切り替えればいいだけの話ではあるが、楽しく時間を過ごすためのゲームで自分のお気に入りの日本語入力方式が使えないなんて拷問以外の何者でもないですしおすし。まだこの実装は中途半端なのでそのうち何とかするかも。
あと振動防止機能。アプリケーションによっては候補の推定表示が一瞬画面外に表示されてしまう現象を防止するための機能だが現在はほとんど機能していない。第一世代のコンセプト実装レベル。次の版の構想だけは既にあるのでそのうち何とかするかも。
上記すべての機能をたったの512バイトのサイズ増加だけで実現。他の日本語入力プログラムが高度な自然言語処理によって快適な日本語入力を必死に目指す大艦巨砲主義の大海原において、数百バイト程度の鼻水が出そうなくらい単純なパターンマッチ処理と胡散臭いシフトキー操作だけで、まるで三輪車で海上どころか宇宙空間をキコキコ進むがごとく瓢々と切り抜けてしまうSKKの魅力を存分にお楽しみください。

2012.06.30

辞書管理 (安定性向上)

ユーザ辞書出力時、lispのconcat命令によるエスケープが正しく行なわれていなかったエンバグを修正。5/15あたりからずっと放置されていたバグと思われる。ﾄﾎﾎ

2012.07.01

インストーラ (安定性向上)

起動時にウィンドウが裏に出てしまうことがあって操作が面倒だったので自動的に前面に移動するように改良。あと辞書プロセスの起動にたま～に失敗することがあるようなので判定を強化しつつ失敗時の反応速度を高速化。

日本語入力 (安定性向上)

ひらがな入力時以外に和英自動判定を行なわないようにした。あとカタカナ入力状態では補完候補は出ませんが最低限の変換は可能。とりあえず暫定措置ってことで。

2012.07.02

日本語入力 (機能追加)

絞り込み開始直後の無駄なメモリ転送・比較を行なわないよう改良。
ネトゲモードは簡単な挨拶用途くらいでしか使いものにならない(特に丁寧語などと組み合わせようとすると悪夢レベル)なので、次の版から削除予定。普通にSandSか順次打鍵を有効化して片手操作すれば十分ナリィ……次のクローンはきっとうまくやるでしょう。
カタカナ入力時の和英自動判定を復活。補完も正しく動作するよう改良。普段カタカナ状態で操作していなかったので気づかなかったがこれは重要な機能だったと反省。これでヒュペリオンの台詞も問題ない。月ニ栄光アレ、地球ニ慈悲アレ。
なお、カタカナの変換処理を追加したため64バイトほど増えてしまったサイズを詰め込むためにいろいろ修正。例によってアルゴリズム変更レベルの書き直しが発生しているため安定度は未知数。ロスじゃ日常茶飯事だぜ！

2012.07.06

日本語入力 (安定性向上)

第二世代防振装置試験中。
変換なし確定後の状態遷移エンバグ(20120623頃発生)を修正。
英単語変換時に動的補完が動作しないエンバグ(20120701頃発生)を修正。
外部表示領域の表示に失敗するエンバグ(20120612頃発生)を修正。
ネトゲモード廃止。ビット6は別処理で使うことにする。
動的補完の精度を上げるためにローマ字yiとwuを小書き文字に変更。

2012.07.07

日本語入力 (安定性向上)

特定の条件下の後退処理で確定が発生しないバグを修正。

2012.07.08

日本語入力 (安定性向上)

単語登録に失敗するエンバグ(20120629頃発生)を修正。
ローマ字かな変換の子音関連のワークエリア・状態遷移を大幅に刷新。さらに編集中の内部状態を削減。どれだけ問題が起きようとも、今やっている修正を完遂せねばならない。すべては未来を実装するために。
とか言いつつ64ビット版のサイズをちゃっかり0.5KB削減。
「ん」で終わる単語の判定に失敗するエンバグ(20120708頃発生)を修正。
外部表示領域の描画処理を大幅に刷新。オブジェクト数を削減し高速化。
32ビット版のサイズを0.5KB削減。34KB台へ再突入。
暗黙の確定時に大地に草が生い茂らなくなるエンバグ(20120708頃発生)を修正。

2012.07.09

日本語入力 (安定性向上): シフトキーを超高速で操作することで日本語入力を意のままに操り敵の攻撃を潛り抜ける！火属性。; アツイゼアツイゼーアツクテシヌゼェー; SKKFEPさん……酸素欠乏症でバグって……！

単語登録をキャンセルした直後のコマンドを1回だけ認識しない可能性があるエンバグ(20120629頃発生)を修正。
辞書の状態によっては子音n入力途中の補完が意図した通りに動作しないバグを修正。
さらに内部状態を削減。64ビット版はあと2バイトで0.5KBの壁を破れそうなのだが挫折。無念。

2012.07.10

日本語入力 (その他)

アイコン変更
さらにアイコン変更。一番シンプルなやつを採用。8種類くらい作ったので置いておく。他のものに変えたい場合はrule iコマンドでいつでも変更可能。あと、アイコンファイルとして他のIMEや普通の実行ファイルなんかも指定できちゃうけど偽装、ダメ！ゼッタイ。

その他

ダウンロードページの当たり判定を地味に改良。ウソみたいだろ。IE6でも動くんだぜ。それで

2012.07.12

日本語入力 (安定性向上): あ…ありのまま今　起こった事を話すぜ！; 『おれは子音入力中にBSキーで文字を削除していたと; 思ったらいつのまにかもりもり文字入力していた』; な…　何を言ってるのか　わからねーと思うが; おれも何をされたのかわからなかった…; 頭がフットーしそうだよおっっっっっっっっ

というお話だったのさ。SKKでガッツ！(SHIFTキー超連打)
特定条件下で子音入力中の削除でなぜか文字がガンガン増えるエンバグ(2012.07.08頃発生)を修正。

2012.07.13

日本語入力 (安定性向上)

アイコンを作りなおしてみた。IMEデザインガイドなんざひたすら無視して好き放題やってみるテスト。なんだか小さすぎて見辛い気もするけどしばらく使ってたらなんだか慣れてきた気もする。スパシーバ？プラシーボ？破ァ！
絞り込みを行った単語に対する暗黙の確定で、入力した文字が一部出力されない可能性があるバグを修正。
絞り込みの中止時により正確に状態を復元するよう改良。
状態遷移に関する最下位レイヤの処理を全て差し替え。実用上考慮する必要のない処理を徹底的に排除。x64版のサイズを0.5KB削減達成。うぉぉぉぉぉぉぉぉｷﾀｰ！

2012.07.14

日本語入力 (安定性向上)

英単語認識中の特定条件下でBSが正常に動作しないエンバグ(20120708頃発生)を修正。

2012.07.19

偶然にもシフトキーを押し忘れてしまった俺たちは、

早速修正しようと小指を伸ばそうとして不審な白い粉を発見する

「ペロ・・・これは酢酸カリ！！pH調整剤として食品添加物にも使われている」

静かな山荘で俺たちを待ち構えていたのは恐ろしい陰謀だった！

名探偵SKKFEP劇場版スペシャル『シフトキー小指殺人事件』

――どうした？敵に攻撃が当たらんか？

A:「当たらない。」

B:「それほどでもない(謙虚)」

――そうか。なら…

俺の知る基本の技術を教えてやる。

レベルを上げて物理で殴れ！

日本語入力 (機能追加)

物理アンドゥ、爆誕！ネトゲモードの無念を補って余りある独特な操作感覚を実現！すべてはSKKの未来のために。勢い余ってSekka日本語入力IMEに改名しようと思ったけど大言壮語すぎるので自重。嘘・大袈裟・紛らわしいじゃろ？でも、SKKFEPからそれを取ったら、何が残るっていうんです？
日本語状態のまま「&ｈｄ=1」とか「ｐｙてょｎ」なんて入力してしまい、気づいたら時すでにおすしでハワワ侍。なーんて経験、ないですか？またシフトキーを押し忘れてるんじゃないですか？確定してしまった入力を取り戻すなんてこと、無理だって諦めてるんじゃないですか？駄目だ駄目だ！諦めちゃだめだ！できる！できる！絶対にできるんだから！
デフォルト操作では変換キーで発動。メモ帳を起動してアルファベットのままローマ字を適当に入力し変換キーを押せ。君はこれまでのIMEの常識を外れた何やら得体の知れない挙動を目にすることになるだろう。そのまま変換して確定し、再度変換を押せ！爆ぜろLisp！取り戻せFORTH！ﾌｫｫｫｫｫｫｫｫｫ
直前のキー操作や確定情報を元に、既に確定済みの文字をBSキーで物理的にティロ(中略)して消し、過去の編集状態をド根性で復元する。この特性故に多くのアプリケーションと激しく衝突することは必至。それでも広大なEmacsのバッファの海から這い出るためにはこの機能がどうしても欲しかった。
IMEオン時は確定済みの入力内容の一部とバックスペースの入力回数に関する情報がメモリ上に保持されていることに留意。この情報はコントロールコードや無効なキー操作があると即消去される。すなわちCTRL+J等のコントロールコードを空打ちすれば保存用メモリが全域ゼロクリアされるので活用されたし。高レベルのSKKの使い手ならいつもCTRL+Jを禁断症状よろしく超連射しているので問題ないとは思うが。
本機能を使いたくない場合は、設定「取戻操作」を値0にすることで無効化が可能。この手の機能は気にくわない人もいるだろうしアプリとの相性問題が強烈に出るだろうから、デフォルト無効にしておいてお行儀よくオプトインに……すると思った？残念！SKKFEPでした。この操作感覚は一度知ったら病みつきなのでデフォ有効にしてしまえ！むしゃむしゃしてやった。今は反芻している。
そんなこんなで勢いだけでデッチageた機能なので、確定アンドゥまわりの挙動はまだまだ不安定だと思います。おかしな挙動を見かけたらご報告願います。
第五世代SandSユニットを塔載。SandSキーの割り当てルールを変更。単体でキーを押した時に、スペースキー固定ではなく本来のキーコードを出力することで割り当ての自由度が上がるよう改良。併せて設定ファイルも更新。設定変更して使っている人は修正よろ。
SandS処理種別判定処理(プロセスの整合性レベル取得)が間違っていて通常権限のプロセスで狙い通りに動いていなかったバグを修正。第四世代までのSandSユニットとは何だったのか。今度こそEmacsやVimと協調動作してくれりゃれ？
設定「特殊送り」のAquaSKK互換動作を隠し設定扱いに変更。一応、値を2にすることで以前と同じAquaSKK互換動作にできるが、将来的には削除の方向で。

2012.07.21

日本語入力 (安定性向上)

英語キーボード時の物理アンドゥ操作をSHIFT+SPACEに割り当て。
子音確定した時物理アンドゥの文字数カウントに失敗するバグを修正。
ウィンドウフォーカス変更時およびオートコンプリート発生時に物理アンドゥ情報を消去するよう改良。
SandSによるシフト入力時にメモリアクセス回数を誤差レベルで削減。判定処理を共通化してコードサイズ短縮も達成。
PSO2で変換マーク表示がうまくいかないのでデフォルト文字をNo-Break Spaceからただのスペースに変更。
PSO2だと4文字以上の物理アンドゥがまともに機能しない。速度が落ちるが一気にキーバッファに書き込まずにじわじわと入力する作りに変えてみた。が・・・・駄目っ・・・・・！1文字あたり500msのウェイトをかけて出力しても3文字しか認識しない。ゲーム用に作った機能なのに肝心のゲームで動かない／(^o^)＼ﾅﾝﾃｺｯﾀｲ
モード遷移時、英数の入力なら物理アンドゥ情報を記録し、コントロールコードや無効なキーなら物理アンドゥ情報を消去することで「public」などの英単語の物理アンドゥを可能にした。
物理アンドゥ情報が存在しない時はキーイベントをアプリケーションに渡すよう改良。これで普通のキー操作に割り当てても(CTRL+Jを超連射してれば)わりと普通に使えるはず。
コントロールキーを含む操作に物理アンドゥを割り当て可能にした。調子に乗ってCTRL+Gに標準で割り当ててﾋｬｯﾊｰしようと企てたのだが……やはりというか当然というか、Emacsとの相性は最悪であった。……あさはかなり。(新しい設定「特殊中断」を1にすると有効になります)
Windows XPで物理アンドゥ後にキーが押されたままになる20120721b版のエンバグを修正。

2012.07.22

日本語入力 (安定性向上)

無駄にきっちりやっていたキー生成処理を廃止。どうせ誰も使ってないだろうし最低限動けばいいや。ハイ！！やめやめ。バッファを一括してAPIを呼び出してみたり、間欠動作を行なったりいろいろやってみたけどどーにもならん。なんかコンポジションのありなしでも挙動が変わるし、ゲーム側で意図的に制限をかけているとしか思えん。自由度と可能性を奪う実装に世界が埋め尽くされて終わる。無念。キーボードドライバでも経由しないと駄目か。ゲーム用マウスがキーボードデバイスつきだったりするのは、つまりはそういうことなんだろう。
絞り込み確定後の物理アンドゥで読みではなく絞り込みに使った単語が出てしまうバグを修正。
CTRL+Jのタイミングによっては物理アンドゥバッファがクリアされない可能性があるバグを修正。

2012.07.29

日本語入力 (安定性向上)

執拗に追い続けてはや数ヶ月。ついに、ついに、ついに、突き止めた！高速打鍵時に操作感覚がなんだかおかしいと感じる原因を！最近の爆速PCでは発生しないけど、ちょっと古いパソコンを使っていてCPU負荷が高かったり、画面描画イベントが大量に溜まっていたり、ゲームを実行中だったりすると、Win32API GetKeyboardStateで取得するシフトキーの状態が実際よりも遅れて反映されてしまうため、「Kak」などの左右で交互かつ高速に打鍵できるキー入力の時に『きちんと操作しているにもかかわらず』シフトキーが押されっぱなしだと判断されてしまうことが判明。公式のAPIで取得しているのに内容が信用できないとか、どんだけ修羅の国なんだ、Windowsは…。
なお、この反応速度向上の効果があるのは整合性レベルが中以上のプロセスに限定。
わりとどうでもいいレアケース対応その1。ホットキーによるIMEオン・オフの挙動をskkimeと同じになるよう変更。そもそもSKKFEPではホットキー自体が不要なので影響はないはず……ﾀﾌﾞﾝﾈ。前と同じ挙動でないと問題が起きるという場合は連絡を。
わりとどうでもいいレアケース対応その2。半角英数以外の文字入力による暗黙の確定時の挙動を改善。
FirefoxのFlashプラグインのプロセスとそれ以外の整合性レベル低のプロセスはどうも挙動が違うようだ。前者はSandSのキーエミュレーションが完全に無視されるが後者は問題なく動作する。制限が異様にきついFlashプラグインとそれ以外のプロセスをきっちり区別する方法があるといいのだが。今は整合性レベルだけで判定しているので、制限のドぎついFlashプラグイン側に動作の最低ラインを合わさざるを得ない。Adobe先生…IMEのキーエミュレーションが使いたいです…。おながいします。おながいします。全体の1/40のコードがこんなくだらない制限のために費されているなんて情けなくてﾌｧｯｸﾌｧｯｸ0x0B00B135三倍アイスクリーム(裏声)
整合性レベルの判定が正常に行なえない上、初回のSandSエミュレーションを行なった瞬間だけ、なぜかフォーカス変更イベントが発生する愉快なプロセス(IE)で一回目のSandSでキーが誤判定されないよう改良。

2012.07.30

日本語入力 (安定性向上)

インストール直後の環境ではセーフモードと誤認識されてしまうエンバグ(20120719頃発生)を修正。
Windows Vista以降の環境でのIE7～9のバグ回避判定を追加。サイズが肥大してしまった…無念。

2012.07.31

インストーラ (安定性向上)

githubの非公式ミラーの非圧縮辞書を参照するように変更。公式サーバが直るまでの緊急措置ということにしておく。この先永遠にCVSしか使えないとかマジ勘弁。どこもかしこも圧縮状態でしか辞書を扱っていない(テキストファイル形式の辞書フォーマットのメリットが丸潰れという)最悪の逆境の中、よくぞ…よくぞ置いてくださった…！

2012.08.03

数百バイトしかプログラム領域が残っていなくても

それでもSKKFEPなら・・・SKKFEPならきっと何とか「飛影はそんなこと言わない」

日本語入力 (試験実装)

OneNote2010のバグ(断言)に対処する方法がわからず一回休み中。OneNote2010のコンポジションの操作がバグってる。テキスト入力プロセッサ側からコンポジションに特定の文字を書き込んだ後の操作がブロックされてしまう。酷い…どうすんのこれ…OfficeIME2010でさえ変換中の表示がおかしいし、MSサンプルベースの入力プロセッサではきちんと動かない。これ、Microsoftが直すべきだろ常考。こんな糞処理を世間に広めないでくれ。逝ってよし。どうしてMS-OfficeといいLibreOfficeといい、Office系アプリは揃いも揃って変な動作のものばかりなんだ…。
FirefoxのFlashプラグインやIE7～9対策で肥大化してしまったプログラムを、命を削って縮めるのはもうそろそろ限界というか、とっくにいろんな意味で限界を突破していたので、ちょっと方向性を変えて余裕のできたスキマに試作機能を詰め込んでみるテスト。
CorvusSKKのかな入力方式とは正反対の実装、すなわち「かな入力中の利用者の思考に合わせてキートップに書かれている文字のみを対象とし、極力シンプルなコードでローマ字かな変換方式と共存させる」方向性を試みる。β0のネタ構想の一つ、アンチかなロック機能を実装。かなロックのオン・オフとIMEの内部状態によって入力文字を適切に切り替えることにより、かなロック状態の切り替えを利用者が意識せずに使えるように改良。
実行モジュールのサイズを一切増やさずに実装するため、ページの隙間にテーブルと命令をいかにみっちりと詰め込むかが鍵となる。試行錯誤の結果、432バイトのコードサイズで目的を達成(32ビット版)。半角カナ変換テーブルの再利用による効率化と物理アンドゥを利用した濁点入力という葉茶目茶な実装により前代未聞で人類未体験な操作感を実現したものの、整合性レベルの低いプロセスでは日本語すらまともに入力できないという誰得の欠陥品(ヒャッハー雑魚属性)が誕生。送りがな入力は最後の1文字を送りがなと見倣して変換する合理的(手抜き)仕様。ちなみにサイズ的にいろいろと限界だったので「かな入力時は」動的補完・和英変換・物理アンドゥ・接辞変換・とにかくいろんな機能がすべて無効。いまいち萌えないが仕様とする。お待たせようこそ皆さん。例によってこれはテスト版です。この仕様はフィクションであり、登場する人物・団体等はすべて架空のものです。将来に渡ってこの仕様が維持される保証はありません。
skkrule_kana.txtを公開。かな入力を使う場合は、この定義を登録して言語バーのかなロックを有効化した状態で使ってください(かなロックが無効の場合は従来通りの操作で使えます)。ひらがな入力はCTRL+J、英数入力はCTRL+L、編集開始は変換または無変換キー、送りがな変換は送りがなの文字まできっちり入力した状態で無変換キーです。もはやSKKですらなくなってしまった気もするけど人類最強なので気にしない。ｱﾝｹﾞﾛｱﾝｹﾞﾛ
かな入力時の回避用設定として残していた(つもりだったけど使途不明だった)設定「特殊反応」を廃止。

2012.08.04

日本語入力 (安定性向上)

OneNote2010のバグ(断言)に関して、Nathan Solis氏より詳細な調査結果を教えていただき、ついに対処方法が判明。問題の起きるAPIを回避してコンポジション操作を行なうよう修正。これがその解析情報だ！

OneNoteの数学記号の入力の件を調べました。

問題となる文字は、Unicode で Mathematical Operators という名称が付いているU+2200～U+22FF の範囲にある文字全てでした。その外の文字は未調査です。

問題を発生させているのは、ITfRange::ShiftStart()、ITfRange::ShiftEnd() の２つのメソッドで、上記の文字を越えてシフトさせてもらえずに、壁にぶつかるような感じで直前または直後までしかシフトさせてもらえませんでした。

ITfRange::ShiftStartToRange() と ITfRange::ShiftEndToRange() は問題無いようなので、回避策としてはこの２つを使用するか、数学記号がまず入っていないであろう範囲でShiftStart() と ShiftEnd() を使用するということになると思います。

OneNoteならではの機能でそんなことをしているのか単なるバグなのか分かりませんが…

すごい…なんと文字範囲まで…。こういう調査と対策がきちんとできるからこそ、CorvusSKKはWindows8にもきちんと対応できているのだなぁ…と、ただひたすら関心。SKKFEPはなぜ、いつまでたってもWindows8に対応できないのか。なぜSKKサーバ連携やGUIがいまだに作れないのか。どうして差がついたのか…慢心、環境の違い――
かなり根本的な動作変更が行なわれたため、各種アプリケーションとの互換性テストは全部ゼロからやり直しレベルのような気もそこはかとなくしちゃっているけど、うん、見なかったことにしよう！
定義ファイルの不備により、順次打鍵設定にするとエラーで設定ができなかったので定義ファイルを修正。これ致命的だよね？…まさかこんな長い期間、(自分を含めて)誰も使ってなかったってことか…。落ちつけ…大丈夫…こんなもんだよ…泣く程の事じゃねぇよ…最初から期待なんてしてなかったもん…こんなもんだよ！

2012.08.07

日本語入力 (安定性向上)

第六世代SandSユニットを塔載。
一部のアプリでSandSのシフトキーが押されっぱなしになる、という貴重な動作報告から、.NET Framework系のアプリでSKKFEPがおかしな動作をする現象が判明。さらに調べてみると、この根本原因はSKKFEP側ではなく、テキスト入力プロセッサのAPIであるITfKeyEventSink::OnTestKeyDownにキーリピート情報が正しく反映されていない…てか定数しか入ってないという、MSDNの仕様と違なる規格外の値を返すとんでもない挙動のせいであることが明らかとなる。戦わなければ生きのこれない…ていうかこれMicrosoftのバグでしょ。これじゃMSWordのOnTestKeyDownの多重呼び出しと区別つかないんだが…どうする？どうすんのこれ？実装した奴は馬鹿なの？死ぬの？
というわけでテキスト入力プロセッサが.NET Framework系でロードされた時は内部ロジックを変更して根性で対処するよう改良。もう対処療法の嵐でアッヘアヘだがSandSの操作感を維持するためには多少狂っているくらいが丁度いいのかもしれない。
この現象、自分でも.NET Frameworkアプリは自分でも多少は使っていたけど、SandSで日本語入力しまくって使い倒すくらいでないと気付けんわ…それにしてもこれは酷いわーありえんわーまさかAPIの引数に~~定数を返すだけのどう見てもただの手抜き実装~~MSDNにない独創的な挙動が許されてるなんて、ホントMS内製ツールは地獄だぜ！フゥハハハーハァー！
セーフモードを検出した時にシフトキーが押されっぱなしになるエンバグを修正。(20120807a)
Excel等のMicrosoft謹製アプリでまれに発生する、SandSを駆動した初回動作で極短時間のフォーカス変更通知が送られて内部状態が不一致になる現象への対抗策を実装。(20120807b)

2012.08.11

日本語入力 (安定性向上)

第七世代SandSユニットを塔載。
無駄なシフト操作を徹底排除し、想定外のフォーカス遷移を起こすアプリが将来登場したとしてもキーが押されたままにならないよう改良。
第六世代まではWORD(一回キーを押しただけで複数回のキー押下テストが通知される)、Excel(SandS処理の瞬間にフォーカスが切れる可能性がある)、Firefox(入力欄のフォーカス移動後キー離上イベントを送ってこないことがある)の三者の挙動のうちどれか一つを捨てなければならなかったが、全部一挙にまるっと解決。ﾀﾌﾞﾝﾈ
これで、現時点で対応不可能な相手はWORDの検索窓(キーイベントが通知されないので論理的に判定不可能。自動的にセーフモードを検出して一時的にSandS無効化することで対応)と、SandS処理の直後に(検閲削除)なIE7以降(どーしようもないので強制的に互換モードで動作)の二つだけとなったはず。他のサンドボックス系対応アプリについては…ｱｰｱｰｷｺｴﾅｲ
キーボードモードの判定処理を簡略化。
IMEにネイティブ対応しておらずシステムが用意した代理の入力ウィンドウが表示されてしまう~~デキの悪い~~独創的な挙動を見せるアプリにおいて、代理の入力ウィンドウ内でCTRL+MやCTRL+Jで文字が確定できないのは仕様とする。SandSで培った技術を応用することで技術的には解決可能なのだが、アプリ側をきちんと直すのが筋。つかこの代理ウィンドウ、MS-IMEユーザのことしか眼中にないって感じの挙動で萎える。とりあえず、普通にENTERを押すだけでも回避できるし、積極的な対応はしないことに決定。なんでも仕様って言い切れるって最高！ﾋｬｯﾊｰ

2012.08.12

日本語入力 (安定性向上)

SandSと関係のない通常のキー入力時にSandS関連の無駄な処理を行なわないようにして誤差レベルの高速化。
SandS定義可能なキーの最大処理数を32から255に拡張。
SandS処理および外部表示領域関連のコードを最適化しサイズ削減。
整合性レベルの低いプロセスにおいて、シフトキーと組み合わせたキーバインドを定義した際にSandS入力に反応しないバグを修正。

2012.08.13

日本語入力 (無駄排除)

LibreOfficeと戦うため、事実上LibreOfficeのためだけに書かれていた筋の悪い対策処理をすべて削除。オープンソースの雄、LibreOfficeなら……LibreOfficeなら、きっと何とかしてくれる！

2012.08.14

日本語入力 (安定性向上)

nProtectなどという屑と組みあわせて動いているネットゲームでSandS操作が正常に動作しなくなったため、回避策を構じる。自動判定は技術的には可能だとは思うがこんな糞のために何十バイトも判定処理を書くのも馬鹿らしい。てめーはビット判定とジャンプ命令だけで十分だ。だいたいブラウザでさえサンドボックスの安全性が云々とか言ってる時代に、管理者権限を要求してウィルス紛いの動作をする得体の知れない外国のモジュールの動作を許可しろってどういうことなんだ。こんなのに依存しないといけないというのなら、今すぐ国産ネトゲの看板を外せ。アンチウイルスソフトはこういう時こそ仕事すべき。って…違うでしょ！何も違うでしょAviraサンッ！ｶｰｲｺｰｸｼｰﾃｸｰﾀﾞｻｰｲ
というわけで、SandS設定の最上位ビットを1にすると(例: rule pso2.exe s135)回避モード(第一世代互換)で動作するよう改良。サイズ増加なし！
でもな……回避モードだと物理アンドゥも動かないんだ……。本当は両手がゲームパッドで塞がっているネトゲの戦闘中のチャット時に、シフトキーを押しそこねちゃった時の支援機能として、ネトゲモードや物理アンドゥを作ったはずだったんだ……。どうして……どうしてこうなった……。

2012.08.19

日本語入力 (機能追加)

BACK
TO THE SKK9

もしも…SKKがカタカナ語を切り捨てなかったらどんな未来になったのか――？

SKK10からSKK9へ進化せよ！DDSKKが選ばなかった未来を取り戻せ！

次世代SKK妄想科学シリーズ第9弾、カタカナ語自動認識・学習機能を追加。
ただのL辞書に興味はありません。この中に、カタカナ語、ひらがな語、半角カナ、アスキーアートがいたら私の所に来なさい。以上。
かつてL辞書に存在し、今は絶滅してしまったカタカナ語。当Webサイトで公開している、『L辞書からカタカナ語辞書を自動生成するツール』を使うことで、20XX年、既に人類はSKK操作系においてカタカナ語の動的補完や短縮入力を可能としていた――
SKKにおける、辞書にないカタカナ語の入力方法は二つ。一つは、あらかじめqを押してモードをトグルするというもの。そしてもう一つは、とにかくひらがなで入れてから最後にqやCTRL+Qを押す方式。今回の機能は、後者を辞書の学習と対応づけるものとなる。余談だが前者の操作はSKKの操作で唯一のトグル動作によるモード変更であり、混乱の元となる可能性もあると考え、設定で無効化できるようにしておいた。
カタカナ語変換操作の時、変換した単語が辞書に存在するかどうかを調べ、『辞書に存在する場合のみ』単語を学習する。学習によって同じ語が再度出現した際、動的補完による短縮入力の提示がより的確に行なえるようになる。漢字と同じ読みのカタカナ語(人名や擬音等も含む)が大量に出現する、専門文書や小説などの入力時に効果を発揮するはず。とにかく大事なことはたった一つ。「従来の操作方法、操作結果をまったく変えることなく、学習が行なわれる」ということ。
上記の特性により、未知の単語を入力した場合は学習は行なわれない。言い換えると、デフォルト設定のL辞書だけの(カタカナ語辞書を使っていない)場合は、操作感覚は一切変わらない！……というわけでこの機能もデフォ有効化することを決断。カタカナ語辞書推進委員会としては、この調子で将来、カタカナ語辞書の自動抽出もインストーラに統合してしまいたいッ！
でも、本当は英語認識時の動作と同じように、カタカナ語を認識した時のUIの段階からもうちょっと工夫すべきなんだよなぁ…。これどう考えても手抜き実装だよなぁ…。ｱｰｱｰｷｺｴﾅｲ
最近、安定性向上ばっっっっっっかりで超ツマンネとお嘆きの皆様、お待たせしまッ……また地味子機能だよ！ごらんの有様だよ！

2012.08.25

日本語入力 (機能追加)

漢数字の読みを補う辞書生成ツールを公開。これで数値変換そのものが不要となった。……というわけでもないんだろうけど……正直これ以上の機能って本当に必要なんだろうか？自分では使わないのでわからん。要望もあんまなさそうだし。そもそもSKKFEPなんてほとんど誰も使ってな(ry
というわけで、超簡易漢数字入力機能を塔載。なんてことはない、カタカナ変換操作の時、数字を漢数字にするだけ。そうそう、SKKならこのくらいシンプルじゃないとな。これで十分だったんだよ。
補完処理周りを作りなおし。子音vの補完が正常に行なえないバグを修正。「ヴ」まわりの処理はいつか抜本的に作り直したい。Win32APIを使っているくせにいまだにSJISとかEUCしか扱えない旧世代アプリとの境界面でうまいことやらかすのが入力プロセッサの本来の動作のはず。などとテキトーなことを書いて己が放り投げたブーメランが深々と突き差さったまま全力で放置しておく。
64ビット版のサイズを0.5KB削減。いける…まだいける！
デフォルト設定を大幅に見直し。古い版では記号入力系のプレフィクスにはFJZXCが使えていたわけだが、今後デフォルト設定ではXとCを無効化することにした。正直自分で使うときはFとJしか使ってないし。ZはSKKとの互換性アピールのためのデコイ。残像だ。Xはなんで入れてたのかすら忘れた。Cは…実装してから自分の日本語入力の操作の範囲では一度も使わなかった…まだ正直未練はあるし役立つシーンがどこかにあるはずだろうとは思うが…この機能はデフォルトから排除するのが正しいと信じてばっさり削った。反省なんてしない。反省する服がない。サルの反省。そんなことより反省だ！
とりあえずいろいろ作りなおしている途中なので安定するまでもうちょっとかかるかも。

2012.09.11

日本語入力 (機能追加)

…と思ったけど気のせいだった。わりと安定してた。一部の.NET Framework系アプリとのSandSの相性問題のレポートが一件。これは個別対応を考える次期に入ったかもしれない。プロセス名判定の拡張の形で実装して未来のアプリにも対応可能としたいところ。まだどう実装すべきか見当もつかないけど。
お試しでWindows 8 Release Previewをインストールしてみた。Windows 95/2000で完成の域にあった、枠の太さを自由にカスタマイズ可能なウィンドウマネージャはもう見る影もなく、ウィンドウの枠の幅とか文字と文字の行間とか、本来の情報量とはまるで関係ない部分を強制的に水増ししてウィンドウの『顔』を変形させ、まるで地獄のミサワ顔のように空白の表示領域を無駄にデカくする方向に進化を続けてきたWindowsだが、ついに来るところまで来ちゃったかという感じ。あまりの使いづらさにﾜﾛﾀ。とはいえせっかくなのでSKKFEPを対応させてみた。というかWindows 8といってもNTカーネル6.1に毛が生えた程度の違いでしかなく、通常アプリ用であれば既に対応していたわけで…(βテスタのみなさん、レポートありがとうございます！)。今回対応したのはMetro(Modern UI)アプリ対応。カテゴリを1つ追加登録するだけの簡単なお仕事。これによりシステムのデフォルトIMEとして設定可能となった。
既にIMEとして必要となる処理(入力・検索・表示)はだいたい作り込んであったので、6.2で必要とされる細かい処理を微調整するだけでなんとかなった。まず入力処理。いきなりTextInputProcessorExを廃止。聖典MSDNへの反逆。次に検索処理。DACLを26文字追加して対応。最後に表示処理。MSの説明通りにGetFocusを追加しただけで動いた。…たったこれだけで動かなかったのか。なんでこんな意味不明な制約をつけるのか、さっぱりわからない。表示条件をわざと複雑にして、過去にマイクロソフト自身が公開したTSF/TIPサンプルを、わざと動かなくするとかMSのIME/TSF関連の開発チームは互換性という概念を理解していないというか常軌を逸している方法ばかりあえて取っているように思えてならない。
まだMetroアプリ側からはレジストリがうまく読めないので手動でACLを設定する必要あり。詳細はTwitpicの絵日記にて。俺が、俺たちが…！日記帳だ！

2012.09.14

日本語入力 (機能追加)

Windows 8の拡張タスクトレイアイコンの挙動を改善。入力禁止のとききちんと状態が反映されるようにしてみた。
この挙動、最初まるでまともに動かず、三日三晩悩んだ挙句自力ではうまく解決できなかったのでNathan Solis氏に救援を要請。即座に、MS-IMEやCorvusSKKに存在する言語バーの点滅が観測されないという細やかな違いを一瞬で見抜いて詳しいレポートを頂いたおかげで、ソースチェック箇所を絞り込むことができ、なんと数時間でCorvusSKKと同じ動作になるよう改良に成功！ありがとう！そしてありがとう！
ちなみに今回、言語バーまわりの挙動がCorvusSKKをパク…互換性が大幅に向上したおかげで、自動的に「ブラウザ等のパスワード入力で言語バーの表示を切り替えられるようにする改良」も追加となった。
諸々の機能追加のせいで64ビット版のサイズが0.5KB増えてしまったがしゃーなし。ちなみにビルドオプションを全部つけて試しにバイナリを出力してみたら余裕で1KB以上増えてて、なんだかもういろいろと絶望的。明日から本気出す。

インストーラ (安定性向上)

祝！Openlab復旧。辞書はOpenlabからダウンロードし、失敗した場合はミラーから持ってくるよう改良。
圧縮フォルダ内やネットワークドライブ上でインストーラを直接起動した時の挙動を若干改善。フォント設定などがたまに動かない場面があったのできちんと動作するようになったはず。
アンインストール時に、サービス解除が確実に完了してから次の動作を行なうよう改良。
ごく低確率で、一般権限のプロセスの起動に失敗することがある模様。インストーラがエラーを出した時は、レアアイテムが当たった！レア充ｷﾀｰ！と叫…慌てず騒がずもう一回実行するべし。

2012.09.17

日本語入力 (安定性向上)

小書き文字連続状態において動作がおかしくなるエンバグ(20120825で発生)を修正。最悪の場合動作停止しちゃうヤバいバグが残ってた。わりと安定してたかなと思ったけど油断してた。反芻している。むしゃむしゃと。

インストーラ (安定性向上)

Windows 8標準添付のHaruka Desktopでも喋るように改良。
書庫の展開に失敗した場合などで、フォント設定関連で停止してしまう問題を見つけたので、setup.jsのファイル単体だけで実行した場合にエラーが出ないようにちょっとだけ改良。もともとsetup.js単体だけしか揃わなかった場合でもアンインストールだけは行なえるようにデザインしてあったのだが、いずれはsetup単体でもZIPをダウンロードしてきて根性で展開→実行くらいはできるようにして、自動更新への足がかりとしたいところ。

2012.09.19

日本語入力 (安定性向上)

動的補完時の促音関連の探索空間を半分以下に削減し処理効率を改善。(体感できないけど速度二倍)
小書き文字連続状態を解除するシーケンスで動的補完が動作しないバグを修正。
64ビット版のサイズを0.5KB削減。
SKKFEPでは.NET FrameworkでのTSF/TIPでまともにキーリピート判定ができないMicrosoftのバグを回避するために.NET Frameworkの自動判定処理を持っているのだが、この自動判定に失敗する一部のプロセスに対して個別に動作モードを変更可能とした(例: rule krile.exe s71)。キーリピート後にSandSが正常に動作しなくなるアプリが出現した場合に使用するべし。同種のアプリを見かけた場合は報告求む。(20120919a)

詰みゲーでヘブン状態
Cortex-M3ワンチップマイコンへ移植。こいつ…動くぞ！

2012.10.27

呪！Windows8発売！Windows8環境への初回インストール時のレジストリ設定ツールをおまけで追加。

2012.10.30

ワンチップMCUへの移植という誰得の試練を乗り越えて、奴が帰ってきた

「倍プッシュだ……！」

これ以上プログラムを削ったらただのゴミになってしまう。圧倒的不可能・・・！

しかし SKKFEPに電流走る――！

辞書管理 (サイズ縮小)

プログラムを再構築。内部データ構造を一新。ワンチップMCU移植実験の成果が今ここに。
辞書占有メモリ量を削減(テスト環境ではプロセスの占有メモリが16%減少)。アルゴリズム改良による検索の高速化。補完時最大計算量の削減。ブロック内完全平衡化と分割時のソート不要化。
そして何よりも―――

サイズ1.5キロバイト縮小！12.5KBへ！

今回はたった1ページ(0.5KB)程度を削ったとか、そんな生易しいもんじゃねーんです。そこんとこ夜露死苦。

2012.10.31

辞書管理 (安定性向上)

文字数0の候補などを含んだ単語の削除を繰り返すと辞書プロセスが落ちるバグを修正。これで上位クラスから見た動作、安定度ともに旧辞書プロセスと同等になったはず。私がそう思うんならそうなんだろう、私の中ではな。
さらにサイズ削減。20121030版で組み込みを断念したモジュールを続々追加中。
要素比較回数を半減させ、探索・分岐時のメモリアクセス回数を削減し、通常検索速度を倍速化。例によって人類には体感できないレベルの高速化。
惰性で残していた動的補完実装以前の通信フォーマットを一部廃止。ものすごく古い版からアップデートした場合は、再起動してから使ってください。
メモリブロック内要素のデフラグ処理を実装。従来はサイズの都合で単語マージ処理中くらいにしか役に立たない簡易版だったものを改良。ガベージコレクタを持たないワンチップMCUで長期間運用を行なうためには必須の機能。(20121031a)
ユーザ辞書保存前にメモリ構造を検証するよう改良。1年くらい前の不安定だった頃の辞書プロセスで頻発していた、保存処理中のクラッシュで辞書消失という事態を構造的に起きにくくした。つか「辞書保存してから使え」みたいなお約束の枕詞があると誰も使いたがらないですしおすし。個人的には今の版のほうが古い辞書プロセスと比べるとロジックが安定してるしより確実に末端まで把握できているし高速だし省メモリでいいかﾆｬｰと思うのだが、なにぶん運用実績がないのでいろんな意味でまだまだ諸刃の剣。素人にはお勧めできないﾜﾝ。(20121031b)

ここまでを要約すると――

通常版と比べて目立った機能追加は一切ありません。

まだまだ行くよー！

2012.11.02

辞書管理 (安定性向上)

……とか言ったそばからバグ発覚てへぺろ。安定のフラグ回収率。
送りがなのブロックサイズ計算が間違っていて、ユーザ辞書の保存で落ちる致命的なエンバグ(20121030発生)を修正。
20121030版(α版)を使っていた場合、ユーザ辞書にゴミが混ざっている可能性あり。ゴミが混ざったままでも通常の操作には影響はないが、バックアップがあれば戻したほうが吉。
バックアップを取ってなかったうっかりさん(私だ)も、大丈夫だ、問題ない。いつかはやらねばと思っていた、SKKの構造上どうしても貯まってしまう送りがなエントリのゴミ掃除を兼ねて、メンテツールを作って対応する予定。当然CUIで。C・U・I！C・U・I！
送りがなのブロック登録に失敗した時、正常なサイズ計算が行なえないバグ(旧バージョンから存在)を修正。これはほぼ100%使われることのない異常系のルートだったのだが、この場合にも正常なサイズを取得できるようにしておいた。サイズも削っといた。満足！
フロントエンド側で通信要求が出た瞬間に辞書プロセスを起動した場合、辞書プロセスが正常動作しないバグ(旧バージョンから存在)を修正。
デッドコードと無駄なワーク領域を徹底排除。BSS領域の利用効率を上げ17.3KB→13.5KBに領域を縮小。
さささすがにもうこここれで安定しただろ(フラグ)大丈夫？SKKFEPだよ？

2012.11.03

辞書管理 (サイズ縮小)

関数の粒度見直しで若干コードサイズを縮小。Cortex-M版とソース共通化。しばらく動かしてみて特に問題がなければ(≒コード縮小がネタ切れ状態になったら)正式版に昇格予定。

2012.11.07

トイレで滑って転んで便器で頭を打った拍子にサイズ削減のネタを思いついたので試してみた

……2.5KB……縮んだ……だと……

うぉぉぉぉぉぉぉぉぉｷﾀ━━━(ﾟ∀ﾟ)━━━!!

SKK！SKK！SKK！SKKぇぇぇうううわぁああああああああああああああああああああああん！！！

あぁああああ…ああ…あっあっー！あぁああああああ！！！SKKSKKSKKぇううぁわぁああああ！！！

あぁシフトシフト！スーハースーハー！シフトシフト！スーハースーハー！

三倍アイスクリームタピオカパンほ、ほーっ、ホアアーッ！！ホアーッ！！

日本語入力 (サイズ縮小)

無駄なGUIDや意味のない処理を徹底排除し、ワーク領域の配置を最適化することによりDLLのサイズを32ビット/64ビット版ともに2.5KB削減。ついに32.5KBとなった。
だが次の瞬間！また1KBほどリバウンドして膨れちゃう可能性高し。次回の機能追加まで、かりそめのサイズ縮小状態をお楽しみください。

2012.11.08

フラグ回収ッ！！

辞書管理 (安定性向上)

というわけでやっぱり残ってた致命的なバグを退治。よ、よゆーだZe……。メモリブロックの分割時、分割禁止のエントリを計算対象に含めてしまいメモリブロックのサイズ計算に失敗することがあるエンバグ(20121030発生)を修正。
特殊な条件下(天文学的低確率)でブロック内デフラグの開始判定がスルーされるバグを修正。
旧バージョンからのロジック変更点を全てリストアップしたらサイズ縮小のネタが閃いたのでちょっとだけ縮小化。

2012.11.09

辞書管理 (機能追加)

侵略！SKK娘　第一話「他のIME辞書でやらなイカ？」
てなわけで、久々にやってきました新機能！ATOK/MS-IME/Google日本語入力等で幅広く使われているテキスト形式辞書を、直接読み込む機能を塔載。
他のIME形式からのインポート機能自体は、特殊なツールを一切使わずに顔文字辞書を使う♺試みや、変換ツールskkdict_nicoime.jsなどを用いることによって既に人類はとっくの昔に実現済みだったわけですが、これからは変換作業すら不用とナルノデス。
例えば…

にちゃんねる顔文字辞書♺

ニコニコ大百科IME辞書♺

　などの辞書をダウンロードして解凍し、お好みの辞書ファイルを辞書フォルダに放り込んで再起動または再インストール操作をするだけで即・利用可能です。

なお、複数の辞書形式がある場合は、ローマ字かな変換のルールがSKKに最も近いATOKの辞書を使うのがお勧めです。

2012.11.10

辞書管理 (安定性向上)

IME共通テキスト形式辞書の読み込みで、スラッシュを含む単語を正常に読み込めないバグを修正。

2012.11.11

インストーラ (機能追加)

インストール操作を経由しない辞書の書き出しと停止・更新機能を実装。GUI側は未実装。
Windows 八兵衛のWindowsストアアプリ用レジストリ設定ツールを統合。
辞書プロセスの起動方式を変更し確実に起動するよう改良。一部の環境で、インストーラが辞書プロセスの起動に失敗する問題を改善。
セーフモード時はWMIクエリを一切利用せずに動作するよう改良。
通常インストール時もWMIクエリ1回だけで動作するよう改良。

日本語入力 (安定性向上)

変換キーおよび無変換キーを順次打鍵に設定した際、次変換操作が余分に割り当てられてしまう設定ミスを修正。なおプログラム側は変化ありません。設定ファイル側のみの変更となります。

2012.11.14

辞書管理 (安定性向上)

BSS領域の構造を変えたせいで排他制御が不十分となっていたエンバグ(20121102版で発生)を修正。BSS領域の使いかたを戻せば同じロジックでいいんだけど、SKKFEPはそんなこと言わない。排他制御のロジックそのものを変えてメモリ消費量はそのままを維持。

インストーラ (機能追加)

インストール前に辞書プロセスと言語サービスのプログラムのファイルを比較し、更新不要ならファイルを維持するよう改良。

β0+4i版公開

2012.11.15

β0+4i版公開

通常版に昇格 (βテスタ向けバージョンからは変化なし)
β0+4i Preview 通常版からの変更点はちょっと多すぎて思い出せないのであとで書く(そして忘れる)

インストーラ (機能追加)

メンテナンスボタン(辞書プロセスの一時停止と再起動)を追加。
ユーザ辞書フォルダの表示ボタンを追加。

2012.11.16

デフォルト設定を疑え――

日本語入力 (機能追加)

ローマ時かな変換に関するデフォ定義を大幅に見直し。
編集中に殆どの記号入力が可能となるようルール変更。また、z/は和英変換ではなく中点の入力を優先するよう変更し(f/とj/も同様)、中点を含むカタカナ語や顔文字の候補を入力可能とした。というか今まで入力できなかった。L辞書にはそんなエントリはないから、編集操作で入力できなくても大丈夫だろうと完全に油断していた。旧バージョンでこんなものをデフォ設定に決めた奴は頭がおかしい。誰だこんな設定を作ったやつは！料理長を呼べ！わたしです　|　＾o＾　|
というわけで従来版と比べて操作感覚が大幅に変わるがそんなことお構いなしでサクっと変更。やったッ！さすがSKKFEP！通常版でさえ平然と変更してしまう、そこにシビれる！あこがれるゥ！
上記ルール変更を受け付けるよう、従来のローマ字かな変換ルールの受け付け範囲を拡大するよう改良。内部フォーマット自体は完全互換なので、以前の設定が残った状態でも問題なく利用可能ではあるものの、標準状態から設定変更して利用していた場合は、今回の定義ファイルをベースに再設定することをお勧めします。
そしてこの混乱に乗じてローマ字変換ルール「wy+母音」による「わ行＋を」の入力に対応。「ATOKやGoogle日本語入力ではこれらの一部のルールが標準設定で採用されている」との情報を極秘ルートで入手したので、あちらさんよりも広い、全母音の範囲で入力を受け付けるようにしといた。よし！最強！
でもこのルール、文科省の内閣告示ローマ字とはちょっと違うし、そもそもSKK10にはなかったルールなので、プログラムサイズが8バイトぎりぎりの攻防で厳しい局面の時とかはコメントアウトされる過酷な運命に翻弄されるかもしれない。そのことをどうか諸君らも思い出していただきたい。つまり・・・・我々がその気になればSKKFEPの縮小は10年後・・・・20年後も可能だろう・・・・ということ・・・・！
動的補完時のデフォルト色設定を変更。もともと、候補が1つだけしかない場合、視点をまったくずらさず動的補完エリアの状況を色だけで認識して即座に推定変換操作の反応が可能なよう、あえて赤色で強調表示していた。しかし、初見の人にとってこの設定はちょっと強調しすぎであり、習熟期が来ればそれほど強調しなくても問題なく視界周辺の状況は認識できることを自身で確認。今回の版から色変更ではなく下線表示に変更。

2012.11.17

インストーラ (安定性向上)

　アップデートやメンテナンス時、辞書プロセスの通常停止に失敗する(かわりに最終安全策の強制停止処理が動作してしまう)現象を修正。これで安心してボタン連射できるので多い日も安心(？)。

2012.11.20

日本語入力 (機能追加)

　モジュール構造を変更し通信フォーマットを拡張。

インストーラ (安定性向上)

　将来モジュールのGUID変更が行なわれた場合に備え、更新インストール時の処理を強化。

2012.11.25

その他

　SKKGate公開
　32.5KBのプログラムサイズで健気に頑張る非力なSKKFEPの前に突如現れた謎の変態外部拡張モジュール。敵かな？味方かな？
　日付変換、数値変換、文脈学習、SKKサーバ対応への布石、スクリプト実行などの機能を大胆不敵に追加！

2012.11.29

その他

　SKKNet公開
　これまでのSKKサーバの常識を覆す、サーバ経由でのユーザ辞書の運用を実証した、まったく新しい通信プロトコルが登場！

2012.11.30

日本語入力 (機能追加)

　子音の連続入力中に雪花機能による英単語判定が正しく行なわれているにも関らず、ローマ字かな変換ルールによる記号入力ルールが優先されてしまうためスペースを押しても正常に変換できないように見える動作を改善。変換操作を優先するようにした。デフォルトテーブルの消費サイズを2バイト短縮。
　プログラム側の変更はなく、デフォ設定(と設定ファイル)のみ変更なので、ルール設定を変更して使っていた場合は再設定が必要。

2012.12.01

設定補助 (機能追加)

　サイズ縮小してみたらまだまだ詰め込めそうだったので条件判定文と論理和の記述を追加。
　設定の上書きルールを追加。追加するのを半年ぐらい忘れてた。(笑)

インストーラ (安定性向上)

　古い版からのアップデートの際、Windows XP Homeだと正常に辞書プロセスを停止できなくなっていたエンバグ(2012.11.11発生)を修正。このルートに入った場合、WMIクエリを利用してプロセス制御が行われる。
　メンテナンス処理でもWMIを使って辞書プロセスの状態に応じて起動と一時停止を判定するよう改良。
　最新版を使って通常ルートでアップデートしている場合はWMIクエリを使わずに高速に処理するよう改良。

2012.12.03

日本語入力 (機能追加)

　SKKGateとの組み合わせを想定して辞書プロセスとの通信回数を僅かに削減。

2012.12.04

日本語入力 (安定性向上)

　Firefoxでシフトキーが押されっぱなしになる現象への対処とかやってみるテスト。

β0+5i版公開

2012.12.12

日本語入力システムSKKFEPは、改造SKKである。

彼を実装したショッ…Windowsは世界制覇を企む悪の秘密結社である。

SKKFEPはSKKの自由のためにWindowsと闘うのだ――

β0+5i版公開

　SKKFEP は ?ひっさつわざをおぼえた！ローマ字かな変換ルールによる文字入力と同等のレベルで変換処理を発動させることが可能となった。例えば「@ ?.today()」のように記述したり、辞書プロセスに『なう /.today()/』とか学習させておいて「@ ?なう」と記述することが可能。要するに任意のキー操作でSKKGateと直結！合体だ！やめて！辞書プロセスに乱暴するつもりでしょう！SKKGateみたいに！
　子音表示処理を変更。反転表示はオリジナルのSKK10のモード表示にインスパイアされ……SKK原作へのリスペクトのため表示パレット色を同じにしてずっと維持していたんだけど、例によって色の主張が激しい微妙な機能となってしまっていた。モード表示とかもはや自分じゃ見てないし、そもそもモード表示が必要だったのはSKKに「カタカナ入力モード」なる設計上の欠陥(断言)が存在していることが原因ってだけだし。設定でこの欠陥を無効化できるようになった現在、毎回モードを主張されるのもウゼェし、そんなのやめて今風にしたほうがいいじゃん、すげーじゃん的な判断によりｼｬﾊﾞﾄﾞｩﾋﾞﾀｯﾁ変更。(でも完全廃止ってわけじゃない……あとはわかるな？)
　編集中に半角空白を入力可能にする設定「シフト半角」を追加。編集中ってのは登録中じゃないのだぜ。これでスペースを含むコマンドの入力ができるようになってちょっと便利になるかも。ただこれはSandSと通常シフト操作を組み合わせて使うスタイルの操作系と相性が悪く、SandS習得中の人だと誤操作が増える諸刃の剣かもしれない。ひとまずデフォ無効としておく。
　漢数字変換機能を廃止。代用機能として「数字入力」設定を追加。SKKGateで数値入力できるようになったし、急場凌ぎで作ったはいいけど自分ではまるで使わなかった(最初にQを押すってのが超面倒だった)し、なんかもーデフォ無効でいーや。(投げやり)
　その他、入力操作に関する内部コマンドを追加・変更(特殊コマンド系の廃止統合など)。設定ファイルを微妙かつ大幅に変更。
　カーソル移動処理と単純な行編集機能を実装。関連する内部処理を全面的に変更。きたぜ！β版！
　行編集……こんな利用頻度の低い機能は実装するだけ(コードサイズの)無駄無駄無駄無駄ァ――――ッ！というのがちょびっと本心ではあるが、行編集ができるということはSKKGateの利便性向上に役立つはず。利便性が上がれば利用者も増えてアイディアが広がり、ひいてはSKKの進化の促進に継がるはず。私は　お金SKKで動く。あと、Windowsの加護の元で安穏と動くプロセスにはまるで必要ない機能ではあるが、他に頼る手段がないワンチップマイコンのような極限環境においては、絶体絶命のピンチを切り抜ける最後の切り札としてラインエディタ機能はきっと役立つはず。

　以上の変更を

512バイトのサイズ増加

　で実現。
　1つ前の版の32ビット版のバイナリと比較すると、これを成し遂げるためにどのくらいSAN値を削ったかわかるかも。命を燃やせェ！

　えーここで残念なお知らせ。一連の変更により、過去の設定ファイルは利用不可能となってしまったけどSKKFEPなので仕方ないよね。半年ほど互換性を守りつづけて微塵も進化のなかった設定ファイルだが、またしてもお全部お書き直しのお時間です。お覚悟！

2012.12.13

その他

　標準設定/AZIK/ACT/T-Code/なめこの各種定義を更新。

2012.12.16

インストーラ (機能追加)

　辞書のオンライン更新機能を追加。Openlab鯖がバルスしないよう更新確認には180秒のガードタイムを設けてある。ボタンを連射しすぎて更新済と表示された場合は、『3分間待ってやる！』と叫んで少し待つべし。
　当然ながら、辞書のオンライン更新ボタンを押すと、Openlabからダウンロードが行なわれてローカルマシン内の辞書ファイルが書き換わってしまう。いやだ！L辞書は古いままずっと大事に使いたい！という要求もあるかもしれない。そこでL辞書のファイル属性をチェックして読み取り専用属性の場合は保護する機能を塔載。辞書はもう一切更新したくない、更新確認のためのパケットを外部に出して観測されたくない、などといった場合、[辞書フォルダ]ボタンを押してフォルダを開き、L辞書のファイルのプロパティを変更して読み取り専用にしておけば一切の更新は禁止される。(属性を解除すればまた更新できるようになるので安心だ！)
　辞書の最適化状態を選択できるよう改良。最適化しない場合は本来のファイル名と文字コードのままディスクにデータが保存されるが、メモ帳などの標準のエディタで編集できなかったり、将来登場する(かもしれない)L辞書のデータを利用するスクリプト類がそのままでは使えなくなる(かもしれない)ので注意。よく分からない場合はデフォルト設定(最適化あり)のまま使うこと。
　カタカナ辞書の認識機能を追加。

βテスタの方へ: 次の版からカタカナ語の自動変換スクリプトをインストーラに統合します。

カタカナ語辞書のファイル名はまだ未定ですが、L辞書のファイル名がskk-dict.txtでもSKK-JISYO.Lのどちらでもカタカナ語辞書が後に読み込まれるようにするため、ファイル名skk-kana.txtを予定しています。

　特に要望がなければこのファイル名で行く予定。既にカタカナ語辞書を使っている人はこの名称にリネームしておくとインストーラから簡単にカタカナ語のあり・なしを設定できるようになるので便利かも。

2012.12.20

インストーラ (機能追加)

　カタカナ語辞書の更新機能を追加。複数辞書対応と同次期(4月7日)に公開したカタカナ辞書変換スクリプトを使用することで、WSHの利用方法を理解している上級者であれば、β初期の頃から自由にL辞書からカタカナ辞書を作れるようになってはいたのだが、この処理をインストーラに統合した。
　導入は「カタカナ辞書」にチェックを入れて「アップデート」ボタンを押すだけでOK。
　現在所持しているL辞書に基づいてカタカナ語辞書を自動生成し、辞書フォルダにskk-kana.txtの名称で保存する。
　このカタカナ辞書の追加により、日本語入力時の予測変換の大幅な精度向上が期待できる。また標準設定の「仮名認識」機能により、qによるカタカナ語の入力時にも学習機能が働くようになる。長いこと準備してきたSKKの予測変換回りの改良案がついにボタン一発で誰でも使えるようになった。
　なお、カタカナ語辞書が不要な場合はチェックを外して「アップデート」を押せばいつでも解除可能。
　前回のL辞書の保護方法と同様、カタカナ語辞書の書き換えを禁止したい場合は、辞書フォルダを開いてskk-kana.txtを読み取り専用にすること。読み取り専用の辞書ファイルはアップデート時の書き換え対象外となる。

その他

　設定「引金拡張」を追加。Xtuqで「ッ」のような入力が可能となる。これは他のSKKクローン(Linuxの設定？)との互換性向上のための設定で、オリジナルのSKK10やDDSKKとは互換性のない操作となるので習得時は要注意。

2012.12.23

インストーラ (安定性向上)

　カタカナ語辞書がメイン辞書よりも先に読まれてしまうバグを修正。なんとファイルシステムの並び順序とエクスプローラの並び順はハイフンとかがからむとまったく一致しないというとんでもない罠があった。
　将来Openlabの辞書ファイル名と組み合わせることを想定し、これらのファイル名の間に割り込まず、かつメイン辞書(と本来のL辞書)とカタカナ辞書が逆順にならない名称をNTFS/Explorerソートの両者で実現するにはメイン辞書側のリネームしか無いと結論。独自ソート処理を追加して肥大化なんて死んでも嫌だし…たまには(？)大胆に変更ッ！
　アップデート時に自動的にファイル名を変更するので普通にアップデートするだけでOK。
　OpenlabでL辞書のアップデートがありました。concatの記述ミスが修正され、正しく変換できるようになりました。ついに辞書のオンライン更新機能が役立つはず！

2012.12.24

インストーラ (機能追加)

　初回インストール時にskkime/SKKIME1.5改のユーザ辞書を自動的に引き継ぐ(インポート)機能を追加。

SKKFEPからの大切なお願い → 解決しました！

　skkimeの辞書をインポートした環境で、辞書プロセスが正常に動作しない症状が報告されています。
　現在、辞書データが原因である(β0+4iで追加した辞書の破損防止機能が動作している)可能性が高いと見ていますが、どのような条件で発生するのかまったくわからず、大変苦戦しています。
　もし、辞書プロセスが突然停止するような辞書データを発見した場合は、作者までご一報ください。よろしくお願いします。

　問題が発生した場合は、以下の操作でユーザ辞書を読み込まずに起動して回避してください。

1. インストーラを起動し[メンテ]ボタンを押し、辞書プロセスの停止メッセージを確認する

　もしこの時「再起動」と表示された場合は、もう一回ボタンを押して停止させる

2. [ユーザ辞書]ボタンを押してフォルダを開く

3. フォルダ内のskkuser.txtを別の名前にリネーム

4. 再度[メンテ]を押して辞書プロセスを再起動させる

2012.12.26

"The Windows® Is Your Friend. Happiness is mandatory."

インストーラ (安定性向上)

　管理者権限を持たないアカウントに正常にインストールできるよう改良。
　このような環境でUACのパスワード入力によって管理者権限を取得すると、管理者権限のプロセスとログオン中のユーザ名が異なる状態で動作してしまう。要するに内部では完全に別のユーザとして扱われてしまい、インストールに必要な個人プロファイル回りの情報取得が理論上不可能だった。……こんな事態をまったく想定していなかった……
　要するに、これまでの版では一部の環境では正常にインストールできなかった。これはアカン。てなわけでWindowsの仕様をド根性で回避するコードを追加して気合いで対応！
　管理者権限を持たないアカウントで、過去のバージョンをインストールしていた場合、管理者権限でログインしてアンインストールするか、コマンドプロンプトを管理者権限で起動してそこからsetup.jsを起動し、一度アンインストールを行った後、通常の権限でsetup.jsを再度実行しなおすと綺麗な体に戻ります。よくわかんなければとりま放置で普通の権限で上書きアップデートしとけば問題なし！
　インストール/アップデート時にSKKGateのインストール状況を識別する処理を追加。
　セーフモードのバッチファイルを廃止。setup.jsを右クリックし「コマンドプロンプトで開く」と操作すれば同じような動作ができるし、誰も使ってないみたいだし、不要ってことで同意と見てよろしいですな？

2012.12.28

日本語入力 (機能追加)

　アプリの動作速度が低下している状態のキー入力反映速度の高速化処理をSHIFTキーだけでなくCTRLキー側にも拡張。ウィンドウ切り替え直後などに現在のモードを見ずにCTRL+Jlなどと操作する場合の入力とりこぼしが起きにくくなったはず。これ以上高速化する場合はもうちょっと別のアプローチが必要。アイディアはあるんだけど実装はもうちょっと先になりそう。

2012.12.29

日本語入力 (安定性向上)

　コピペ等の操作で編集バッファに大量の文字を入れた際に暴走する可能性があるエンバグ(β0+5i初版で発生)を修正。
　Firefoxにて予測入力ウィンドウが不規則に動く問題に対応するための設定を追加。レジストリskkfep_col_browser.regを追加し、ブラウザを再起動するとちょっとだけ改善するかも。

2012.12.30

辞書管理 (安定性向上)

　skkime/SKKIME1.5改から辞書をインポートした際、送りがなの文字数が多い(64文字以上の)エントリがあると辞書プロセスがメモリスキャンを行なった際、辞書データ保護のため緊急停止する(確かに辞書は保護されるけど、何回再起動しても同じように止まってしまうため、実質的に漢字変換が利用できなくなる)問題を修正。恐らくEmacsからインポートした場合にも同様。そのため以下の対策を追加し、辞書をインポートした環境でも安定動作するよう改良。

文字数が多すぎる送りがなのエントリを除外
送りがなの最後に音素がない送りがなのエントリを除外

　その他、辞書プロセスの入出力処理回りを見直し、なんとかサイズ増加なしで実現にこぎつけた。
　なお、SKKFEP自身が生成した辞書で使っている限りはこの問題は発生しない。
　これでSKKFEP最大の難関だった「常用できなくなるレベルの停止バグ」は解決できたことになる。本当にﾖｶｯﾀ……(涙)
　ご協力いただいた皆様、ありがとうございました！

日本語入力 (機能追加)

　文字をペーストした箇所をBSで消すとペーストした文字が一気に消えてしまって使いにくいので1文字づつ消せるように改良。
　文字ペースト直後に動的補完が正常に働かないバグを修正。

　DDSKKの確定アンドゥの操作設定を行った.skkのまま何の気なしにSKK10で操作したら……あれ？あれあれ？

こいつ……動くぞ！

　SKK10でも確定アンドゥが……動く……だと……
　うわぁぁぁぁああああぁあああ(ry

SKK10にも実装がある、備えよう。(ｷﾘｯ

　てなわけで(？)SKKFEPも確定アンドゥにある程度対応させなきゃいかんと思ったので、動作を見直した。確定アンドゥの操作受付期間が変換直後にしか存在せず使いものにならなかった部分を、変換後にひらがなを数文字入れた状態からでも操作を戻せるように改良。
　この実装中、暗黙の確定を行なった際、物理アンドゥの文字数を正常に計算できないルートが存在するバグを発見したのでこれも修正。
　今回の確定アンドゥの実装は第一世代の試作レベル。実際の操作としては物理アンドゥによる自動BS→ユーザ操作による手動BS→変換という手順が必要となっている。所詮は30数KBのプログラム。ショボい処理だと笑うがいいさ。理想の器、満つらざるとも屈せず。

2013.01.02

日本語入力 (機能追加)

　SKKFEPの持つ設定能力を、プロセス毎に完全に書き換えられるよう、設定処理を改良。
　例えば以下のような設定が(理論上)可能となった。

・アプリごとに異なるキー操作設定 (メモ帳だけ漢直設定にするとか)

・アプリごとに異なる表示設定 (ネトゲなどの日本語入力欄の小さいものだけ注釈表示オフ化など)

・アプリごとに異なる色・表示属性の設定 (Firefoxだけ表示属性を変えるとか)

・ゲームで特定の操作を行なった時自動的に日本語入力を無効化・有効化とか (予定)

　ただし、まだ設定処理の実装が追いついていないので、プロセス別に設定できるのは従来通り初期モードとSandS設定のみとなっている。
　プロセス別設定方式が根本的に変化してしまったため、従来の設定(Exe)は一切効かなくなる。一応サンプル設定のバッチファイルを用意しておいたので適当に実行しなおしを推奨。そんな設定、使っていなかったけど？という場合は放置で問題なし。

2013.01.03

日本語入力 (安定性向上)

　想定外に巨大なレジストリ設定を与えた時、ごく低確率で「不正な設定」と認識できないバグを修正。初期バージョンからあるバグで、常識的な範囲で使っている限り発生しないものだけど、プログラム16バイト短縮のついでに修正しておいた。

2013.01.10

日本語入力 (機能追加)

　辞書属性を追加。通常の変換と予測変換との区別や偽装確定の通知処理を実装。
　属性はまだ他にもいろいろ使い所があるはず……というか可能性に終わりが見えない。
　SKKGateやWebぽを連携させることでいろいろ遊べそうな予感。サンプル設定が定義ファイルのコメントに隠れているかもしれない。

辞書管理 (機能追加)

　辞書属性を追加。属性に合わせたデフォルト処理を追加。
　これまで隠し設定として残してあったAquaSKK互換の検索動作はゲート側で実装可能となったため削除。もともとSKKの標準設定と互換性のない動作だったので、こういう特殊な処理は今後はゲート側で実現させる方向とする。

2013.01.18

日本語入力 (機能追加)

　DDSKK互換の矢印入力ルールzLを追加。おまけでfL/jLも追加。
　DDSKKの文字と同じにした理由として、

1. やはりDDSKKは本家であり、多くのSKKの利用者が使っているデフォルト設定と互換性を持たせることはたいへん重要であること

2. SJISでも入力できる文字であること

3. シフトキー併用で太くなるという操作系はEgg記号入力と似ており筋がいいこと

P. ルールを追加しつつテーブルサイズを4バイト削減する余計な方法を思いついちゃった

Q. 本当はUnicodeの黒光りするぶっといアイツ➡にしようと思っていたけど、ふとAndroidのデフォ文字で見たら案外細かった……(´・ω・｀)ｼｮﾎﾞｰﾝ

　Unicodeの記号は何もかもがテキトーすぎて泣ける……ハートマークに全角幅を明示できないような文字セットなんてエ○表記で使えないこと甚だしいのでお逝きなさってくださりやがれDEATH❤
　なお、テーブルサイズを削りまくった結果、一部の設定適用時の入力パターンに面白い動作(実害はないけど不要な入力ルール)が副作用として出ていたりするんだけど、そもそもこれに気がつくほどの人なら自分で直せるだろうってことで放置。見なかったことにしよう(超法規的措置)。

拡張モジュール (機能追加)

　SKKGateの拡張モジュールをSKKFEP側に統合。スクリプト部分はまだSKKFEP側には組み込まれていないため、単にSKKFEPを普通にインストールしただけでは、これまでと処理内容に変化はない。(スクリプトは有効にはならない)
　従来のSKKGate相当のアーカイブはスクリプトのインストール処理のみに特化し簡略化。スクリプトを使用する場合は別途スクリプトのインストーラを実行することで設定を行う。こちらも圧縮フォルダ状態のままインストールできるように改良。導入は従来版と比べて一億倍くらい簡単になったはず。ただし、まだボタン一発で動くレベルまで到達できていないので、SKKFEP本体と比べるとまだ一億倍くらい面倒。さらに改良予定。まだ~~オワコン~~終わらんよ！

インストーラ (機能追加)

　拡張モジュールのインストール処理を追加。
　特殊動作指定オプションを変更。
　特殊動作指定で辞書削除を指定してアンインストールを行なった時、元の辞書を完全に削除せずにごみ箱に移動するよう改良。
　ネットワークドライブ上で実行した場合、インストール途中にネットワークが切断されてもインストールを確実に行なえるよう改良。
　圧縮フォルダで実行した際、OSが自動生成する作業用のゴミデータが残らないように改良。インストール途中で圧縮フォルダを閉じてもインストールを確実に行なえるよう改良。

2013.01.19

同日、SKKMR編集部にて――

『も……桃白白……Zzz』

「coバヤシさん！！」

『ﾊｯ！……どうやら俺たちはとんでもない間違いをしてたのかもしれない。これを見てみろ。』

「読者からの手紙ですか？どのご家庭にもあるローマ字変換のサンプルですよ」

『しかし「二文字目」の変換と言いながら、ほぼ全てが「ん」に関するルールなんだ』

「まさか……何かの暗号ですか！？」

『どうやらSKKFEPについて調査する必要があるようだな』

「ドキュメントから出てきた文字は…えーと"no su to ra…"？(アナグラムにすらなってねぇ！)」

『そう、これは

　SKKによって人類が滅亡することをカモフラージュするためのマインドコントロールだったんだよ！』

ΩΩΩ「な・・・・なんだって――！！」

日本語入力 (機能追加)

　DDSKK互換のシフトキー受け付け範囲拡大への対応は2ちゃんねるでの指摘を受けて20120530版で既に完了していたのだが、「ん」の確定ルールがバグっていた。
　CorvusSKKの更新の記述が気になったので調べてみて発見。正しくはこうだ。

入力	正しい出力
udonnya	うどんや
udonya	うどにゃ
udoNya	うどにゃ
udonYa	うどんや ← ここ
udonyA	うどにゃ

　急いで修正しすぎてシフトキー連続押下のルール(NA等)をエンバグしてしまったので修正。(20130119a版)
　なお、以下のルールはSKK10/DDSKKとあえて異なる内容にすることに決定した。

入力	SKK10	SKKFEP
Na	▽な	な
NA	▽な	な
nA	ん▽あ	んあ
NaNa	な*な	な*な
NaNA	な*んあ	な*な ← ここ
NanA	なん*あ	なん*あ

　このように~~私がモテないのはどう考えてもお前らが悪い！~~一貫性のない結果になるのはどう考えてもSKK10/DDSKK側が悪い。そもそもシフトキーを押して人間が指示を出した地点を遵守するという観点からも「んあ」なんて間抜けな文字が出ている時点で設計を疑うべき問題。このため、SKKFEPではこの部分に関しては躊躇なくSKK10/DDSKKとの互換性を切り捨てることにする。そもそもこんな操作は日本語入力では行わないので気にするだけ無駄無駄ァ！
　てかもう切り捨てすぎて何が残ってんだかよくわかんねぇ！ﾋｬｯﾊｰ

2013.01.24

日本語入力 (機能追加)

　変換属性8,9を追加。
　変換に失敗して辞書登録になる直前、属性8で変換処理を一度走らせてゲートから候補を取得するように改良。
　辞書プロセス側は以前から対応済み(あえて空の内容を返す)だったのだが、フロント側はコードサイズがどうしてもモリッとはみ出てしまってうまく収まらなかった。ずっと無効化されてきたけどSKKggr実装に伴い、この属性の実装が急務であると判断。ちょっと時間がかかったけど気合いで33KBに詰め込んだ。
　属性つき辞書検索コマンド「!辞書」を追加。skkrule.txtのサンプルの行を有効化すると「強制的に外部辞書で検索(属性9で検索)」の操作を追加可能。
　SKKFEP単体では何の意味も持たないこの謎機能、果たして一体どんな効果があるというのか……？SKKGateの更新履歴や属性表に答えが隠されているかもしれない。あとはTwitpicで学習時の動作の様子が見れる♺のでそちらを参照。

2013.01.25

日本語入力 (安定性向上)

　単語登録から復帰した時に入力モードが元の状態に戻らないバグを修正。

2013.01.27

日本語入力 (機能追加)

　表示系処理をアップデート。通常状態でのローマ字子音入力中と、編集開始の瞬間のローマ字子音入力中との見分けがつかなくなってしまったエンバグ(20121212版で発生)を修正。通常状態を青下線、編集状態を赤下線とした。

設定補助 (機能追加)

　表示スタイル設定を追加。rule pオプションにより▽▼マークを表示するスタイルも選択可能とした。(20130127a)

警告: G社に注意せよ！

　マーク表示を有効にした場合、skkime/SKKIME1.5改/CorvusSKK等のマーク表示機能を持っている他のIMEと同様の動作となってしまいます。
　つまり、skkimeのコンポジション回りの欠点がそのまま再現されることになります。
　ブラウザの検索窓などでは日本語入力中の文字列が▽▼の文字部分を含めてサーバに送信されることになります。この結果、(skkime利用時と同様に)SKK使いであることが検索サービスを行なっている営利企業側に筒抜けとなります。このことを十分に理解した上で使ってください。

2013.01.30

― SKK的眩暈FEP:API層への変更において、彼の小宇宙に生じた摂動 ―

MSのガイドラインによれば、COMの大文字小文字を区別してはいけないらしい。コンピュータ様のために区別しないように改善しておこう！ALL YOUR BASE ARE BELONG TO MS

処理を一文字変えるだけの簡単なお仕事！ﾋｬｯﾊｰ！楽勝だじぇー！……うぐっ!!　ぐああ!!(合体解除)

ん!? まちがったかな…

変数名debugとメソッド名Debugが衝突しちゃったてへぺろ❤　……何……だと……

拡張モジュール (機能追加)

　MSガイドラインに従い、APIのメソッドの大文字小文字を区別しないように改良。
　拡張スクリプト側の変数名とAPI名称が衝突してしまうため、スーパー~~宮藤さん~~斜め上解決策として、思いきってメソッド名をDebugからEchoに変更しちゃった。日本よ、これがSKKFEPだ。
　拡張スクリプトは一応標準設定なら動くと思うけど、何が起きても不思議ではないレベルなので基本的にSKKFEPをアップデートした場合はSKKGate側も速やかに最新版に更新しておくべし。
　Syncを引数省略して起動した時の処理アルゴリズムをα版初期の頃の動作に近付けた。極力スクリプト言語側に実行を渡さずに狭い範囲で処理を動かすことで、重いブラウザのページ内などでも影響を受けにくくなるよう改良。またもや例によって人類には知覚できないレベル。作戦名は「無駄な足掻き」で。

日本語入力 (機能追加)

　漢字変換中に漢字変換が行なえるよう改良。な…何を言っているのかわからねーと思うが(ry
　要するに漢字変換中に「今の辞書じゃこの単語は見つかりそうもない、ダメだこりゃ」と悟った瞬間、オンライン変換操作を即座に受け付けられるようにした。
　設定「外部」を追加。1にするとアスタリスク*が特殊変換操作となり、編集中・変換中に強制的にオンライン辞書「だけ」の検索を行う。
　なお、機能拡張スクリプトがない標準状態でこの操作を行った場合、空応答で検索失敗となるので強制的に学習モードとなる。注釈の再編集ともまた違った操作となるので、変換中の操作のバリエーションの1つとしてこれはこれで便利かもしれない。

2013.01.31

設定補助 (機能追加)

　謎の隠しコマンド「!中断吸収」を追加。CTRL+Gによる中断処理をアプリ側に渡したくない(かなり特殊な)場合に利用可能。
　補足。入力メソッドが通常状態でもキーを奪うというのは、本当に、本当に最後の手段です。CTRL+Jのように「普通の状態でアプリにキーが渡らない」という事態は、設定者・利用者の強い意思がある時のみにし、可能な限りアプリケーション側で判断する余地を残しておくべき、という設計思想が根底にあります。CTRL+Jは「特殊ってレベルじゃねーぞ」ってことです。基本にして奥義。
　普通はキー入力支援アプリ側のキーフックのほうが先に動いてくれるはずなんで、実はあんまり気にする必要なかったりもして。とりま製作者側としてはここは大事な部分ってことで。

2013.02.01

日本語入力 (安定性向上)

　某所のAbbrevモード開始時の表示等を改善する新設定を取り込み。
　既に古い暫定版のレジストリ設定を取り込んでしまっている場合、そのままだと今後なにかと問題が起きるかもしれないので、不安な場合は

rule cd

と操作して設定をクリアしておくことを推奨。
　βテスタ向けページのカラー定義サンプルも修正。

設定補助 (機能追加)

　色設定関連コマンドcを追加。今のところ色設定のクリアのみ。今までこの設定に関する解除方法が(βテスタ向けの「色消」のレジストリファイルを読み込ませる以外に)なかったので追加。

　全レジストリ設定をプロセス別設定に振り分けられるよう改良。今まで理論的には「メモ帳だけ漢直」みたいな動作も設定可能だったのだけど、レジストリの直接操作みたいな黒魔術が必要で事実上封印状態だった。今じゃSKKFEP！合体新機能解禁じゃ！(カメラ目線)

rule notepad.exe skkrule_tcode.txt (適用)
rule notepad.exe rd (解除)

……ってな感じでコマンド指定だけで超お手軽にできるようにした。あれ？GUI――(おいカメラ止めろ)――ここは何処じゃ？わしは誰じゃ？

　例によって設定の反映にはアプリを再起動するか、言語バーで一旦別の入力方式に切り替えて戻すことでDLLをロードしなおす必要あり(OS標準のショートカットキー設定を使えば一瞬じゃよ)。よくわかんない時はOSを再起動するんじゃ！

2013.02.02

設定補助 (安定性向上)

　m/sコマンドが設定できないエンバグ(20130201版で発生)を修正。
　肥大化してたのでサイズを0.5KB縮小。

日本語入力 (機能追加)

　選択キャンセラーを追加。候補選択時の操作系を変更。(20130202a)
　聞き慣れない単語……？……(ﾗｳﾞｨ…)
　……ﾊｯ！試作版の予感！……(・∀・)ﾗｳﾞｨ!!

しまった！これはSKKFEPだ！

オレが止めているうちに通常版へ逃げろ！

早く！早く！オレに構わず逃げろ！

――悲しいけどこれ通常版なのよね。

　おまたせようこそ皆さん。今から試作が始まる。
　従来版では候補選択状態になっている場面で(asdfjklで確定で)、ASDFJKLで偽装確定だったわけだが、この操作をあっさり廃止。その変わりに選択キャンセルが発動する。これは、『選択を中断し、対象の候補を単一の変換状態にする』新たな操作となる。
　例によって、SKK10の標準操作にはこんなものは存在しない。そもそも一般的なSKKの操作では、大量の候補の中から候補を1つに絞ることと、1つの候補を何らかの操作対象にすることが同時にできない。必ず一度変換し、ユーザ辞書の先頭付近に配備することが大前提となっている。もちろん長期間使っていれば必然的にそうなるわけだし、そんなことを誰も問題としてないみたいだけど、これって要するにSKKの構造的欠陥じゃん？つーわけで学習なしで選択可能にしてやった。むしゃむしゃしてやった。セルロースなら何でもよかった。今も反芻している。
　単一候補の選択さえできてしまえばあとはこっちのもの。これに続けてさまざまな操作を拡張することができる。暗黙の確定だろうが偽装確定だろうが、はたまた、辞書・ネット検索系のコマンドを発行するとか。クックック。
　なお、従来版の独自拡張だった「選択中の偽装確定操作」に関しては、1打鍵ぶん操作が増えてしまうことになる。(ASDFJKLで選択した後、CTRL+Qを押す)
　これは少々悩ましいが……この先の展開が「なんだかちょっと面白そう」という根拠のまるでない直感を信じて、思い切って操作系を変える。そして……

2013.02.04

日本語入力 (何も変えない)

　操作系の改造は大規模な変更となるので覚悟が必要かもしれない、と思いつつ学習キャンセラーを実装。
　で、結果がヽ( ・∀・)ﾉｳﾝｺｰだったので全部元に戻した。
　そもそもの起こりはこうだ。ユースケースとして「3番目の候補を偽装確定(学習なしで選択)したい時に操作をミスった」というシーンを考えてみよう。

「間違えて3番目の候補を確定しちゃった。こんな簡単な操作すら間違えるような自分がすべて何もかも悪いんだ駄目人間なんだ。あーあ、辞書、元の並び順に戻してーなー、でも戻す操作、超めんどくせぇなー」

某氏「もっと……熱くなれよ！！」

　今回の例では偽装確定の存在を前提にしてるが、SKKで「1回スペース余分に押して確定しちゃったてへぺろ」なんてのは稀によくあるから、それほど想定が的外れってことはないだろう。さらに加えるなら、従来の偽装確定は「これ、確定すると辞書の順序が変わっちゃってなんかイヤだなー」というストレスを軽減するためのものだ。だからあらかじめユーザが辞書の順序を意識して操作する必要がある。本当にこの処理が必要となる真のケースとしては、「辞書順序変えたいんだけど……あ、スペース押しすぎた。1つズレちゃった。直してぇー！」という時かもしれない。(辞書プロセス的にはどれも一緒なんで気にスンナ)

「完璧超人なSKKの理に逆らうなんてできっこないよ……」

某氏「はやく(アンドゥ)しろっ!!間にあわなくなってもしらんぞ――っ!!」

　しかし確定操作をしてしまったら、たとえ確定アンドゥしようが後の祭りなのがSKKの定めなのであった。むせる
　で、具体的な誤操作の手順と、辞書の内部状態を元に戻して正しい入力結果を得るまでのシーケンスは以下の通り。

従来手法1 (手動で並べ直し、最後に偽装確定しなおす)

KAISPACESPACESPACECTRL+J(やっちまった！本当は最後CTRL+Qしたかったのに！)

1変換2SPACE3SPACE4SPACE5CTRL+J(2番目確定)6変換7SPACE8SPACE9SPACE10CTRL+J(1番目確定、これで辞書の順序が復帰)11変換12SPACE13SPACE14SPACE15CTRL+Qこれでようやく本当に最初にやりたかった状態に戻る

15ステップ

従来手法2 (確定はそのままで、手動で並べ直して文字を消す)

KAISPACESPACESPACECTRL+J(しまった！)

1K2A3I4SPACE5SPACE6SPACE7CTRL+J(2番目確定)8変換9SPACE10SPACE11SPACE12CTRL+J(1番目確定、これで辞書の順序が復帰)13変換14CTRL+G

14ステップ

　と、ここまで回りくどく書いたあたりで、SKK使いは

「じ……辞書の順序なんか意識したことすらねーよ(震え声)」

…と見苦しい言い訳を始めるのが世の常というものである。
　何もできず諦めるのがあまりにも当たり前すぎて誰もストレスと認識しなくなっている。

SKK10「貴様らにそんな玩具は必要ない(棒読み)」

　こんな世界に誰がした。
　構わん、やれ！SKKFEPならできる！命を燃やせェ！

第一世代(失敗作)

　そもそも、何をどうすればいいのかわからん。しかし男は度胸。向こう見ずに何でもためしてみるのさ。
　そんなわけで、直前の偽装確定と同じ操作をもう一回やったら辞書の順序を戻すようにしてみた。
　使ってみると……ウホッ……なんだこれ……関係ない文字列がアプリ側に何度も入ってしまって直感的でない。斬新すぎてそびえ立つクソミソすら生ぬるい操作感覚だったので没。

第二世代(ビミョー)

　CTRL+Zによる特殊変換操作を行うと、直前に学習した内容を巻き戻す。~~ブーメラン~~アンドゥと変換を組み合わせたまったく新しい操作である。

改良後(手法1)

KAISPACESPACESPACECTRL+J(またか！)

1変換2CTRL+Z3SPACE4SPACE5CTRL+Q

5ステップ

改良後(手法2)

KAISPACESPACESPACECTRL+J(ちくしょー！)

1K2A3I4CTRL+Z5CTRL+G

5ステップ

　よっしゃ！ゼツボー的にSKKFEPだぜ！(ﾄﾞﾔｧ)

びっくりするほど　誰も　のってこなかった

　確定アンドゥした瞬間に学習内容もリセットするのが筋だと思われる。ひとまず外部のキー入力支援ソフトでも使って、F12とかに変換.CTRL+Zみたいなキー操作シーケンスを仕込んでおくと、8割くらいの入力シーケンスには通用するはず。残り2割のシーケンスを目ざとく見つけて、こっちの操作が欲しいんだけど(どうせSKKFEPなんか使わないけどな！)なんて赤さんのように言ってのけるほどの上級者に関しては、もはや自力でSKKを作れるレベルだろうってことで勘弁な(笑)

　で、使ってみたけどなんかこれでもいまいち使いにくいというか、使えば使うほど「こんな機能、なくてもいいんじゃね？」と感じるようになってきた。バックエンド・フロントエンド間のプロトコルや拡張スクリプトを全部巻き込んで書き換えて試作してたけど、そこまで~~人間性~~バイナリを捧げて実現するほど必要とされる機能じゃない気がしてきた。でも……「できないから、やらない」ではなく「できるけど、必要ない」にしておくことは悪いことではない。定義ファイルを修正して、隠し設定でCTRL+Zを再現できるようにしておいた。でも将来は削除するかも。

　結論。デフォ操作変更なし。

じ……辞書の順序なんか意識したことすらねーよ(震え声)

泣いてない！

2013.02.05

日本語入力 (安定性向上)

　アプリの動作速度が極端に低下している状態でコントロールキーを取りこぼすエンバグ(20121228版で発生)を修正。過ぎたるは猶及ばざるが如し。

2013.02.08

インストーラ (安定性向上)

　テンポラリフォルダをドライブのルートに設定しているとインストーラが起動しないバグを修正。

2013.02.11

人は何かの犠牲なしに何も得ることはできない

何かを得るためには、同等の代価が必要になる

それがOSアップデートにおける等価交換の原則だ

その頃僕らはそれが世界の真実だと信じていた――

これまでのあらすじ: Microsoft「残念だったなSKKFEP。既にWindows 8ではアイコン表示の互換性を破壊した。フルカラーのアイコンを持たぬ貴様の情報量では到底実現できまい」; 兄「……くっ……言語バーさえ表示できれば……」

Microsoft「絶望しろ！そして死ぬがよい」

兄「……ぐっ……うおぉぉぉぉぉぉぉぉ」

弟「これはhackbinの欠片……まさか……バイナリ錬成！だめだニーサン！」

SKKの錬金術師『禁断のバイナリ錬成』完

インストーラ (機能追加)

　錬金術の基本は等価交換である。無からリソースを作り出したり、性質の違うセクションを作り出すことは不可能である。そのため今回は原材料としてどのご家庭にもある基本的なアイコンDLLを用意した。もはやサイズ制限もなく、各ドットに32ビットも使えるのでメインアイコンは奮発して1色増やして、なんと合計5色も使ってしまった。むしゃむしゃしてやった。あ、あとMSのドキュメントには使いもしない意味不明なサイズのアイコンを大量に入れろと書いてあったけど知るかバカ！そんなことよりドーピングだ。とりあえずMSの指示なぞガン無視で実際に使われそうなものだけを選別してみた。もし問題が起きたら、また等価交換すればいいってだけの話さ。命を燃やせェ！
　錬成者はDLLの構成元素や特性を理解し、セクションを分解・再構築する。構築式に誤りがあったり、対価以上の物を錬成しようとすると失敗し、リバウンドと呼ばれる現象が起きる。リバウンドが起きると術者に多大なダメージが及ぶ可能性があるため注意が必要だ。setupをhオプションをつけて起動することで、強制的に錬成させることも可能。将来、アイコンを差し替えたくなったらhオプションが役立つはず。
　コピー元バイナリのタイムスタンプを温存するよう改良。(20130211a)

2013.02.12

日本語入力 (機能追加)

　単語登録で何も入れずにTABを押すことでカタカナ語入力支援またはオンライン手動検索の操作とした。
　新機能詰め込みキツすぎﾜﾛﾀ
　あとでちゃんと書く。絶対に睡魔なんかに負けたりしない(ｷｯ

拡張モジュール (安定性向上)

　COMのスレッドモデルの登録が正しく行なわれていなかったエンバグ(20130130版で発生)を修正。永遠のシングルスレッド番長なので動作上は変化なし。

日本語入力 (安定性向上)

　単語登録を重ねすぎると表示が崩れるバグを修正。(20130212a)

2013.02.14

日本語入力 (サイズ縮小)

　x64版のサイズを0.5KB削減！まだいける！

日本語入力 (安定性向上)

　TABによるオンライン検索操作の直後に、日本語変換状態ではなく一覧表示状態になってしまう可能性があるバグを修正。(20130214a)

2013.02.16

日本語入力 (安定性向上)

　TAB補完の直後の操作で文字数計算に失敗してしまい、ﾁｮﾛっと補完候補の文字がはみ出ちゃう可能性があるﾁｮﾛいバグを発見したので、ﾁｮﾛっと処理を全部書き直した。
　スッキリと書けたのでサイズもさぞや縮んだだろうと思ったら48バイトも増えてた。ｷﾞｬｰ！(悲鳴音)悪夢だ。全部捨てた。
　……朝、目が覚めたらバグはいつの間にか直っていた。サイズは変わってなかった。ﾖｶｯﾀ

2013.02.17

日本語入力 (機能追加)

　カーネル/VM探検隊を見てたら、こんな意味不明なドキュメントばっかり書いて遊んでばかりで機能追加を諦めてる場合じゃねぇ！って感じでいても立ってもいられなくなったので、もう一度挑戦してみることにした。
　β0+5i当初、コードサイズが肥大化しすぎて導入を断念していた子音入力継続系の編集機能の追加に成功。サイズ増加なし！
　編集途中にカーソル移動した際、末尾までカーソルを戻せば子音の入力を継続できるようになった。
　でも、この編集操作はワンチップマイコン用にオマケでつけただけの機能なのであまり実用面では期待しないこと。
　これまで何度か書いてきた通り、SKKFEPはこのプログラムサイズで多数のオモシロ機能を実現するために、いろんなものを犠牲にしている。
　その最たるものとしては最近導入したアイコン回りだったりする。SKKFEPではアイコンデータを16色にすることで、サイズを稼いでいるのだが、なんとWin8ではサポートが打ち切られてしまって(こんなくだらない互換性排除を行うなんてマイクロソフトっぽくない仕事なので、たぶんMSのIME関係者が設計ミスをやらかしたんだろう)うまくアイコンが表示できない。OS未対応ってのはもうどうしようもないので、アイコンを差し替えた実行バイナリを根性で自己生成してからインストール、みたいな『錬金術』に頼ってなんとか延命している。
　てな感じで、正攻法で作られたエレガントな実装などでは決してないので、一般的な利用方法を外れた入力を与えるといろいろ面白い挙動が見れるかも。
　現状の編集回りで起きる個性的な挙動の大半は「通常の利用ケースでは使われない動作パターンのため問題なし(震え声)」と判断された仕様だったりする。もし一般的な利用方法でも実用面で問題があるという場合は全力全開で対処するのでお気軽に報告を。
　某ちゃんねるで指摘のあった英語キーボード時の物理アンドゥの設定に関して、まずはドキュメントなど見なくてもすぐ発見できるように定義ファイルに(英)マークをつけておくことにした。(20130217a)

2013.02.18

設定補助 (安定性向上)

　海外版Windowsで日本語設定にしていても文字が正しく表示されない問題(ただし動作自体は問題なし)を改善
　論理演算と謎のELSE風構文を追加し設定ファイルのサイズを1%削減。(20130218c)

インストーラ (安定性向上)

　海外版Windowsで英語設定でもインストールできるようにした。(20130218a)
　UNCパス上で実行した場合にコマンドプロンプトで警告が出ないよう改良。

2013.02.20

日本語入力 (何も変えない)

　設定ファイルのサイズを13バイト削減。AZIK/ACT設定サンプルも新構文に合わせて更新。従来の設定もそのまま使えるので別に変更する必要はない。

2013.02.24

今年のエイプリールフール向けネタとして温めていたしょーもない全部入り設定ネタだが、また余計なことを閃いてしまった。

あれ？もしかしたらこれ、AZIKや漢直の習得初期段階の養成ギプス的な用途にも便利なのではなかろうか。

じゃ、いつ実装(や)るか？
『今でしょ！』

日本語入力 (機能追加)

　ルール定義を複数読み込み、アプリ動作中に再設定不要で自由に切り替えることができるよう改良。
　以下のようなユースケースに対応する。

ケース1: 表示系を切り替えるケース: 起動直後は動的補完が有効で、切り替え操作で動的補完をオフにできる; 起動直後は注釈表示が有効で、切り替え操作で注釈表示をオフにできる、等々……

ケース2: 操作系を切り替えるケース: 起動直後は標準ローマ字かな変換で、切り替え操作でAZIKや漢直にできる(逆にすればAZIKや漢直の養成に使えるかも); 起動直後はSandS有効、切り替え操作で無効化; 起動直後はegg-like-newline、切り替え操作で改行通過、等々……

　切り替え操作の記述と対応処理追加のため、定義ファイルskkrule.txtのフォーマットを以下の通り変更。
　他にも「詳細」指定を数値ではなくビット番号での指定に変更。「空欄」を廃止。こちらはさらに追って修正が入る予定。また当分の間、バージョンアップごとに設定の互換性がなくなるβテスト期間が続くかもしれない。

記述	内容
読込	外部からファイルを読み込む。(C言語で言うところの#includeのようなもの)
新規	複数の定義を記述する際、この記述地点を区切りとして解釈する。

!通常	一番目の定義を使用する。
!特殊	二番目の定義を使用する。
!超特	三番目の定義を使用する。
!激特	四番目の定義を使用する。

　これらのコマンドの設定サンプルとして全部入り設定skkrule_multi.txtを作成。カレントディレクトリに各種定義ファイルをダウンロードしておいて、

	rule skkrule_multi.txt

　と実行することで適用可能。

　ちなみに、当初の構想では#include的な実装スタイルを使わず、テキストエディタやcopyコマンドなど(GUI処理ってのは禁句な)(笑)で定義ファイルや辞書を切り貼りして使うことを想定していた。歴代の各種skkrule.txtの末尾1行が、どれも必ず空行になっていたのは、バイナリレベルでの結合時に結合場所を目視で判別しやすくするため、みたいなことを考えてたような気がするが――いや、もう時代は変わったのだ。明日は明日の風がﾊﾞﾋﾞｭｰﾝ！なのだ。SKKは風まかせ。

　なお今回の機能追加に伴い、ごっそりファイルサイズが増えそう……だったんだけど、~~中の人~~小人さんが「不完全燃焼なんだろ？」とか呟きながらスキマを埋めてくれた。

2013.02.25

日本語入力 (サイズ縮小)

　前回の機能追加によってx64版のサイズがまた増えてしまった。あ、でもなんか根性で取り戻せそう。
　ということでx64版のサイズを0.5KB削減。

2013.03.02

インストーラ (安定性向上)

　外部要因によってシステムファイルが消滅した場合にも安定して動作するよう改良。具体的には、インストールしたファイルを外部から強制的に削除されるタイプの攻撃を受けた場合に、タイミングによってはインストーラが停止してしまう可能性がある問題を修正。システムファイルが損傷して実行できなかった場合のエラー表示を追加。こんな考慮まで必要だなんて、やはりWindowsは修羅の国。OSはまさに世紀末。

2013.03.03

日本語入力 (サイズ縮小)

　x64版のサイズを32バイト削減。
　32ビット版のサイズがもう何をやっても縮まない。もはやこれまでか。覚悟を……決めろ……！

2013.03.04

日本語入力 (サイズ縮小)

　32/64ビット版ともにさらに16バイト削減。
　候補選択時の無駄な判定処理を削って動作クロックとプログラムサイズを僅かに削減。例によって人類に知覚できないレベル。
　β0+5i最終版になるといいな(……と壮大な失敗フラグを立てておく)

2013.03.05

日本語入力 (サイズ縮小)

　最終版になると言ったな。あれは嘘だ。
　32ビット版を16バイト削減。全然……足りない……ッ！
　(確かこの版は未公開のはず)

β0+6i版公開

2013.03.14

SKK職人の朝は早い――

「まぁ好きではじめた趣味ですから」

まず、シフトキーの入念なチェックから始まる。

「毎日毎日ユーザ辞書の順序が違う」

「やっぱねえ、シフトキーだからこその弾力(？)ってあるんです。

機械学習がいくら進化したってコレだけは真似できないんですよ」

「指先が音速突破しても失速しないように前進翼の形に手を添えるんです」

シフトキーの材質を変えると学習効率が変わるのはSKK界では常識という。

「キーボードは静電容量無接点方式が最高ですよ」

いつもOpenlabから専用線で我が家まで辞書を引っ張り込むと笑う職人。

ここ数年は、安直な米国ブランドに押されていると言う。

「私は続けますよ」「私はSKKを続けるよ」

改造SKKの灯火は弱い。だが、まだ蠢いている。

今日も彼は、日が昇るよりも早く積みゲタワーの整形を始めた

明日も、明後日もその姿は変わらないだろう

そう、SKK職人の朝は早い

β0+6i版公開

　第四世代補完エンジン搭載。送りがなの予測変換と補完入力を実装。予測検索空間の最適化による計算量削減(平均1/3)。
　送りがな情報を発見できなかった時などに、送りがな情報のないユーザ辞書エントリの追加と削除の操作に対応。
　変換状況の色強調や予測変換などの工夫がことごとく酷評され、人々からウザいキモいと言われ続けて幾星霜。それでもあえてこの機能を絶対にデフォルトから外さない(設定すれば外せるけど99%の人が使う初期設定に含めている)理由はただ一つ。それは予測という動作の可能性を信じているから。今回の補完でもその姿勢は微塵も変わらない。ちえっ、またSKKFEPか。まいったねどうも。どうせ利用者は数人程度しかいない、どマイナー路線まっしぐらなプログラムだし、いいんだ、もうとことん好きなようにやってみよう。
　今回から送りがな入力を認識した瞬間にも予測が走るようになった。意識してもほとんど違いがわからない、細かすぎて伝わらないレベルだが、ほんの僅かな時間、従来よりも早い段階で「未来が提示」されるようになった。人類の可能性に賭けろ！このほとんど無意識に近い視界の片隅で、文字の形や下線色の認識ができるようになる日が、もしかしたら来るかもしれない。いや、きっと人類なら訓練を続けていればいつの日か、数フレームの画面の輝きを永遠の時間に感じられるはず。そう、つまり……

己の反射神経の限界に挑め！

ごめん無理！

2013.03.19

日本語入力 (安定性向上)
辞書プロセス (安定性向上)
拡張モジュール (安定性向上)

　辞書プロセスとの通信(ゲート間通信)がタイムアウトした場合、以後の漢字変換が不可能となってしまう厄介なタイミング起因バグを修正。この問題はスクリプトやネットワーク処理による応答の遅れや、ありえないほどの高負荷による動作の遅れなどの要因により、極低確率で発生する可能性があった。とりあえず全部潰した。

　…と思いきや、負荷の重い時に文字を取りこぼすエンバグが発覚したので即刻公開停止の巻。20130319？そんなものは　ない

2013.03.20

日本語入力 (安定性向上)
辞書プロセス (安定性向上)
拡張モジュール (安定性向上)

　ゲートや辞書プロセスが停止や無限ループなどでスレッドがブロックされた状態に長時間陥ってしまったり、その後動作が復旧した場合などにおいて、アプリ側は一切待ち状態に入らず、かつ復旧後も即座に動作継続できるよう改良。これまでの版にあった問題全てを一撃で解決するため、プロセス間通信に関する処理を一新。従来の通信処理とまったく互換性がないため、従来版からのアップグレードや、従来版へのダウングレードを行なった場合は必ず再起動またはログオフすること。(手動でゲートと辞書プロセスとアプリを立ち上げなおせば一応動くとは思うけど自己責任な)

　従来版ではゲートが固まった場合はタイムアウトを検出して、アプリ側は処理を続行できるように作っていた。ゲートが固まるってのはありがちな話で、スクリプト開発中のバグでスレッドが長時間ブロック状態になる無限ループ(円環の理)とか、ネットワークアクセスでサーバがクソ重いとか、そういう面倒な事態がいつの日か発生するというのが世の常である。ただでさえシングルスレッドのSKKFEPが応答待ちというトラブルを受けて直線番長になって昇天してしまう胸熱の展開である。で、そうなった場合に備えて、元々の実装でもタイムアウトしたらアプリ側の操作に戻るという素直な(同期処理としてはひねくれた)設計になっている。だからこそスクリプトに処理を任せるなんていう大胆な技が使えるわけだ。しかし設計思想とか理念はよかったのかもしれないが実装がチョーテキトーすぎてまるで妄想に追いついてなかった。ﾁｸｼｮｰﾒ！ﾌﾟﾙﾝﾌﾟﾙｰﾝ！
　要するに従来はプロセス間通信の完成度が低く、ゲート(辞書プロセスや拡張スクリプト)が長時間停止した場合(変換処理等になった状態のままスレッドがブロックした状態になった場合)、アプリケーションで何か変換・補完操作の時、毎回通信タイムアウトまで待つ動作となってしまい、キー操作への応答が非常に悪くなってしまっていた。あとスレッドのブロック状態を抜けた後はアプリ側の操作は復旧するけど事実上通信途絶みたいな感じになってゲートや辞書プロセスの再起動(メンテ)が必要だったり……と、いろいろと残念な動作になっていた。
　まぁ、その、なんだ。全てはこの極小プログラムサイズで妄想を具現化するための挑戦だったわけなんだけど、傍から見たらバグってるんじゃねーのコレ状態になってしまっていた。

　違う！これはバグジャナイ！仕様なんじゃわい
　でもボクが欲しかった操作感覚はコレジャナイ！
　それなら直せばインジャナイ？互換性なんて窓から投げ捨てろ！

2013.04.11

くぅ～俺(SKKFEP)の幼馴染(辞書プロセス)と委員長(拡張スクリプト)の二人が修羅場すぎると思ったらいつの間にか社畜2.0だったオレオレ、オレだよ俺、って何で俺君が？

日本語入力 (機能追加)
辞書プロセス (機能追加)
拡張モジュール (機能追加)

　新番組ふたりはSKKGate2.0「やめて！私にも接続するつもりでしょう？辞書プロセスみたいに」
　従来、SKKGate拡張スクリプトを有効化するためには、初回のみ1回だけ辞書プロセスの設定を変えてプロセスを再起動させる必要があった。これはフロントエンド側(TSF/TIP)が、自身の接続相手となるバックエンド側(辞書プロセス)の接続口を1つだけしか想定していなかったことが原因だった。結果、接続先を辞書プロセスから拡張スクリプトに変更するためにヒミツの儀式が必要だった。要するに嫁は二次元であろうが一人のみ。脳内ゲームは一日一時間。
　しかし今回、フロントエンド側から複数のバックエンド(辞書プロセスや拡張スクリプト)に自動接続する機能を追加しちゃった。
　常に接続先を複数持ち、先に生存確認できた側に接続する、究極の肉食系通信機能を搭載。なんと奇遇な！
　つまり~~アドルはスケコマシ~~嫁が二人いても大丈夫。※ただしイケメンに限る

　というわけで、再起動なしで拡張スクリプトのプロセスを任意のタイミングで起動・終了させた場合においても、アプリや辞書プロセス側の設定を一切変更することなく動作を継続できるようになった。これでようやくSKKGate拡張スクリプトを本体に取り込むための準備が整ったことになる。あとはインストーラを直すだけ。オマエ(SKKGate)ヲ同化スル。抵抗ハ無意味ダ。…ってな感じでできるんじゃないかな～と思うんだけど(願望)今ちょっと社畜2.0なのですぐに直せませんごめん無理！ドキュメントも一部直さなきゃいけないけどごめん無理！気合いで憶測！大丈夫！

　例によって従来版からのアップグレードを行なった場合は必ず再起動またはログオフすること。

日本語入力 (安定性向上)

　数字や一部の記号など、テキスト入力プロセッサ側で一切加工せずにアプリ側に直接渡す文字で暗黙の確定を行なった際、ローマ字かな変換の状態遷移が初期化されてしまう(細かすぎて伝わらないレベルの)バグを修正。いつもながら、いろんなバグを見つけた方々の注意力と着眼点は本当に凄いわ……SKKFEPは初期の頃から優秀なテスターの方々に恵まれててほんと感謝感激でござるよ。
　上記暗黙の確定ルートを通過後、確定アンドゥを行なった際に物理アンドゥの文字数の計算を間違えるバグも連動して修正。

2013.04.12

メシ食ってる場合じゃねえっ！

日本語入力 (安定性向上)

　新生FF14ちゃんに仮対応。ちょっとミコッテｓとマンティコア狩ってくる！

2013.04.20

日本語入力 (機能追加)

　雪花関連の動作を見直し。英字認識中のTAB補完の際、単語が一致していたら次の語を即座に出すよう改良。

インストーラ (安定性向上)

　アーカイブ構成を変更しヘッダサイズを僅かに縮小。
　過去の一部の版からのアップデートの際、まれに辞書プロセスの更新に失敗してインストーラが停止するバグを修正。

2013.06.29

日本語入力 (安定性向上)

　社畜ライフで忙しくてイフリートもケルサイクもモフモフできぬ！なぜだ！というわけで、新生FF14ちゃんにさらに仮対応。IME回りの作りがおかしくてダイレクトモードからの初回キー操作時にキーリピートのイベントが異常発生してSandSが誤動作するとか散々な作りだったがTSF側からできる対策は全部やった。これ以上の動作はアプリ側が対応してくれないと我々の魔法力ではどうにもならん……(MSのDirectXサンプルの通りに日本語入力回りを実装しているゲームなら20130411版で何ら問題なく動くはず)。TABキー操作を常に奪い取るバグとか候補選択のバグとか、いくらなんでも製品版までにきちんとMSのTSFのガイドラインに対応してくれないと、このままではお話にならないレベルだと思うんだけどﾍｪｰﾗﾛﾛｫｰﾙﾉｫｰﾉﾅｰｧｵｵｫｰ
　製品版できっちり問題が改善したら、この対策のためだけに入れてある腐った処理は全部バッサリ切り捨てたいのでお願いします術士様。
　日本語入力状態でCTRL+Lを一回だけ英字モードへの変更として判定するようデフォルト操作を大胆に変更。繰り返す。デフォルト操作を変更。これは訓練ではない。旧バージョンの動作に戻すには定義ファイルの「設定追加」の値を0にすること。もっ先を目指したい場合は2にすること。

2013.07.09

日本語入力 (機能追加)
辞書プロセス (機能追加)

　学習記録属性を追加。単語登録(および注釈変更操作)の際に拡張スクリプト側で判定可能にした。一応プロトコルは後方互換(上位互換)なので再起動なしでも動くはずだし、古い拡張スクリプトもそのまま動くはずなんだけど、念のため再起動推奨。
　これにより、「単語学習した時だけログファイルに記録する」といった機能が実現可能となる。
　拡張スクリプト側では学習記録はデフォルトでオフとなっているため、実質的な動作の変更はなし。(拡張スクリプトの導入後、skkgate.iniの変数loggerの値を1にしておくことで、拡張スクリプトと同じ場所にskklog.txtというファイルが記録されるようになる)
　自分がSKKをどのように利用しているのか、後から確認できるようにしておこうと思って拡張スクリプト側に機能を追加してみた。これでいつどんな傾向の単語を登録したか、あとから確認することができるようになるはずだ。要するに……こういうことだ。

SKKFEP「覚えるの！？これ、覚えるの！？ねぇ！単語！単語登録する！？」

ユーザ「あぁ、登録だよ」

SKKFEP「本当！？大丈夫なの！？また2ちゃんねるとかネトゲの用語じゃない！？」

ユーザ「(ぎくぅ)あ、あぁ、一般名詞だから大丈夫だよ。呼ばれてるから急いでね」

SKKFEP「そうかぁ！ボクSKKだから！単純だから単語の傾向とかわかんないから！」

ユーザ「そうだね。わからないね」

SKKFEP「うん！でも名詞なんだ！そうなんだぁ！じゃぁ新規登録していいんだよね！」

ユーザ「そうだよ。登録していいんだよ」

SKKFEP「よかったぁ！じゃぁ登録しようね！新規登録しよう！」

ユーザ「うん、登録しようね」

SKKFEP「あぁ！一般名詞だからOpenlabにどんどん登録できるね！ね、ご主人様！」

ユーザ「うん。処理を続けてていいよ(……パーティ解散したらログ確認しとこう)」

SKKFEP「あぁーご主人様とボクは今単語を登録しているよー！日本語に気をつけようねぇー！」

選択肢

[A. このままゲームを続ける]

[B. Openlabの真実を告げる]

2013.07.10

日本語入力 (機能追加)

　ここ半年ほど自分の入力エラーを観察していたのだが、「あん」「てん」「しん」などのような『2文字の単語で「ん」で終わるもの』を入力しようとしている時、変換失敗してしまうケースが多発していることに気づいた。
　20120224版で実装した送りがな入力中のロックで、SKK10(や後継のDDSKKなど)と同程度の操作感覚を実現していたわけだが、今回はこの機能をさらに改良し、「ん」などのようなローマ字変換ルールの途中にある文字を変換する場合は人間の意図を汲んで通常の単語変換として扱うように改良した。
　この原因は「細かなシフトキー操作が必要な場面でキーを押しっぱなしにしてしまうことがある」という人間側のオペレーションミスではあるのだが、これはSKK側で改良できる・解決すべき案件であると判断。SKK10やその派生とはまたもや違う道を進むことになるが、従来のSKK本来の操作性を阻害しないはずであり、こちらのほうが絶対に使いやすいはずなんだ！という信念の元、デフォルト操作をまたもや変更。実はフラグ判定処理を1箇所入れただけで解決できちゃうことに気づいただけってのは内緒だ。
　なお他にも、類似のケースでは「安寧」を「編んねい」等としてしまう入力エラーもあるが、こちらは変換を押して物理アンドゥ(いわゆる確定アンドゥ)すれば簡単に解決できる。この機能は超絶苦労して実装した割に使いづらいとか文句しか聞いたことがないのでどうせ誰も使ってないだろうけど、それがどうした！自分が信じたSKKを信じろ！

2013.07.24

拡張モジュール (安定性向上)

　ごく稀に拡張スクリプトが異常終了してしまうエンバグ(20130411版で発生)を修正。
　これ、ずっと気になってたんだけどなかなか再現しなくて困ってたんだよね……。というわけで今回、ちょっと気合いを入れてデバッグしてみたのだが……サイズを削りまくっていた時になんと初期化処理の一部をごっそり削っちゃってた……なーんてあまりにも単純な間違いだったなんて恥ずかしくて言えないナリィ……

2013.08.04

そうだ

これは夢なんだ

ぼくは今、夢を見ているんだ

目が覚めたとき、

ぼくはまだ中学二年

SKKどころかパソコンすら縁のない学園都市で、

休み時間にスマホの画面をフリックしてフレとチャットして、

放課後はSレアとお宝画像を探しておもいっきり遊ぶんだ・・・

(回想中)
レア返せよ～～ (さわさわ)

アハハ～～ (さわさわ)

などと幸せを噛み締めていたら、なんか違和感が……
あれ？……このスマホ……

シ　フ　ト　キ　ー　が　つ　い　て　る　よ

SKK10「ズッ友だょ……！！逃がさない逃ガサナイ」

ギャァァァァァァァァ

　(ガバッ)……ハァ……ハァ……
　どうやらEmacs20を起動したまま寝落ちしていたようだ……_※

日本語入力 (サイズ縮小)
辞書プロセス (サイズ縮小)
拡張モジュール (サイズ縮小)

　……などと学園×いちゃいちゃ×SKKデレ要素ゴリ押しのあげくに夢オチぶん投げといて何ですが特に機能追加はありません。てかコードレベルでは変更なし。最新のバイナリ変換ツールの先行試作テストベッドとしてなんたらかんたら(ry
　辞書プロセスの0.5KBサイズ縮小に成功。
　32ビット版DLLはあと64バイトのところまで漕ぎ付けた。
　64ビット版DLLの0.5KBサイズ縮小に成功。

※ちなみに、SKKFEPの99%のコードはEmacs20上で書いてます。

2013.08.05

その他 (安定性向上)

　標準設定/AZIK/ACT/T-Codeの定義ミスを修正。
　CTRL+Lで暗黙の確定操作をした際に入力モードが変わらない問題を修正。
　AZIK/ACTでの切替抑制の動作を改良しデフォ有効化。矢印の追加やひらがなキー設定など、標準設定の更新に追従。
　ルール設定を変更して使っていた場合は再設定および再起動が必要です。

2013.08.07

設定補助 (機能追加)

　重複するルールの記述でエラー停止せず無視して処理を続行するよう改良。今まで、解析失敗で停止する場面の99%がルール重複が原因だったりした気がするので~~定義ファイルを毎回直すのが面倒だよパトラッシュ~~んうぅ～ユーザの利便性を向上！(ｷﾘｯ
　同一定義判定の処理をサクっと削ったのでプログラムの内部サイズも短縮だァ！
　なお、同一の定義が複数存在する場合、最初に定義したものだけが有効となり、後から定義したものは無視される模様。
　この性質を逆手に取って重複回避判定の条件の記述を微妙に省略する、なんてテクニックが使えるようになる反面、適当なコピペで寄せ集めたローマ字定義なんかで同じ内容が大量に含まれていても(重複による情報量の無駄遣いが検出できないので)ずっと放置されたままになってしまう、なんて局面もあるかもしれない。定義ファイルの品質には各自注意されたし。おまゆ。

その他

　標準設定/AZIK/ACT/T-Codeの記述を見直し。

読点と句点に半角文字の選択を追加
感嘆符と疑問符を半角にする選択を追加

日本語の句読点や感嘆符・疑問符などを半角で書くスタイルもあると聞いたので、簡単に設定できるようにしておいた。

記号を全角文字化する設定の際、数字キーで暗黙の確定を行うと半角で数字が出る問題を修正
使用頻度の低そうな項目(全角セミコロンと全角コロンの選択と特殊中断)を削除。

ちなみに全角コロンとかを使いたい場合、定義ファイルの末尾に「\: ：」みたいなルールを追加すればよい。もともとこの定義ファイルは、どのご家庭にもある一般的なローマ字かな変換定義ファイルにちょっびっと毛が生えただけ先っちょだけですしおすし。

新しい設定補助ツールの仕様に合わせて記述を簡略化して256バイト程度短縮

　前回の修正などもあるので、なるべく新しい定義ファイルへの乗り換えを推奨。昔の定義をベースに弄って使っている場合、古い定義ファイルのままでもまだ当分は使える。別に不便に感じていないならそのまま放置でも問題なし。

　標準設定のまま普通に使っている場合、今回の更新は一切関係ありません。そもそもコンフィグの存在自体がおまけ機能(ｷﾘｯ GUI？あばばばばばばばばば
　デフォ設定自体にまったく変化がないため、日本語入力プログラム側は一切変更なし。
　設定など笑止！99%の利用者は初期設定を使うのだからデフォ仕様を死ぬ気で厳選せよ！との師匠の教えを守るべく、もう標準設定は余計なことを思いついた時ぐらいしか変えないはず。……この前思いつきで変えたばかりのような気がするのは、たぶん、きっと、気のせいだYoﾁｪｹﾞﾗ

2013.08.10

パトラッシュ、ボクは見たんだよ。

一番見たかった、SKKの小さなバイナリを。

だから、だからボクは今すご～く幸せなんだよ……

日本語入力 (サイズ縮小)
辞書プロセス (サイズ縮小)
拡張モジュール (サイズ縮小)
設定補助 (サイズ縮小)

　32ビット版モジュールを0.5KB縮小し33KBに戻した。くぅ～
　64ビット版拡張モジュールを0.5KB縮小。
　辞書プロセスおよび設定補助の内部サイズを縮小。
　このサイズのバイナリが見られるのは、冗談抜きでこれが最後になるかもしれない。
　32ビット版がもうどこを弄ってもサイズが増えるワカメ状態で最後の16バイトの壁が本当にきつかった……

　パトラッシュ、疲れただろう。僕も疲れたんだ……
　なんだかとても眠いんだ。パトラッ……シュゥゥ……　修　造　！　できるできる絶対できる頑張れもっとやれるってやれる気持ちの問題だよ(ry

　ってな感じで、次の版かその次の版では、通信フォーマットがまたしても思いっきり変わっていろいろ詰め込まれてしまい、またサイズが増えてしまいそうな予感。
　機能追加なんてなかった。こまけぇこたぁいいんだよ！(AA略

インストーラ (安定性向上)

　音声回りを改良。nLiteを使ってインデックスサービス類を削除してセットアップしたWindows XPにSpeech Platformをインストールして中途半端に機能が有効になっている(かなり特殊な)環境において、音声を有効化すると動作が停止してしまう問題を修正。

2013.08.11

インストーラ (サイズ縮小)

　コードの見直しと謎のハッタリテクノロジーで5.5キロバイトほどサイズを縮小。

2013.08.12

インストーラ (機能追加)

　起動直後に最新状態かどうかを表示する機能を追加しつつハッタリ技術向上でサイズを微妙に縮小。
　砂糖と塩を間違えるレベルで最新状態チェックに失敗するバグを修正。(20130812a)

2013.08.21

深刻化する若者のSKK10離れ

限界集落と化したSKKFEPが選択する少子化対策(最後の幻想)とは――

「エディタ戦争は終わった。SKKは変わった。SKKイコールEmacsという図式はもはや近代国家には存在しない」

「そもそもSKKの最終バージョンであるSKK10(聖櫃)を動作させることができるEmacs20など、もはや誰も動態保存しておらん」

「そんな……宇宙の起源はEmacsだったんじゃないんですか？cat > filename？うっ頭が……」

「ランセルノプト放射光……？！」

「メモ帳並みの超高速起動が手軽にできた最後のEmacsが……星が……失われてしまった……」

「復元せよ」

「ネジ余っちゃいましたァー！」

日本語入力 (機能追加)(サイズ縮小)

　SKK10の入力モード表示(カーソル色で入力モードを示す)を模擬した魅惑の新機能『疑似カーソル』を実装。
　御託はいい。とにかく画面を見てくれ。こいつをどう思う？

すごく……SKKです……

SKK10での入力

SKKFEPでの入力

　通常のひらがな入力中、ユーザの注視点付近に見える色がほぼ同等になったので、Emacsとそれ以外の文字入力の時の感覚をだいぶ揃えることができるんじゃないか、という期待から実装してみた。もともとSKKFEPのデフォルトカラーパレットはSKK10のカーソル色の再現を夢見て決めたんじゃよ……。(遠い目)

　しかし、現時点ではカーソル表示に関して全てが完璧に再現できているわけではない。アプリ側にキーを渡すべき場面(アプリ側のカーソル移動とか、コントロールコード入力などの場面)では、疑似カーソルをいったん消さないといけないのだ。
　だから同一行で日本語入力を続けている時だけカーソル表示が有効って感じで動作するのが精一杯。許せ。

　それにしても、SKK10やその直系であるDDSKKのなんと優雅なことか。まさに、「立てば芍薬、座れば牡丹、歩く姿は百合の花」を体現した感じである。
　SKKFEPもあの御方に少しでも近づきたい！日本語入力の女子力を上げたい！「女子力たったの5？」とか言われて毎度ゴミ扱いされないようにしたい！太正桜に浪漫の嵐！
　誰か入力言語を萌え擬人化したIMこれくしょんゲーム化画像はよ

……なーんて、可愛い入力メソッドだと思った？

　残念、SKKFEPちゃんでした。疑似カーソルによるモード表示なんてのは、ただのカモフラージュなのさ。本当の目的は常にコンポジションが存在することによる「真の予測変換」の実装の可能性を見極めることにある。今の世代のSKKFEPでは達成できないかもしれないけど、この機能を突き詰めていくことで、SKKの動的補完と同じレベルで通常入力操作をも支援できる拡張プラグイン的な何かをいつか実現できると信じて……(打ち切り)

　ちなみにこの疑似カーソル機能、最初はデフォではオフにしとこうかな……と思ってたんだけど……。だってこんなことしたら、どうせ他のプログラムとの相性問題が強烈に発生するだろうし……。でも実際に1週間くらい使ってたら慣れてきた。戻れない体になってきた。んんっ？ネトゲとかの自動判定と組み合わせて操作が吸いとられる系の問題を避けるようにしてみたら意外とどこでも動くっぽいゾ。あと、自分で使いもしない機能を実装して死蔵するつもりは毛頭ないし……いいぜ？もうゴールしよ？とりあえずデフォ有効でいいカナ？カナ？
　というわけでデフォ有効にしたった。ｱﾊｰﾝ

　しばらく使ってみて、このまま残すか消すかをあとで考えることにする。未来に託して先延ばし！
　なお、従来と同じ見た目にする(設定でカーソル表示をオフにする)ことも可能。rule p0と設定すべし。また元に戻して有効化するにはrule pdと設定すること。

　その他の機能追加・修正について。
　この版では表示系以外もかなりの範囲で変更が加わっている。以下抜粋。

C++/CLI系アプリケーションの自動判定(SandS入力シーケンスなどの不正な入力を自動回避)

　以前はフリーソフトのKrile等のアプリでは正常にSandSが動作しないため、アプリ個別設定が必要だったが今後はそのようなことはなくなる。古い個別設定は残ったままでも問題ない。放置でOK。もし消しておきたい場合はrule krile.exe sdで完全消去可能。
　これに加えて、Windows8以降のストアアプリでも疑似カーソル、確定時の改行通過、物理アンドゥの操作が有効になった。正直、ストアアプリを使う機会がほとんどないので、問題があればガンガン報告してもらえると助かる鴨！

ネットゲームなどのUIレスモード判定機能の強化
整合性レベルLowのプロセスの判定を簡略化
メモリ確保処理の最適化

　ヒープの断片化(アプリのメモリ消費量増加)を理論上最小限に改良。どうせ微々たるもんなので人間が知覚できるレベルではないシリーズがまた1つ増えただけ的な。

内部処理の再設計と簡略化によるコードサイズ短縮

　前回のバージョンと同じ機能だけなら200バイト近く縮んでいる。上記の機能追加をすべて含めてもx64側のサイズ0.5KB縮小が実現できている。

　なお、この版は次期β0+7iの開発途中の試作版を元に作りなおした安定版候補となっている。次期バージョンでは表示系の改造に加え、匿名化プロセス判定、ダイナミック辞書切り替え、それを支える辞書プロセスと拡張モジュールやプロセス間通信フォーマットの大改造、などを予定している。でもこれは実現するまでに相当に長い時間がかかりそう！すでのな。どうせ壮大な永遠のベータテスト(自称)なので、現状でまともに動作する部分はガンガン先行投入していく。特に、表示系をこのまま続投するべきか、アプリとの相性などといった部分については、長期間使ってみないと何とも判断がつかないので、どんどん修正を入れていくかも。飽きた寝る。
　この改造が終わったら、故郷に帰って次世代バージョンにGUIを載せて、SKKFEPもWikipedia♺に……うっ頭が……

2013.08.22

日本語入力 (安定性向上)

　疑似カーソルをオフに設定しても消去が不完全だったバグを修正。
　疑似カーソルをオンにしても疑似カーソルが出現しないエンバグ(20130822版で発生)を修正。(20130822b)

2013.08.23

日本語入力 (サイズ縮小)

　疑似カーソルまわりの状態遷移を簡略化。だいぶ小さくなった。
　暗黙の確定と入力モード変更を同時に行なった時、入力内容が消えるエンバグ(20130821版で発生)を修正。

2013.08.24

日本語入力 (安定性向上)

　疑似カーソル処理と暗黙の確定が同時に作用すると入力内容が消える、操作性をかなり低下させるバグを修正。

その他 (安定性向上)

　コロン・セミコロンの全角入力設定を復元。
　AZIK/ACTで全角英数モードから半角英数モードに切り替えられるよう改良。

2013.08.25

日本語入力 (機能追加)

　SandSを標準設定から外し無効化した。またか！またヤツ(SKKFEP)が何かやらかしたか！てな感じでデフォ設定を変更。繰り返す。デフォ設定を変更。
　いろいろ考えてみたけど端的に言うなら「まだSandSを標準採用する時期じゃない。明日から本気出す」といったところ。SandSを即有効にしてしまうと混乱を招く悪影響のほうが大きいのではないかと考え直した。こう考えるに至った理由はいくつかある。

SandSが有効だと、スペースの入力はキー押下時ではなくキーを離した時になる。これが、SandSの存在を意識せずに導入したユーザから見ると「なんか重い」「反応が悪い」と感じられてしまう恐れがある。これまでネットで見かけた不評の原因は恐らくSandSが根底にあったのではないかということに気づいた。
つまりSandSは存在を強烈に意識した上で使わないといけない。きちんと説明を重ねた上で有効化するという導入手順が必要。そうでない限り「普通に操作したはずなのに誤動作しているように感じる」「単に反応速度が遅くなっただけ、プログラムの作りが悪いように感じる」と誤解されてしまう可能性がある。こりゃとんでもない濡れ衣ですぜ。それでも僕はやってない。
SandSを積極的に使っていくタイプの利用者は、一般のPC全体ではまだ1パーセントにも満たないと考える。SKKFEPの利用者は(今まで強制的に機能オンだったこともあって)それに比べると圧倒的に使ってくれていた方々は多いと考える。今までのTwitterの反応などから、SKKFEPのβテスターの方だとたぶん全体の半分くらいがSandSの存在を意識してくれていたんじゃないかと推測している。これは本当に凄いことだ。しかし今後は、SandSの存在を意識する以前に、まずSKKへの入門を志した利用者が増えてくるのではないか。そこにいきなりSandSの洗礼を浴びせるのは、入門の道を閉ざしてしまうことになってしまいかねない。SKKの普及という一番大事な観点が欠けているのではないか。
今までSandSを利用していたほどの利用者なら、インストーラでボタンを押してコマンドを初回に1回実行するくらいの対応なら難なくこなしてくれるはず。設定はレジストリに保存されるので、一度やっておけばOSを入れ替えるまで再設定は不要。よって負担も最小限となるはず。というかそもそもルール定義を自分で弄っちゃうくらいのレベルの皆なら、デフォ設定なんてまったく関係ない。大丈夫だ。問題ない。
反応速度を少しでも高めたい人は、そもそもSandSを使わないのではないか。「Skill Level: Japanese」のテトリス使い♺並みのSKK使いが将来出てくるとしたら、その人たちにとってSandSは逆に足枷になるかもしれない。

　SandSをデフォルトオンにするメリットと、デフォルトオンで誤解されるデメリット、デフォルトオフにした際の設定変更のための初回設定の負担など総合すると、やはりデフォルト設定はオフにしておくべきとの結論になった。

　……などと延々と書いたけど単にバイナリを1バイト変更しただけだったり。でもね、デフォ設定には命かけろってばっちゃが言ってた。
　きっとこの更新記録を確認してくれるほどのSKKFEPの使い手の方々なら、インストーラで[コマンド]ボタンを押してrule s7と実行すれば今までと何も変わらずSandSが使えるし、設定ファイルでSandSが有効な状態で既に設定済なら何も変更しなくていい、な～んてことぐらい、ここにいちいち書かなくたって気合いで推測して使いこなしてくれるはず！
　あと、設定ツールにバグがあったんで直した。w値1 値2 値3とwの後に空白なしで書いた時値1が無視されてしまうバグを修正。ついでに順序をウィンドウ幅不透明度反発力の順序に変えといた。

　以下余談。
　某ネトゲのチャット回りの実装に絶望した、とある漁師(元■信者)の軌跡

新生FF14魔界DQ10塔士SKKa・GaラグーンT: そうさ……俺は……; SKKFEP……。; ……醒めちまったこの街に……; ……熱いのは………俺たちのTYPING……

かみ「やっとうごきましたね。おめでとう！

　　　このIMEはいじょゲームをまけぬいたのはきみたちがはじめてです

ぼく「ゲーム？てかうごかないんだけど？

かみ「スクエニしゃがつくったそうだいなストーリーのゲームです！

ぼく「どういうことだ？

かみ「わたしはおかねのかかるゲームかいはつにあきあきしていました。

　　　そこでIMEたいおうをせずにこうほひょうじバグやもじしょうめつバグをうみだしたのです

ぼく「なにかんがえてんだ！

かみ「バグはせかいをみだしおもしろくしてくれました。

　　　だがそれもつかのまのこと 4かげつまえのようぼうにもたいくつしてきました

ぼく「そこでたいおうをにおわせてほうちプレイ‥‥か？

かみ「そう！そのとうり！！

　　　きほんてきなバランスちょうせいがさいゆうせんです

ぼく「なにもかもあんたがかいたすじがきだったわけだ βとはなんだったのか

かみ「もうじかんがありませんしようです IMEたいおうなどなんのかちもない

ぼく「そんなりふじんなことだれが‥‥

騎士「家畜(I M E)に神はいないッ！！

女剣士「！！！！

ぼくはばらばらになった

　FF14のTSF対応はもうなんというか絶望しかない感じ。TSFオンリーでコンパクトな処理のレガシー版SKKFEPをメインストリームにするという理想への道は断たれた。だが諦めねーよ。ところで婆さんや、採掘のギルマスが踊り子時代に「しょうがないにゃあ」とか言ってる画像はまだかね？

2013.08.28

＼バグだー！／

2013.08.29

日本語入力 (機能追加)

　プロセスの状態によってかな入力が正常に行えない(限りなくバグっぽい)仕様を修正。かな入力時の挙動を大幅に変更。

　ここ半年分くらいの入力関連の改良で、「かな入力」の存在をまるっと忘れてた。よって関連するデバッグを全然やってなかった。かな入力機能って、物理アンドゥ技術のハッタリ応用って感じで適当に作った気がするんだけど、疑似カーソルとかSandSキー入力シーケンスエラー攻撃対策とかで増やした状態遷移ではこのへんをまるで考慮してなかった。考慮漏れバグ祭り開催の予感。っべー直さなきゃ。
　そもそも物理アンドゥは万能ではないのでこの機能には一切頼らずにかな入力を実装しないといけない。
　でもそうなると実装が大変だしちょっと歪な感じになってしまう恐れがある。例えば「あ行」は即座に入力できるけど「か行」は濁点・半濁点受け付けのための入力待機状態になる、みたいな操作系を導入しないといけなくなる。こういうのはなるべくやりたくない。
　もう面倒だからいっそのこと、かな入力回りは全面削除――とも思ったのだが、しかしいきなり機能削除ってのは安直すぎて面白くない。かといって局所的にしか動かない物理アンドゥ方式を無理矢理直して、動かないのは仕様と言いはりながら今後メンテし続けるなんてのはもうマジ無理。どうする？どうすんのSKKFEP？

ぼくP「人間辞めますか、それともSKK(アイドル)辞めますか――」

SKKFEPちゃん「私、SKKやめますｗ」

ぼくP「おやおやー？そこは血の涙を流してでもSKKへの執着を見せて歌い続けるところでしょう？」

SKKFEPちゃん「やめますｗｗｗｗｗ」

ぼくP「あっるぇぇぇェェェ？ナンデ？SKKナンデ？」

　というわけで、かな入力に関してはSKKの操作方式を辞めちゃった。かな入力を検出したらSKK的な即座のひらがな出力動作を行わず、一般的な日本語入力ソフトのように変換操作の開始を行う。これにより、物理アンドゥに頼らずにかな入力を安定して行えるようにした。これは過去の失敗作ネトゲモードと、2ちゃんねる向けに作ったトリガーハッピーモードの応用で実現している。
　ゴチャゴチャと書いたが要するに、インスコ直後のデフォ設定のままでもかな入力で簡単な漢字入力ができるようになった、というのが大きなポイントでござる。
　かな入力で暗黙の確定を行なった時に文字が確定してしまうバグを修正。(20130829a)

　この機能変更に関連して、かな入力時の送りがな変換操作に関するテーブルの位置を、プログラム内から定義ファイル設定(レジストリ)側にごっそり移動し、プログラムサイズを削減。かな入力で送りがな変換を行う設定を使いたい場合(定義ファイルでかな入力を1にする場合)はruleコマンドで定義ファイルを設定しなおし、レジストリの再設定が必要となっているので注意されたし。定義ファイルの内容自体はそのままなので、かな入力を普段使わない利用者の場合は今回の更新は関係なし。そのまま放置で。

2013.09.01

　AZIK設定サンプルにローマ時互換の促音入力を許容するEnhanced AZIK略してEZIKモード(簡易=1)を追加。

2013.09.03

　AZIK接点サンプルで、DDSKK互換操作に設定した際、拗音の補完の一部が動作しないバグを修正。標準設定には問題なし。

2013.09.08

　SKKFEP、ついにバージョンダウン――

「でもSKKFEPは役に立ったんですよね？また何か適当な、思いつきででっち上げた機能じゃなくて、この実装はMSやGへの反撃の糧になったんですよね！」

「もちろん……いや……今回の実装で我々は、

　いや、今回も……くっ……

何の成果も得られませんでしたぁぁッ！！

　私が無能なばかりに、ただいたずらにバイナリを肥大させ、デフォ機能に昇華させることが、できませんでしたぁぁ！！」

進撃の巨IME 最終回「IDE発動」

日本語入力 (安定性向上)

　疑似カーソル機能をデフォ無効化。疑似カーソルを再度有効化したい場合、rule p2と設定してください。
　設定ツールのpオプション関連の設定をGUI化した時、直交性が高くなるよう変更。各ビットが設定のON/OFFになる予定(ビット0:▽マークビット1:疑似カーソルビット2:最小構成)。従来のrule p2はrule p4に変更となったので注意。

　だめだった。疑似カーソルを有効にしていると、ブラウザ・オフィス系アプリと強烈に相性が悪いことが発覚。例えば範囲選択中にCTRL+Jとかやってみるとわかる。これはアカン。
　正直、アプリ側の実装がどう考えてもおかしい。OS標準のコンポジションであれば、IMEからアプリに文字を渡すまでは選択範囲はしっかりと残ってくれるのに、この手の自前コンポジション処理を備えた高貴なアプリは、どういうわけかコンポジションが1文字でも書き変わると選択範囲が空になってしまう。……これが……世界の選択でちゅか……。奴らがこれを標準仕様だと言うのだから仕方ない。クソオフィスが！みんな星になってしまえ！
　というわけで「現時点では」疑似カーソルを無効化する以外に対策はない。現時点では。

　レジストリにプロセス別設定をきっちりと書き分けて切り抜ける、という手もあるのだが、標準インストール程度でレジストリを汚したくない。ある程度設定がわかる人が、このあたりも自力で切り抜けてくれることに期待するしかない。
　大多数のユーザは設定を変えずに使うものと想定される。だから、これは最善の選択となるはずなんだ。機能をバージョンダウンして疑似カーソル機能はデフォ無効にしよう。無念なり。

おまけ: 疑似カーソルを有効化する場合の設定例 (上級者向け)

	rule p2		(全てわかった上で使うのであればこの行だけでよし)
	rule firefox.exe p4
	rule excel.exe p0
	rule outlook.exe p0
	rule winword.exe p0
	rule powerpnt.exe p0

低速なマシンの場合は、p0の部分をp4にしてコンポジションの書き換え量を最小限にすると、MS-Officeの無駄な描画アニメーションが少なくなって少し反応速度が上がるかも。

2013.09.11

インストーラ (安定性向上)

　アンインストールを選択して管理者権限を取得した場合、ヘルプ表示が出てしまいアンインストールが行なわれないエンバグ(20130812版で発生)を修正。

2013.09.12

日本語入力 (安定性向上)

　動的補完をオフに設定したのに反映されないエンバグ(20130821版で発生)を修正。

2013.09.18

日本語入力 (サイズ縮小)

　編集関連の処理を見直して50バイト程度サイズを縮小。バッファの縁まで使って編集時の最大文字数を1文字増加。
　これで書庫が70バイト程度縮むってのは、相当すごいことなんよ……。ZIP書庫のサイズがでかいと言われて、少しでも削るためにヘッダ改良とかファイル名変更とか構造見直しとかの工夫を長いことやってたけど、もうこれ以上はマジ限界っ……！

2013.09.19

日本語入力 (サイズ縮小)

　書庫をさらに12バイト縮小っ……！

2013.09.21

日本語入力 (機能追加)

　ナゾの隠しコマンド「半角」を追加の謎。このコマンドを正式採用するかどうかはもうちょっと操作感覚を調べてから考える予定。
　これは、各種エディタやゲーム等において、「あるキーの打鍵後に高確率で半角文字(コマンド文字列等)を連続入力することが多い」アプリケーション向けの専用設定にきっと役立つはず。

参考 FF14ちゃん用設定

2013.09.22

日本語入力 (安定性向上)

　キーボードモードがONのままIMEにキーイベントを送りつける一部のゲームなどで、IME側に文字が貯まる問題を修正。ずっとDUALSHOCK3で孤独に遊んでたから気付かなかったZE……これでキーボードマウスモードでもチャットができるよ！やったね！

2013.09.23

Eggの　法則が　乱れる！

日本語入力 (機能追加)

　一年越しのCorvusSKKへのデフォルト設定見直しの要望がついに通った！感謝っ……！圧倒的感謝っ……！(これとかこれとかこれ♺とかこれ♺とか)

　SKKFEPのデフォルト記号入力ルールを変更するには、この期を逃してはならない！
　チャンス！チャンス！今、変更チャンス！

　というわけで、z(, z), z{, z}のルールを変更。
　DDSKK/CorvusSKKと同様、全角括弧と墨付き括弧とした。
　これでついにWindows上のSKKクローン間で記号入力ルールを統一できる！
　(なお、SKKIME1.5改やSKKFEPではz前置ルールはfやj前置でも同様に入力できるわけだが、f(やj}等も同様に変更してある)
　このほうがSKK利用者の混乱を防げるはずであると信じて、今後はこちらを標準設定とする。

　しかし、これにより、Egg互換の入力コンセプト(シフトを押しながらの入力は太めの文字が出る)は維持できなくなってしまった。ちくしょう、SKKFEP……ちくしょう！！「総員、SKKFEPに敬礼！」

　おまけで、Windows 8のタスクトレイのIME状態アイコンのクリックで入力モードを変更する機能を追加。CorvusSKKの驚異の女子力に近づこうとして失敗しちゃったような感じの、あくまでおまけのネタ機能(既存部分をむりやり接続しただけの子供騙し)なので、ちゃんと動かなくても勘弁な！
　IMEのオン・オフをした時、疑似カーソルオフの設定でも疑似カーソルが出現してしまうエンバグ(20130908版で発生)を修正。まだ残党が潜んでいたかッ！

2013.09.25

辞書プロセス (安定性向上)

　ユーザ辞書のコメント部分をSKK原作と同じ文字列に変更し、ユーザ辞書のエクスポート時の互換性を向上。
　これで、SKKFEPのユーザ辞書から他のSKKクローンに持っていくことも手軽にできるようになったはず。
　書庫のサイズが10バイト増えてしまったがどうということはない。

「現状でSKKFEPの性能は100パーセント出せます」

「識別子(コメント)はついてない」

「あんなの飾りです。偉いSKK10にはそれが分からんのですよ」

　外部とのとのやりとりはSKKGateで、みたいな先入観にずっと囚われていたせいで、インポートしまくることしか考えてなかったZE……。すまぬ……すまぬ……。

2013.09.26

辞書プロセス (サイズ縮小)

　コードサイズを18バイト縮小。元のものよりサイズを縮小しつつ互換性向上という悲願を達成。

2013.09.28

書庫 (サイズ縮小)

　書庫フォーマットを改良。配布用の書庫サイズが93,530バイトから90,880バイトとなり、約2.5キロバイト小さくなった。繰り返す。2.5キロバイト縮んでしまった。これは訓練ではない。

2013.10.15

日本語入力 (機能追加)

　送りがなの変換中にCTRL+Gでキャンセルを行なった際、送りがな部分を削除しない、SKK10原作のデフォルト動作と同様の動作を追加。
　その上で、この挙動をデフォ操作に変更。
　繰り返す。デフォルト操作をまた変更。
　またか！またデフォ操作変更か！なんどめだバルス目がァー

　SKK使いなら、たまに「今日はなんだかシフトキーをちょっと長く押しまくってる気がするZEてへぺろ❤」みたいな状況に陥ってしまった経験が、稀によくあるのでないかと思われる。そしてその状況になると、同じようなミスを連発することも、さらに稀によくあるのではなかろうか。

べっべべ別にパッド片手にネトゲ……うぬにケアルー(野太い声で)……操作しながらなんてSKK使いのくせにシフトキーに魂を集中できてないなんて原因があるわけないんだからねっ！

　こういう誤入力をしてしまうとどうなるかというと、「感動」を入力しようとしたけど「噛んど」になってしまって、あわてて修正する、みたいなことを何度も繰り返すことになるわけだ。
　で、従来のSKKFEPでは、skk-delete-okuri-when-quit相当の機能が有効になっていたので、「▼噛んど」をCTRL+Gすると送りがな部分が削除されて「▽か」になるわけだ。一見、実に自然で美しい動作であるように思われる。しかし、本当にこれがベストなのか？ここから復旧するのに「んどう」と毎回入力しなおすのはあまりに戻り量が多いと思わんかね？

　送りがなの入力エラーの発生パターンとその復旧操作のケースで、自分では、このパターンが圧倒的に多いことに気付いたのでこっちをデフォルトにすべきではないか？と考えを改めた。
　もちろん設定を変えれば従来の動作にも戻せるけど、せっかくだから俺はこのデフォ設定を選ぶぜ！

2013.11.09

辞書プロセス (安定性向上)

　整合性レベルの低いプロセス(IE等)で正常に漢字変換が行なえなくなるエンバグ(20130925版で発生)を修正。こんな初歩的なバグを二ヶ月も放置プレイだなんて……くやしい……でも……勧進帳(ﾋﾞｸﾝﾋﾞｸﾝ)
　最初はIEでプロセス間通信の方式がブロックされたのかと焦ったが、単にソースの記号が一文字間違ってただけだなんて恥ずかしくてパンツでストライク男だもん！

日本語入力 (安定性向上)

　英字編集(abbrevモード)を変換せず確定した際、物理アンドゥの文字数を数え間違うことがあるバグを修正。ついでに内部ロジックの見直しによるサイズ縮小。(20131109a)

拡張モジュール (サイズ縮小)

　内部ロジックの見直しによるサイズ縮小。(20131109a)

　なお、本バージョンでβ0+6iは最終バージョンになるかも。次の版から微妙に操作が改良されて、SKKという枠を越えて先っちょだけ離陸してしまうかもしれません。お覚悟！

β0+7i版公開

2013.11.26

　――過去のしがらみを逃れたSKKFEPを待っていたのはまた……地獄だった。

　互換性破壊の跡に棲み着いた、欲望と暴力。連文節戦争が生み出した、ググルの監視。

　悪徳と野心、退廃と混沌とをコンクリートミキサーにかけてブチまけた、ここはマイクロソフトのウインドウズ。

　次回、『アンドゥ』

　来週もSKKFEPと地獄に付き合ってもらう。

これまでのあらすじ: co「えーと。いまさら説明するまでもないと思いますが、SKKプラスの送りがな変換についてお話します。; 　えー……SKKFEPではシフトキーの操作遅延による変換位置の指定ミスを補正するため……」; N村「うーん。coちゃんさあ。『送りがな変換』じゃ余りに平凡じゃない？」; co「はい？」; N村「真なる絶望をもたらす『コンヴァート・オヴ・オクリガノス』でどう？」; T山「ですね」; N村「それとSKKFEPだけど、僕の解釈だとあれは『日本語入力』じゃないんだよね」; co「は？」; N村「あれは『壁』なんだよね。自分とアプリケーションの壁」; T山「『壁を越えし者ども』ね」; N村「それと僕の解釈では、あれは仕様(バグ)じゃなくて『再構築』って呼びたいな。それとね……」

　一時間後

co「……かりそめのシフト操作に酔いしれる『壁を越えし者ども』は

　真なる絶望をもたらす『コンヴァート・オヴ・オクリガノス』の『再構築』により

　互換性消滅の危機に瀕していた。しかし、むしろこれを進化の過程と歓迎するものもいた――」

β0+7i版公開

　SKK送りがな入力補正のための辞書フォーマット拡張実証実験用試作略して「SKKプラス」を塔載。Sekkaとは違う方向で誤入力を補正する試みとなる。
　詳しくはSKKプラスの解説ページを参照。
　半角英数入力状態の時、物理アンドゥ情報を保存しないように変更。パスワード等の半角英数による入力パターンがIME内の物理アンドゥバッファに一切入らないように機能を制限した。
　Sekkaの入力方式に慣れることができるか、自分で訓練していたつもりだったんだけど、いまひとつ慣れることができなかったし、そもそも物理アンドゥが生きるシーン自体があんまりないし、もう削除でいいかな、みたいな……。
　もともと、この機能は、CTRL+Jを連打しすぎたとか、最初のシフトキーを忘れたとかで「ｐｙてょｎ」とか入力されてしまった時のリカバリーを想定して作った機能だったし、このパターンさえ防げれば十分のはずだ。
　なんでこんな言い訳ばっかり書いているかというと、要するにこの変更により、Sekka互換入力(半角英数でローマ字を入れておいてから変換)は未来永劫動作しなくなってしまうことになるのだ。

　だが、しかし！これはSKKであってSekkaではないので、これで良いんだ。Sekkaみたいな入力方式と共存したい！とか無邪気に妄想していた純真無垢だったあの頃にはもう戻れない。泣いてない！これがベストだ信念を貫け！

　なお、α版からの変更はまったくないので1ヶ月前の版と中身は同じ。たった100バイトのバイナリの追加のためにサポートツールだのドキュメントだのを書かないといけなくなってきた時点で、そろそろ拡張ネタを探すのに飽きてきたんじゃないかと思っちゃったそこの俺君？俺だよ！

2013.11.30

辞書プロセス (機能追加)

　送りがなのマッチングにワイルドカード指定ができるよう辞書検索処理を改良。14バイトの追加バイナリで世界が変わる。パッチで復活！「ニューSKKプラス！」
　これにより、ワンチップマイコンなどのメモリ容量がプログラマーの命より重い極限環境においてもROM容量などを減らすことが可能となる……かもしれない。つか最近のワンチップマイコン性能上がりすぎﾜﾛﾀ
　恐らく、現状のSKKプラスの辞書データはまるでお話にならないレベルでデータ量が足りてない気がするので、送りがなの入力ミスが発生する時のパターンに法則を見つけちゃったとか、入力ミスが非常に多いパターンでこれを追加して欲しい、なんてものがあればお気軽にご連絡を！

2013.12.01

日本語入力 (安定性向上)

　暗黙の確定で物理アンドゥの文字数計算を間違えることがあるバグを修正。
　実は初期の物理アンドゥ実装時からずっと存在していたかなり根本的なバグだった模様。
　よくぞ……よくぞ見つけてくださった……！βテスターのみなさんは本当に優秀なりよ！ありがとう！そして、ありがとう！
　関連ルートを一通り見直してみたけど、これ以上文字数計算の精度を上げようとすると、全部作り直しレベルになっちゃうので、これ以上は現在のコードサイズではちょっと難しい。実用になるギリギリ限界ラインを崖っぷちでなんとか保ってる極限状態ってことで、多少アレでも現状維持で勘弁ッ！

2013.12.05

「おー。SKKFEPの設定があるぜ。

　ちょっと使っていこうぜ。先生もどうだい？

「いいえ。

　わたしは遠慮しておきます。▽

日本語入力 (機能追加)

　設定ファイルに変更が加わりました。「子音表示」を1に設定して使っていた場合は再設定が必要です。それ以外の箇所の変更だけの場合はプログラムのアップデートのみで問題なし。
　ほう、ATOKに物理アンドゥとまったく同じ処理が入るとな。こっちは機能廃止してバイナリの隙間をゲットして浮かれてたところだというのに。なんと奇遇な。
　ならば！機能復活させるしかあるまい！
　とはいえこの機能はデフォ無効化としておきたい。ならば！とコンフィグで機能選択できるようにすると、判定コードと戻した処理とでバイナリがモリモリはみ出て顔面肥大化しちゃう。食べちゃうにゃん。
　ならば！削るしかあるまい！
　というわけでビットレベルで削って削って削りまくった。内部テーブル構造を見直してサイズ削減。β0+7iで廃止にしたはずの、半角英数入力からの物理アンドゥ機能を、設定変更で再度有効化できるように改良した。
　設定ファイルの「全開」を1にすることで、β0+6i相当の物理アンドゥ動作になる。これがSKKFEPの全力全開！ヨロシクSekka！
　そういや関係ないけど、Gもなんか雪花(英字の自動認識)と同じ処理が入ってきてるみたいだし、SKKFEPの機能実装の方針は間違ってなかったってことだなこれは。要するにSKKのほうが進んでるってことだぜ？(誇張)
　で、サイズをガリガリ削りまくったらなんか余裕が出たので、今こそ封印を解く時！サイズ肥大化防止のために封印していたSKK10互換の送りがな変換表示の処理を追加してみた。実は昔ワンチップマイコン向けに書いたコンセプトコードを見つけたので、試しに有効化してみたら、動作が滅茶苦茶だったんで泣きながら全部書き直した……ってのは内緒な。
　てな感じで、表示系の処理追加で設定回りに変更が入った。子音の全角文字表示の制御は設定ファイルからではなくrule pオプションで行うように変更。設定の「子音表示」を廃止。余ったビットを物理アンドゥ設定用に転用。オプション回りで使えるビットの残りはあと2ビットか……。1ビットがとてつもなく重い……！で、虫食い状態になったビットの並びが美しくないから一部を並べなおした。互換性？知るか馬鹿！そんなことより再設定だ！ということで最初の「再設定が必要」の話とつながるのであった。
　と、長い前置きだったけど、要するにrule p1してTo;ndeとか操作してみると違いがわかるはず。あ、これは~~サービスサービス~~おまけ機能っていうか利用頻度の低い隠し要素の一種という位置づけなんで、サイズが厳しいときは最優先で無効化されるかもってことでヨロシク！
　これと組み合わせるためのおまけとして、SKK10(Emacs)の変換カラー設定も作ってみた。反転表示色2つを変えただけのかなり投げやりな作り。もうちょっとパレットを調整してやれば、よりSKK10っぽい見た目にできるかも。わたしは遠慮しておきます。
　いろいろ追加したので、64ビット版バイナリはもう1バイトも隙間がなくなってしまった。だが後悔はしていない。むしゃむしゃしてやった！今は反芻している。

2013.12.06

日本語入力 (安定性向上)

　ちょっとサイズを削りすぎてた。し　しまった　つい力が…
　絞り込みの開始直後の表示が崩れるエンバグ(20131205版で発生)を修正。ついでに32ビット版をさらに16バイト削っといた。
　標準設定の更新に合わせて、AZIK/ACT/T-Code/FF14の設定内容や変数名等を近代化改修。

2013.12.07

設定補助 (機能追加)

　設定用変数名の範囲を広げて、設定用変数を最小1～2バイトで構成できるよう改良。
　遥か遠い未来の世界で、SKKFEPにGUIがついて利用者がテキストファイルを弄らなくても良くなった時、設定用変数で使っている何百バイトという無駄な文字列部分をばっさり切り落とせるようにしておいた。未来ってすごいや！で、未来はいつ来るんだって？うっ……頭が
　定義ファイルの設定を見直し。設定用変数を2文字(4バイト)に統一。
　注釈の表示の選択肢を2ビット4タイプではなく、skkime/CorvusSKKと同様の3タイプからの選択に変更。ぶっちゃけ使う/使わねーの二択で99.9%のニーズに応えられるだろうし十分じゃね？と思ったけど、大した変更ではないので妥協した。たまには長いものにまかれろ！らりるれろ！
　設定「外部」(CTRL+Oで直接外部辞書に接続)を廃止。これは登録モード時のTAB操作が既にあるということと、TABのほうが自然に使えるはずで、こちらの操作のほうを一般化したいとの信念があること、自分の利用範囲ではCTRL+Oで操作を短縮する必要がなく、これまで積極的に使う機会が見出せなかったこと、複数の同じ機能に対する操作を「標準設定として」持ちすぎてはいけないのではないか、との判断からTAB操作側に一本化することにした。(AZIK/ACTの設定では、まだしばらく残しておく予定)
　実はほかにも、サイズ縮小とタブストップ位置を8文字以内に強制的に収めるため、隠し動作用の簡易記述用の演算子("==" → "=", "!=" → "!")の利用もこっそり解禁しちゃった。実は論理演算の演算子を入れた時からとっくに使えるようになってたんだけど、Cの演算子っぽい記述のほうが格好いいかなーと思ってあえて使ってなかった。だが、今や定義ファイルをZIP符号化しやすくビット単位で調節する時代である。小さいは正義！否ァ！パイナリこそがこの世の理。豊パイナリは富であり絶対。うえーんもうやだ母星(おうち)帰る～
　なお、デフォルト状態で生成される定義内容は、以前の定義ファイルの時とと完全に一致しているため、20131206版の定義ファイルが入っているのであれば、特に変更する必要はない模様。
　また、当面の間はACT/AZIKの定義に関しては20131206版の改修後の版を使用するものとする。
　長々と書いたけど要するに、デフォ設定で使ってる場合、今回はアップデートすら不要ってことさ！

日本語入力 (安定性向上)

　……と、思ったのも束の間。必殺技コマンド回りに潜んでいたローマ字かな変換の基幹部分にくい込んでるレベルのバグを発見！
　必殺技コマンドによる文字入力で暗黙の確定をすると文字列がおかしくなるバグを修正。
　この修正、かなり厄介だった……。でもだいぶ手を入れまくったおかげで内部ロジックの見直しによる処理簡略化と共通処理のくくり出しに成功してサイズがさらに縮んだ。
　具体的にはもう何をやっても縮まないと思ってた64ビット版バイナリが16バイト縮んだ。32ビット側もさらに16バイト縮んだ。ﾋｬｯﾊｰ！

2013.12.09

期待されてないのはわかってるんだ……
C級フリーソフト(SKKFEP)が大して役に立たないなんてこと
俺が一番よくわかっているんだ！
俺じゃMSやG級で通用しない、自分が弱いってことは
ちゃんとわかってるんだ！
フリーソフト(SKKFEP)が理不尽な誤検出に勝てないなんてことは
俺が一番よくわかってるんだよぉッ……!!

それでも

やるしかないんだ

俺しかいないんだ

勝てる勝てないじゃなく
ここで俺は
お前に立ち向かわなくちゃいけないんだ！

(第34話♺より)

　……ってな気分で日本代理店に相談したら、簡単に報告できるページを教えてもらって、鼻水流しながら1クリックであっさり解決した。
　この系列のエンジンを使ってた各方面からの理不尽な誤検出は、多少は減るんじゃなかろうか。
　ありがとうワンクリマン！

2013.12.11

日本語入力 (サイズ削減)

　個別対応の結果を確認すべく、さらにサイズを徹底的に削ったバイナリを作成してやった。
　内部ロジックを見直して32/64ビットともに48バイトづつ削って確認。大丈夫だ、問題ない。

2013.12.13

日本語入力 (安定性向上)

　ヘボン式ohの長音表記が正常に動作しないエンバグ(20131207版で発生)を修正。

2013.12.14

日本語入力 (機能追加)

　必殺技で0文字を返すことにより、IME操作を文字入力以外の特殊機動に利用することを可能にした。しちゃった。てへぺろ❤ﾃﾞｭﾌｺﾎﾟｫ❤
　実は候補0文字を返した時に停止する可能性があるバグを発見して慌てて修正した、そのついでだったってのは秘密だ！ついでにサイズ削減。
　例えば以下のような感じでtsf-vim♺などと連携できる。

・通常モード(ひらがな、半角英数モード問わず)でESCを押したら必殺技コマンドを発動

・必殺技でスクリプトを実行し、キーストロークを生成

・結果、IMEが別のものに切り替わる

　SendKeys系はWSHの応用例の筆頭に挙がるくらい実に強力な機能なわけで、IMEをオフにしたり切り替えたり、文字入力そのものを行なったりするなど、アプリの標準設定だけではできないことを平然とやってのける、そこにシビれるあこがれるぅー
　だがしかし！SendKeys系は一発ネタとして使うには十分な威力はあるけど、連続動作に弱い(連発すると送信失敗のあげくエラー検出できないという致命的な問題がある)ので、正直業務用としてまともに使えるレベルの品質に到達してない、あくまでお遊びレベルだってことには十分留意しておくこと。

　以下サンプル。それぞれ最終行あたりに以下のような内容をテキトーに追加されたし。

ルール設定

通常:
^[	?change()	# IME切り替え
共通:

skkgate.ini

function change() { return S.SendKeys("+^9"), "" }	// SHIFT+CTRL+9

2013.12.14

日本語入力 (機能追加)

　順次打鍵(Sticky-Shift)キーを2回押したらそのキーをそのまま入力するように改良。
　標準設定で「順次」を2にすると順次打鍵(Sticky-Shift)モードになる。この時；を2連打すると、セミコロンが1文字入るっていう寸法。ちなみにAZIK標準設定だと標準でSHIFT+@がSticky設定と等価だったりするので、この場合逆クォートが入るようになる。
　某2ちゃんねる情報によると、Sticky-Shift入力のキーを2回押すと本来の文字入力にするってのが便利らしい。初期βテスタの方にSticky-Sihft使いが何名かいたはずなので、これは取り入れておくべき！と直感したので早速入れといた。どうよ？！

2013.12.24

日本語入力 (機能追加)

　今回は微妙な修正が多すぎて何をやったかもう覚えてないので思い出せる範囲で書いておく。

世界初！送りがなの促音・撥音などの入力を延長する新たなルール表記を追加し標準設定/AZIKに試験導入して標準設定を目指したが挫折(後述)
世界初！Win8系のソフトキーで「点」と「丸」以外の句読点を入力できるように改良(後述)
標準設定からの差分設定ファイルを記述できるよう表記を拡張。FF14設定みたいな標準設定＋αの定義ファイルはかなりコンパクトに書けるようになった
設定項目が多すぎるので統廃合をしようとしたらまたモリモリ増えた
ローマ字cy行をSKK10互換の「ちゃ」にまた戻した
外部辞書接続操作CTRL-Oの設定を復活
IME切替キーの記述を簡易記述可能に改良。［CTRL-\]のようなパターンも記述可能にしといた
変換トリガ設定の記述文字数をさらに少ない文字数で記述できるように改良
AZIKの設定を一部取り込み。短縮0の時の動作を合わせた
ACTの設定を一部取り込み。Dvorak配列時にはcをか行に設定
pオプションに隠し番号を追加。値を8加算して設定すると微妙に表示が変化する……かもしれない

　なんかいろいろ追加したけど、例によって一つだけ言えるのはいつもと同様、

デフォ設定で使ってたなら何も見た目も操作もあんまり変わってない

　……ってこと。設定のバリエーションと余計なハッタリ機能がまた増えた。

その0

　ローマ字かな変換ルールは、修正されなければならない――

撥音の1打鍵入力ができないのは
ローマ字かな変換の最大の欠陥である

　……ということをずっと考えていたのだけど、AZIKのようなフリーダムなルールを使いこなすのがどうしてもうまくできない。理由はまだよくわからないのだが、打鍵の文字の「音」が頭に響かないってのが大きいんじゃないかなって気がする。アルファベットの音と日本語文字の音が一致する入力方式ってのは個人的には大事なわけ。
　だから撥音にnを使うのは既定路線。
　だがちょっと待ってほしい。本当にそうなのだろうか？なんて疑問はまずプロトタイプを作ってからほざくんだな。
　ではnの一打鍵で「ん」を出力するようにしてみよう。こんなの一行で十分だ。

n	ん
#(な行ルールを削除)

……しばらくお待ちください

ｱｯｰ❤

　いかん、な行が入力できなくなってしまって危うく向こう側の世界に逝きかけてしまった。
　やはり2打鍵は必要ということを身をもって痛感したので、もうちょっと別の路線を目指してみる。
　つまり、こういうことだ！

撥音の直後のな行が入力しづらいのは
ローマ字かな変換の最大の欠陥である

　そこで試しに、撥音の後のな行をnの打鍵なしで打てるようにしてみた。具体的には以下のようなルールを通常設定の撥音の部分の中間あたりに追加すればよい。

n	ん
?新式	nn	ん	m:
?	m:!	なにぬねの
nn	ん

　これはどういうことかというと、nnと打つとな行入力モードになって、その後母音(!マーク)を打ち込むと即座にな行が出るっていう寸法である。どうよ？これなら最強間違いなしだ！

……しばらくお待ちください

ｱｯｰ❤

　ダメだ、ダメすぎる。「あんい」「かんい」みたいな撥音＋あ行、「おんな」「そんなに」みたいな撥音＋な行の出現パターンが(SKK的な意味で)ランダムすぎて、本気で実用になるレベルで打鍵数を減らすには某の日本語辞書パターン抽出みたいなハイソなことをやらないといかん。
　考えれば考えるほど悪化するので、もっと単純な方法でやったほうがよさそうだな。だって要するに予測変換を使えば十分だし、もうどうしようもなくなったら記号入力ルールの拡張(いわゆるオレオレAZIKや漢直)で十分な範囲なわけで……。

　しかし、もっとサクサクとランダムなパターンを、文字の並びの見た目と実際の発声とがだいたい同じイメージで脳内に想像できて、かつスムースに入力できる良い方法はないものか……(と毛布を被って寝てしまう)

――君はこれを次期バージョンへの伏線と考えてもいいし、面倒なので実装を放棄してこのまま立ち去ってもよい。

その1

　先の撥音入力の戦いで痛手を負った我々取材班だが、トイレで滑って頭を便器にぶつけた時、あるアイディアを閃いてしまった。
　つまり……逆に考えるんだ！
　送りがなを常に1文字で確定しなければならない、ではなくて
　2文字目以降が入るまで確定を待つようにすればいいんじゃないか？

これはSKK系入力方式の革命になる世界初の機能の予感！

　これによって、撥音+あ行、な行のパターンの変換の精度が上がることが期待できる。
　例えば「あ*んい(補正発動) な」「有*んのか」「あ*んな(補正発動)に」みたいな入力パターンを変換前に区別できるようになるはずだ。SKKプラスのさらに拡張版となることからこれを「ニューSKKプラス＋」と命名。
　同様に促音側についても同じようなルールを入れてやることで、撥音・促音を1打鍵で入力できるようになった犠牲に辞書の学習状態が標準的なSKKと異なってしまう道を選ばざるを得なかった、AZIK/ACTの学習パターンを、標準ローマ字かな変換ルールとだいたい同じ雰囲気になるように持っていくこともできるかもしれない。
　あと、これまでのローマ字かな変換ルールでは、撥音のあとの「あ行」「な行」の時だけ、送りがなが「ん」固定になるというのが一種の例外表記みたいな感じでどうにも納得いかなかったので、この設定を有効化することで、撥音に連なる送りがなの確定タイミングがすべて同じになって美しくなるはず！
　こ、これはもうSKKとの互換性を捨ててでもこっちを標準化してしまおう！もう我慢できない！即座に実装アンド実装アンド使ってみた。

……しばらくお待ちください

ｱｯｰ❤

　どうやら……長い悪夢を見ていたようだ。操作感覚が違いすぎるのでデフォ機能化は断念。泣いてない。
　だがこの機能は100年後のSKKには間違いなく標準機能として入っていて、初めてSKKに触れた人が初期習熟の段階から使うことで、間違いなく入力効率を上げることができる、一番最初から使いこなしておくべき操作であると信じる。よって、設定だけは残しておくことにする。泣いてない。

その2

　タブレットPCってやつを買ってみた。350グラムのくせに艦これがサクサク動いてたまげたので、これでちょいと日本語入力しようと思ったら……絶望した！
　Windows 8のIME回りのAPIを設計した連中は相当な素人か間抜けに違いない。過去のIMEの互換性をことごとく潰した上にソフトキーの標準設定にこれでもかと相手を無能にさせようとする狂気すら感じる。
　そもそもβのときから、IMEの16色アイコン*だけ*がなぜかおかしな色になる(他のアプリは互換性のためにタスクバーアイコンは16色でもちゃんと表示できる)という、正直どういう作りにしたらこんなおかしな動きになるのか理解に苦しむ実装をやらかしていたので、これはOSとIME、アプリとの連携みたいな全体を理解してない連中が設計してるんじゃないか、という嫌～な雰囲気は見えていた。
　その極めつけはソフトキーボードまわりの実装に集約されていた。だいたい、IMEからOSに1ビットの情報量(ソフトキーボードの専用配列を使う/使わない)を通知したいだけなのに、やれCOMのインタフェースをもりもり追加してクエリを何度もやって何キロバイトもプログラムを連ねないと動作させない、とか酷すぎる。事実上の標準形式の日本語キーボードを、過去のTSF実装ではわざと使えないようにしてあるだなんて、悪意以外の何者でもないわ。そもそもこういうのはOS側が古いアプリに合わせて「デフォルトのキーボードスタイル」みたいな感じでOS側で選べるようにしておくだけで十分じゃねーか。なんでAPI呼ばないとデフォルト無効なんだよ。設計したやつはちょっと間抜けを通り越して無能の極みとしか言いようがないだろこれ。
　とどめにソフトキーボード側が勝手に日本語の長音記号や句読点などを、IMEの入力状態を見ずに勝手に入力するのでIME側がOS側に合わせろ、とかいう謎仕様にしやがった。数値入力中は句読点のかわりにカンマを入力したい、みたいな文字入力回りの状態遷移を管理するのはIME側の役目だろうに。なに　かんがえてんだ。この設計思想をあと何十年維持しろとかどんなMSプレイだよ……。
　で、この勝手なソフトキーボードの仕様は文字入力だけかと思ってたら、なんか文字コードで編集操作(ページ変更操作)を伝えるという信じられない作りになっていた。あまりにも設計のセンスが悪すぎてもう笑うしかない。IME実装側に負担を思いきりかけようとする悪意の塊で作っているとしか思えない。つーかUnicode文字を使って操作を渡すのは百歩譲ってよしとしても、デフォ配列では特殊文字は使わないようにしておく、みたいな感じでもっと設定を練っとけよ……。これをもし良かれと思ってやったのだとしたら、相当にプログラムのセンスが悪く頭が弱いくせに権力だけある連中が音頭を取って頭の良い連中を一方的にこき使ってゴリ押しして作ったとしか思えないような耐えがたい代物になってる。
　こんな代物を使えっていうのか……もう絶望感しかねえ……。必死で対応させたけど、SKKFEPのコード量の3%くらい、キロバイト単位のサイズでこのためだけの対策に費されるとか情けなくて七孔噴血モノである。梨汁ﾌﾞｼｬｰ。こんなのラッパーの設計を工夫すれば過去のIME側は完全に無改造で最新IMEの操作感を付随できるレベルの内容だろ？もっと熱くなれよ！

ぷちーん

　もういい。まあよし。グッドだ。標準通りに作るのやめた。てかハナから作ってない。ゴール！
　てな感じで、ソフトキーボードでの入力だと強制的に句読点は点と丸固定、というWindows八兵衛のディストピアに少しでも亀裂を入れようと笑顔でソフトキーの入力内容を無視しちゃうSKKFEPなのでした。これでも食らえやマイク＊＊フト！Win8のクソ仕様にSKKFEPのクソコードで対応したった。争いは、同じレベルの者同士でしか発生しない!!
　高速入力を追求した結果こうなったのだから後悔などしない。むしゃむしゃしてやった。今は己のコードのクソさ加減を反芻している。Anotherなら死んでた。

　このポイントは1つ。Windows 8用IMEとしては世界で初めて、ソフトキーの句読点の操作時にIME側のコンフィグで設定した文字を反映させることができるという点に尽きる。やべぇ……物は言い様って感じのハッタリ感がタマ姉たまんねぇ！
　Win8系でのタッチキーボードの操作は以下の通り。これで一応、最低限実用になるレベルにギリギリアウトって感じまでは持ってこれたはずだ。

・点ボタンで「半角カンマ」に割り当てた文字を入力

・丸ボタンで「半角ピリオド」に割り当てた文字を入力、または予測変換

・次頁ボタンでTAB相当(編集中の補完操作)またはCTRL+J相当(英字モードから日本語モードへ)

・前頁ボタンでSHIFT+TAB相当(補完を一手戻す)

　でも正直、このソフトキーはまだ使いものにならない。
　なぁ・・・レイアウト変更しようや・・・・
　画面が狭いってわかってるくせに不透明で画面を占拠しやがってよぉぉぉぉ！！
　何がソフトだよ何一つフレキシブルに使えないじゃねーかシフトキーの面積5倍にしろｵﾗｧｧｧ！！

　仕方ないので現状で妥協しまくるデキるオトナを演出するために、以下の設定をやってタッチキーボードを「ハードウェアキーボードに準拠したレイアウト」のタッチキーボードにして使うのを推奨。Windows 8.1の場合は以下のように操作すれば設定を変更できる。超わかりにくいけどこれが世界の現実だ。

1. 右端スワイプ→設定画面に変更し右下の「PC設定の変更」を選択

2. 「PCとデバイス」→「入力」でタッチキーボードの項目を選択

3. 「ハードウェアキーボードに準拠したレイアウトをタッチキーボードオプションとして追加する」をオンに変更

一方、ロシアは1,980円のUSBキーボードを接続した。

辞書プロセス (安定性向上)

　アルファベットのみの文字列の最後にひらがなの送りがなをつけて辞書検索要求を行うと、送りなし側のエントリを検索してしまい、検索に失敗するバグを修正。
　これは実質的に問題が発生するようなことはないのでずっと放置してた。
　そもそも人類がこんな間抜けな検索を行うほど日本語はまだ乱れていないはず。でも将来の雪花の機能拡張を見据えて直しておくことにした。

その他

　標準設定の更新に合わせて、AZIK/ACT/T-Code/FF14の設定内容を近代化改修。

2013.12.25

日本語入力 (機能追加)

　Win8系用のメインアイコンに32/40ドットのものを追加。不要だと思ってあえて削ってたけど、高解像度のタブレットとか使ってみたらこりゃ必要だわーと思ったので追加しといた。サイズがもりもり増えるけど、これが世界の選択か――
　ちなみにWindows Vista以降の環境ならでメインアイコンにフルカラーのものが使えるので、setup hとやってアップデートすれば有効になるはず。

インストーラ (機能追加)

　初回インストール時のみ、カタカナ辞書を有効化するよう改良。ずっと有効にしてたつもりだったのになってなかったんです。もうね、イヴかと。メリークリスマスかと。

2013.12.26

日本語入力 (機能追加)
インストーラ (機能追加)

アイコンを変更。Vista/7のインストール時に高解像度アイコンを使用するよう改良。なお、XPは従来の16色小型アイコンのままとなる。

　やべぇデバッグ(肌色画像E&E)表示用端末として酷使してるはずなのに、まだ充電を数回しかやってねぇBay Trail電池持ちすぎﾜﾛﾀ。Windows RTでは脱獄がお話にならないレベルで、まともに動作試験とかできなくて泣いてたんだけど、これなら利用者の視点で使い倒せる！
　というわけで艦タブ向け最適化を本気でやってみることにした。

　本気を出すなら、まず全裸でドット絵描画の儀である。
　なぜ今またアイコン修正なんて面倒極まりない所から入るのかというと、これには理由がある。
　よく考えたら、Windows XP～7向けバイナリもあと数年で使えなくなるわけで、その時はもう今の最小バイナリ構成の16色アイコンは(マイクロソフトの陰謀により)事実上使えなくなってしまう。おのれニンゲンめぇ……。そうなったらアイコンフォーマットを変えなければならない。今までの版で使っていたモード表示用32ビットカラーアイコンは4ビット(16色)表示用のものをそのまま変換した中途半端なものだったのだが、いつまでも適当なものを使っているわけにもいかん！と思ったのが1つ。そして、そうやって専用アイコンを用意した際に避けられないのはバイナリサイズの大幅増加である。
　しかしよくよく考えてみると、このソフトの利用者でファイルサイズのことを気にするほどROM残量がヤヴァい人はまずいない。極力シンプルでコンパクトなサイズで構築する、というSKK実装の基本にして奥義となる方針を捨てるわけではないけど、サイズ縮小だけにこだわってSKK本来として大事な使い勝手や機能追加を疎かにしてはいかん！と考えなおしたのだ。
　そこでまずは手始めに、アイコンのドットの複雑度を上げてバイナリサイズを爆増させて窮屈な過去と決別する。その言葉が忍耐を断ち切る。もっとサイズ増加する！

　と思ったのだが……。寝ずにドットを打ちまくって調整して計算による純粋なアンチエイリアスに比べて圧倒的なパターンの圧縮率向上を達成しちゃった。参考レベルでしかない情報だけどアイコン化前の画像圧縮比較で11KB→4.1KBになってる。人間の視界を欺け！具体的にはアンチエイリアスを効かせるところと「あえて効かせない」ところを調整するのが圧縮の鍵となる。はっ！私は一体何をやっているんだ……
　アイコン画像は、ちょっと手動補正が効きすぎて粗い部分もあったりして、まだ気になる所があるってのが正直なところなんだけど眠いこれ以上マジ無理。細かいリファインは時間のあるときにじっくりやる。
　アイコンサイズは16/20/24/32ドットのパターンに対応。12ポイント相当で計算するので100%/125%/150%/200%のデスクトップDPIに対応する。本当はIMEは300%まで対応できるんだけどあえてやらん。これは理由があって、現状ではシステムトレイの他のアイコンの最大パターンが32x32みたいなので、正直これ以上の解像度のものはを用意してもオーバースペックなだけだろうってことでこうした。つか眠い。寝たら死ぬ。

　なお、今回からVista/7も高解像度アイコンを錬成するようにしたので、バイナリのサイズが微妙に増えるわけだけど、当然、今までの世界最小スタンドアロンSKKの実行バイナリを使うこともできる。インストールの時、書庫からskkicon.dllを抜いてインストールすべし。これでWin7まで最小構成でいけるようになってる。もう誰もやらんだろうけど、一応技術的に可能であることを実証する方法を残しておくのが正義ってことで。

　MSのサイトを見たら、高DPI環境では「フォント」と「アイコン」が崩れる、みたいなことが書かれていた。アイコンについては今回の実装で対応したからいいとしてフォントはどうかな？と思って見てみたらﾐｻﾜモード発動。
　……あっちゃー思いっきり物理サイズで指定してたわー……うわーどうすんのこれーやばいわー対応面倒だわー……待て……落ちつけ……多少サイズが小さくなって見えるだけで実用上はあんまり問題ないからこのまま放置でいいカナ？かな？……。喝！初心忘るべからず！三歩おきにウォッチドッグだ！
　フォント側もディスプレイDPI設定に合わせて適切なサイズにするように即座に修正。(ｷﾘｯ
　ただ、古い設定との互換性を取るため、昔の設定が残っている場合はこれまでの版と同じサイズで表示するようにしてある。一度フォント設定を開いて、OKを押して確定しておくと、新しいDPI計算処理が反映されるようになる。「なんかフォント小さくね？」って時は~~まず服を脱ぎます~~設定しなおすべし。

設定補助 (機能追加)

　前述の通り、フォント設定時にフォントのポイント数を保存するよう改良。
　実は過去の版で、複数のアイコンイメージに対応させるために一部別の構想を実装に反映させてた版があって、フォント設定をやるとアイコンの物理サイズを計算して設定を保存する版なんてのも微妙に混ざってたりするんだけど(その版で設定してるとフォントが小さめになる)

そんなものは　ない

　見なかったことにしよう。フォント設定は上書きが基本。東京ドームシティで僕と握手！

2013.12.27

日本語入力 (機能追加)

　言語バーの入力モード表示の内容を空にした。これはWindows 8系で入力モードを変更するために「あ」のアイコンをタップした時、タップした位置のあたりにツールチップとして「モード」という間抜けな文字が出て視界を奪われることを防ぐためにこうした。7以前だと猛烈に小さいツールチップが出るんだけど、正直7以前は言語バーをマウスやタッチパネルで触るという行為自体をやらないので放置。ｷﾘｯ
　ソフトキーでの「次頁」ボタンで物理アンドゥを行うよう改良。ちょっとこのあたり、まだ見直しが必要な感じなのでこれから調整していく。

2013.12.28

日本語入力 (機能追加)

　外部からIME制御を受けた際、物理アンドゥ関連の情報をすべてクリアするよう改良。
　外部制御を検出した瞬間、即座に全メモリを消去する。

Windows「そのキーボード制御を、渡してもらおうか！」

SKKFEP「その娘(メモリ消去)と交換だ！

　　　　　　いやならこいつは水の中だ！」

Windows「……よかろう。」

　要するにこんな感じだ。正直ここまでやらなくてもいいかなという気もするんだけど、こういうのは過剰なくらい安全方向に振っておいたほうが安心だと思うので、この機会に改良しといた。
　ちなみにWindows 8以降だとOS標準のソフトキーボードがIMEを勝手に制御しようとする。おいおい普通は逆だぜ常考。ソフトキー側の初期状態とかキーバインドなどをIME側から制御したいのだが……どうやったらいいのかさっぱりわからぬ。ぐぬぬ……。

　閑話休題(それはさておき)。

　Win8系のタッチキーボードの次頁ボタンを常に変換キーとして扱うように変更。1つのキーに複数の固定機能をハードコーディングしていた旧バージョンはあまりに酷い実装だったと反省して、ある程度は設定で弄れるようにした。
　とりあえず変換=2と設定することで、親指で押せる順次打鍵キーとして使えるはず。

インストーラ (機能追加)

　インストーラのウィンドウサイズを可変に変更。
　サイズを広げて動作できるようにしておくことで、将来アンインストールの時に萌えキャラを出せるくらいの十分な表示領域を確保できるようにしておくのが重要だ。
　そう、まずはIMEの萌え擬人化から。他力本願寺。

2013.12.30

日本語入力 (安定性向上)

　レジストリ未設定時にフォントが異常に小さなサイズで表示されてしまうエンバグ(20131226版で発生)を修正。

2013.12.31

日本語入力 (機能追加)

　Firefoxでの艦これに対応！
　ことの起こりは冬コミ会場で、IMEこれくしょん(仮称)の主人公に「このあと滅茶苦茶SKKした」系のネタを使えないか思慮に耽りながら西館に向かって歩いていた時に閃いた艦これ対策コードである。アプリから不当な指示が来てもリセットせず、内部の状態遷移を記録して判定を延期すればいいんじゃね？！IME未対応のアプリが来ても、ある程度SKKとして最低限の操作を行うことができるはず！きた！これで勝つる！
　……と、いてもたってもいられず会場でデバッグしてたんだけど、~~ソフトウェア技術系・電子工作系サークルの内容があまりに高度かつアツすぎて~~ ~~艦娘のコスプレイヤーの方々についつい視界を奪われてしまって~~最後までうまく動かせなかった。己の無力を痛感しつつも、このアイディアは間違っていないはずだ！とプルプル震えながら帰宅。――このあと滅茶苦茶SKKした。
　ただ……正直なところ、こういった局所的な対応は、IME側でやるべきじゃないと思うんだよね……FirefoxとかFlashファイル側がきちんと対策をすることこそが、本当に正しい流れのはず。だがそんな青く清浄な世界ではWindowsちゃんは生きることができないというのもまた真実なのかもしれない。某日本語入力のプロセス判定コードとか涙なくしては見れないですしおすし。とにかく、現状を真の意味で打開することは難しい。正直、底辺かつ嫌われもののいちプログラマーにはどうすることもできん……。一体どうしたらよかんべか……(と毛布に包まったまま寝てしまう)
　あともう一つ。Windows 8.1にてタッチキーボードでとある操作を行なうと、ログアウトするまでおかしなキー入力がアプリとIMEに通知され続けるバグを発見した。この問題は現在、CorvusSKKの作者さまにも連絡して対策を考え中。ひとまず、今回実装したのはあくまでも思いつきレベルの暫定措置という位置付けとなる。だが、今自分にできることは今年のうちに全てやっておく！マイク○ソフトよ、これがSKKFEPだ。

2014.01.08

(SKKへの)愛は……沈まない！

設定補助 (機能追加)

　ついにSKKFEPに設定GUIが実装だァ！
　インストーラに新設された「設定」ボタンを押すことで起動する。

GUIｷﾀｺﾚ！

……やだ……ナニコレ……

　というわけで上げて落とす系SKKFEP恒例、GUIぬか喜びのお時間です。
　従来は[設定編集]ボタンで『メモ帳を起動』して『カーソルを数字のところまで移動』して『値を書き換え』て『書き換えたファイルを保存』して、[コマンド]ボタンで『コマンドプロンプトを起動』して『ruleコマンドとパラメータを指定して実行』して、ようやく設定が変更できたわけだが、どうやらこの単純明快な設定方式は、Windowsの利用者の大半にとってはまことに受け入れがたい、儀式めいた代物として映るらしい。どうせ一回設定したら終わりなんだし、多少面倒なほうが記憶が強化されて楽しめるんじゃね？って思ってたけど、そんな暇があるならブラウザでマウス連打してツンデレヴォイスでも聞いてたほうがまし、という意見にも一理あると思った。もしGUIがあれば、操作は設定→OKボタンを押すだけでよいのだ。

　よろしい、ならばGUIだ。

　だが……普通のGUIじゃ面白くない！絶対にGUIなんかに負けたりしない！(ｷｯと意気込んでいたのにやっぱり勝てない予定調和の形式美に悔しくてﾋﾞｸﾝﾋﾞｸﾝしちゃう。
　そこで白羽の矢を膝に受けてしまったのがHTAである。封印されし太古のHTAを開放するなら今しかない！じゃーん！かわいいEXEファイルかと思った？残念！HTAちゃんでした。
　HTAベースのGUIはジャストシステムの製品でも使われてた、みたいな記述をどこかで見かけたし、これはもうSKKFEPが使ってもオッケーってことですよね？！同意とみてよろしいですかな？もう我慢できない！というわけで使っちゃった。

　謎の超古代文明の遺産HTAとの邂逅により、デフォルト選択表示インジケータ、疑似半透明色合成カーソル、行選択による設定の順次変更、艦これリスペクトの右端×ボタン(装備脱着)などを搭載し、約4KB弱の極小サイズのくせにWindowsのGUIとは思えない、他に類を見ない操作系を備えた実にSKKFEPにふさわしい代物となった。

　GUIの設定内容は、ユーザ辞書フォルダのskkrule.iniに差分の形で記録され、次回以降の設定で再利用される。[ユーザ辞書]ボタンを押して該当ファイルをダブルクリックすればメモ帳で中身を確認できる。SKKFEPではレジストリが設定の基本となっているため、このファイルを単独で書き換えても何の効力もないことに留意すること。GUIと組み合わせた時のみ、このファイルの情報が輝くのだ。もし二度とGUIを使わない覚悟があるなら、このファイルは消してしまっても問題ない。

　GUIの定義ファイルに合わせて拡張子INIも定義ファイルとして扱うように変更。ついでにEXEファイルの判定を変更し、TXT INI以外のファイル名であれば実行モジュールとして扱うようにしておいた。これでLibreOfficeのようなEXE以外の拡張子を持つ実行モジュールにも設定が可能となる。従来はダミー名称で登録してレジストリエディタで手動で名前変更するしかない、なーんて感じのことを各自推測して扱わないといけない、あまりにもエクストリームすぎる仕様だった。今は反芻している。ﾑｼｬ

　なお謎のハッタリテクノロジーHACKJSだが、順調に進化してHTA内部を書き換えできるようになった。今回のケースだとだいたい1KBほど縮小に成功している模様。HACKJSは、あまりにもテキトーに作った割には他の競合品に負けずとも劣らぬ効率を叩き出せてちょっとびっくりである。その分制約も多いけどな。そこが燃える！

2014.01.09

設定補助 (安定性向上)

　GUI処理は、ほとばしるパッションに任せて勢いだけで作っちゃった代物だったので、山のようにバグがあった模様。えー、なんだ、スマン。これから毎日デバグしようぜ？
　前回設定した内容が正常に画面に反映しないバグを修正。
　デフォルト値の色指定が正常に行なわれないエンバグ(20140109版で発生)を修正。(20140109a)
　Windows XPで設定が正常に反映されないバグを修正。(20140109b)

　愛が足りなくてコードの削りが甘かったと反省して、持てる科学力のすべてを投入して128バイト程度さらにサイズを削った。これによりGUI処理モジュールを3KB以下に縮めることに成功。んうぅ～満足。あとはこれを基礎として機能を付け足す感じでやる予定。実はまだ10バイト以上余裕で削れる目星はついているのだけど、これ以上やると新規追加時の保守の手間が別次元に面倒になりそうなため、これは将来に向けて予約ということにしておく。

　そうそう、AZIK/ACTでもGUIを使いたい！という場合は、ちと面倒だけどZIPを展開してskkrule.txtを上書きしてから起動すべし(ファイル名は必ずskkrule.txtにすること)。中身を詰め替えたZIPを作りなおせば、自分だけの専用SKKFEPインストーラの完成だ！

2014.01.11

設定補助 (機能追加)

　設定画面からIMEの初期モードや▼操作モードや■入力モード(擬似カーソル)の表示オンオフの設定を可能とした。
　正直、この忌まわしき逆三角にまつわる選択肢をGUIに入れるべきではないのではないか、との迷いはずっと変わらない……変わらないはずなのだが……。仮にもSKKの系譜を自称するのであれば、たとえそれがハッタリであり子供騙しであり目くらましの一種としての存在であったとしても、この先SKKの利用を志す人たちが、見た目から入れる余地を残すために入れておくべきなのではないかと思い直した。
　ああそうさ！大衆に迎合したさ！笑うがいいさ！

信念は曲げるためにある！

　とにかく、GUIもそうだけど、時として見た目の第一印象ってのはとても大事ってことだ。備えよう。

※ただしイケメンに限……爆破ァ！

　設定項目内容の見直し。さらに趣味全開で項目の配置を見直した。
　設定項目が多すぎてGUIが視界に入った瞬間に脳が焼き切れそうになるので、設定のグループごとに区切り線を表示するように改良。
　今後、差分ファイルなどで機能のオーバーライドやリネーム等をする場合に備え、標準設定では基本的に値を0にすれば機能オフになるような方針としてみた。たかがテキストファイルの数字1つの違いってだけだけど、いつかこれが重要な選択ってことになるかもしれない。
　設定チェック機能を追加。定義ファイルにエラーがあった場合はエラーダイアログが出るようにしてみた。
　上記機能を追加しつつGUIのコードサイズをさらに縮めた。人力……LZ圧縮うぅぅッッ！……命を燃やせェ！

インストーラ (機能追加)

　英語版OSでも根性で文字コードを変換して設定GUIで日本語が表示されるように改良。

2014.01.12

設定補助 (サイズ縮小)

　さらに8バイト削ってついに3000バイトの壁を突破……っ！

2014.01.12

手動更新プログラム (機能追加)

　謎の手動更新プログラム、爆誕！

ソース: 圧縮前のソース
実行: いきなり実行してみる

　極小サイズのスクリプトを実行するだけで、最新版のURL取得→ダウンロード→セットアップ画面の起動までを全自動でやる便利ツールを作ったった。
　見た目からしてテキトーの産物だけど、こいつは実に強力だぜ！

　実はOSの圧縮フォルダを制御してみようと勉強がてら作ってみた代物。なんかWSHの入門ページとかサンプル集みたいなのを見ると、圧縮フォルダの扱いで毎回IEを経由したりしていて、すごい大袈裟な実装になってる……。たぶんこのツールで使っている方法こそが一番シンプルかつ高速で、WSH本来の使いかただと思われるので、この方式をどんどん広めるべき……なんだけど説明文とか書くの面倒だし放置でいいや。明日から本気出す。

　以下ドキュメントより

SKK日本語入力FEP
自動更新機能の試作実装

解説

　最新版のプログラムを自動判別してインターネットから取得し、一時的な作業領域で展開してセットアップ画面を起動します。

　本ファイルをブラウザから直接実行した場合、書庫ファイルは保存されません。
　クラウド(笑)から全てをダウンロードできる環境では、直接実行がお手軽です。

　書庫を手元に残しておきたい場合は、本ファイルを「名前をつけて保存」してから実行してください。
　ダウンロードした書庫ファイルは、カレントディレクトリ上に保存されます。

従来手法との比較

　これまではアップデートの操作に、何かと手間がかかりました。

1. ブラウザを起動してSKKFEPのページを開く

2. ZIPのリンクをクリックしてファイルを開く

3. セットアップを実行

4. その間、次々と表示される承諾云々のダイアログのボタンを押す

5. おおっと、最後に圧縮フォルダを閉じるのを忘れんなよ！

　うわー面倒くせぇ……こんな七面倒な操作、金輪際やりたくない！
　そこで本プログラムの登場です。自動更新機能を導入すると……

1. このプログラムを実行する

2. 最新版のセットアップが起動！いきなりクライマックス！

　これで、アップデートの手間と心理的負担を大幅に軽減できるはず。
　ぜひご活用ください。

2014.01.13

手動更新プログラム (サイズ縮小)

　1,024バイト達成ッ！第3部完！

2014.01.14

手動更新プログラム (機能追加)

　サイズを維持しつつFirefoxからの直接実行に対応。Windows XP + IE6からWindows 8.1 + Firefoxまで手広くサポート。
　今回の実装で、各種ブラウザやOSの違いによる実行開始時の環境の違いやその判別方法が見えてきた。手動更新プログラムはたったの1KBだけど、詰まってるノウハウの濃度は正直、SKKFEP本体よりも遥かに高いし再利用する価値もあるはず。

2014.01.16

設定補助 (機能追加)

　詳細ボタンを追加。
　ボタンをフラットなタイプに変更。

インストーラ (安定度向上)

　tmpフォルダの設定にLFNではない短いファイル名を使っている一部の環境においてインストーラが圧縮フォルダからの起動判定に失敗するバグを修正。

手動更新プログラム (サイズ縮小)

　996バイト達成！
　くぅ～疲れました(ry

2014.01.17

設定補助 (安定度向上)

　ボタンの縦幅を揃えるよう改良。あとサイズ縮小。

2014.01.19

　AZIK設定サンプルを近代化改修。
　AZIK専用インストーラのZIPファイルを自己生成する手動更新プログラムを試作。
　こういう処理をWSHで実現して悪の限りを尽くそうと思う人にはかなり便利な雛形なのではなかろうか？
　前衛的すぎてどうせ誰も使わんだろうけどさ。自分はこの方法こそ、一番利用者が必要としている正しいやり方だと信じてる。

2014.01.20

設定補助 (安定度向上)

　GUI設定で設定に失敗した時のエラー検出を強化。

2014.01.22

日本語入力 (機能追加)

　Vistaで追加されたアプリ側の入力モード制御の仕組み、InputScopeに対応！
　これは何かっていうと、あれだ、パスワード入力欄にフォーカスが移動したら自動的に日本語入力モードが一時的にオフになるっていう、よくあるお節介機能の一つ。SKK使いなら根性で入力モードを管理しろよ！って気がしないでもないんだけど、時代の流れには逆らえないのだよ……。とはいえあって困るものでもないような気もするし、ひとまずどんな操作感覚が得られるのか、まずはやってみる。考えるのは後回しだ！

　というわけで実装してみた。全体的に削りまくったけど、この規模の大改造をやるとサイズ増加はどうしても防げなかった……0.5KBほど無様に肥大化してしまった……だがもうサイズは気にしないって決めたんだ！……気にしないなんて無理だぁ～

　対応している入力スコープは以下の通り。

enum InputScope	入力モード
IS_HIRAGANA	ひらがな
IS_KATAKANA_FULLWIDTH	カタカナ
IS_KATAKANA_HALFWIDTH	半角カナ
IS_ALPHANUMERIC_FULLWIDTH	全角英数
IS_NUMBER_FULLWIDTH	〃
IS_DEFAULT以外	半角英数

　ぶっちゃけパスワード入力欄以外で使うことなんて、この先二度とないんじゃないかなって気もするけど、こういうのは自己満足できることが大事ってことで。僕、満足！

　なお、Windows8.1の素敵な(クソ)仕様に合わせて、入力スコープの制御下にいる時にIME制御を受けた場合は、制御を無効化するようにしてある。忌まわしきOS標準の顔デカタッチキーボードが、あらゆる局面でIME側の日本語モードをオンにしようと攻撃を仕掛けてくるので、IME側はひたすら防御しないといかん模様。この攻撃に気付いた時は紅茶だよと騙されてコーヒーを飲まされた艦娘みたいな顔になってしまってファッキン。ファッキンべいてい～！！そろそろあの設計ミスとしか思えないタッチキーボードのウザい挙動を我みたいな底辺の負け組ヒューマンにも弄らせてくりゃれ？

座標サイズ配列透明度デフォ入力モード……つか全処理総入れ替えレベルでIMEと独立して弄らせろやｺﾞﾙｧ

　ちなみに、この機能を試すには、当然ながらアプリ側が対応していないといけない。現状ではまだWindowsの設定入力欄などの一部でしか使えないかもしれない。とりあえずはIE11を使うのが一番手っとり早い。C#で独自アプリを作ってフォームのInputScope設定を変える、なんて手もある。
　あと、実はFirefoxでも設定を変更してTSFサポートを有効化することで、この機能を試すことができる。intl.enable_tsf_supportをtrueに設定して再起動すべし！(falseにすればいつでも戻せる。あとこの設定項目の名称は将来変わるとのことなので今後の動向に注目)
　Firefoxは日本の開発者が精力的に改良していて、いずれこのTSFサポートもデフォ有効化されるとのことで大期待してる。長年使い慣れた主戦力アプリで、個人的に簡単なアドオンを公開するくらい愛着もある。これで日本語入力まわりの表示や入力状態が正確に扱われるようになれば、さらに素晴らしいものになるはず。
　今回の改良は、こうして今後どんどん増えるアプリ側のTSFサポートに備えた準備ってことでひとつ。

2014.01.23

日本語入力 (安定性向上)

　一部のターミナルエミュレータ(cmder)で、起動直後の1回目のキー入力が無効化されるバグの報告を受け、調べてみた。UIレスモードの調査用の処理(TSF)が、アプリ側でIMM32エミュレーションを経由して伝わるうちに「候補一覧表示すんぞ？」みたいな状況に見えてしまうらしく、その時なぜかアプリ側ではキー入力を無効化する処理が実装されていてこれが問題になっていた。
　正直、アプリ側を直すべき……って気がしなくもないんだけど、TSF側の処理フラグをいろいろ設定してみたらIMM32側に影響が出ない動きが実現できることがわかって無事解決。こうして、人類はバッドノウハウをどんどん蓄積していくのであった……

2014.01.24

日本語入力 (安定性向上)

　Webブラウザなど、InputScopeとは異なる方式でIMEを一時無効化しているアプリの入力状態を言語バーに正確に反映するよう改良。
　特に、Windows 8以降の環境ではCorvusSKKやMSのIMEサンプルと同じ挙動になったはず。
　この件、TSFのAPIマニュアルには、キーボード(≒日本語入力)の無効化状態を取得する方法としてGUID_COMPARTMENT_KEYBOARD_DISABLEDってのが書かれてるんだけど、実はこれだけでは駄目でGUID_COMPARTMENT_EMPTYCONTEXTも同時に調べないといけないってことらしい。それどこ情報……どこ情報よ……
　なお、Windows 7以前の環境では、IMEによる入力不可能な状態だと言語バーが窪んでIMEの入力モードが表示されるようになっている。MS-IME等と比べて動きが違うように見えるけど、実は~~手抜き~~この動きは

この禁止状態が解けたら、故郷に帰って次のモードで文字入力するんだ……！

　というSKKFEPオリジナルの追加機能なのです。(ｷﾘｯ

2014.01.25

日本語入力 (安定性向上)

　コマンドプロンプトで日本語入力モードが表示されないエンバグ(20140123版で発生)を修正。
　実はこのあたりの挙動には、すべて擬似カーソルまわりの処理が関連している。
　擬似カーソルはMS-Office系と強烈に相性が悪いせいでデフォ有効化を断念してむせび泣いた無念の機能だったけど、なぜ相性が悪いのかとか、アプリ種類によってどういった設定を抑制しないといけないのか、コンポジションの設定タイミングをどう合わせなければいけないのか、などいろいろと問題点や改良点が見えてきたので、そろそろ処理ロジックを世代交代させないといけない段階にきたのかもしれない。面倒じゃのう……。だがオレはやるぜオレはやるぜそうかやるのかやるならやらねば

2014.01.29

日本語入力 (安定性向上)

　一部のアプリでウィンドウのフォーカスを変えた際、InputScopeの取得に失敗して停止してしまうエンバグ(20140122版で発生)を修正。

2014.01.30

インストーラ (安定性向上)

　環境変数TMP/TEMPの内容が存在しないパスを指している場合でも、インストーラが停止せず根性で(OSインストール時のデフォルトパスを使って)動作を継続するように改良。

日本語入力 (安定性向上)

　ウィンドウの表示処理を最適化。これはα版の試作実装の部分的な導入となる。具体的にはウィンドウ生成のタイミングより前に各種リソースの準備を済ませるのと、表示完了時に速やかに画面更新を行なうように改良。システムの負荷が高い状態で変換した際、動作が遅くて表示がもたつくような場面での反応速度を改善したつもり。例によって人類には知覚できないレベルかも。

2014.02.17

日本語入力 (機能追加)

　ここしばらくひたすらαテストをやっていたわけだが、そろそろ機能をこっち(~~リリース~~β版)に持ってくる時期。

αテストをやっていた方へ: αテストのものとは内部の設定方法が根本的に違っているので、一度設定GUIを起動してOKを空押しして擬似カーソルまわりの設定を再設定してから使用してください。

　というわけで疑似カーソル機能を完全再構築した。
　見た目の違いは以下の通りだ。

SKK10での美しい入力

以前の疑似カーソル

改装された新しい疑似カーソル

お分かりいただけただろうか？

　ぱっと見、「ちょっと薄い……カナ？なんか着色されてる？」という印象しかないかもしれない。そもそも、以前の疑似カーソルのほうが、見た目上はかなり近いし、何が良いのやら……、と思われることだろう。
　しかし今回の疑似カーソルも再現度についてはかなり気合いを入れて作っている。よく見ると、変換中もカーソル部分が着色されているのだ。これは、コンポジションによる表現では原理上不可能だった、真のSKKカーソルの表現への挑戦なのだ。

　これまでの疑似カーソルは、コンポジション(変換操作中の文字表示部分)を変換用途以外に応用したちょっとトリッキーな代物だった。このせいで、マイクロソフトのオフィス系アプリで壊滅状態の操作性になっていた。具体的には、シフト+カーソルで範囲選択した状態でカーソル表示をちょっと変更しただけで、範囲選択部分がごっそり消えるなどの問題が存在していた。このせいでデフォルト採用が見送られてしまったという暗い過去を背負っていたのだ。

　今回の疑似カーソルはコンポジションは一切使わず完全な自前描画を行っているため、過去にあったようなアプリケーションのキー入力への悪影響というのは原理的に存在しない。
　ちょっと見た目が細くて色が薄い、影が薄い地味子ちゃん状態なのはご愛嬌。これは気のせいではなくて、通常カーソルへ部分への重ね合わせを半透明を使って自然に行なうための仕様となっている。

　今回の疑似カーソルの実装は、謎のアクセシビリティAPI対応や候補ウィンドウ以外の描画処理、Windows8対応などのさまざまな修行を経てようやく実現に漕ぎつけた、執念の実装となる。
　当然ながら、これだけの機能を実現するために、かなりのサイズのプログラムコードが必要になってしまっている。
　なぜ、小型サイズを至上とするSKKFEPにおいて、こんなしょうもない、SKKの変換操作や入力機能などとは一切無関係な、ショボい表示機能なんかを作ったのか。この程度の処理で2KB近くもバイナリを消耗するとか馬鹿なの？死ぬの？と憤る向きもあるかもしれない。否！

馬鹿め、と言って差し上げますわ

　このカーソルによる入力モード表示こそ、SKKの入力体験の核心部分なのだ。
　これがあるからSKKでは、高速・頻繁に日本語と英字を切り替えても迷わず入力できるのだ。
　……と言い切っちゃうのはちょっと語弊があるけど、少なくとも習熟期を迎えるまでの期間においては、絶大な入力支援能力を秘めているはずなのだ。
　眼球を左右にﾋﾞｸﾝﾋﾞｸﾝさせるだけの▼マークなどとは次元が違うのだよ。
　……仮にまったく役に立たないとしても、リスペクトという名の紳士機能だよ。初めてSKKに触れた時に感動したあのカーソルの表現、強烈に刷り込まれた体験を少しでも現代のWindows上で表現したいという、この思いは誰にも止められないのさ。どんなに世間は厳しくたって、頭の中までは検閲できません。

　………。
　さて……。
　そろそろお約束のお時間です。

やあ（´・ω・｀）

ようこそ、SKKFEPハウスへ。

このSHIFTキーはサービスだから、まず超連打して落ち着いて欲しい。

うん、「また」なんだ。済まない。

仏の顔もって言うしね、謝って許してもらおうとも思っていない。

でも、この機能を見たとき、君は、きっと言葉では言い表せない「ときめき」みたいなものを感じてくれたと思う。

殺伐とした世の中で、そういう気持ちを忘れないで欲しい

そう思って、この機能を作ったんだ。

　そう、つまり……デフォ有効化は今回も断念したってことさ……。

　今回、通常のIMEとは明らかに一線を画す機能を載せているわけだが、そもそもIMEには「常時カーソルを追従する」という機能は備わっていない。変換モードが変化した時にモード表示をする、なんていう一般的なIMEと違い、この疑似カーソルは「常に」カーソル位置を追尾し続けなければならない宿命を背負っているのだ。
　当然、アプリによっては対応が困難なものが存在する。

　たとえばブラウザ。現在の主要なブラウザで、カーソル座標が正確に取れるのは、IE11だけと言ってよい。他のブラウザでは座標は漢字変換中に取れるかどうかといった所。ちなみに、あとほんのちょっとでFirefoxは対応できるかもしれない。
　他にも、MSオフィス系はかなり正しくカーソル位置を取得できるが、LibreOffice系はまるでお話にならない(アクセシビリティAPIやTSF Awareな動作にまったく対応していない。おそらく対応が必要だということを認識してる開発者は一人もいないんじゃねーの)レベルだったりするなど、前途多難な感じ。
　つーわけで多くのアプリケーションは、まだ十分にアクセシビリティAPIに対応していない。困ったことにこのAPIへの対応は義務ではないため、対応が行き渡るにはとても長い時間がかかりそう。

　ではどうするかというと、SKKFEPではアクセシビリティAPIとTSFによる座標更新の2つのデータを同時に取得し、正しそうなほうの情報を使ってカーソル位置を推定しながら動作させている。
　この「推定」ってのが曲者で、100%確実じゃないんだなコレが……。アプリによっては最後に漢字変換した座標をずっと指していたりしてカーソル座標取得への応答がウンともスンともいわないものがあったりする。

　このため……残念だけど……今回もデフォ有効化の夢は断念せざるを得ない……。
　だが、旧方式と違い、オンにしてもアプリの操作系自体に影響は一切ないので、常時オンに設定する敷居はだいぶ低くなっているはずだ。

　ここはぜひ、各自の判断で表示オンにして使っていただきたく。君にだけ伝わればいいやもうほんとに。

　なお、Windows8.1のストアアプリなどの没入型モードでは擬似カーソルが常時有効化されるようになっている(つかこれ以外に入力モードの提示方法がない)。これもやっぱり一部のストアアプリはカーソル移動をきちんと追従できなかったりするんだけど、ストアアプリってのは所謂スクリプトの集合体みたいな代物だし、そのうちOS側で自動的にアクセシビリティAPIに対応してくれるだろう、という希望的観測を信じてみようと思う。

設定補助 (機能追加)

　前述のように、疑似カーソルの動作はまだ完璧ではない。Windowsのカーソル座標をたかがIME風情が正確に取得し続けることは非常に困難な課題となっている。つまり現状では、一部のアプリでカーソル座標が荒ぶってしまうものが存在する。
　そんな困ったアプリに対し、ピンポイントで疑似カーソルをオフにする機能が必要だ。
　そこで、今回、アプリ毎の疑似カーソルの表示変更の設定を行なえるようにした。

rule アプリのEXE名 m12

とコマンドから実行することで、指定アプリの疑似カーソルの表示状態を反転できるようになっている。
例えば、設定GUIで疑似カーソルをオンにしている環境で、カーソル表示がうまくいかないアプリopera.exeに対してのみ、表示状態をオフにするには

rule opera.exe m12

と実行すればよい。なお、解除は

rule opera.exe md

と行えばよい。これは従来のmオプションの指定と同じである。
　この12という値は、初期入力モードの番号である4(半角英数)のビット3を立てた値(8を足した値)となっている。通常、アプリの初期入力モードは4なので、m12と覚えておけば問題ないはずだ。

2014.02.17

　擬似カーソル以外でもいろいろ改良を加えてあるので忘れないうちに記録しておく。なんかもう既に忘れたし。

日本語入力 (機能追加)

　縦書き対応。縦書き部分を自動認識して、外部表示領域を自動で折り返しするなどの処理を追加。

　Windows8.1のタッチキーボード等で日本語モードをオフにした後、物理キーボード側のCTRL+Jで日本語入力に復帰できるよう改良。

　アイコンのドット絵を微妙に修正。圧縮率を向上させ、インストール時のバイナリサイズを0.5キロバイト削減。

　物理アンドゥ系の半角英数モードでの動作制限を撤廃し、最初の実装時と同じ動作に戻した。
　これはAT○Kへの対抗措置である。この程度の機能で新機能とかいって大々的に紹介されやがって！うらやましい！IME充爆発しろ！
　SKKFEPなら1年半前にとっくに実装してんだよチクショウメー！(ドイツ語) ま、ぶっちゃけSKKだとあんま必要ないけどな！
　だからこのまま「知る人ぞ知る」機能のまま埋もれさせておいてもいいかな、と思ったけど、せっかくだからもうちょっと目立たせておくことにする。

設定補助 (機能追加)

　rule a と実行することで、アプリ個別設定を設定したレジストリの一覧を見れるようにした。
　まだエントリ名が見れるだけだけど、そのうちこれもなんとかする予定。目指すは~~アウヤンテプイ~~XKeymacs――

　rule aの機能(レジストリのスキャン機能)、数バイトのコードで手抜き(という名の外部コマンド呼び出し)で実装したら、なぜかAvira先生とWindows SmartScreenが誤検出で発狂することが判明したため、機能を封印。面倒だけど手動で以下のコマンドを実行して代用しておくれ。(20140217a)

reg query HKCU\Software\SKKFEP /f .

2014.02.20

味方から浴びせられる激しい嘲笑の中

私を生き存えさせたのは、ある疑問だった

何故、毎回変換せねばならないのか？

私の見た日本語は

指導部の云うような理想郷ではなく

機械語と同じ不毛の言語だった

既にこの変換操作の目的は失われていたのだ

だが、この馬鹿げた操作自体が

指導部の目的だったとしたら・・・

設定補助 (機能追加)

　註釈部分の選択操作CTRL+Vを追加。でもっていきなりデフォ操作に組み込みだー！
　以下、1行でまとめ。
　連鎖変換機能を試作したけど糞すぎたので封印。選択機能のみ部分的に採用。以上！

　事のはじまりはSocialIMEへの一つの疑問だった。
　SocialIMEのメリットとは一体何なのだろうか。
　やはり、何といってもあの無駄にカバー範囲の広い語彙にあるのではないかと思う。

　例えば「まりさ」で変換するだけでこんなに候補が出る♺わけだ。

　よく見ると、変換しようとする単語そのものではなく、関連する単語や用語・概念など、あらゆる範囲の単語が登録されている。
　これはSKK的な、いわゆる厳密な「漢字変換」という考えからするとあまりにも滅茶苦茶であると言わざるを得ない。そもそも漢字変換が目的のはずのIMEにおいて国語辞典を引くような動作になってしまっている。
　すなわち、SKK的な、変換精度という面のみで評価するならこれは最悪レベルであると言ってよい。

　でも、なぜだかこの変換は憎めない。悪いとは思えない。なぜ？どうして？悔しい……でも……ﾋﾞｸﾝﾋﾞｸﾝしてるうちに病み付きになっちゃうレベル。冷静に考えても、正直、こういった変換候補を使う場面は殆どないはずなのだが、こういう人間臭い候補が提示されることにより、すんごい親近感が持てるというか、何というか性能で表せない良さがあるのではなかろうか。

　と、ここまで分析できたなら、あとはもう妄想電波の命ずるままに進めるだけである。
　SKK的な変換精度を保ったまま、この旨みをSKKにも取り込みたい！
　――でもどうやって？

　ここで生きてくるのがSKKの註釈情報である。註釈情報は、SKK10の頃にはなかったデータである。
　正直SKKFEPを作るまでは註釈なんてｲﾗﾈと思ってた。

　しかし、ぷよぷよテトリス画像を漁った直後にトイレで滑って頭を便器にぶつけた時にふと余計なことを閃いてしまった。
　註釈を常時表示で使うようになり、動体視力が追いつくようになってきた今、

この註釈部分も日本語入力に活用できるのでは？

　というわけで早速試作したのが20140219alpha版である。ﾋｬｯﾊｰ！

　これは、漢字変換中の候補の註釈情報をカンマ区切りのCSVと見做して、その内容をもとにさらに変換操作を行うというものである。名づけて「連鎖変換」である！

　今回、操作には、CTRL+Vを採用した。従来、動的補完から予測変換に入るのに．とか↓とかCTRL+Nを使っていたわけだが、これをそのまま適用するとすんごい混乱することがわかったので、Emacs系の次ページへの変更操作を採用した。Emacs使いであればそれなりに馴染む操作のはず。

　例えば、

ろてい変換CTRL+V変換ENTER

　と操作すると、「露呈」の註釈である「expose」を使った変換が行われて「エクスポーズ」が出てくる。
　つまり、うまく辞書データを作り込めば、変換した結果をもとにさらに変換を続けていって関連用語などを入手できる、という、SKKの辞書内で完結する一種のハイパーリンク的なことができるわけだ。

　……で、ここまでは順調だったのだが問題も多いことに気付いた。例えば以下のような例だ。

じだいさくご変換CTRL+VCTRL+V

　のような操作をすると、CTRL+Vするたびに「アナクロニズム」「時代おくれ」が出てくる。
　ただ、どちらもこのままではSKKで変換できない。変換するためにはアルファベットかひらがなの読みになっていないといかんのだ。(もちろんただ確定させるだけでよい、ということであれば問題ない)
　もちろん、註釈の編集で「anachro,じだいおくれ」みたいに修正すれば、望みの結果が得られるが、こんどは『註釈の見た目がバカっぽくなってしまう』という問題に直面する。
　また、そもそもCSVの区切りは万能ではない。CSVが通用するのは体感で全体の1～2割といったところ。このあたりをきちんと統一していれば、汎用単語間連想ハイパーリンク型データベースとしての活用の道が開ける時が来るかもしれない。

　あと、もっと深刻な問題も出てきた。「そもそもほとんど使わない機能のくせにプログラムサイズが無駄にデカくなってしまう」といういつものアレと、「そもそも、変換を何度も行うこと自体が無駄なのではないか？」という根本的な問題である。SKKの設計思想に従うなら、可能な限り少ない変換回数で目的の単語に確実に到達できることこそが大事なわけだ。

　要するに、単語入力→変換→選択→変換という人間の判断が何度も入るような操作系よりも、元ネタのように単語入力→変換の1ステップでできるような専用辞書を用意するという、至極真っ当な、従来のアプローチのほうが遥かに実用的なのでは？と我に返ってじっと手を見る羽目となってしまった。

　ざんねん！SKKFEPの冒険はここで終わってしまった！

GAME OVER

　というわけで、可能性を感じつつも、この機能は一旦凍結し、「註釈部分を入力部分にスライドさせる」(註釈部分を確定して入力できる)機能のみ採用することにした。これならプログラムの実装を超単純化でき、操作に関しても入力→変換→選択と1ステップ操作が増えるだけで済む。註釈部分のコピペ入力、名づけて「連想変換」誕生の瞬間である。

　本当はコピペ入力というのは正確な表現ではないのだが、CTRL+VがWindowsでのコピペ操作と類似しているのと、実際画面に見えているものがコピーされるという動作から、まあそれほど動作説明として違和感はないだろうということで採用した。

　とにかく全ては、L辞書の完成度の高さの賜物である。L辞書は通常変換の用途だけでもすばらしい精度を持ち、他のIMEと対等に戦えるだけの十分な内容を提供してくれているわけだが、今回の機能追加によってさらにより多くの情報をユーザが享受できる、ということだ。

　例えばブラウザのURL入力欄で

るーぶるびじゅつかん変換CTRL+VENTER

　と操作するといきなりURLを入力できたりする。

　従来、この手の変換はネットの向こう側でやるものだ、という先入観があった。我ながら人間電池として飼い馴らされた者の末路って感じである。
　で、この変換がローカルでできてしまうってのは、一種のG○ogle避けみたいでなかなかの新感覚っぽい。

　さて、最初の途方もない構想からはだいぶ離れてしまった気もするが、まずはこの操作を採用してどんな感じになるか見てみることにする。というわけでデフォ操作に追加だｲｪｰ！

　あ、標準操作データ部分が差し替えになったので、GUI設定で操作変更してた場合は、いちどGUI設定を起動してOK空押しが必要ってことでヨロ。

2014.02.21

日本語入力 (安定性向上)

　物理アンドゥ後の単語登録が正常に行えないエンバグ(20140220版で発生)を修正。α版からさらにサイズを削りまくったのだがこの部分が問題を起こしていた。だが我々人類はサイズ縮小の夢を決して諦めないッ！

設定サンプル

　標準設定の更新に合わせて、AZIK/ACTの設定内容を近代化改修。

2014.02.25

日本語入力 (安定性向上)

　候補を大量に持つ漢字を変換し、かつ候補一覧が表示された状態で絞り込みを操作を行い、キー操作を何度か行なった後にCTRL+Gでキャンセルすると高確率で停止するバグ(状態遷移の考慮漏れ)を修正。

インストーラ (安定性向上)

　Windows XPの一部の環境において、アンインストール時にL辞書データを削除してしまうバグを修正。

設定補助 (機能追加)

　表示系の設定項目に「未確定子音の半角表示」を復活。以前、このあたりの設定をかなり大胆に弄ったことをすっかり忘れてた。
　pオプションの数値を微妙に変更(p1→p9)。+8すればとにかく半角文字になるようにして処理を単純化。設定内容は同じで数値が変わっただけなので、以前の版でp1に設定済みの場合はそのまま放置で問題なし。

日本語入力/インストーラ (機能追加)

　Windows XPにおいて、インストール時に「既定の言語」で選択されているキーボードマップを代替キーボードとして使用するよう改良。インストール時にWindows XPで動作させるための(呪われた)初期化設定まわりを最小限に削減。
　これによりMS-IMEのかわりにskkime/SKKIME1.5改を代替キーボードマップとすることも可能となり、MS-IME系の完全除去を可能にした。(アップデート前に「既定の言語」を切り替えておけばよい。SKKFEPが既定となっている場合は以前の設定を引き継ぐ)
　この変更により、海外版のWindows XPで初回インストールする場合に、事前に若干の追加設定が必要となる。コントロールパネルのテキストサービスと入力言語から何らかの日本語の入力言語用サービスを先に設定しておく必要がある。

2014.02.27

あらゆる困難がオンラインで解決する

この平成の時代

L辞書の閉ざされた心の闇に蔓延る

魑魅魍魎(Emacs Lisp)が存在していた

辞書検索ではどうしようも出来ない

その奇怪な輩にたちむかう

神妙不可侵にて胡散臭い漢が一人

その名はSKK野Gate麻呂

そう……人は彼を陰陽師(エミュレータ)と呼ぶ――

辞書プロセス (機能追加)

　SKKGateとの統合に向けて、初版からずっと封印されていた辞書プロセスのリミッターを解除。L辞書に登録されたLisp命令を利用できるようにした。
　これはSKKFEP単体で使う場合は珍妙な文字列が出るだけの改悪となるが、SKKGateに追加されたハッタリLispエミュレータと組み合わせることでL辞書の魅力をフルに発揮できるようにするのが狙い。
　詳細はSKKGateの更新記録および以下の解説を参照。どーまんせーまん。

参考: SKKGateにおけるEmacs Lisp命令のエミュレーションについて

　たまには(いつもの)愚痴を書いておくことにする。
　そもそもLisp除去処理などを考慮しないといけない、という時点でまずL辞書のデザインを疑うべきなわけ。
　冗談抜きでL辞書には不幸な魑魅魍魎が詰まっている。おそらく、SKK10の頃からある(skk-today)や(skk-times)のような『簡潔な名称を使ってポータビリティを維持すべき』『Lispが動かず、命令がそのまま利用者にポロリと露呈しちゃっても影響を最小限にすべき』と、初期のL辞書のデザインを決定したかつてのメンバーはもう開発陣には残っていないのだろう。
　L辞書のポータビリティなぞ微塵も考えない思考停止した連中が、Emacs Lispの表記を誇示したいだけの素人が作った長ったらしくて扱いが面倒な内部処理向けの機能を、名称や機能(他にも引数の指定方式の統一性など)を厳選せずそのままL辞書に突っ込むといった暴挙を何度も繰り返してしまったせいで、醜いエントリができてしまっている。まさに不幸の連鎖である。todayのエントリがどれほどおぞましいものになっているか、興味がある奴は調べてみるといい。そしてポロリして思う存分震えるがいい。(とどめに、このエントリは当のSKKですらまともに実行できないものがあって涙する)
　こういうのは一刻も速くL辞書から分離して、もっと気軽にLispの限界に挑戦できる場(SKK-JISYO.gadgetなどと銘うった専用辞書)を用意すべきなのだ。その上で、誰でも気軽に開発に参加できるようにすれば、Lispを書いてSKKの機能アップに挑戦する人も、Lispインタプリタを開発・検証する人も、SKKクローン(L辞書の処理系)をゼロから構築する人も、全員が幸せになれるはず。

　書き殴っているうちになんか大量に思い出したが、数値変換の#8をなんとかしてL辞書に導入して普及させなければならないし、SKKプラスによる送りがな補正フォーマットの普及についても考えなければならない。次の一手をどう打つか。名もなき冒険者の孤独な戦いは続く。

2014.03.02

……どうやら俺たちはとんでもない間違いをしてたのかも知れない。これを見てみろ。

予言書にはこう書かれている♺。

『人間の目が一度に認識できるのは13文字程度』

SKK10のデフォ設定では一度に表示される候補は7つ

候補一覧が出る条件は、5回以上の変換の施行であり

これだけの回数の変換が必要な候補は殆どが2文字

ここから導き出される数値は7候補×2文字＝14文字

この奇妙な文字数の符合……まさか……いや間違いない……

つまり……

人類はSKKによる最終破局(カタストロフィー)によって滅亡する！

ΩΩΩ『な、なん(ry

設定補助 (機能追加)

　2つ設定を追加。
　1つはGUI設定に候補一覧表示用ウィンドウの表示幅の設定項目の追加。
　もう1つは註釈表示の設定項目の追加。

　ウィンドウ幅は候補一覧の時の視線の動きなどを考慮して、おすすめ幅として480ドットと800ドットの2つを用意した。他にも、縦一列の設定も追加。
　文字を読む時、物理的な視線の移動だけに80%の時間がかかる、というデータに衝撃を受け、なるべく各行の横方向の視線移動を減らすデザインを取り入れた。
　480ドットというのは、96DPIの解像度で16ポイント付近の文字を使い、2文字の変換候補が7つ並んだ時のウィンドウの幅となっている。
　視線移動なしで人間が一度に認識できる文字数を各行に表示する、という意図によるものである。(行内にはアルファベットによるキーボードのマーク等も表示されるため、厳密な文字数としてはこれよりずっと多いのだが、マークは記号であり候補選択時の認識とは異なる部分で処理されるはずと考え、ここでの文字数からは除外している)
　また、800ドットは、互換性の観点からCorvus-SKKのデフォルト値に合わせた。
　なお、今後HighDPI対応のスクリーンで使う場合に備えて、横幅のドット数はruleコマンドからの設定の値を維持できるようにしてある。表示幅の設定で「他」を選び、コマンドプロンプトで rule w幅と実行することで、これまで通り任意の幅を維持できるようになっている。

　これで視線の移動距離が減ってますます己を高速化できる……と思ったんだけど……。
　実際使ってみると、候補一覧が横一列に並んでいないと、あまり見やすくない……。なぜだ……。

　そこで更に考えた。
　従来の註釈表示の設定項目は「なし」「表示する」「候補一覧の時のみ」となっていた。つまり「なし」以外の設定では、候補一覧の時に註釈が表示されるために横方向の文字数が増え、視線の移動距離が増えてしまう。
　そこで、視点を維持したまま選択しやすいよう「変換中のみ」の(候補一覧の時だけ註釈を表示しない)モードを追加した。

　もしかすると本当に必要なのは、この設定だったのかもしれない……と思ったんだけど……。
　これも実際使ってみると、文字数の同じ単語ばかりになって、あまり見やすくない……。なぜだ……。
　もう註釈なしでは同音異義語とかを素早く選べなくない体になってしまったのかもしれない。

　つまるところ、個人的にはデフォルト設定にしている「註釈あり・横一列」以外の設定は操作性低下しか感じられず、選択肢としてはまるでありえないという感じなのだが、正しいと信じる根拠のある値を選んでいるつもりなので、もう少し使い込んでから判断してみようと思う。

日本語入力 (安定性向上)

　Abbrevモードではなく雪花を使ったvi式罫線入力(Hjkl等)を全パターン行なえるようにするため、j+方向のルールを除外した。
　そもそもこのルールは、レジストリが空のインストール直後やお試し中などの状態で、内部テーブルを極力小さくするために血の涙を流しながらサイズを削っていた時の名残りで、6バイト縮めるために発生した一種の副作用のようなものだった。
　6バイトくらい、操作性向上のためならくれてやらァ！ということで元に戻した。これで全パターンで罫線が正しく動的補完されるようになってめでたしめでたしである。
　なお、設定を変更して使っていた場合、「設定」を出してOKボタンを空押しする必要があるので要注意。今後、何か内部のデフォルト設定が変化した場合は、大抵このOKボタン空押しが必要になると思っておいたほうがいいかもしれない。

　Windows 8系で言語バーを表示する設定にしている際、日本語入力時に入力モードアイコンが言語バーから消えてしまうエンバグ(20131226版で発生)を修正。(20140302a)
　Windows 7と8以降で言語バーの挙動が違いすぎﾜﾛﾀ……わろた……

2014.03.04

インストーラ (安定性向上)

　IEコンポーネントが取得できなかった場合、取得できるまで待機するよう改良。
　設定GUIのウィンドウが最前面に開くよう改良。

2014.03.05

日本語入力 (機能追加)

　候補一覧などが表示される外部表示領域の表示幅を、システムDPIの拡大率に合わせて調整するよう改良。
　例えば幅に480(rule w480)を設定した場合は、100%の時は480ドットとなり、150%のときは720ドットとなる。
　既にフォントには拡大率が適用されるようになっていたので、システムDPIを変更しても候補一覧の表示レイアウトは維持されるようになった。

　なお、Windows 7～8では「画面の解像度」→「テキストやその他の項目の大きさの変更」でこの拡大率を設定できる。Windows 8系では最大500%まで指定できちゃうけど、キーボードのないタブレットPCなどで調子に乗ってホントに500%とか設定すると戻せなくなって凄いことになる♺ので注意でおじゃる。

2014.03.06

インストーラ (安定性向上)

　インストーラのアップデートボタンの表示を「最新版です」から「リフレッシュ」に変更。
　将来SKKGate側スクリプトを統合した時、スクリプトの不備などでうまく動かなくなってしまった、とか、社会派ジョークソフトの妨害からの復活とか、とにかくピンチを切り抜けるために辞書プロセスの再起動などを1ボタンで行うことができる、必殺のお助けボタンとして使うことを想定している。
　要するに、気軽に押しまくってもいいのよ？的な雰囲気を醸し出すネーミングが大事ってこった。

2014.03.08

インストーラ (安定性向上)

　セットアップツールの起動時にGUIウィンドウがなるべく最前面に配置されるよう改良。
　その他、インストーラの内部動作にかなり大胆に手を入れた。全てはSKKGateとの統合のため。はいはい民のため民のため。
　XP/IE6と8.1/IE11(開発環境は7/IE8と7/IE11)の両極端の環境で動くようになったので、ひとまず公開。

　つーか、これまでの版だと、GUIウィンドウがかならず画面の奥に表示されてイライラ感ﾊﾟﾈｪって感じだったので、ずっと直したかったのだよ。
　でも……IEやIEコンポーネントの挙動の全てが謎すぎて、何をやっても挫折の連続であった……。ただ普通に、一般的なアプリケーションウィンドウとして開くだけという単純明快なクエストの、なんと難しいことか。セットアップを起動するたびに悔しくていつもﾋﾞｸﾝﾋﾞｸﾝしてた。
　だが、そんなことでは駄目だ！
　己の持てる科学力の全てを投入して最前面に来るようにしてやった。どうよ！
　まだ完璧ではないっぽいけど……クソ挙動すぎた前のものよりはだいぶ良くなっているはずだ。
　そりゃさ……完全無欠を望むなら、Web技術に頼らずインストーラを標準的なもので作り直すべきなのは重々承知なんだけどさ……こっちのほうが断然面白いし、いいじゃん！スゲーじゃん！

　ちなみにこのインストーラは、ろくにバイナリ化もされていない素朴なスクリプトコードだけで記述されているが、その実体はDLL本体のバイナリに勝るとも劣らぬ究極のノウハウの凝縮体となっている。私がそうが思うんだからそうなんだろう、私ん中ではな。
　あるOSの特定バージョンとIEの特定バージョンの組み合わせで動かない系の問題とか、IE6でも動作するための処理を入れたらIE8以降が全滅、みたいな問題とか……そんなエクストリームな環境に漬かってしまったコードには、Windowsの深い闇に対抗するための呪文が大量に刻まれているのだ。(プログラマの)人間性を捧げよ。
　もし君が、この最新版を使ってみて、管理者権限を取得する時の表示がWSHからコマンドプロンプトに変わっていること(さらに、中身は単にcmd /c startが追加されているだけであること)に気付いたとしたら……そして初版SKKFEPのインストーラが全てバッチファイルで作られていたという衝撃の事実こそが、この最前面化を達成するための重大なヒントとなっていたことまで見抜けたのであれば……君もまた、名探偵としての素質があるということなのかもしれない。

　以下、その他の修正内容。
　起動時にIEコンポーネントが取得できなかった場合、起動中のダイアログを出しつつ、最大20秒間、オブジェクトの取得を繰り返すよう改良。そのまま放置しておくと、だいたい8～16秒くらいで取り戻せる模様。これまで「少し時間を置いてから実行してください」と出て止まって泣いてた人もいたのではなかろうか。もう、大丈夫だ。
　日本語OSで動作している場合、JavaScriptソース部分の文字コード変換をせず極力元のバイナリ配列を維持したまま動作するよう改良。
　拡張スクリプトを起動する場合に備えて、辞書プロセスの再起動シーケンスを変更。インストール関連処理が完全に完了してから再起動を行うよう変更。将来、このタイミングで拡張スクリプトを同期して動かすようにする予定。
　「辞書最適化」のチェックボックスを切り替える条件が、「アップデートやリフレッシュを行って管理者権限を取得した直後」かつ「辞書の更新ボタン(リフレッシュボタンではない)を押した場合」のみとなっていたせいで、かなり分かりづらかったので(てか、作った本人も忘れていたのだヲ！)、ウィンドウが管理者権限を持った状態でリフレッシュボタンを押したタイミングでいつでも反映できるように改良。
　要するに、カタカナ辞書のON/OFFと同じタイミングで操作できるようにした。あとは同じタイミングでスクリプトのON/OFFもできるようになれば……これだ！ようやく出口が見えてきた気がするヲ！(フラグ)
　ボタン類をポイントした時マウスカーソル形状が変化するよう改良。
　チェックボックスのラベルもクリックに反応するよう改良。

2014.03.08

インストーラ (機能追加)

　システムのDPIスケーリングに合わせてウィンドウサイズ等を調整するよう改良。
　なお、管理者権限を取得している状態では、自分のスケーリング設定ではなく管理者側の設定が適用されるため微妙にウィンドウサイズなどが変わるかも。(一般的な環境で使っているぶんにはあまり気にならないはず)

設定補助 (機能追加)

　こっちも、システムのDPIスケーリングに合わせてウィンドウサイズ等を調整するよう改良。
　IE11の環境の一部で、IEのフォント設定をメイリオ系にしているにもかかわらず、何故かボタン部分にMSゴシックなどというオゾい形状が出現し世界を混沌に陥れようとする~~IE11のバグ？~~Micr○softの陰謀への対抗措置を追加。

2014.03.18

インストーラ (安定性向上)

　64ビットOS環境で、32ビットのランチャー系アプリなどを経由してセットアップを起動し、かつセーフモードで起動した場合に、インストーラのウィンドウが亜空間に引きこもってしまいインストーラのメニューが表示されないバグを修正。
　ついでにインストール手順のドキュメントの内容があまりにも古すぎて現状と合っていない部分が増えていたので、少し直しておいた。

2014.03.29

日本語入力 (機能追加)

　α版で試作していた機能を取り込んだ。プログラムサイズをそのままに、以下の全ての機能を追加した。正直、自分でもどうやってこんだけ詰め込んだのかよく思い出せない。

1. 疑似カーソル表示のオン・オフ操作機能を追加

　コンポジションが表示されている状態で、CTRL+］を2回叩くと表示が切り替わる。
　AAで表現すると、要するにこういうことだ。

　 _ 　 ∩
(　ﾟ∀ﾟ)彡
　⊂彡　　

　CTRL+JOppCTRL+］CTRL+］……のように操作してみると、疑似カーソル表示のオン・オフが力一杯切り替わる様子がよく分かるはず。いっぱい！いっぱい！
　これにより、疑似カーソルのデフォルト表示設定が何であっても、状況に応じて表示を切り替えられるようになったので、多少は便利に使える局面も出てくるのではないだろうか。
　

……実はこれ、エイプリールフール用の一発ネタとして実装してたんだけど、
なんか思ってた以上に便利っぽいので本採用しちゃおうかな、みたいな……

2. 送りがな表示処理を過去の版と同様に復元

　第二世代疑似カーソルの導入時に発生した描画処理のデグレード(送りがなの色分け表示処理が古くなっていた)を修正。これで表示系は、第一世代疑似カーソルの最終版と同等の表示能力を取り戻したことになる。この処理をここまで押し込めるのに大量の人間性を消耗してしまった。こうして人は亡者になってゆく。作り直しを決意してからここまで、長い戦いであった……。

3. TSFコンパートメント(IMM32 API経由)による入力モード制御に対応

　Windows Formsなどの入力領域の属性になるべく合わせて動作するよう改良した。既に実装済みのInputScopeと同様に、アプリケーション側の要求する入力モードに追従する。
　設定値と実際に反映されるモードの対応は以下の通り。

FULLSHAPE	KATAKANA	NATIVE	入力モード
0	0	0	半角英数
0	1	1	半角カナ
1	0	0	全角英数
1	0	1	ひらがな
1	1	1	カタカナ

　Windows 8/8.1でこの機能を使う場合は、「言語設定」の「詳細設定」で「アプリウィンドウごとに異なる入力方式を設定する」を有効にすること。実は今のところ、こんな設定なんていちいちしなくても動くんだけど、将来に渡ってこのままという保証はないので……まーでも永遠にこのままっぽい気もするので、別に何も設定しなくてもいいかも。とにかく、MSの理不尽極まりないIMEのデザインに迎合する気なんて今のところ微塵もないんで宜しく。でもあらゆる状況から即座に掌を返せるオトナの練習は怠らないぜ！

4. TSFコンパートメントによる制御を完全無効化する特殊設定を追加

　これは、Windows 8.1タブレットにおいて、コマンドプロンプトに「ipconfig」などと打ち込もうとしてタッチキーボードを開くたびに、わざわざ、毎回、いちいち、ｸｿｯ、ご丁寧に、日本語モードに切り替えてくださりやがるあの最高に無能なデザイナーどもによる公害としか言いようのない素晴らしきディストピア万歳挙動を無効化する、ただその一点のためだけに実装した、特殊機動である。
　劣悪なタッチキーボードしか選択肢がないような極限状態で、全てを犠牲にしてでも入力モードの決定権をマイク○ソフトから奪還して人間に戻りたいといった場面において、覚悟を決めた上で使うべし。

5. 変換キーにIMEの切り替え操作を割り当てる設定を新たに追加

　前述の特殊設定が有効な場合、タッチキーのIME制御キーもろとも使えなくなってしまうため、代替操作として変換キー(次頁キー)によるIME切り替え設定を追加しておいた。上記設定と併わせて利用すべし。(なお、この設定と物理アンドゥ操作は排他となっているので留意すること。)
　あと、タッチキーボードの前頁キーに無変換キーの操作を割り当て可能なよう拡張した。

6. カラーパレットを4色追加し、計16色に増強

　実はカラーパレットの扱いは、β0+iの時から今までほとんど同じだったのだが、動的補完の時の文字と単一候補発見時の表示色を、当時のコードサイズと科学技術の限界ぎりぎりで表現できる12色の中に無理矢理詰め込むため、使用頻度の低い全角英数のカーソルのパレットを泣く泣く潰して他の色を割り当てていたのであった。全角英数モードは犠牲になったのだ……。
　『たかが色データを数個追加する程度で、一体何が難しいんだ？』……と不思議そうな顔をしている諸兄姉もおられることと思う。が、しかし！よく思い出していただきたい。今回、コードサイズはほぼ同じ情報量(ZIP書庫のサイズが同程度)なのだ。IMEでは1色あたり4バイト×9個、すなわち36バイトの属性テーブルが必要なので、4色増やすためには144バイトの情報が必要だ。そして、増えたデータの部分を操作するための処理をどんどん追加実装しないといけない。何も考えずに全て記述していたら、どうやってもサイズが足りなくなってしまう。よろしい、ならば圧縮だ！……となるわけだが、生半可な詰め込み方をしてしまうと、バイナリのエントロピーをいたずらに増大させるだけで、結果、ZIPの圧縮率がガンガン下がって書庫が肥大化してしまうという逆転現象に泣く羽目になる。困った……一体どうすれば……Zzz……はっ！
　なんかいつの間にか~~魔法少女~~妖精さんが超軽量マジカル圧縮パワーで詰め込んでくれました。てへぺろ。ﾃﾞｭﾌｺﾎﾟｫ❤

7. 疑似カーソルの全角英数モード表示を追加

　今回のパレット追加によって、全角英数モードの時も疑似カーソルに色がつくようになり、全モードの判別が可能となった。長かった……。なお、このモード表示用のパレット色は、Emacs20+SKK10のデフォ設定時のカーソルの色と同じ。スクリーンショットを取ってドットの色コードをコピペしただけの簡単なお仕事である。
　なお、前述の2色に加えて▽▼マークの表示属性2色を独立して指定できるようになっているが、べっ別にこれはたまたま、たまたまなんだから！あくまで暫定措置なんだからねっ！(赤面)……とはいえ本当に他の用途とか余計な機能を思いついた時は、また属性を統合(旧バージョンみたいな灰色表示化)する場合もあるかもしれないので悪しからず。

8. デフォルトのカラーテーマを変更

　変換中の時、選択状態で反転表示+下線としていたのだが、反転表示にしている状態と、エディタなどの領域選択状態の判別が難しい局面があるということに気付いたことと、MS-IMEなどの一般的なIMEの表示方式との兼ね合いを考えた結果、反転表示はデフォルトとしては持たないほうが良い(必要に応じて設定で対応すべき)、との結論に至った。
　旧バージョンと同じカラーテーマなどの設定をこれから用意していくので、各自必要に応じて適用すべし。
　旧バージョンにあった伝説の戦士(ryの設定等はこれから対応予定。
　一応、レジストリキーの「Col」を「Pal」に書き換えるだけで、それなりに動くはず。
　本当はもうちょっと簡単に色変更とかテーマ設定とかできるようにすべきなのはわかってるんだけど、めんど(ry

9. そのほかカラーテーマが続々登場……？

　SKKの画面がｷﾓｲｷﾓｲというのが日課のｷﾓｲｷﾓｲ星人の皆様が安心して寝過ごせるようにMS-IME風テーマをご用意。
　「あぁ～今日もMS-IMEが快適だわ～」とミサワ顔で開始したら、
　「見たことない色のIMEﾃﾞｽ」「これSKKだ！」「ﾌｧｯｷﾝ」と続けて頂く予定調和の様式美へ。
　なお、このテーマを使っている時の外部表示領域(疑似コンポジションエミュレータ)に下線の太線がないと表示属性の見分けがつかないため、太字下線の表示モードを追加した。ちなみにこの領域内では、下線同士がくっついて表示される仕様なんだけど、実はこれは通常のコンポジションと微妙に見た目が違ってる。でも、試しにくっつかないように変更してみたら……うわっ、私のSKKFEP、ｷﾓすぎ……？
　うん。くっついたままのほうがいいや。D・V・D！D・V・D！
　ちなみに、どうやら最近のMS-Office2013とかのコンポジション独自描画でも下線部分は見事にくっついているので、きっとこれが全宇宙(マイク○ソフト)の意思。MS-Officeと一緒だと嗤えばいいと思うよ。

10. アイコンデータの圧縮率をさらに向上

　アイコンのドット絵を同一形状に保ちつつ、若干のサイズ縮小に成功。

　うーんまだ他にもネタがあったような気もするんだけど、手持ちの人間性を使い切ってしまったので、今日はそろそろこのへんで。

設定サンプル

　標準設定の更新に合わせて、AZIK/ACTの設定内容を近代化改修。

インストーラ (安定性向上)

　DPI設定に合わせたウィンドウや文字の拡大率を、インストーラを起動したユーザの設定に一致させるよう改良。従来は管理者権限の時は管理者のスケーリングに合わせていたため表示サイズが変化する環境があったが、こうした環境でも常に同じ縮尺で表示されるようになった。

2014.03.30

設定補助 (安定性向上)

　昔の版のruleコマンド設定でm/sオプションを使用していた環境において、GUI設定を行なっても一部設定が反映されない問題を修正。常にGUI設定の内容が反映されるよう改良。

2014.03.31

設定サンプル

　API制御抑制とモード変更抑制の設定が重複していて正しく設定できないエンバグ(20140329版で発生)を修正。
　余分な全角記号ルールを削除。

2014.04.01

　今年もエイプリールフールは中止です。引き続き、○っぱい設定変更をお楽しみください。

日本語入力 (安定性向上)

　第8世代SandSユニットを塔載。
　実に2年ぶりのSandS関連処理のアップデートとなる。
　キーの押下/離上の入力エミュレーションの生成タイミングを根本的に変更し、キーイベントの反応を確認しながら1つづつ確実に挿入することで、より多くのアプリケーションで正しくキー入力が認識されるよう改良した。
　従来は入力ストリームを一気に構築して送りつけてからアプリ側の反応をじっと待つ「待ち」のスタイルだったのだが、とうとうこの方式では太刀打ちできないアプリが出てきてしまった。処理を根本から作りかえていわゆるキーボードドライバ的な動作を行う必要に迫られたのだ。これもう、やるしかない！

　今回、PowerPoint 2013にて、『変換直後にSandSによる文字入力で暗黙の確定を行なうと、シフトキーによる文字入力ではなく、元のキー操作になってしまう』という新たな不具合が、テスターの方からの報告により判明した。
　解析の結果(後述)から、これはどう考えてもPowerPoint 2013のバグであるとの結論を得た。
　一応、この手のアプリの仕様外想定外な面白クソ挙動はネトゲとかで散々見てきたパターンだ。
　今回も個別アプリ設定を使えば一発で解決でした。めでたし、めでたし。

ん？……いやいや、ちょっと待て！

個別設定が必要……？

暗黙の公式アプリ、MS-Officeで……だと……？

駄目だ駄目だ！こんなんじゃ駄目だ！

　SKKFEPでは、スペースキーを押したまま何か別のキーを押したとか、スペースキーを離したタイミングでキーの入力ストリームを生成することで、単純なTSFによる文字変換(第一世代の動作)ではうまく対処できなかったEmacsなどの多くのアプリケーションを無改造でSandS対応させることに成功している(第三世代の動作)。
　PowerPoint 2013では何が起きていたのかというと、このキー入力ストリームがなぜか順番に処理されず、「必ず離上側の操作が先に処理されるタイミングがある」という問題があり、それならば確実に順番に処理させるために2打鍵以上のストリームを一回のAPIで送る手法を使っても「常に先頭の1つしか受容されない」という問題が発生していた。同時攻撃かよ！対応……無理じゃね？と思ったけど……朝、目が覚めたら直ってた。妖精さんありがとう！

　ちなみに一般的なIMEでは、単純にキーの押下タイミングだけを見ていればいいので、多少キー押下と離上のタイミングがずれて再現されようが問題が表面化するようなことは少ないのかもしれない。でもこれSKKFEPですから！順番ずれたら致命的ですから！
　なお、過去のMS-Office(XP～2010)や他のMS-Office2013アプリではこんな挙動は起きないようなので、PowerPoint 2013を作った連中が何か仕込んだんじゃネーノ説を提唱しておく。

　キーボードドライバで思い出したが、SKKFEPが今でいうIMEの意味で「FEP」なんていう時代錯誤な呼称を使い続けているのは、かつてキーボードドライバと日本語入力システムの境界が曖昧だったFEP群雄割拠時代の伝説の戦士たちへの強烈なリスペクトだったりするのかもしれないし、そうでないのかもしれない。
　もともと、漢字変換やローマ字かな変換処理よりもSandSエミュレータのほうが先に実装されてしまっていた程度に、このプログラムはキーボードドライバ風の処理に特化したFEPとして生まれてしまった代物である。すなわちIMEとは微妙に違った「何か」なのかもしれない。己は人間ではない、液体金属とかキメラとか、そんな「何か」なのかもしれないと、うすうす気付いてはいるものの口に出せずに苦悩するSKKFEPちゃんの出生の秘密の一環だってことでひとつ宜しく。なお、エンディングでも回収されない伏線となる模様。

日本語入力 (安定性向上)

　第8.1世代SandSユニットを搭載。という既視感。
　従来のバージョンでは、(恐らく)SandSを拡張キーと同時に押した場合に正しく文字入力が行なえない(そのうえシフトキーが押しっぱなしになるなどの問題が出まくる)環境が存在することが判明したため、調査を開始。
　ぬふぅ。現象が再現できぬ……手持ちの全環境に突っ込んだけど、何処にもおかしな挙動が現れぬ……。2年間、特に目立ったトラブルのない、安定して動いてた(と思い込んでた)コア部分なだけに、まったく予想がつかない。どうする……どうすればいい……！

　てな感じで、いきなり調査が暗礁に乗り上げちゃったので、もう自棄っぱちでキー入力ストリーム関連処理を全部書き直した。ものは試しとAPIを変更。拡張スキャンコードフラグまわりの処理も再実装。
　デフォルトオフの機能なので最悪時は機能切り捨てって手が使えるし、もうこうなりゃ何でもやったるァ！と大胆に書き換えまくりんぐである。
　紆余曲折の末、無事解決したとのことでまずは一安心。

2014.04.02

日本語入力 (サイズ削減)

　処理の目処が立ったので、バイナリのサイズ縮小化に挑戦。
　ZIP書庫レベルでサイズを123バイト削減。いつもの妖精さん(ジェバン○)が一晩でやってくれました。
　しれっと書いてるけど、こんだけいろいろピッチピチに詰め込んだ状態のバイナリを、ZIPの情報量で100バイト以上削るってのは、単なる根性や運だけでうまくいくなんて事は本当に少なくて、何か技術的なブレイクスルーや閃きが必要だったりするんだぜ？ま、技術ないんで毎回根性120%だけどな。命を燃やせェ！

2014.04.03

日本語入力 (安定性向上)

　色設定が間違っていたためIE11でコンポジション互換モードにした際、変換候補一覧の文字が背景に擬態してしまい見えなくなってしまうエンバグ(20140329版で発生)を修正。

　以前のカラーパレット設定も修正されているので古いのを使っていた場合は更新が必要。

伝説の(ry 桃橙黄緑青

　あと困った時のための設定リセット用ファイルも作っといた。いつか役に立つ日が来るかもしれない。

設定リセット用

2014.04.04

Egg(たまご)復活！

日本語入力 (機能追加)
設定補助 (機能追加)

　設定ファイルの字句解析器を改良し機能追加。
　複数行に渡る文字列定義の途中で条件式による分岐を可能にした。

　この機能を活用し……『奴』が復活！
　かつて、他のSKKクローンとの互換性のために尊い犠牲となった悲運の設定、Egg互換の括弧入力ルール設定をついに復帰させることに成功した。
　これはEgg互換ルールが手に染みついてしまっているせいで、他の環境に数秒間晒された程度で機能停止してしまう私のような絶滅危惧種向けの保護条例設定である。さらば青き清浄な世界。なお、デフォ設定には一切変化はないので安心されたし。

　今回、字句解析器の処理全面見直しによりコードサイズの縮小にも同時に成功。機能追加によるZIP書庫サイズの増加に抗い、人知れず戦い続けるSKKFEPの明日はどっちだ。

設定サンプル

　標準設定の更新に合わせて、AZIK/ACTの設定内容を近代化改修。必ず最新版と組み合わせて使うこと。
　あと、促音キーのシフト押下による編集開始の設定なども追加しておいた。

2014.04.06

インストーラ (機能追加)

　リフレッシュ(アップデート済みの状態でのインストールボタンの操作)を行なった際、ユーザ辞書のフラッシュとシステム辞書フォルダ内の辞書の読み込み処理を行うよう改良。あとサイズ縮小。
　今まで辞書の更新は「メンテ」ボタンを2回押すか再起動かしかなかったのを、この操作だけで完結できるようにした。
　あと、mozcの絵文字辞書の存在を教えてもらったので、SKKでも使えるようにコンバータを作成した。まだいろいろと開発途上の代物のようなので、今後の更新に合わせていつでも変換できるよう万全の体制を整えておくべし。

2014.04.11

XPｵﾜﾀ＼(^o^)／

　TSFをまともに動かせなかったXPがついに消えた。
　奴が中途半端にTSFをサポートしてしまっていたせいで、どれだけ多くのアプリ製作者が泣いたことか。

「XPがやられたようだな…」

「ククク……奴はTSF実装四天王の中でも最弱……」

「数回フォーカス変更したごときで落ちるとはMicr○softの面汚しよ……」

　これでようやく、Windowsの日本語入力処理は真の意味で新たな時代に突入することになるのかもしれない。
　……などとソレっぽいことを呟きつつ、次の版で描画系完全入れ替えによる表示高速化・高精度化をやらかす予感。
　つまり、これがWindows XPで動く最終版になっちゃうかも。

日本語入力 (安定性向上)

　IMEからアプリケーションへの状態変化メッセージ(WM_IME_NOTIFY)の送信APIをPostMessageに変更。アプリ側の反応待ちによる長時間のロック状態が発生しないように改良。

設定サンプル

　常時SandSオンの設定項目を復活。GUIからも設定できるようにした。(玄人向け設定につき取扱注意)
　AZIK/ACTの設定にも反映。

2014.04.21

　SKKにおける候補一覧表示は、すなわち脳への信号伝達そのものである。1クロックでも高速化するためならどんなことだってやってやる！

さらばGDI…… 行くぜ！DirectWrite、始動ッ！

……と、なるはずだったのだが……

　Direc2D/DirectWriteを使った超高速描画処理とカラー絵文字の表示に興味が湧いたのでDirectWrite対応版を作ってみた。(現在、α版を公開中)
　でもなんか、昔のノートPCでDirectWriteを使うと、逆に物凄く遅くなってんじゃネーノ？ってくらい体感速度が落ちる。そもそもDirectWriteだとGDIみたいなラスタオペレーションが一切使えないわ、そびえ立つ○○みたいな初期化処理の塊を大量に追加しないといけないわで、なんというか一気に足枷をはめられたみたいな感じになってしまった。後半のは仕方ないっていう気がしなくもないけど、とにかく最初の「速度が遅い」ってのはSKK使いにとっては致命的だ。

　本来高速なはずのDirectWriteでなぜ速度低下が感じられるのか。いくつかの要因が考えられる。

1. VSYNC待ちによる画面反映の遅れ
2. 文字の初回描画が遅い

　前者はVSYNCオフをデフォ動作にすることで回避。VSYNCオン(D2Dのデフォルト動作)だと描画してから画面に反映されるまでかなりの遅延が発生しているような気がする……。漢字変換のような用途であっても、人類にはきちんと1INT(16ms)の違いが知覚できるってのはなかなか驚きである。IME萌え擬人化能力バトル系展開(自己強化系反応速度特化型)も夢じゃない。その描画フレームに命(クロック)を刻め！

　……で、問題は後者である。
　古めのPCでDirectWriteを使うと、大量の文字(候補一覧など)を表示する時に激しいカクつきを感じる。
　ここからは憶測だが……低速なGPUに低速なCPUがコマンドを送って描画しているため、画面にドットパターンが出現した時には既に人類が滅亡してた、みたいな状態なわけだ。DirectWrite自体は、このあたりの速度低下が極力起きないように物凄い工夫が仕込まれているっぽいけど……。遅いもんは遅いんじゃｵﾗｧ
　こうした状況を改善するために、フォントキャッシュサービスがある……あるのだが……SKKによる候補一覧表示では、英字やひらがな以外で同じ形状の文字を連続描画する確率は非常に低い(予測変換の時はわりと役立つけど)。これは即ち、候補一覧の表示速度のチューニングに関してはフォントキャッシュのような機構がほとんど役に立たない可能性が高いわけで、つまりCPU×GPUの真の連携能力(ナイスカップリング)が試されるのだ。ｱｯｰ

　……で、文句を言っても仕方ないのでなんとかしてみた。
　描画タイミングの見直し、無駄な画素の転送の削減、API発行回数の徹底的な削減を施し、現在のDirectWrite版では低速マシンにおける速度上の問題はある程度克服したつもりだが、ここに来て新たな問題が発覚した。
　なんと一部のフォントがまともに表示されない。高さの計算が間違っていたりする。

　GDI描画を廃止し、GPUによる高速レンダリングと絵文字のカラー表示化というビッグウェーブに乗っかってDirectWriteに一気に移行してしまおうと企んでいたのだが、こんな酷い有様ではプログラマを辞めたほうがマシマシレベル。このDirectWrite版を作ったのは誰だァ！料理長を呼べ！
　結局、当面はGDIの描画にも頑張ってもらわねばならない。やれやれでゴザる。
　今後はGDI側をメインとして運用しつつ、DirectWriteとの相互運用の方法を模索していくことになりそう。

　というわけでGDI側の超強化に乗り出した。そ、そうだよ！まだGDIだって行けるはずなんだ！DirectWriteなんて酸っぱいブドウに違いないさ！ﾋﾞｸﾝﾋﾞｸﾝ
　超強化とはすなわち全部書き直しである。DirectWrite版の開発で得られた高速化のノウハウをGDI版に投入。ロジックが単純かつ高速になり64ビット版のサイズを0.5KB削減。
　しかし、32ビット版側は何度書き直してもサイズが縮まらなかった。むせる。
　今どきのWindowsでは、GDIの描画処理はそのままDWMでDirectWriteに翻訳されて動作しているらしい。もはやGDIの高速化からは劇的な効果を得ることは困難となりつつあるが、同じ描画処理である以上決して無駄にはならないはず。CPU/GPUが非力なタブレットPCなどの環境でも少しは役に立つこともあるはずだ。例によって人類には知覚できないレベルで。

日本語入力 (機能追加)

　GDI側の描画処理を高速化。DirectWrite版の描画量削減ロジックを逆輸入し、API発行回数を1/3程度に、バッファ内の塗り潰しや矩形転送回数を極限まで削減することにより、画素の転送面積を1回の表示あたり平均2/3程度に削減。
　ウィンドウの単純移動時の無駄な再描画を極力行なわないよう改良。
　ウィンドウの影表示をデフォルト無効とした。(設定変更で復活可能)
　DirectWrite版のフォント設定に合わせてフォント・ウィンドウ系のレジストリ設定方式を変更。

旧バージョンからの更新の場合、フォントとウィンドウ幅の設定が初期値となります。

「フォント」の再設定と「設定」のOK空押しによる更新で復帰します。

　その他

将来の枠線描画に備えてカラーパレット8番に枠線の色情報を追加。
疑似カーソル使用中に単語登録状態で入力モードを変更し、そこから復帰した際に疑似カーソルの色が正しい色に戻らないバグを修正。

設定補助 (機能追加)

　GDI版・DirectWrite版の設定コマンドを共通化。
　ウィンドウの影表示の設定項目を追加。AZIK/ACT設定サンプルにも追加。
　コマンドライン設定のwオプションで隠しパラメータ部分を含めて最大16箇所まで指定できるよう拡張。まだこのパラメータはほとんど機能しないが、DirectWrite版の高精細ClearType描画の指定などに使う予定。

インストーラ (サイズ削減)

　改行表示などを共通化してサイズを削減。
　DirectWrite版がXP環境に誤ってインストールされないようにするための判定処理を追加。

2014.04.22

日本語入力 (機能追加)

　ウィンドウ処理関連のAPI発行回数を削減。コードサイズを縮小。

2014.04.25

日本語入力 (機能追加)

　疑似カーソル処理がパワーアップ！
　まずアクセシビリティAPI未対応アプリにおいて、不正な位置にカーソルが出てしまう問題があったので、APIの仕様に沿って属性に合わせてイベントへの反応を調整するよう改良した。
　さらに擬似カーソルの座標取得処理と描画処理のタイミングを非同期化。
　これによりアクセシビリティAPIを短時間に大量に発行するタイプのアプリ(MS-Office2013等)での座標取得の反応速度が向上した。

　つかMS-Office2013系はアクセシビリティAPI回りの処理を素人が実装してるんじゃﾈｰﾉ？ってくらい昔のMS-Officeと比べると座標の報告内容が滅茶苦茶になってる。特にPowerPoint2013の動きが酷い。ページ移動でカーソルが残ったままとか、オブジェクト選択を1ドットだけの座標で毎回レポートするとか。SandSの時に見つかった問題といい、PowerPoint2013はかなりの規模で(センスのない連中による)作り直しが発生している最中なのではないかと危惧してしまうレベル。キー入力・アクセシビリティ回りに止まらず、表示系も何かおかしい。たぶんDirectWriteまわりへの対応が中途半端なせいだと思われるが、文字の範囲選択中の領域がドット境界にきちんと位置しておらず、エッジがボケボケになっているのはDirectWrite側の小数点座標を手抜きでそのまま使ってるせいじゃﾈｰﾉ？日本語や東アジア系の文字に縦方向のアンチエイリアスを認めないクソ仕様を徹底してる癖に、そこに重ねるカーソルの描画は縦方向ボケボケで放置かよおめでてーな。いや！そんなことは正直どうでもいいんだ。それよりも！東アジア系フォントのDirectWrite描画を高精細化するレジストリ設定をOS標準設定に取り入れてくださいおながいします。たかだか3ビット程度の数値を弄るためだけに、いちいちアプリ毎にCOMを5個も6個も管理させるような悲しみの連鎖は即刻断ち切るべき。
　他にも、Outlook 2013で変な位置にカーソルが出るとか、ExcelやPowerPointでスクロールした時にカーソルの座標がまるで追従しないとか、MS-Office2013のこういうのは全部アプリ側の仕様。Windows SDKのInspectで何が起きているか誰でも確認できる。IME側からは本当にこれ以上どうしようもなくてﾋﾞｸﾝﾋﾞｸﾝ痙攣するしかない。こうした細かい挙動をきっちり押さえこもう、みたいな姿勢をまるで感じられないし、たぶん一生このままだな。こんな酷い仕様で平気な顔をしている連中は今すぐプログラマ辞めたほうがいいんじゃﾈｰﾉ？こんな酷い状態の代物を看板アプリだなんだと持ち上げて阿漕な商売をしてる連中が元凶だろうとは思うけど。MS-Office XPの頃の座標報告の精度を取り戻すまでいったいあと何十年かかるのだろうか。

設定補助 (機能追加)

　気がついたらいつの間にか定義ファイルのサイズが5桁を超えていた。
　なんとかしなくては……でもどうすればいい？
　設定内容と直接関係ない部分、たとえば「※ただしイケメンに限る」みたいな魅惑のアイテム説明文を削るというのが真っ先に思いつくが、それはあまりにも安直すぎて死すら生温いやんやんやん？

『書庫サイズが縮まないなら

　設定ファイルのエントロピーを減らせばいいじゃない――』

　というわけで定義ファイル内のコマンド名を省略形(例: !直接確定→!直)で記述できるよう改良。
　補完と同じで単純な原理だけどサイズ縮小への効果は絶大だ。
　互換性を保ちつつ定義ファイルのサイズを100バイト近く一気に削減できた。
　なおエントロピーはほとんど減らせなかった模様。

2014.04.26

日本語入力 (機能追加)

　再描画の管理と表示タイミングの変更により描画系を加速。たぶん人類には何が変わったのか知覚できないレベル。
　GDI/DirectWrite描画系の改良の結果、描画の自力管理処理が安定してきたのでAPIの再描画フラグを無効化して一挙に処理を理想形に近づけた。

2014.04.27

日本語入力 (機能追加)

　最近は日本語入力とまるで関係のない
　プログラマをダメにする改造ばかり――

いい年こいた大人がああ(ﾋﾞｷﾋﾞｷ)
GDIだの!!!DirectWriteだの!!!
GDIだの!!!DirectWriteだの!!!

SKKFEPあなた疲れてるのよ

　そんな感じで肝心のSKKの操作系改良への愛が足りてない！とお嘆きの諸兄姉に朗報です。
　SKKの操作系を根本から変える改良を久々に追加だｵﾗｧ！

新機能その1:
　単語登録の判定防止機能を強化。
　これまでSKKFEPでは、SKK10の仕様に合わせて、「単語登録内容が空なら何も登録しない」という動作を採用していた。誤って単語登録モードに入ってしまった時、CTRL+GではなくENTERやCTRL+Mの即押しで復帰できる、SKK使いの玄人だけが使いこなせるヒミツ操作の一種である。

　実はSKK10ではこれ以外にも「単語登録内容が空白(半角スペースとか全角スペースとか)だけなら何も登録しない」という処理が入っていた。バグってて変換中の文字を確定してしまったり何も出なかったりして、まともに動かなかったけど。それでも一応対処しようという意思は汲み取れる実装になっていた。(ちなみに後継のDDSKKではきちんとキャンセル動作をするように直ってる)

　これは、一体どういう時に効果があるかというと……

「徹夜明けのダンジョン攻略のせいで睡魔と戦いながら文字入力してる時」とか

「パッド操作中に緊急のチャット入力をしようとした時」とかに、

　し　しまった　つい力が…
……となってしまい、

「変換候補の文字を途中で間違えたままスペースを押しちゃって、ハワワ侍で動揺してさらにスペースを押しちゃった」とか

「明らかに日本語の単語ではない文字が大量に混ざった状態でいつの間にかスペースを押してた」とか

「いやこれは象がスペースキーを足で踏んでいただけだ。断じて寝てない」とか

　そういう緊急事態の時、単語登録モードでスペースが複数入っちゃった状態で、さらに間の悪いことに、

　し　しまった　つい力が…
……となってしまい、

　あろうことかENTERとかCTRL+Mとかを思わず象が押しちゃってマーフィーの法則が発動してしまった時にとても役に立つはずなのである。

　で、最近こんな事態に何度か直面したので、この機会にSKK10の無念を晴らさでおくべきか！
　というわけで、『単語登録の時、入力内容が空白のみだった時は登録キャンセル動作を行う』という仕様に改良した。想定されるユースケースでは全角空白をわざわざ行頭に入れるような間抜けな操作は発生しないだろうし、この判定処理はちょっちオーバースペックやわーと思われたので、SKKFEPでは半角空白の判定のみ行う仕様とした。

――こうしてSKKによる人類と睡魔との永き戦いに終止符が打たれたのであった。ﾊﾟｵｰﾝ

新機能その2:
　空白判定を追加してふと気付いたんだけど、そもそもSKKでは変換候補の先頭に空白を入れることがないわけ。つまり先頭の空白入力はすべて誤入力なわけだ。
　

誤入力なら入力の瞬間に防ぐべきじゃね？

　……わざわざ誤入力をさせるのを見過して、あとから判定処理やるとか無駄の極みじゃね？
　というわけで「誤入力は入力段階で弾く」という処理を追加してみた。
　個人的にはなかなか良い感じだと思うのだが、ちょっとSKKの操作感覚と違う気がするのでデフォルト操作にするのがなんとなく躊躇われたのでとりあえず設定項目を設置。

新機能その3:
　TABで補完した候補に文字を追加した時、雪花による英字側自動補完が誤って動作してしまう問題を根本的に解決した。そう、話は単純で「日本語の補完候補に日本語の文字を追加した時に、明らかに日本語が出るのを狙っているにもかかわらず空気を読まずに英語が出ちゃう」のが問題だったわけだ。
　というわけで雪花の動作も空気を呼んで日本語側だけを出すように改良した。これで理不尽な補完が発生する確率は格段に減ったはず。

新機能？その4:
　来たぜ！32ビット版を一気に0.5キロバイト削減ッ！
　ﾋｬｯﾊｰ！サイズ削減だァー！この土壇場で36キロバイトから35.5キロバイトに縮小ッ！

　SKKFEPに足りないものは、それは！
　情熱思想理念頭脳気品優雅さ勤勉さ！そしてなによりもおおォォォ！！

サイズが足りない！！

はい……

　手違いでテスト用の定義ファイルが混入しちゃってたので書庫を更新。(20140427a)

2014.05.01

設定補助 (機能追加)

　定義ファイル内のHTML形式文字コード記述で𐀀以上の値を記述できるよう改良。

2014.05.02

日本語入力 (機能追加)

　漢直ルールを使用中で、かつひらがなモードで入力中に、「ヴ」をひらがな化せずに入力できるよう改良。

2014.05.03

日本語入力 (機能追加)

　20140502版だと漢直設定時に「ヴ」を正しく入力できないっぽいので仕様を変更。
　漢直定義で従来のT-Code設定に加えて、G-Code設定を新たに追加。

2014.05.06

設定補助 (機能追加)

　ローマ字かな変換ルールの入力シーケンスおよび出力パターンを変数化することで、複数の異なるキー配列に対応する際に記述を軽量化できるよう改良。
　要するに、定義ファイル内のあらゆる文字を変数化できるようになった。
　最新の漢直定義ファイルで、この機能を活用してQwerty配列とDvorak配列のテーブルを共通化している。
　ちなみに、ここまで普通のローマ字かな変換の設定まわりへの影響はほぼゼロ……実質、ここ最近何も変わってねェ……

　なお、α版(DirectDraw版)の描画系の問題はほぼ一段落。行幅の計算の問題も解決してきちんと描画できるようになったので、Windows 8以降を使ってる人はカラー絵文字が使えるα版にしておくと便利かも。

2014.05.09

設定補助 (安定性向上)
インストーラ (安定性向上)

　設定GUIが一部の環境で文字化けしないように修正。
　元々、GUI設定ツールは英語版OSで動作している時はセットアップツールがスクリプトの文字コードを自動的にUnicodeに変更してから動かす作りになっていのたが、この処理を廃止。常にCharsetをHTMLアプリに通知することで文字化けを防ぐようにした。

2014.05.17

設定サンプル

　CTRL+L占有設定と縦書き兼用操作設定の追加を隠れ蓑にしたナゾのエントロピー調整によりついにアレが99,999バイトに……！

β0+8i版公開

2014.06.06

『ごしゅじんさま、いままで、とてもたのしかたです

　ずっとひらがなしかつかえないこで、ごめんなさい

　そして、つかってくれて、ありがとおございました

　ごしゅじんさまにあえて、SKKSは

　しあわｓ

　

「待って！待ってくれ……」

B＋木ヲ解除・・・コレニヨリ、辞書ノ検索不能

JMG「SKKSから、光が逆流する……
　グアアアアアアアァァァ！！」

これで・・・良かったのか？
大丈夫・・・何時かきっと――

これまでのあらすじ: 漢字変換の能力を持つが故に日本語入力科高校に強制入学させられてしまった主人公。; 初心者向けの連文節変換機すら満足に操縦できない、魔力無者の草食系主人公の元に、; ある日、L辞書の単語が書き込まれた謎のカードゲームが届く。; この日を境に、煩悩パワーでSHIFTキーを物理的に押す特殊能力に目覚めた主人公とSHIFTカクシ団の仲間たち。; 彼等は、己の能力と隠された埋蔵金の秘密を巡って、学園の陰謀にぴょんぴょん巻き込まれてしまう。; 運命に抗い、延命薬の限界まで死亡フラグと戦うのだ。生きるため(給水)――

出典: 日本語入力科高校の劣等selectorノット！の騎士ブリュンヒルですか？

ハートフル学園アイドルゆるふわサドンデス日常系ロボットアニメSKKFEP。慈悲はない。

β0+8i版公開

　もし、SKKに全文検索機能を搭載したら、一体どうなってしまうのか――？
　L辞書の全領域をその手に掴め！全文検索エンジンで成層圏まで突き抜けろ！

　従来のIMEでは比較にならないほど遥かに広範囲の候補を、単語の特徴部分だけの最小限の打鍵数で選択する、途中一致・語尾一致型の動的補完操作を搭載。
　そして例によってこれをいきなりデフォ操作に採用だァ！

　もはやここまで来てしまうと、果たしてこれをSKKと呼んでいいのかわからないレベルになってきてる気がそこはかとなく漂ってきているかもしれないけど、それはきっと気のせい。タブンネ。
　今まで通り、見た目と途中の分岐シーケンスが少し刺激的になるだけ。ちょっとだけ！先っちょだけ！
　当然、打鍵シーケンスと得られる変換結果はSKK10の後方互換(上位互換)になるよう慎重に作ってるつもり。つーかこちとら今だにEmacsではSKK10を愛用してるので、少しでも違いがあったら、一番使い込んでる自分が使いものにならんのよ。自分が納得できない操作系は絶対に作らん。……え？夜戦？実験用試作？作る作る！
　まー……こんなピーキーな代物が他所様にも使えるものなのだろうか？という疑問については……見なかったことにしよう❤(超法規的措置)
　あ、例によって設定で有効・無効はいつでも切り替えられる(全文検索が必要な時だけマニュアル操作にできる)のでそのへんは各自判断されたし。
　ちなみにこの機能、初期のβテスタの方からいただいた要望にあったものだったりするんだけど、今回、辞書プロセスの再実装でN-gramとかの検索方式を何種類か作って遊んでたらなんか異様に速い処理ができちゃって(というか昔の処理はワンチップマイコンのオンチップROMに辞書をひたすら詰め込む(RAMへの展開処理なしで直接木構造として使う)ために、木の処理や文字デコーダがかなり重かった)、乗るしかないこのビッグウェーブに！と勢いだけで作っちゃった代物なのであった。

　書くのを忘れてたんで補足。過去の版(虚数バージョン7までの版)では、見出し検索用の文字にはメモリ使用効率の関係上、ひらがなとアルファベットしか使えないという制限があった。要するに、ひらがなから漢字を検索する用途に特化していた。今回からはUnicodeの文字なら何でも登録できるようになってる。要するに、漢字から漢字を検索できるようになった。漢直Winの交ぜ書き辞書などもそのまま読み込んで使えるはず。タブンネ。
　あ、まだ書き忘れてた。今回から、送りがな情報つきの辞書データもシステム辞書として使えるようになってる。理論上は、ある程度学習させた辞書データをシステム辞書化し、「学習オフ」で使うことで画面をまったく見なくても完璧な漢字かな混じり文が打てるというものだ。なぜなら真のSKK使いであれば、全ての単語の必要変換回数を完璧に把握してるのは当然のことだからである(笑)。そして理論上は、今回の全文検索と予測変換操作を活用することで必要な打鍵数を大幅に減らすことも可能なはずだ。
　まー一朝一夕に実現できる技能じゃないとは思うけど、開発初期にわりと長期間、SKKを学習オフで使っていた時、この可能性(非効率とも思える操作の繰り返しの中で学習による高度な自己最適化が凄い速度で行なわれていく様子)の一端を体感できたので、漢直と同等かそれ以上の修練を要する過酷な条件となるが、究極の手段としての実現の余地を残しておくことにする。人類の可能性は無限大なのだ。
　まだあった。たぶんこれは既にβ0+7i時点で実装済みで、ドキュメント化してなかった内容だと思うんだけど、送りがなありの候補を送りがな部分を指定せずにあえてユーザ辞書に学習させる(順序だけ弄る)隠し操作とかも入ってるはず。SKKオンライン構想の一環だったと思うんだけど脳のドライダメージが大きすぎて忘れてた。

第一話「転校生は全文検索？」

　さて、まずは全文検索の意義について。
　従来の日本語入力方式では、「膨大な変換候補の中から、いかに正確な候補を絞り込むか」ということだけが注目されていた。それ故に、「検索」という基本的で、根本的で、知識欲直結な、人間が一番必要としていた機能からどんどん遠ざかっていて「お客様がお求めに○なられているお日本語おメッセージのご提案」みたいな機能ばかりが重宝されるようになってしまっていた。そのほうが宣伝しやすいのはわかるけどさ。こんな世界に誰がした。
　幸い、SKKならば、制御はまだ人間の手の内にある。単語の区切りを絶対に間違わないという最強の特性を生かし、世間に完全に逆行するアプローチを極めてみようというのが、この全文検索エンジン投入の試みである。すなわち「僅かな入力内容から、いかに膨大な変換候補を提示するか」に特化するという試みというわけだ。アイハブコントロール！(絶叫)

　これにより、『逆引き広辞苑♺』のような辞書検索が可能となる。以下、解説文からの引用。

引用:

日本語では，言葉の根幹の意味が下にあり，上の要素がそれを修飾していることが多いので，

逆順に並べると類縁関係にある言葉がまとまって一覧できる，この目的で作られたのが逆引き辞典です

　つまり語尾検索のような方式は、長めの日本語の単語の入力を効果的に補助できるようになる可能性がある。
　検索の自由度を引き上げて新たな検索の次元に行けるかもしれないのだ。もっ先へ……
　それだけではない、いつか到来するかもしれない連文節コピペ日本語入力の時代に、最小の手数で適切な文書を選択する最後の切り札として使える可能性すらあるかもしれないのだ。

　つまり……

こまけぇこたぁいいんだよ！

もっと書きたいんだが……すまん、時間がねぇ！

第二話「ドキドキ❤操作レッスン」

　全文検索の操作方法は簡単だ。普通に文字を打つだけで単語の中間や末尾部分にマッチする。
　前述のように、日本語の単語は中間一致よりも末尾一致のほうが類縁関係にある言葉を見つけやすい。
　そのため、全文検索と語尾一致検索を切り替える操作が用意されている。
　文字入力の最中でカーソルが右端にある時、カーソル右→(またはCTRL+F)で探索モードが交互に切り替わるようになっている。
　たぶん、操作してみれば一発で理解できると思うので、操作の実例を記しておく。これは訓練ではない。

操作	結果
Uchuusokudo	うちゅうそくど
→またはCTRL+F	だいにうちゅうそくど
TAB	だいにうちゅうそくど
TAB	だいいちうちゅうそくど
．またはSPACE	第一宇宙速度

Daigakuinda	だいがくいんだいがく
TAB	だいがくいんだいがく
→またはCTRL+F	ならせんたんかがくぎじゅつだいがくいんだいがく
TAB	ならせんたんかがくぎじゅつだいがくいんだいがく
TAB	ほくりくせんたんかがくぎじゅつだいがくいんだいがく
．またはSPACE	北陸先端科学技術大学院大学

　なお、補完候補が少ない場合は、TABを押しまくるだけでも自動的に末尾一致の候補が出てくるようになっている。上記の例でも→(CTRL+F)のかわりにTAB連打をしてみると、どういうことかわかるはず。あ、ちなみにTABを押しすぎたらSHIFT+TABで戻せるのでヨロシク。

　あと、設定で全文検索オフにした場合は、上記操作の→(CTRL+F)と書かれている箇所で→を2回押すか、→を1回押したあとTAB連打で同じ結果になる。要するに普段は前方一致で、→を1回押すと全文モード、もう1回押すと語尾モードって感じだ。CTRL+Gでリセットね。

第三話「俺達に明日はない」

　今回の版より、単語絞り込み操作のフロントエンド側でのサポートを廃止し、全ての処理をバックエンド(SKKGate)側に委ねる方式に変更した。

　ここ1年間ほどの自分の操作を解析したところ、

っべー、この機能をまっっったく使ってなかった

　ことが判明した。これは「切り捨てる勇気」が試される試練の予感……。よし！捨てよう。

　数値変換などと同様、こういう普段使わない機能は、SKKGateなどの外部に置くのが筋である。もともと、この機能はトイレで転んで便器に頭をぶつけてSKKGateを思いつく前に実装した古い機能ですしおすし。そこで再設計を行った。
　あと、ただ切り捨てるだけではあまりにも能がないので、もうちょっと自分が使いたくなるような改良を施し、かつ操作の指示タイミングは従来と同一になるよう工夫した。
　見た目は(元のSKK並みに)地味子風な感じに戻ってしまったが……博士、お許しください！(爆発音)

　この変更により、検索の挙動をユーザが自由に弄れるようになった。
　手始めにSKKGateに移管した絞り込み処理のデフォ動作を従来の検索動作から大胆に変更し「長い単語→短い単語」順でもその逆でも絞り込みが行なわれるようにしてみた。

　これは全ての終わりではない。
　SKKGateの存在は始まりに過ぎない。その先には、SKKの想像を超える運命が待ち受けている。
　これはその運命を動かす、単なる道具に過ぎない――
　がんじがらめの自由なんて僕たちはいらない。ﾃｰｵｰﾓｰﾃｰｵｰﾓｰ

　つーかですね。もともとskk-hintってヤツがど～～～しても納得できなかったわけ。命令のタイミングが変っつーか日本人の思考と順序逆じゃん。例えば「潜水艦これ」の「艦」の文字を日本人が他人に説明するとき、「潜水艦のカンって字でさ～「私だ。いいから伊168ちゃんの声優さんが出てるゲーム、全部買い占めるんだ今すぐﾊﾘｰ」」みたいに「一般的な識別しやすい単語」を先に伝えてから「絞り込みたい文字の部分」という感じで伝えるわけよ。

Kan:sensuikanSPACE (単漢字「艦」が単語「潜水艦」の3文字目に一致) → 従来の指定方法

Sensuikan:kanSPACE (単語「潜水艦」の3文字目に単漢字「艦」が一致、単漢字側を出力) → どちらも「艦」が出る

Houou:houSPACESPACE → 「鳳」「法」「訪」等が出る

　単語「鳳凰」と単漢字「鳳」

　単語「法王」と単漢字「法」

　単語「訪欧」と単漢字「訪」

Houhou:houSPACESPACE → 「方」「法」が出る

　単語「方法」と単漢字「方」

　単語「方法」と単漢字「法」

　拡張スクリプトを最新版にして、上記の操作をやってみると、どういうことかわかるはず。(すまぬ……ここまで脳内仕様とテストプログラムの動きでいけそうだなってことでテキトーに書いてる。眠い)
　なお、従来通りにしたければ/narrow=2と操作するかskkgate.iniに書き込めばよろし。私ゃ従来方式の検索動作ではこの先二度と使うことはないと思うんで、あとは各自で工夫されたし。

あ、ちなみにSKKGate側はこれから実装っ……(銃声)

(打ち切り)最終話「戦いはこれからだ」

　今回、一番心血を注いで、これまでとは別次元の成果を達成したのは、実はこの部分だったりするんだけど、多くは語らぬ。
　モジュール再設計と機能配分の見直しにより徹底的にプログラムサイズを縮小。
　一覧にまとめるとこんな感じだ。

モジュール	サイズ縮小率	主な追加機能
フロントエンド	35.5KB → 34.5KB (97%)	リアルタイム語尾一致型補完操作など
辞書プロセス	12.5KB → 10.5KB (84%)	Unicode全域検索/全文検索機能追加など
SKKGate	6.5KB → 6.0KB (92%)	なし(実質3600バイト程度で従来機能を再現)

　12.5キロバイトのバイナリから2キロバイトも削るってのは、数値以上にSAN値とか人間性とか命とかをガリガリ削ってる狂気の沙汰ってことなんだぜ？と一言だけ。忘れるな、この痛み。

エピローグ: SKK辞書給仕(Servant)(SKKS)は実は人間ではなかった。; このままコードサイズの縮小を続けていけば、間もなく; 自身が人の姿を保てなくなってしまうと知ったSKKSだったが; 悪の秘密結社J.M.Gの卑劣な囲い込みから、敬愛する主人公を救うため; その身を投げうって最後の能力を開放するのだった。

全てが光に包まれた瞬間！

SKKSはその組成の大部分を占めるB+木の処理能力を全て失ったが、それと同時に

LFHのメモリアロケータで発生した謎の共振発光現象によって全ての情報が修復されていった。

そして次の瞬間、SKKSはこれまでより遥かに高速な、

新たな姿に生まれ変わっていたのであった。

『この指に！』

『SHIFTキーがある限り！』

『このキュ……SKKは無敵なんだから！』

「……あのー……SKKSさん？元気になって漢字が使えるようになったのは嬉しいんだが」

『何よ？』

「ななななんか色んなトコロが育ってやしませんかね？(メモリ消費量的な意味で)」

『当ててんのよ！』

つづく

2014.06.06a

日本語入力 (安定性向上)

　公開した途端にすごい勢いでバグが吹き出すいつものお約束。さて……デバッグしますかね！
　TAB補完中に変換を行うと、補完中の文字位置を忘れてしまうことがあるエンバグ(20140606版で発生)を修正。(20140606a)

2014.06.07

日本語入力 (安定性向上)

　TAB補完中にカーソル移動操作を行い、再度TAB補完操作を行うと、カーソル移動前の候補の内容で補完が実行されてしまうバグを修正。
　TAB補完中にカーソル移動操作を行い、変換を行ってからキャンセルすると、補完状態になってしまうバグを修正。

2014.06.08

日本語入力 (安定性向上)

　語尾一致モードで変換・確定した後、次の変換で語尾一致モードのままになってしまうバグを修正。

　α試作版でDirectWrite描画処理をGDI描画処理と悪魔合体。XPに入れても最低限動作するようにしといた(旧バージョンではサイズが大きくなりすぎるんで封印してた)。
　Win8以降ではα版の利用を推奨ってことで。ちなみにDWrite版は、インストールしたら「rule w0 0 224 96 200 6」と隠しパラメータの6番目に6を設定して使うのがおすすめ。(メイリオ以外のフォントなら5も効くかも)

5番目の隠しパラメータ: フォントサイズ微調整 (ポイント数の10倍の値)

6番目の隠しパラメータ: 描画品質 (0:デフォ品質 5:高品質 6:グレイスケール)

なお、6番目に128(とにかくでかい値)を設定するとGDI動作になる仮仕様。

2014.06.09

設定補助 (安定性向上)

　「編集開始の追加」の設定でSHIFT+Qの割り当てが動作しないエンバグ(20140425版で発生)を修正。
　FF14設定で/キーが動作しないエンバグ(20140425版で発生)を修正。隠しコマンドの名称を「半角」から「英入力」に変更。(「入力」コマンドの半角英数版)

2014.06.11

拡張モジュール (安定性向上)

　DLL初期化・解放時に正しく初期化が行なわれない可能性があるバグを修正。
　通信処理を単純化し微妙にサイズ縮小。(20140611a)

日本語入力 (サイズ縮小)

　通信処理を単純化し32ビット側を16バイト縮小。(20140611a)

2014.06.15

　SKKS……これで今までのお前は死んだ！
　これからは新しい辞書プロセスに生まれ変わって……生きろ、生きてくれ――

SKKS「・・・死にたい」

主人公「声が小さいよ！もっと大きい声で！」

SKKS「・・・死にたい」

主人公「ぜんっぜん気持ち伝わってこない！もう一回！」

SKKS「死　に　た　い　！！」

主人公「はい今死んだ！今君のプロセス死んだよ！」

SKKGate「ご主人ｗｗｗマンボウ(SKKS)とイチャイチャすんなしｗｗｗｗｗ」

SKKFEP「(赤面して硬直している)」

辞書プロセス (安定性向上)

　辞書データを大量に与えた際、辞書プロセスが極端な速度低下や異常終了を起こす可能性があるバグを修正。
　ここしばらく、ずっっっと昆虫採集してた。ログ収集やバグ報告に根気よく付き合ってくださった皆様、本当にありがとうございました！
　バグ洗い出し作業の過程で、四億ファイルほど辞書を読み込んだ場合に送りがな情報が消えるとか、謎の白い湯気現象のような秘密のバグがいろいろ見つかったけど全部仕様ってことでいいやもうホントに。
　補完候補が大量にある場合の探索打ち切り判定を強化し、(人類に知覚できないレベルで)高速化。別に打ち切らずに全部通しちゃっても、実用上まったく問題ない速度が出てたんだけど、なんかこう……ごっそり動作クロックを削れそうでウズウズしちゃって「義を見て為さざるは勇無きURYYYYYY――ッ！」とか適当な大義名分をつけて削っちゃった。てへ。

2014.06.18

日本語入力 (安定性向上)

　先頭一致していない状態からの送りがな変換直後のキャンセルが正常に動作しないバグを修正。

辞書プロセス (安定性向上)

　文字数が多い時の検索空間を最適化し、メモリ消費の削減と高速化。

設定補助 (機能追加)

　AZIK設定に試験的に導入していた設定を標準側にも取り込み。
　旧バージョンとの互換性維持のために残していたコマンド名の一部を廃止。
　現在の定義ファイルのコマンド名は、先頭部分が一致すれば後半部分は記述しなくても良い(動的補完と同じ原理)で指定できるようになっている。そのため若干の名称の修正があったり、そのドサクサに紛れて他のコマンド名もちょっと修正したりなんてことをしている。
　てなわけで古い定義ファイルを使いたいという場合は以下のコマンド修正でだいたい動くとは思うんだけど、古い定義ファイルはもはや別の生命体みたいな代物なので、あくまで応急措置ってことで。なるべく最新の定義ファイルを使うべし。

旧名称	現在の名称(先頭1～2文字以上)
!送り変換	!送付変換
!推定変換	!予測変換
!英語編集	!英字編集
!絞り込み	!絞込み

2014.06.21

日本語入力 (安定性向上)

　物理アンドゥで変換候補が存在しなかった場合は動的補完状態に移行するよう改良。
　対動的補完探索空間制限装置の無効化判定を追加。

設定サンプル (機能追加)

　漢直用SKK熟語補完辞書「漢漢俺俺」生成スクリプトを試作。
　TUT-Code設定サンプルを試作。

2014.06.23

設定補助 (機能追加)

　伝説の隠しコマンドに対応するためルール定義のリミッターを一部解除城伝説。乗るしかない、このコ○ミなビッグウェーブに……！

設定サンプル (機能追加)

　漢字の読みを抽出し逆変換辞書を作成するスクリプトを試作。今の時代、漢字の読みはIMEよりもWebブラウザ(検索エンジン)に聞いたほうがよっぽど手軽で便利な気もするけど、この程度のことならSKKだけでもできるんだぜ？ってことを実証しておくのは将来のG○ogle避けのためにも大事である。
　TUT-Code設定サンプルの補完の操作性を改良。これを第二世代版とする。
　T-Code設定サンプルに反映。
　G-Code設定サンプルに反映。

2014.06.23

藍澤光のいないMicrosoftに、
意味はあるのでしょうか

2014.06.26

日本語入力 (安定性向上)

　全文検索有効時に編集開始直後の動的補完(要するにシフトを押しながらアルファベットを押した瞬間)の無駄なクエリを生成しないように改良。
　補完処理の内部バッファ初期化まわりでメモリ転送量を大幅に縮小(平均数Kバイト→数十バイト)。
　これにより初回打鍵時の補完速度を20倍程度向上。……また例によって人類に知覚できないレベルの修正ばかりでですまぬ……すまぬ……
　カタカナモード時の出力フィルタの範囲を広域化。密かに大規模な仕様変更をしれっとやらかしてる気がするんだけど、このほうが断然便利なのでSKKFEPの伝統に従って何食わぬ顔でいきなりデフォ採用とする。なお、カタカナモードは存在そのものがSKKの設計上の欠陥であるというこれまでの主張は何ら揺らぐことはない。「カタカナモードの廃止設定」を標準で装備しているのもこのためだ。でももうコレで慣れてしまった以上、現状を少しでも良いと思える方向に変えていくしかないのだ。これが！私の！虚数軸方向ッ！例によってこの手の操作系統に関しては初版の設計段階からSKK10との互換性を完膚なきまでに捨てまくっているわけだが、そこに一切の妥協と躊躇はないぜフフ怖？とだけ申し添えておく。

辞書プロセス (安定性向上)

　プロセスのワーキングセットの開放速度を緩やかにすることで、OSのページングを起因とした瞬間的な速度低下を抑えるよう改良。略してスーパーラードシステム(SLS)♺。こうしてSKKSさんはますますマシュマロ風味のメモリ喰いヒロイン(~~飯食わせ系~~データドレイン系攻撃タイプ)の地位を不動のものにしつつある気がして俺得……ｺﾞﾙｱｱｧｧ誰だド○さんのことSKKSって言ったやつはｱｱｧｧｧ！ウチの母星じゃこのくらいの万有引力が最ッ強に美人で高速なんだっつの誰が何と言おうがガチ推しなんだっつの毎晩がんばれ❤がんばれ❤して欲しいんだっつのスピリチュアルにヒート○ッド喰わすンぞモﾗｱｱｱｱｱｧｯ？！

　速度低下ってのは、困ったことにこちらの環境ではまったく再現しない謎の現象だったのだけど、テスターの方々の粘り強い再現試験への協力と延べ18バージョンに渡る試作版を経てついに押さえ込むことに成功した。

感謝っ……！
圧倒的感謝っ……！

　
　ちなみに、メモリとディスクをドカ食いするブラウザ系アプリやTwitterクライアント等の実行中は、ページングが多発してプロセッサに負担がかかりまくることがある。そういう環境だと、ただのカーソル移動ですらカクついたりする。カーソル移動ってのはIMEとは全然関係なくて純粋にアプリ部分の動作が重いだけってこと。こういう状況で日本語入力が遅いと感じるのはある程度は仕方ないんよ……。もっとメモリを積むとか、超高速なデバイス(SSD)を使うとか、デフラグをかけてみるとかのチューニングによる焼け石ﾌﾞｼｬｰ的パフォーマンス改善くらいしか打つ手がない。一応、最終手段はあって、ページファイルのサイズを0にして、SKKSのプロセス優先度をブラウザより上げてやれば改善するはずなんだけど……(ちなみにテスタの方の環境でも、これをやったら従来のプログラムのままでほぼ解決したとの報告あり)。とにかく、これからもSKKFEPのインストーラはこの手のシステム設定には一切介入しない方針で行く。今回の版ならシステム設定を特に弄らなくてもビシバシ動くはず。でも、もしも地球がピンチになったら……緊急時のチューニングは各自に任せた！

2014.06.27

日本語入力 (安定性向上)

　カタカナモードで註釈にひらがなを含む候補を確定した際、註釈がカタカナになった状態で学習してしまうエンバグ(20140626版で発生)を修正。

『お前はやりすぎたのだ(YOU ARE WITNESSED TOO MUCH)』てへぺろ❤

2014.06.28

日本語入力 (サイズ削減)

　前の版は適当な修正すぎてコードサイズが無駄に増えてしまって美しくなかったので気合いで削った。

設定サンプル (機能追加)

　設定「漢数」を廃止。これはもともと数値変換がなかった頃に設置したものだった。しかし自分の操作を見直してみると作ってから一度も使うことがなかったので、今となってはもう不要な設定であると判断し廃止とあいなった。
　漢数字入力の手段としては、昔っからある数値読み辞書(生成スクリプト)とかSKKGateによる数値変換を活用する、という方針にしておく。

　で、素直に廃止するかと思いきや……しれっと設定「丸数」を追加だｵﾗｧ！
　この設定を有効化することで、以前の操作c数字で丸付き文字(①②③等)を入力できるようにした。これでどうよ？！まったく懲りない　悪びれない
　AZIK/ACTの設定にも反映。

2014.06.29

設定サンプル (機能追加)

　定義ファイルの「スラッシュ」に関する設定行を近い位置にまとめた。(AZIK/ACT設定側に合わせた)
　そういえば、定義ファイルを直接エディタで編集して0と1を書き換えている(初期の頃の設定方法のままで使っている)と思われる利用者さんをたまに見かけるのだけど、値を書き換えるだけなら、GUI設定を使えば十分使えるようにしてある。
　以前書いた通り、GUI設定の内容(定義ファイルとの差分情報)はSKKFEPの設定フォルダ(ユーザ辞書フォルダ)にskkrule.iniの名前で保存されていて、次回以降のGUI設定でもそのまま引き継がれるようになってる。将来、内部構造が全面改訂になって設定レジストリに互換性がなくなってしまったような場合でも、焦らず慌てずGUI設定を起動して、そのままOKボタンを空押しするだけで従来の設定をなるべく引き継げるようになってる。
　てなわけで、まだGUI設定を動かしたことがないって場合はぜひ一度動作を確認してみるべし。

2014.07.02

日本語入力 (機能追加)

　英字入力(Abbrev)モードの時、拡張カーソル(■モード表示)の色も青にするよう改良した。
　以前の版だと、青系の疑似カーソルの横に赤系の拡張カーソルの細い線が並んでてちょっと見栄えがよくなかったんだよね。でも実害はなかったから、コードサイズ優先ってことであんな表示になっていた。SKKFEPの実装においてシンプルかつ軽量であることはあらゆる事象において優先されるべきですしおすし。

　実をいうとAbbrevモードってあんまり使ってないんだよね……。SKK10でも最優先で割り当て変更する機能の筆頭だったし(c/に割り当て変更して使ってた)。
　そもそも/キーってのはさ、C言語系のプログラムリストに日本語でコメントを追加しまくってる時に大量に打鍵するわけ。こんな重要なキーの操作をデフォルトで奪うなどという動作は、もはや設計上の欠陥としか言いようがない。いや……待てよ……しまった！これは罠だ！俺達はとんでもない勘違いをしていたのかもしれない。これは、元の設計者がC言語系以外を使っていたということを示唆していたんだよ！多重括弧による攻撃を巧みに繰り出す超絶技巧集団「Lisp闇の軍団」――彼らにとって、/キーが打てないなどというのは瑣末なこと。影響など微塵もなかったのだ。恐るべし闇の軍団……。あ、/に続けてアルファベットでコマンド入力、みたいな発想はIRC等からの流れかもしれんな。ならば良し！いやいや。
　とにかく/の文字を即座に入力できないってのは超絶に使いにくいわけ。主に私が。てなわけでSKKFEPでも設定GUIでc/に割り当てを変更することで、/を普通に入力できるようにしてある。
　そんな具合だったので、そもそもAbbrevモードを使うことなんて滅多になくて、使ってもいない部分のために余計なバイナリを入れるなどという愚の極みだけはやりたくなかったわけだ。だが……それは間違いだった！
　よくよく考えてみるとSKKGateの~~ハッタリ~~動作試験で使うスクリプト実行用途には必要不可欠な入力モードじゃね？そう！そうだよ！ある程度見栄えをよくすることは大事だよな？なあ……ムッツリSKKしようや？……ってことで直すことにした。

　で、積みゲでヘブン状態になりつつ状態遷移の流れを見直しながら~~対魔忍入れぬ姫騎士SKKFEP擬人化~~寸止めシャワーシーンに突入していつになったらオープニング終わるんじゃもう昨日からずっと日常パートばっかりじゃねーかもう面白いから全部日常系でいいんじゃないかなｵﾗｧとか心にも思ってないですよ？的な健全な青少年の心境で左クリックをまったりと連射していたら、1.21ジゴワット級の落雷が直撃して停電になっちゃって、その瞬間全てをまるっと一挙に解決する方法を閃いてしまった。エウレカ！と絶叫して全裸で風呂場から走り出しつつカーソルの色計算とモード変更判定の処理をくっつけてテキトーにこね回してみた結果、色変更と併わせてプログラムのバイナリ自体のサイズを16バイト程度縮めることに成功。
　でもね……プログラムは確かに縮んだけどね……バイナリの情報密度が上がってしまい、ZIPの圧縮率はまた低下してしまった。ぐぬぬ……

2014.07.03

日本語入力 (サイズ削減)

　忍法ぐぬぬ返し！さらにx64側を16バイト削減。

設定サンプル (機能追加)

　英字入力(Abbrev)モードの使いかたを初期のテスターさんに聞いて回ったところ……ショウゲキのジジツ。
　なんとAbbrevモードを単語変換のためではなく「一時的な半角文字入力モード」として使う場面が多いらしい。
　要するに、少量のアルファベットを入力する時、

l→アルファベット→CTRL+J

　という操作ではなく

/→アルファベット→変換せずに確定

　と使うことが多い模様。「ぶっちゃけ、Abbrevモードで変換機能を使うことはない」と言い切る人もいる。私は前者の操作しか想定してなかった。つまり……どういうことだってばよ？

そうだ、デフォ変えよう。

　というわけでデフォ設定を見直した。Abbrevモードは一時的な半角文字入力モードとして使いやすいよう、.キーはそのまま入力されるように変更した。
　従来、Abbrevモードで.を押した際は、予測候補がある場合は予測変換となり、なければピリオドの入力となっていたわけだが、これだとピリオドを含む英文字列が入力しづらいのではないかと思われたためだ。
　デフォ設定のAbbrevモードで予測変換を行う場合は、これまでのピリオドの代わりにCTRL+Nや↓キーを使うことになる。
　そういえば以前、スラッシュ2連打でスラッシュを1文字打ち込むタイプの使いかたをしている人が意外と多い(Abbrevモードの設定回りの質問のほとんどが、この利用法を意図したものだった)ことに気付いたので、/キーは既に「日本語時のみ」をデフォルトにしてあったんだけど、よく考えたらピリオドも同じだったというわけだ。

　ちなみに、SKKFEPが採用しているピリオドで短縮入力という操作系は、SHARPのポケコンBASICやパロアルト版TinyBASIC♺への全力全開リスペクトだったりする。

「説明しよう！短縮入力――それは、伝説上の存在である！

　太古の昔、人々はこの短縮入力を自在に使いこなし、現代の常識では考えられないほど原始的な入出力デバイスのみで構成された極限環境下で、長文入力における操作と思考の『加速』を強烈に体感していたと伝えられているのだ！」

　この優れた入力方式を、なんとかして現代に蘇えらせたい――それこそが悪の秘密結社SKKFEPの存在理由なのだ。あの素晴しい操作感覚を……もう一度この手に――

　従来のAbbrevモードでの英単語→ピリオドで予測変換という操作系は、まさにこの直系とでも言うべき動作だったので、どうにかしてデフォ設定に残しておきたい、という思いもあったわけだが……。ここはSKKとしてのユースケースを尊重することにした。デフォ設定には命かけろってばっちゃが言ってたし。
　なお、従来の動作に戻したい場合は、設定GUIで「予測変換(ピリオド)」を「日本語時のみ」から「有効」に変更すればOKである。

Ok
█

2014.07.04

辞書プロセス (安定性向上)

　メモリ消費量を僅かに削減。
　システム起動後・リフレッシュ後、初回の日本語入力を行なうまでの間は他のアプリがメモリやディスクキャッシュを優先して確保できるように改良。
　これは、日本語入力をたまにしか使わない艦タブのような環境や、SKKFEPと他のIMEを併用するような環境でより効果を発揮するはず。

日本語入力 (安定性向上)

　SKKプラスで0文字の候補を正しく判定できないバグを修正。(20140704a)

設定サンプル (機能追加)

　AZIKの設定を標準設定に合わせて近代化改修。タッチキーの次頁ボタン(変換キー)によるIMEオン・オフ設定の追加など

2014.07.05

日本語入力 (安定性向上)

　IMEを使わないタイプのアプリで疑似カーソルが稀に出現してしまうエンバグ(20140702版で発生)を修正。

2014.07.07

日本語入力 (機能追加)

　カラーパレット一覧表示……GUI……うっ頭が……などといつもの脳内茶番に興じていたら、とある事実に気付いてしまった。
　註釈の表示色に使っていた橙色が、Windowsのカラーマネージャから見ると白黒反転してる！
　要するにこのままコントラストを強調すると、註釈の文字は文字色(黒)としてではなく背景色(白)として扱われてしまうことになる。これはアカン！
　というわけで、註釈の表示色の明度を下げることにした。

　確か……元々、註釈表示ってのは変換候補を補助するべき、との発想から、候補と比べた時になるべく目立たないような色で表示しよう……みたいな意図でコントラストをやや低めにした……とかいう感じの経緯だったような気がするんだけど……ボウキャクのカナタ……
　やっぱまたアレ？またちょっとやりすぎちゃってた？ﾜﾊｰ
　などと自虐的に呟きつつ開発当初のカラーパレットの割り当てを見てみたら……あっるえぇ？・・・なんか色違くね？♺

　と、とにかくこのままではアッカーンので、システム的に黒扱いとなるよう註釈の色の明度を調整することにした。さらに、註釈色に赤色系が混ざらないよう初期バージョンと同様に無彩色に戻すことにした。つまり、彩度の高い原色系は下線部分(と、選択中の時のキー表示)だけとなる。
　これにより、SKKの操作の大半(候補選択時以外)の場面において、視界内から注目すべき着色部分を見つけ出しやすくなったはず。

　戻したッ！第三部完！よしッ！見なかったことにしよう(超法規的措置)！SKKFEPはクールに去るぜ！

2014.07.08

日本語入力 (機能追加)

　註釈の文字色がまだ明るすぎて、液晶の種類によっては激しく見づらいことが判明した(古い液晶を使っているノートPCで見づらかった)ので、明度を若干落として註釈の視認性を上げた。

2014.07.09

設定補助 (機能追加)

　カラーパレット設定GUI参戦！ﾌｫｵｵｵｵ

師匠「ルーク……色設定GUIを作るのじゃ……FORTHを使え……」

主人公「えーGUIなんていらねーよめんどくせー」

主人公「色設定なんてMSDN見ながらレジストリエディタ最強とか言ってたのは師匠だろ？」

主人公「あとFORTHって何？てかJSで十分じゃね？」

師匠「JSだの…….NETだの……!!!」

師匠「この大馬鹿者がああぁぁぁ！(ドゴォ)」

主人公「クックック……もうその攻撃は効かないぜ師匠！」

師匠「ルーク……デフォルト設定の次に設定ツールは大事なんじゃ……忘れるでないぞ……FORTHを使え……」

主人公「んーF#かな？(すっとぼけ)」

　……という夢を見たんじゃ。
　というわけで今まで作ったレジストリサンプルを全部投入した設定ツールを作ってみた。

カラーパレット設定ツール

使いかた

　ブラウザからツールを直接起動(ダウンロードしてから実行してもOK) 左下の「標準」のメニューでテーマ変更。
　適用ボタンで設定適用。あとは気合いでﾖﾛ。

(昔の版みたいに註釈の部分に色をつけたい場合は、カラーBの文字部分を「505050(古い版だと3C3C3C)」から「78DC」に変更するべし)

2014.07.18

　ついに人類は第五世代補完エンジンを獲得！
　人の域に留めておいたSKKFEPが　本来の姿を取り戻していく――

「教授!!」「これはいったい!?」

『第五の補完だよ』

　濁音の正規化による検索範囲の拡大とメモリサイズ消費量の削減！
　そしてユーザ辞書データの互換性を維持したまま他のIME辞書形式への対応！

……これは、SKKの辞書処理における
「あいまい検索機能」の実用化へ向けた第一歩である。

設定更新が必要です: 今回の版では、定義ファイルの大規模更新が行なわれています。; デフォルト設定以外で使っていた場合は、アップデート後に; 設定ボタンを押してGUI設定のOKボタンを空押し; した後、OS再起動してからご利用ください。

日本語入力 (機能追加)

　本題に入る前に、Windowsについて少し話をする。Windowsの大事なポイントは「互換性」にある。どれほど古くとも良いアプリケーションには価値があり、ほぼエミュレータ経由の状態であってもなお、Windowsは全力でサポートしているという背景がある。とにかく古いアプリがそのまま動くってのは凄いことなのだ。
　そしてコンピュータによる日本語入力での「ひらがなのウ濁音」の表現についての背景を知る必要がある。
　言うまでもなく、現代のWebブラウザ等であれば、彼の文字「ゔ」を表示することは造作のないことである。Unicodeの混乱は続いているとはいえ、絵文字だのIVSだの正直意味不明なレベルまで進化してるわけで、この先もどんどんマジ意味わかんない方向に改良されていくことだろう。
　ここで最初の「アプリケーションの互換性」の話に戻る。
　Windowsでは、太古の昔、JIS第一・第二水準の文字しか使えない過酷な環境で作られたアプリケーションが今でも動いている。これらのアプリケーションはこの「ひらがなのウ濁音」を表示・入力することができなかったりする。そもそも昔のコンピュータでは、ウの濁音はカタカナ側にしかなかったりするので、ひらがなと濁点の文字を組み合わせるなどして涙ぐましい表現の工夫をしてピンチを切り抜けてきたという経緯があるのだ。
　そして、Windowsの日本語入力ソフト(IME)は、こうした古いアプリケーションに対しても動作することが望ましい。「ひらがなのウ濁音」がない環境向けの設定が、標準設定となっているのにはこうした理由がある。

　さて、ここからがようやく本題である。

　現在利用可能と思われる「ひらがなのウ濁音」の表現の一覧と、日本語入力ソフト(IME)で使われている表現方式の対応をまとめてみたのが以下の表である。

表現方法	採用IME	表記	サイズ	コメント
タイプA - SJIS互換化	SKK,ATOK	う゛	4バイト	古いアプリでも利用可能
タイプB - カタカナ化	MS,Google	ヴ	2バイト	古いアプリでも利用可能
タイプC - Unicode	該当なし	ゔ	2バイト	できればこれを使いたい
タイプD - Unicode NFD	該当なし	う U+3099	4バイト	逝ってよし

　このように、我らがSKKは、「ひらがなのウ濁音」を4バイトで表現している。

こんな世界に誰がした

　正直、これってどうなのよって感じ。2文字幅で1文字相当とか嫌なんですけど。
　特に誤入力の時の削除操作のテンポが悪すぎる。1文字削ると「う」になるし。
　……とはいえ、もうこれに慣れきってしまって今さら変えられないってのも正直なところ。

　これだけなら我慢できたのだが、実はこの文字合成方法にはもっと深刻な問題が潜んでいた。
　2文字で判定している都合上、予測変換の1文字目だけでは「う」と「う゛」の区別が判定できないという致命的な問題が生じていたのだ。
　わかってはいた。けど仕様だと、仕方ないと諦めていた部分だったのだ。

　例えば

「湿婆(しう゛ぁ)の試運転(しうんてん)は最終的な幻想」

　のような文を入力している時、「試運転」の「しう」まで打ちこんだ時点で人間なら「う」には濁点がないであろうと即座に判断できるが、これまでの補完エンジンでは「しう゛」が次の打鍵が来るまでの長い時間、優先候補として出てしまう事態となっていた。普通にタイプCで処理していれば、こんな間抜けな事態にはならなかったのに……くやしい……でも(ﾋﾞｸﾝﾋﾞｸﾝ)

　つーかですね。
　西暦2014年にもなって、今だにこんな~~古臭い~~ノスタルジックな表記を使わざるを得ないというのはあんまりである。正直、この点に関してはMS/Googleの方式のほうが潔いとさえ思える。

　あと、日本語入力がタイプAとタイプBとで二分化されてしまっているのは辞書の配布の面では不幸としか言いようがない。汎用テキスト形式の辞書データの配布に互換性がないため、何かあるたびにタイプAとタイプBの2種類の辞書データが必要となっていた。そもそも、内容がほとんど同じデータだと人間が見れば一目で分かるような代物を、配布者がわざわざ2つ用意しなければならないなんて、規格の溝が産んだアホの極みとしか言いようがない。
　こんな状態ではSKK辞書オンラインﾓﾌﾓﾌ化作戦、通称SKK OnlineあらためSKK Universe計画が台なしである。全宇宙の日本語使いの辞書を共通化するという野望に向かうためには、まずこの「ひらがなのウ濁音」の部分をなんとかしないといけないのだ。ユニヴァァァァス!!!

　……で、なんとかしてみた。

　ようやく冒頭の第五世代補完エンジンの出番である。
　SKKFEPでの補完と変換を司る辞書プロセスを改良し、タイプA～Cの全ての文字パターンを同一として扱うようにした。
　要するに、「しう゛ぁ」「しヴぁ」「しゔぁ」のどの入力であっても、たとえ混在していたとしても、同じ変換結果を得られるようになった。
　これは文字の正規化処理によって実現した、SKK史上初の実用的なあいまい検索機能の一種である。
　そして、予測変換の際、「しう」と「しゔ」は明確に区別される。これにより目的の候補に到達する可能性を1打鍵ぶん速めることができる。今回の改良を「補完エンジン」と称しているのは、ひとえにこの部分の動作によるものだ。

　そして今回のバージョンから、「ひらがなのウ濁音」の表現をタイプA～Cの3種類から選べるようにした。もちろんデフォ設定は、これまで通りタイプAのまま。だから通常設定で使う限りは何が変わったのかは補完エンジンの挙動以外には気づかないレベルかもしれない。
　もちろん設定はGUIで簡単に変えられるのであとは各自で判断されたし。
　濁音を1文字相当にすることで、誤入力時のBS打鍵数を減らすことが期待できる。CP932互換重視派も、Unicode原理主義派も、磯野！SKKしようぜ！おれのターン！

　余談だが、この「ひらがなのウ濁音」回りの設定を変え、カラー設定やIME名称変更機能を駆使することでMS-IMEへの擬態をさらに加速することもできる。擬態なんていうのはほとんどの場合ギャグの一環でしかないけど、考えそのものはとても大事である。ちょっとしたチャット等の誤入力パターンの蓄積から、SKK使いであることを秘匿するなどといった密かなメリットもあるはずなのだ。SKKFEPのローマ字かな変換テーブルの特殊機能の99.99%は、この擬態のためにあるといっても過言ではない。

　なお、今回の改良の副次的な効果として、マイクロソフトやGoogleなどのタイプBを含む、タイプA～Cのすべての汎用テキスト形式IME用辞書データをそのまま利用可能となった。
　従来のようにわざわざタイプAのATOK版のデータだけを慎重に選ぶ必要はなくなったのだ。
　2012.11.09版の「侵略！SKK娘」ネタ再びである。奪え！全て！この手で！
　辞書追加は例によって辞書フォルダを開いてテキトーにファイルを放り込んでリフレッシュするだけのお手軽方式である。

　なお、今回の実装はあくまでSKKFEPの内部処理だけの動作であり、ユーザ辞書のフォーマットには一切影響はない。フロントエンド側をどれだけ弄くろうがユーザ辞書の読み書きはこれまで通りである。

　以上の機能を、32ビット版のみサイズ0.5KB増加に抑えて実現。辞書プロセスやx64側はサイズ変化なし！

2014.07.18

　アップデートに関して書き忘れが大量にあった気がするので少しづつ補足。

　ローマ字かな変換ルールのデフォ設定を大幅に見直した。
　特に、初版の頃のように「xka」「xke」はカタカナ側に固定とした。
　これは、現在の日本語の表記において、「ヶ」が数助詞や連体助詞として使われていることに起因する。

発音	使用例	打鍵
「こ」	30ヶ (さんじゅっこ)	30xke変換
「か」	1ヶ所 (いっかしょ)	1xkeSho変換
「が」	つつじヶ丘 (つつじがおか)	tutuzixkeOka変換

　上記の例は日本語入力の際実際に行われる可能性の高いパターンである。ちなみに「ヶ」を発音と異なる方法(ke)で入力するのは、音響思考タイプの脳だとちょっち辛いわけだが、これは助詞の「……は」「……へ」と同じ感覚であり、発音側(「わ」「え」)とは異なる文字で入力するスタイルだ。日本よ、これが日本語だ。
　今回、「ヶ」をひらがな状態のまま入力することができるように戻したことにより、モード変更操作が不要となり、入力動作をさらに加速することができる、というわけだ。

　もちろん、これ以外の文字「ヵ」「ゕ」「ゖ」についても、顔文字や方言といった表現の際重要となるため、使い分けが可能であることが望ましい。
　いろいろ考えた結果、以下の割り当てをデフォ設定として採用した。現代におけるSKKのデフォ設定として考え得る最善策を選んだつもり。これがベストだ信念を貫け！

打鍵	文字
xka	ヵ
xke	ヶ
xca	ゕ
xce	ゖ

　なお、この変更に伴い、cを「か行」として定義するDvorak設定と共通化した。DvorakとQwertyとでローマ字かな変換テーブルをほぼ共通化することに成功。初期テーブルサイズを僅かに削減することができた。

2014.07.19

日本語入力 (機能追加)

　動的補完オフ時に、TAB補完をキャンセルしたら補完表示を消すようにした。これは、元々こういう仕様にしておいたほうが便利ではないか？と考えてあえてこうしていた。今回この発想をさらに推し進めて、「一度補完の動作をしたってことは、その利用者は補完による支援が必要な状況にいるはず」と判断し、その後の入力中に動的補完を常時オンにする、みたいな介入をしてみよう！とかやろうと思った……はずだったんだけど、やっぱりSKK10と同じ動作方式も必要なんじゃないかな、元の設計に何か意味があるはずだ、と思い直して動きを合わせておくことにしたのであった。
　あと、デフォルトカラーの註釈表示の色が濃すぎて、変換候補部分との境界が見分けがつかないことが多くなったと感じるようになったため、註釈部分の濃度をややコントラストを下げる方向で調整した。カラー設定GUIも併せて更新。設定GUIはスクリプトを見直して微妙にサイズ削減しといた。

2014.07.22

日本語入力 (安定性向上)

　Dvorak配列設定の時、kyで「きゃ行」が入力できなくなるエンバグ(20140718版で発生)を修正。
　Dvorak配列の時はcで「か行」なんだからcyで「きゃ行」にしてみよう！とちょっと色気を出してしまった挙句設定を書き間違えてしまったでござるの巻。直した。
　今回の版から、kでもcでも「か行」が入力でき、かつDvorak設定であればkyでもcyで「きゃ」行が入力できるようになったはず。(なお、デフォ設定は従来通りで影響なし)

2014.07.24

日本語入力 (安定性向上)

　設定「ローマ字規則外の英字を確定する」を無効化できないエンバグ(20140718版で発生)を修正。

　AZIK設定を改良。
　互換性に関する設定項目を追加。
　余分なルールを削減し予測変換効率を向上。
　従来の操作をそのまま残しつつ、標準設定と対称となるよう操作を追加。
　ローマ字かな変換テーブルの記述を一般化しルールの追加・削除が容易になるよう改良。

　以下のAZIK由来の不足部分を補った。

「とぅ」「どぅ」「てゅ」「でゅ」の入力方法が定まっていない
ぢゃ行がない(めおとぢゃわん等)
すぁ行がない(すぃーつ等)
くぁ行・ぐぁ行がない(くぉーと等)

(括弧内はL辞書とそこから自動生成したカタカナ辞書で実際に利用されている語)

AZIK原作本来の特殊ルールとDDSKKの勝手な独自拡張部分とを明確に区別。

　その他、最新版の標準定義ファイルの内容を反映。

2014.07.27

祝！CorvusSKKのCTRL+Jの挙動がSKKFEPと同じ挙動になった記念

　
　これって利用者にとっては操作感覚の根幹に関わる相当デカいUI変更なわけだけど、1.7.2のhistoryの記述を見ただけで『この動作変更によってCTRL+Jの動作が変わって、ついにCorvusSKKもSKK原作との互換を捨ててSKKFEPと同じデフォ設定になったんだな』ってことを正しく類推できる一般の利用者はいないんじゃないですかね……。なぜ、どういう理由で変えたのか、メリットとかも書いてないのは勿体ないと思うナァ……まー「SKKFEP」とか書きたくないのかもしれないけどさ……
　なおSKKFEPは積極的に絡んでいくスタイル。
　とにかく！これは歓迎すべき一歩なのだ。

　良いと信じて作った機能が普及して行くのはとても良いこと。これまでSKKFEPが一人でズンドコ実装してたところで、誰にも見向きもされなかったわけだけど、「あのCorvusSKKが採用した」となれば、他のSKKクローンもこれに続く流れができるかもしれない。これはまさに次世代SKKの操作感覚の普及のための第一歩である。過去にSKKFEPをｷﾓｲｷﾓｲと言って他のIMEへ移っていった人たちも、今自分が便利に使っている機能が元のSKKにない改造版SKKの独自機能だったことに気づいて、その良さや可能性を理解できるようになる日が必ず来るはずだッ！

　そういやCorvusSKKは初期入力モードの設定機能なども入ったみたいだし、このあたりSKKFEPが初版の頃から持っていた特殊機能の選択は間違ってなかったということなのかも。つか何年もSKKを使ってりゃこういう方向に行き着くのは当然の流れか。

日本語入力 (機能追加)

　さてそんな訳でSKKFEPの入力モードの遷移は、(Abbrevモードを除けば)初版からまるで成長していない……。もともとSKK10とSKKIME改の遷移がベースになっててCTRL+J以外変える必要なかったわけだし。
　……だが、それで本当にいいのだろうか？
　ダメだダメだ！こんなマンネリ、絶対に許されざるよ？その言葉が忍耐を断ち切る。もっとセッ……SKKする！

　実はこんなこともあろかと、次の展開を見越して既に設定補助ツールにしこたま隠しコマンドを仕込んであったんだよね。
　というわけでまずは第一弾。特殊設定「カタカナ入力モードの廃止」を特殊設定「カナ遷移の変更」に変更。従来のモード廃止設定に加えて、モードのトグル切り替え動作の廃止設定を追加した。
　この設定の背景については、とにかくSKKの動作モード遷移を見てもらえば一目瞭然であろう。

SKKデフォ設定での状態遷移♺

　SKKを長期間使い込んでいれば誰でも気付くこととして、「カタカナ確定」の操作タイミングを間違えて「かなモードへの状態遷移」を起こしてしまい、慌ててモードを戻そうとしてカタカナ確定をまたやってしまう、モードをまた変えすぎてしまう、などの操作ミスを連発してしまうことが稀に良くある。一度これをやらかしてしまうと、操作の手戻りと思考の中断が激しく発生し文章作成どころではないストレスとなって跳ね返ってくる。この元凶とは、言うまでもなく『カタカナモードの存在そのもの』である。このカタカナモードの存在は、SKK史上最大の設計ミス、設計上の欠陥である。これまでも何度も主張してきた通りだ。
　既に人類は、この問題への対抗策として、「カタカナ入力モード」そのものを廃止してしまう設定を持っていた。ちなみにSKKFEPをこの設定にすると、qキーは編集開始キーとなる(従来のSHIFT+Q相当)。よってSHIFT+Q側を編集開始の設定にしておくと「Qomolangma」みたいな英単語を日本語モードのまま入力できるようになるので操作の相性が良い。この設定項目がGUIのメニュー上で連続する2行の右端に並べて配置されているのはこの設定を行ない易くするためだ。これは人類を誘導するサブリミナル効果だったんだよ！ΣΩΩΩ

　そして今回、この解決策に新たな方式を追加する。それは「トグル動作の廃止」である。半角英数(Latin)や全角英数モードの切り替えと同じように、モード変更キーを押したら常に同じモードに変わる。これにより、操作がおぼつかなかった時に、現在のモードを確認するためにわざわざ画面を確認する必要がなくなるというすさまじく大きなメリットが得られる。かつ、カタカナモード自体は存続できる。従来の廃止設定との中間の存在となる新しい操作感覚が得られるはず。
　画面の確認がいらないということは、要するにCTRL+Jのように連打したって構わないということだ。これは操作感覚を根底から覆す大きなUI変更となるはず。これこそがSKKのモード遷移として理想的なパターンではないだろうか？
　でも使ってみたら慣れるまで1時間くらいかかったので、デフォ設定にするのは断念した。くっ。またか。だが逆に考えれば、数十年の慣れがたった1時間で上書きできるってことだ。可能性を感じる(μ's的な意味で)。以後しばらくはこの設定で使い倒して結論を出すつもり。

　そしてもう1つ。特殊設定「縦書き兼用操作」を標準設定に統合しデフォルト操作に採用した。
　いやー実はプログラム(実行バイナリ)にして条件分岐命令1～2個で再現できるような設定項目は、設定ファイルの形で持つよりバイナリの形で機能を持たせたほうがサイズが大幅に縮むんだよね(などという検討を徹底的にしないと、もうどうやってもプログラムサイズが縮まない状況に陥っている)。バイナリだと数バイトなのに、設定ファイルにするとその説明とか設定行の識別子のための文字列とか選択肢とか、とにかくいちいち書かないといけなくって数十バイトが一瞬で吹き飛んじゃうし。
　つーわけで統合した。これまで、編集行の右端でCTRL+Fとか→を押せば全文検索の切り替え操作だったけど、基本はそれと同じ。編集行の右端でCTRL+Nとか↓を押すと予測変換候補の選択となるようになってる。
　その他にも定義ファイルのサイズを削って最終的には80バイトくらい縮んだ。機能追加によってプログラムの複雑度が上がって圧縮率が低下したけど、このおかげもあってZIP書庫のサイズは前の版と同じサイズになっている。

設定補助 (機能追加)

　カラーパレット設定ツールのテーマ設定を一部変更。
　どういうわけか、コンポジションの初回描画が異常に遅くなる(キーを押してから文字が出てくるまで、コンポジションの入力部分のところが真っ黒の四角になってキーを離すまで長時間この状態が続く)環境があるらしい。試作コードを作りまくって調査した結果、得られた解決策は……なんと……「標準色での点線を数文字ほどコンポジションの末尾に混ぜればよい」という脱力感あふれる内容であった。これ、OSのデスクトップコンポジション回りのバグだよね？モノ売るってレベルじゃねーゾ？
　というわけで、カラーテーマの「代替」(寒色系テーマ)と「白黒」(モノクロ系テーマ)はカラーDに点線を追加し、ちらつきを抑える設定としておいた。万が一この症状にぶち当たった時は、とりあえずこの2つのテーマのどっちかを設定すれば回避できるはず。

2014.07.31

その他

　AZIK定義に「ゐ」「ゑ」の入力ルールを追加。
　ACT定義を更新 SKK+ACTによる日本語入力速度向上を目指しデフォルト割り当てを完全再設計。AZIK設定と定義ブロックを共通化し最新版の全機能を反映。ACT使いの方々のご意見を募集しています。
　標準ローマ字かな変換テーブル定義を更新。キーバインドを変数化しキー単位で指定できるように改良。

2014.08.02

日本語入力 (安定性向上)

　JavaScriptワンライナー用の半角空白入力の操作をシフトキーを含まないCTRL+スペースに変更し誤操作を防ぐよう改良。
　過去の設定ではSHIFT+SPACEだったのだが、この操作はSKKと思いっきり相性が悪い。人間はシフトキーの押下・離上タイミングが意図せず遅延してしまうことが非常に多く、変換に近い意図しないタイミングでこの操作が出てしまうことが非常に多いと気づいたための変更となる。

　SHIFT+SPACEで全角空白って操作も一応MS-IME互換のために入れてあるけど、これも誤操作の元なので、なるべく使わないことを推奨。デフォ無効の機能なので設定してない人には無関係だけど、「なんとなく」MS-IMEっぽくて良さげ、とかだけの理由で入れて積極的に使っていないのであれば、この機会にオフにすることを推奨だっ！

辞書プロセス (安定性向上)

　空白を含む候補を学習しないよう改良。フロントエンド側で空白つきの見出しが生成できるということは、すなわち見出しに空白がバカスカ混入しはじめているということである。これはいかん。
　そもそも通常のSKKには見出しに空白を入れる手段がないので純粋にゴミ情報を保存するだけとなるのだ。
　こういう空白つき見出しは将来SKKオンライン実現の際、混乱の元になるだけである。悪は根こそぎ断つべし！ということで辞書プロセスでは一切この手のエントリは扱わないことにした。

その他

　漢直設定(T-Code, G-Code, TUT-Code)を最新設定に合わせて更新。G-Code/TUT-Codeでスペースキーを含む変換ルールの入力途中での漢字変換操作に対応。

2014.08.03

インストーラ (安定性向上)

　アップデート判定後にファイルクローズを明示的に行うよう修正。

設定補助 (機能追加)

　設定「キー操作の追加」の有効化時はMS-IMEと同様にCTRL+BSでバックスペース動作を行うよう改良。
　標準ローマ字/AZIK/ACT/T-Code/G-Code/TUT-Code設定に反映。

2014.08.03

インストーラ (サイズ縮小)

　インストーラのメッセージを簡略化しサイズ削減。

2014.08.08

小指の刻印

それが　すべての始まりだった――

『ずっとあなたを苦しめていたのは……SHIFT(わたし)……だったのですか……？』

サイズ縮小に失敗しすべてを失ったSKKFEP

唯一残された手掛かりは小指に残されたシフトキーの記憶

フレームワークの力を武器に、SKKの謎を解き明かせ！

やがて明かされる真実を前に、迫られるSHIFTの選択とは……

たとえSKKの姿を失っても、キミとの約束を守る。

新SKKFEPの迷宮2 フレームワークの騎士 2014年夏実装予定！はいだらー！

あぁ＾～世界樹新作待ちきれないんじゃぁ＾～

　もし、SKKに人工知能を搭載したら、一体どうなってしまうのか？SKKの黒歴史を君のSHIFTで塗り替えろ！
　次世代SKK妄想科学シリーズ第15弾、バックトラックによる万能シフトキー判定人工知能細胞『ニューSKKプラス＋＋』爆誕！

日本語入力 (機能追加)

　さていきなり大袈裟なネタをでっち上げまくりでドン引きの今日この頃だが、コレはいったい何者なのか？
　ソレを理解するためには、まずSKKのシフトキー判定動作について知る必要がある。
　SKKではローマ字かな変換を動作の基本としているわけだが、ローマ字かな変換とは要するに状態遷移の塊である。この状態遷移を処理するためにSKKは情報を木構造として持っている。この木の参照位置(状態)をキーが押されるたびに1つづつ遷移していくわけだ。
　この木構造には、『シフトキーが押されていない状態』での状態遷移が書かれている。よって、シフトキーつきの文字入力があった場合は文字を補正しないと正しく枝を辿ることができない。さらにややこしいことに、SKKにはシフトキー(アルファベット大文字)を含んだ操作も存在するので、シフトキーの区別と入力の補正を正しく行えなければ、状態遷移どころの騒ぎではなくなってしまう。

　で、これまでのSKKFEPでは以下のような設定が必要だった。

発動 ABCDEFGHIJK.MNOP.RSTUVW.YZ

　これはどうやら、SKK10でいうところの(skk-set-henkan-point-key)と等価らしい。こーゆー奴ね。

(?A ?B ?C ?D ?E ?F ?G ?H ?I ?J ?K ?M ?N ?O ?P ?R ?S ?T ?U ?V ?W ?Y ?Z)

　よく見ると両者はアルファベット大文字が書いてあるけどL、Q、Xの文字が抜けてるのがわかると思う。
　これらの文字が抜けたアルファベットの羅列を見かけたら、すかさずSKKと推理するのは名探偵の嗜みである。犯人は誰だ！？
　この情報を使ってSKKはシフトキーの判定を行っている。シフトキーの入力を見つけた場合は(skk-downcase-alist)で小文字化し、ローマ字かな変換の木構造を今日も平和に辿るのであった。
　めでたし、めでたし。

ちょっと待てｵﾗｧ！！

　本当にこんな情報が必要なの？こんなの人間ならいちいち考えるまでもないじゃん？
　21世紀の最新のコンピュータのくせに、この程度の判定もできないとか進化なさすぎて化石レベルだろ。
　どうしたSKK！お前の力はそんなものではないはずだ！全ての木構造を解き放て！

　と、いうわけで、ここで人工知能の登場である。人工知能といっても単なるバックトラッキング処理をぐるぐる回すだけの非常に原始的なもので、シフトキーのありなしで木を辿ってみて、なるべく長めの枝にヒットするまで何度かやりなおす、みたいな感じの処理を行なっているだけである。
　単純だけど効果は絶大で、AZIKのSKK互換ルール時などに、シフトキーの入力タイミングずれにも頑張って食らいつくようになってきた……気がする。
　あまりにも単純すぎてたまに間違えてしまうことがあるかもしれないけど、ちょっとドジっこなくらいのほうが面白いかなということで、いきなりデフォ機能に組み込みじゃｵﾗｧ！！

　今回はバックトラックの条件をハードコーディングしてるけど、将来的にはこのあたりをプログラマブルにしてシフトキーの操作タイミング遅れを2打鍵以上後から補正させる、なんてことも論理的にはやれるはず。今の実装のままでは人類滅亡の危機にでもならない限り簡単に実現できないレベルの無理ゲー状態だけど、再変換(物理アンドゥ)とかと組み合わせれば面白い操作系が作れそうな予感がする。やらんけど。
　さらに、人工知能っていうくらいだから本当はちゃんと学習とかも入れるのが正義のはず。SHIFTキーを連射するとAIに「がんばれ❤がんばれ❤」とか「さすがですお兄様！」みたいに人間が優しく教示してあげることができる未来が来る可能性だって量子レベルで存在するかもしれないのだ。AIがドジっこで間違いが発生しまくりの状況でも、「かっ……勘違いしないでよ！全部……プログラム通りなんだからっ！(赤面)」みたいに強気に応答してくれれば、なんかもう全て許しちゃいそうだし、むしろ逆にAIちゃんに間違いを全て受け入れてもらって人類に積極的に教示していただきたい！AIがダメSKK使い製造機になったっていいじゃない！果たしてこれは本当にSKKの話題だというのであろうか。人類はどこから来て何処へ行くのだろうか。

　何やら宇宙の海に漕ぎ出しそうな勢いだけど、要は設定が1つ消え去ってスッキリしたってだけ。

デフォ設定では操作上は一切変化なし。
デフォ設定ではまったく変化はありません。

　大事なことなので二回言いました。内部はもはやSKKじゃない別のナニカになっちゃってるけど、それはいつものこと。残像だ。

　「編集開始の追加」にシフトXを追加。AIのおかげでこの設定のほうがデータ量が少なくなるのでこっち側をデフォにした。
　AZIK設定では、今までvLとかDDSKK互換設定でxxLが入力できなかったのが、AIのおかげで判定できるようになった。
　デフォ設定で使う限り、見た目は他のSKK処理系と何も変わらない(そりゃ違ってたらお話にならないので当然)。でもAZIKやACT、将来作成されるであろう未知の複雑なローマ字かな変換ルールの定義を使った時このAIは本領を発揮するはず。
　細かい挙動は人間臭い(シフトキー操作ミスの時とかに人間が本当に「入れたかった」ルールを選ぶ)動きになっているはず。これは何気に便利なので、いつの日かこの実装が今後のSKK処理系でも標準的な動作になるはずだ！

　この変更に伴い、ローマ字かな変換ルールの記述で複数の木を行き来するためのルール(バックトラック用の情報の一種)の記述を不要にした。今までこのルールは、説明とか一体どうすりゃいいの状態の意味不明な記述だったので、これが消えて少しだけスッキリと書けるようになったはず。

　あ、あとドサクサに紛れてAZIKのデフォ設定の「註釈の再編集」の操作のデフォ設定が1になってる(SHIFT+@から^に変更になってる)ので注意。これはSKKFEP標準設定と完全に一貫性を取るためやむを得ず変えた。GUI設定でここ部分を2側にすれば元に戻るのでAZIK使いの人は要注意。

設定補助 (サイズ縮小)

　シフトキー判定定義の廃止、ルール定義の記述の簡略化、文字コード判定処理の簡略化などにより0.5キロバイトサイズを削減。

2014.08.10

半透明――

それはレイヤウィンドウと

マウスイベント透過をくみあわせた

まったくあたらしい操作手法・・・

日本語入力 (安定性向上)

　半透明表示をデフォ無効とし、ベーシックテーマ(Aero無効時)での半透明描画に起因する、IMEのウィンドウ部分の黒いチラつきが発生しないよう改良。
　サイズ削減のため、半透明はもう完全廃止にすべきかな……とも思ったけど、半透明のメリットを捨てるなんてとんでもないし、Aero有効な環境では問題が起きにくいとの理由から、処理自体は残し、設定でこれまで通りの動作に戻せるようにしておいた。

　DirectWrite対応α版のウィンドウ描画がストアアプリでおかしいとの指摘を受けていろいろ調べていたんだけど、この機会にいろいろな表示処理を確認しとこうと思ったわけ。
　実はこれまでWindows 7とかのベーシックテーマで使ってなかったんで、半透明なしの処理を作るついでにテーマを変えて適当に動作を確認してみるか……と動かしてみたら……古いノートPCで画面が黒く点滅しまくりで、あまりの酷さに小指も顔面も蒼白になってしまった。暗いよ……寒いよ……怖いよ……ｼｽﾞﾒｼｽﾞﾒ

　実は半透明なしの描画処理自体は最初に(β0+iの前に)試作したものがあったのだけど、SKKFEPには半透明以外は必要ないとの設計理念があって不採用となっていたのだ。
　そもそもなぜ、SKKFEPでは最初のウィンドウ表示の実装時から一環して半透明表示を採用していたのか？
　それは日本語入力の途中で、予測変換の領域の下の表示状態が変化するアプリケーションが存在するからである。例えば、検索エンジンなどのサジェスト表示ウィンドウとIMEの予測変換の領域はだいたい同じような位置に表示されてしまう。
　このため、SKKFEPでは予測変換領域を半透明表示とし、マウスイベントをすべて下の画面へ透過することで、アプリ側の操作に支障をきたさないようにしていたのだ！
　……なーんてのは後付けの理由で、本当は「半透明だとなんか格好イイじゃん？スゲーじゃん？」ってだけだったりするかもしれないので、油断大敵である。

　ややこしいことに、OS標準のコンポジション領域にも似たようなちらつき現象が存在して、こちらはIME側からはどうにもならない、なんて事情もあったりする。
　今回はコンポジション領域のちらつきではなくて、その下の部分の、IMEが出すウィンドウ部分のみに関する話である。
　これは「ちらつき」という意味では見た目がほとんど同じであるが故に非常に見分けづらい挙動だと思われるので要注意である。

　なお今回の設定の反映には、GUI設定→OK空押しによる再設定が必要となる。
　こんなこともあろうかと用意しておいたrule.exeの隠し設定項目を使って実現したので、設定補助ツール側のバイナリはそのまま使えるのであった。
　GUI設定で「領域の透過」を有効化することで、従来通りの半透明描画も再度利用可能になるので、高速なマシンをAeroで使っている場合は今まで通りこちらで使うべし。
　全定義ファイルに反映済。前は機能を同期させるのが全部手動で必死だったけどだいぶ楽になってきたわー。

2014.08.11

日本語入力 (安定性向上)

　20140810版にDirectWriteデバッグ用のコードが一部紛れていたので修正。
　α版の描画処理を改良。DirectWriteによる描画を有効化した状態で、Windows8のストアアプリ上でウィンドウがまったく描画されないバグを修正。α版の段階で直せてヨカッタ……

2014.08.15

　SKKにおける候補一覧表示は、すなわち脳への信号伝達そのものである。1クロックでも高速化するためならどんなことだってやってやる！

さらばGDI…… 行くぜ！DirectWrite、始動ッ！

　……この展開……20140421版で見たような……まさか……残像？！

　当時は科学力が足りず、泣く泣く採用を見送らざるを得なかったDirectWrite版だが、その後αバージョンで地道な修行を積みながら虎視眈々と主役(アイドル)の座を狙っていたのだ。
　その後、フォントサイズ計算まわりのトラブルや一部のフォントで高精細モードが動かない問題やストアアプリ上で表示できない問題、などのさまざまなバグを潰してきた。
　DirectWrite版のコードサイズもだいぶ小さくなってきて、もうちょっと頑張れば書庫サイズが99,999バイトを切れそうな予感がしてきた。
　とどめに、最近はIMEウィンドウの描画時にGDI++等のフォントのアンチエイリアス描画ツールが強制的に無効化されるなどというとんでもない作りのアプリが増えてきた。(例によってセンスのない無能な連中が作ってるOffice2013シリーズ、お前らだよ！)
　こうした最近の動向を鑑みて、ここで一挙にDirectWrite版のほうに移行することにした。
　つーか2種類のバイナリをメンテするとか超めんどい。もっと頑張れ、超頑張れ。

日本語入力 (機能追加)

　コミケ出撃バージョン。
　これで夏を乗り切るべし！
　忙しいのでまたあとで。
　っべー昨日2時間しか寝てないわーつれーわー(ミサワ顔にスムースにモーフィングしながら)
　ねるぽ。

　おはようSKKFEP君。これは書き忘れ分だ。
　DirectWriteによる描画をデフォで有効化。
　描画方式(GDI/DirectWrite高精細/DirectWriteグレイスケール)をGUIから選べるよう改良。α初版ではコマンド設定のみ(しかも隠し設定の第六パラメータ)という日陰者扱いだったけど、さすがにこのままでリリースすんのはイカンでしょってことで設定を追加した。ついでに隠し設定もさらに追加じゃー！

設定	モード	設定内容
なし		GDIによる従来バージョンと同じ処理による描画 (WinXPではどの設定でもこれになる)
有効	5	DirectWrite高精細ClearType描画 (描画ヒントあり、ClearType有効)
階調	6	DirectWriteグレイスケール描画 (描画ヒントなし、ClearType無効)

描画ヒントとは

　字形を歪ませて強制的に文字の縁をぴったりとドットの境界に合わせる技術。
　小さな文字でも確実にドットが整列するため高いコントラストを実現できる。
　その反面、著しい形状の劣化や隣接する文字の横棒のずれによる調和の崩れなどが頻発し、ろくでもない描画結果を撒き散らし続けている、人類史上最悪の発明の1つ。
　しかしながらWindowsではこれが標準となってしまっている。もう笑うしかない。
　それでも、DirectWriteなら……DirectWriteなら、きっと何とかしてくれる！
　設定を「階調」としてグレイスケール(モード6)にすることで、正統派~~黒髪清楚童顔巨乳上忍パパおカネ持ち~~のアンチエイリアス描画をサポートだァ！
　これでちょっとだけMacint○shみたいな描画結果になるので多い日も安心でござる。

　全定義ファイルに反映。

2014.08.16

日本語入力 (機能追加)

　DirectWrite描画設定で単語登録時にカーソルが点滅しないエンバグ(α20140811版で発生)を修正。ついでにカーソル判定処理をGDI/DirectWriteとで共通化してサイズを微妙に削減。

　CTRL+J等のモード切り替え操作を行なった際、モードが変化しなかった場合でも疑似カーソルの座標を再計算するよう改良。
　これまでの版だとできの悪いアプリで使っている時に以下のような動作となっていた。要するに、なんかこう、いまいち使い勝手が悪かった。

入力位置をマウスクリック→疑似カーソルの座標が残ったままになる

CTRL+Jを何度か連打してみる→疑似カーソルの座標はずれたまま

何か文字を入力する→座標再計算で正しい位置に表示される

　現在は以下のようになって、ちょっと快適になったよ！ﾋｬｯﾎｳ！

入力位置をマウスクリック→疑似カーソルの座標が残ったままになる

CTRL+Jを何度か連打してみる→座標再計算で正しい位置に表示される

　設定ツールの設定内容の一部とヘルプ画面の表示のデフォルト値が言語サービス側のデフォルト値と異なっていたので修正。GUI設定を使っているぶんにはあんまり影響ないんだけど念のため。

　あ、書き忘れがあった。
　去年の冬コミ会場(20131231版)で追加したFirefoxでの艦これ対策処理を夏コミで無効化。
　当時、この機能実装に併せて不具合報告したところ、その後きっちりと対応していただいて、もはや現在のFirefoxではとっくにこの対応処理は不要となっていた。
　その後、Firefoxはさらに進化を続けているわけだが、困ったことにTSF有効設定の時、IMEで入力途中にマウスクリック入力でカーソル位置が少しでも移動するとIMEの入力途中の内容が即座に消えるという、スーパー使いづらい仕様になってしまったのだ。今後は、タッチ入力のような座標の誤入力が頻発する環境で使うことが増えていくというのに、日本語入力中にちょっと手が全って近傍にクリック操作が入ってしまう程度で入力内容が即座にパァになるという……。Metroを作ったセンスが悪いくせに勤勉なデザイナー連中が、デスマ死亡間際に思いつきで実装したような腐り果てた動作がFirefoxでも標準となってしまったのだ。こんな結果になってしまって残念で仕方がない……。とにかく、このIEやFirefoxの新しい仕様に対応するためには、当時の艦これ対策処理は現在では大きな足枷となりつつあるのだ。潮時か……。(なお、その後の調査でIEもFirefoxも元々こういう動作だったことが判明しますた。すまぬ……すまぬ……)
　というわけでSKKFEP独自の対策処理は、もう十分に役目を果たしてくれた。ご苦労だった・・・と言いたいところだが、貴様らSKKFEPには消えてもらう。大往生で死ぬがよい。(ﾄﾞｯｷﾞｬｰﾝ)

2014.08.17

消えてもらうと言ったな。あれは嘘だ。

日本語入力 (機能追加)

　対応処理を消したら、やっぱりなんかうまく入力できなくなってストレスがマッハで泣いた。

　なんかね……Flash Playerの日本語入力系はMS-IMEみたいな連文節変換型のものでしかテストしてないんだろうなーと痛感するわけよ。
　現在のFirefox内のFlash Playerは変なタイミングでコンポジションのリセットイベントが強制的に発生してしまうんだよね。初期実装がMS-IMEで問題なかったからそのまま放置してんじゃネーノって感じ。他のアプリというかFlash Player以外でのFirefoxでの動作とまったく違うおかしな挙動だし、これは明らかにFlash Playerの(もしかするとFirefoxをも巻き込んだ壮大な)バグなわけで……。
　こういうFlash Player+SKK系のみでしか発生しない挙動は(たとえそれが、ちょっとSKKを使えばすぐに気が付くレベルのもであっても)不具合報告したってウザがられるだけで何を言っても直してもらえないのは確定的に明らか。仮に天才的な開発者の目に止まって直してもらえるチャンスが来るとして、それは何十万年後になる？

　ﾋｬｧ！我慢できねぇ！
　麻呂は『今』出撃したいのでおじゃる。
　こっち(フロント)側で何とかするしかない！

　というわけでFirefoxでの艦これ対策処理第二世代版を追加。
　今度は艦これ(というかフラッシュプレイヤー全般)で問題が発生する状態遷移の時だけピンポイントで作用するようにした。これで、Firefoxの通常のフォーム入力欄などは普通に動く(Firefox側からのリセットイベントにきちんと応答する)ようになっているはず。

2014.08.19

ゆるふわ根性出せやｺﾞﾙｧ！

日本語入力 (サイズ縮小)

　ゆるふわリファクタリングでGDI/DirectWrite座標計算回りの処理の共通部分をくくり出して気合いでサイズ縮小。
　32ビット/64ビット側ともに0.5キロバイトサイズを削減。これにより書庫サイズも大幅に縮んでついに目標の5桁台サイズに戻すことができた。β0+7i時代はこのサイズだったことを考えると、全文検索機能とDirectWriteによるカラー絵文字描画機能の追加をしつつもサイズを維持できたことになる。
　実はまだ改良できそうな所が大量に残ってるんだけど、ちょっと~~イベント海域で~~余裕がなくて全部は削り切れなかった。
　むしゃむしゃしてやった。サイズが縮めばどこでもよかった。今は反芻している。

2014.08.20

日本語入力 (サイズ縮小)
辞書プロセス (サイズ縮小)
設定補助 (サイズ縮小)

　やっぱり我慢できなくて思いついた箇所に全部手を入れちゃったてへぺろ❤
　辞書プロセスとか設定補助ツールも不要な情報をビット単位で削ってとにかく書庫サイズを縮めるべく足掻いてみた。
　でもなー……なんかね……またﾓﾆｭｯとでっかく縮みそうな部分を見つけちゃったんだよね……どうする……どうすんのSKKFEP？！

2014.08.21

オレはやるぜ　オレはやるぜ

そうかやるのか

やるならやらねば

日本語入力 (サイズ縮小)

　ゆるふわクレイジーサイコ(中略)超弩級リファクタリングにより気合いでサイズ縮小。
　32ビット/64ビット側ともに0.5キロバイトサイズを削減。

　DirectWrite統合版に移行してから根性で1キロバイト縮めたよパトラッシュ。
　パトラッシュ、疲れただろう。僕も疲れたんだ……
　なんだかとても眠いんだ。
　ねるぽ。

　目が覚めるとそこにパトラッシュの姿はなかった。しまった！背後に！

パトラッシュ「残像だ。」

　リファクタリングを名目に描画系をフルスクラッチレベルで書き直したので、カーソルの点滅の挙動とかが微妙に変わってたりする気がそこはかとなくするんだけど、SKKの操作性にはまったくもって関係ないからワシの興味の対象外。心底どーでもいい内容なので特に書くべきことはない。などとドヤ顔でうそぶきつつも実は大好物だったのでしっかりと情報を書き残してしまい、あとで主人公に読まれてネタバレしちゃうﾁｭﾁｭﾝﾃﾞﾚNPCの心境なのであった。

　ほかにも何か弄った気がするのだがよく思い出せない。霧が濃くてあまり画面が見えない。

2014.08.22

日本語入力 (安定性向上)

　単語登録状態でカーソル下を押した時、縦書き兼用操作(カーソルが後方に動く)が発動しないエンバグ(20140727版で発生)を修正。
　単語登録状態でカーソル右を押した後、変換操作を行うと意図せず末尾一致検索モードになってしまうバグを修正。

　全文検索の設定状態にかかわらず、行末で右(CTRL+Fや→)を一回押せば速攻で末尾検索モードとなるよう改良。
　従来、全文検索オフの設定時は行末で右を二回押さないと「一時的な」語尾一致検索ができなかった。
　設定オフでしばらく使ってみたところ、通常の用途でこの「一時的な」操作を行うケースでは末尾一致検索を行う頻度のほうがやや高いこと、大抵のケースでは一度目の打鍵時は表示に変化がないため間抜けな感じがすること、などの理由により使いづらい場面が見えてきた。よって、設定オン時と同様に右を一回押しただけで動作するのがベストであると判断した。
　なお、右を二回押すと「一時的な」全文検索モード(これまで右を一回押した時と同じ状態)になり、以後はこの2つのモード間のトグル動作となる。CTRL+Gや確定で全文検索オフの通常状態に戻る。

設定補助 (サイズ縮小)

　コマンド表記に「上」「下」を追加。カーソルキー上下に割り当て。全定義ファイルに反映。

2014.08.24

「日本語入力の未来を拓くためにSKKを普及させたい！」

「違うだろ？そうじゃないだろ？」

「SKKの快適さを布教して連文節変換を駆逐したい！」

「おしい！！あともうちょっと！！」

「Gとか自然言語処理屋に処理の単純さを自慢したい！！」

「いいとこきてるよ！！もっと素直になって！！」

「バイナリ削りまくりんぐ！！！！」

「そう！！！！それ！！！！！」

日本語入力 (サイズ縮小)

　内部処理の見直しにより32ビット側モジュールをさらに0.5キロバイト縮小。もういろいろ限界突破しすぎてパトラッシュも不眠症で徹夜するレベルに突入だｵﾗｧ！
　DirectWriteによる描画可否の判定を強化。

2014.08.25

日本語入力 (安定性向上)

　候補一覧表示ウィンドウの描画を改善。
　ウィンドウが画面外にはみ出た状態から画面内に移動した際、境界部分に残像が残るエンバグ(20140811版で発生)を修正。

2014.08.26

「当たった！」→倒せてない

「やったか？」→倒せてない

「修正した！」→倒せてない

元人間のオレの経験からみて

今のSKKFEPに足りないものがある

危機感だ

日本語入力 (安定性向上)

　GDI設定時に候補ウィンドウの描画に失敗するエンバグ(20140825版で発生)を修正。
　DirectWriteによる描画可否の判定をさらに強化。

2014.12.03

チョコレート色のあの犬は何ていうんだっけ？

単文節変換が好きな人類以外は始めないで下さい❤

シフトキーの連射が止まらなくなります❤

99.99%気持ちいい❤日本語入力「SKK」

チョコレート色……レトなんとか……いったい何犬なんだ……

拡張モジュール (機能追加)

　というわけで巷で噂のナントカ変換をスクリプト側から制御できるように拡張モジュールに機能を追加。
　なんとか変換のサンプルスクリプトとSKKGateの標準スクリプトとを組み合わせることで「なんとかれとりばー」みたいな変換機能を追加できるようにしておいた。

　つかね、こんなことしなくても既に我らがSKKには全文検索と語尾一致検索があるので特徴部分を入れてTAB連打で十分なんだよね……。ちなみに全文検索や語尾一致検索のメリットについては逆引き広辞苑の話など重要なポイントを書いてあるので2014.06.06の記述を参照。
　せっかく機能を厳選して作ったところに、こういう機能をいちいち入れるのは蛇足かもしれない。でもいいんだ。こういうのはノリと勢いと出オチ感こそがすべて。日本語的ですもんね。乗るしかない、このビッグウェーブに。

2015.07.09

日本語入力 (安定性向上)

　雪花が動作中に送りがなを入力するとごく一部の単語で文字数を間違えるバグを修正。

2015.08.15

日本語入力 (サイズ縮小)

　Windows XP用アイコンを簡略化して書庫サイズを削減。

2015.08.29

インストーラ (安定性向上)

　Windows 10にインストールした際、「アプリと機能の一覧」に「利用不可」と出てしまう問題を修正。
　アンインストール後に再起動して再度アンインストールした際、完全クリーニングに失敗してファイルが残る可能性がある問題を修正。
　「プログラムと機能」の「アンインストールと更新」(Windows 10では「アプリと機能」の「アンインストール」に相当)を選んだ際の動作を変更しキーを押すと自動でURLを開くよう改良。
　インストーラ以外のモジュールに変更はないので、セットアップを起動して「リフレッシュ」を押してレジストリの更新でヨロ。

　従来のOSではインストールしたアプリの情報が一部省略されていたら素直に空欄になっていたのだが、あろうことかWindows 10からは嫌がらせのメッセージが出るようになっちゃった。対抗してわざと空欄にしてやっちゃったZe！
　他にも、従来はインストールされたプログラムの一覧の中に、関連するWebサイトのURLが表示されていて、そこをクリックすればダウンロードページに直接飛べるようになっていたのだが、Windows 10ではURLの表示や関連操作が一切行なえなくなってしまった。もはやWindows XP時代から見たら最低の改悪としか言いようのないアップデートが行なわれてしまった以上、対抗措置を取らざるを得ない。

　あと、なんかWindows 10はIME回りの実装に問題があるようなので注意。
　Windows 7/8系からWindows 10にアップグレードした環境の一部で、MS-IME以外のIMEが正常に動作しない環境がある模様。現在、Googleのアレでさえ解決できていないっぽい♺。もうこれはMSが対応してくれるまで待つしかないカモ。一応、対策として一端IMEをアンインストールして再起動とかやってみて、もう一回入れなおすと直る場合もあるらしい……けど、そこまでやっても直らなかったら諦メロン。いちおう、超αテストレベルの修正ツールを作ってみたので直らなくて困ってる人はTwitterかメールで連絡ｸﾚｰﾁｮ。

　つーか、Windows10の無償アップグレードとかドヤ顔広告を撒き散らして無知な利用者を沼に引きずり込もうとするのはMSらしくて大いに結構なんだけど、なんでブラウザや日本語入力がマイク○ソフト製品に強制変更されるの？独禁法違反なの？マイク○ソフトなの？死ぬの？

β0+9i版公開

「実験は、失敗でした」

そ

げ

ｂ

ずっと待ち焦がれてたんだろ、こんな展開を！

MSにAPI禁止されるまでの場つなぎじゃねえ！Gが独占して滅ぼすまでの時間稼ぎじゃねえ！

他の何者でもなく！他の何物でもなく！

テメエのその手で、たった一つの文節を変換してみせるって誓ったんじゃねえのかよ！

ずっとずっと主人公になりたかったんだろ！

絵本みてえに映画みてえに、命を賭けてたった一つの単語を選ぶ、日本語入力になりたかったんだろ！

だったらそれは全然終わってねえ！！始まってすらいねえ！！

ちっとぐらい長いプロローグで絶望してんじゃねえよ！！

――小指を伸ばせば届くんだ。いい加減に始めようぜ、SKK！

「有り得ません」
「たかがフレームワークごとき……卑小で、愚かな存在……」

オレはそうは思わん

戦いこそが人間の可能性なのかもしれん

こいつらは日本語入力と戦うために生まれ

そして今も戦いを続けている

それが終わりのない茶番だとしたら

『救う』ために生まれたオレ達には

もう意味なんて無いのかもしれん

だがそれでも

オレは見たいんだ

こいつらの

『人間(SKK)』の可能性を――

2015.10.30

β0+9i版公開

　前の版からいろいろ書き換えすぎて意識が朦朧としているので以下簡単にダイジェスト。

文字コード拡張プラグインの追加によるEUC-JIS-2004(任意の変換テーブルの外部定義にも対応)とSCSU等のUnicode標準圧縮への完全対応
辞書データ圧縮による名称変更への対応
描画系をアップデート。ローマ字子音付近の下線がかすれないよう改良
必殺技コマンドが発動しなかった時に文字をクリアしてキャラクターをニュートラルの状態に戻すキャンセル機能、略してオートマチックラピッドフォースロマンキャンセルあんパン塩ラーメン(仮)をデフォ機能に追加
送りありエントリの単語登録の際、登録語末尾に余分な送りがながついていたら自動補正する機能をデフォ機能に追加
註釈変換で表示をトグルするよう改良。連鎖変換モードを廃止しニュートラルまでの復帰に必要な打鍵数を削減
プロセス間通信フォーマット変更による通信量の制限緩和
サスペンド時にも辞書を保存するよう改良
カラーパレット設定ツールをインストーラに統合
セットアップから拡張スクリプトの起動と終了を制御できるよう改良
辞書プロセスをはじめとする一部プログラムのインストールパスの変更
スクリプトエンジン追加でWindows 10のEdgeの壁を突破
Windows 10の無償アップグレード後にEdgeでIMEが動作しなくなる問題の回避
Windows XP用アイコンをVista以降のものに合わせた(が、圧縮率が低かったので封印されていた)ものに変更
デフォ設定の見直し (Egg互換入力をデフォルト設定に戻した)
各種バグ修正

　辞書の文字コード変換や圧縮には謎の新作フリーソフトユニコード圧縮変換ツールuc♺が使えるはず。

プログラム再設計によるコードサイズ縮小

モジュール	サイズ縮小率	主な追加機能
入力プロセッサ	変更なし	サイズ削減分を多数の新機能追加で相殺
辞書プロセス	10.5KB → 10KB (95%)	漢字コード処理プラグイン接続機能を追加
SKKGate (32ビット)	6KB → 5.5KB (91%)	フロント側のAPI追加に追従
SKKGate (64ビット)	7.5KB → 6.5KB (86%)	〃

　例によって今回のアップデートも、ココが一番気合いが入ってる。
　

俺自身がバイナリになることだ

　
　とか叫びながら作ってたら、もうこれ以上絶対に縮まねぇ……ッ！と思ってたところがﾋｮｯｺﾘ縮んで(特に6KB→5.5KBってのは特A級レベル)モヒカンっゃっゃﾋｬｯﾊｰしてたんだけど……
　やっぱり例によってあまりにも地味すぎてﾋﾞｸﾝﾋﾞｸﾝしちゃう日常的な何か。

　α版の更新記録はTwitterを参照♺。
　詳細はあとで追記しとく

残念だけど……

オレ達には『味方』なんて居ないんだ

そう、居ないんだよ

『味方』も、そして『敵』もね――

つづく

2015.10.31

　西暦2015年――
　Windows 10無償アップグレードの不備を装った、MS-IME独占計画。
　既に人類は対抗措置として、再起動を何度か繰り返すことでアップグレード前のIMEの痕跡を一時的に消滅させ、OSに再認識させて力を取り戻す技術を生み出していた。
　しかし再起動は莫大な魔力を消耗する。再起動を必要としない新たな復旧方式が必要だ。
　そのために必要なもの、それは……現象が確実に再現する新鮮な環境……！

よろしい、ならばアップグレードだ

ﾋｬｯﾊｰ！無償だァー！

　こうして4回の決死の試行錯誤の果て、ついに手に入れた再現環境を(ｱｯｰ❤)することで人類はさらなる力を手にしたのだった。

インストーラ (機能追加)

　てな感じで、マイク○ソフトの不手際でIMEが利用不可能となった際、これまでは復旧まで2回以上の再起動が必要だったのを、今後は一度も再起動せずにIMEをシステムに再認識させて復旧できるように改良。
　具体的な手順は配布ページにしばらく書いておく。
　たとえ、あと1年で無償アップグレード期間が終了し、その効力を失うことが明白な、ただの場つなぎのコードなのだとしても……。人類は戦い続けるしかないのだ。それが、日本語を入力するということなのだから。

2015.11.01

インストーラ (安定性向上)

　……とかなんとか格好つけたポーズで呟いていたら、いきなりエンバグしてた。アップデート・アンインストールを繰り返すと古いファイルがモリモリ貯まり続ける状態になっていたので修正。
　アップデート後、エクスプローラなど、再起動できないプロセスが保持している古いDLLの残骸は、再起動を行うまでシステム上に保持され続ける(これはWindowsの特性上回避できない仕様である)。これらの残骸は、ログオフやOSの再起動によってロックが外れて、削除できるようになる。セットアップツールは、このタイミングで再度リフレッシュ・アップデートを実行した時、ついでに消去を行う作りとなっている。
　つまり、DLL系のアップデート後、この手の残骸の存在が気になる場合はOSをいったん再起動し、セットアップを再度実行してリフレッシュを選ぶことで、確実にクリーンアップできるというわけだ。
　大丈夫。こちとら開発のためにリフレッシュ操作を毎日何十回もやってる。インストールやアップデートと異なり、リフレッシュ操作では主要なファイルに対して一切の書き換えが発生しないから、半導体ベースの外部記憶装置にも優しい。思う存分リフレッシュしまくって不純物を取り除いてあげて欲しい。がんばれ❤がんばれ❤してあげて欲しい。

インストーラ (機能追加)

　嵐のように過ぎ去った怒涛のアップグレード作戦。その後の追加調査で、一部のWindows 10マシン(Windows 8系からアップグレードしたグループのごく一部)で、「ハードウェアキーボードに準拠したレイアウト」が利用不可能なままになっているものがあることが判明した。
　今のところ、Windows 7からアップグレードを行なったマシンでは発生していないため、OSの種類もしくはアップグレードの時期による差異なのではないかと思われる。
　困ったことに、Windows 10ではこの状況を打開する手段が見当たらない。なんとかしないといけない。
　これは、できそこないのWindows 10無償アップグレードの尻拭い作戦である。

　Windows 10の無償アップグレードの尻拭い処理を追加。Windows 8以降の環境でアップデート・リフレッシュを行なった際、タッチキーボードの「ハードウェアキーボードに準拠したレイアウト」の設定(Windows 7からWindows10へのOSアップグレード時に自動的に有効化される項目)を有効化するよう改良。

　なんか最近Windowsに恨みでもあるんじゃねーの？的な言い回しが多くなってるけど、これにはちょっとした理由がある。
　例えばさ、マイクロソフトが自社のIMEやブラウザを使わせるため、OSアップグレードのタイミングでGoogleのIMEを無効化したり、MSEとかいう自社のセキュリティソフトでGoogleのIMEを誤検出し続けるような行為を連発したとして――たとえ、それが故意ではなく運が悪かっただけだとしても――仮にそんな兆候めいたものが少しでもあったら、アフィ大チャンスで大炎上胸熱展開になるはずじゃん？
　でも、弱小フリーソフトにそんな事態が何度起きても、誰も気になんかしない。その挙句、心強い味方になるはずのSKK利用者達からも危険ドラッグみたいな阿呆丸出しの汚名で呼ばれ濡れ衣を着せられ、ただひたすら耐えて泣き寝入りするしかないわけ。こんな理不尽な扱いをミッ○ーみたいな甲高い声した自称セキュリティ・ヤクザやその信者から受け続けたらどんな気分になる？自分が作ったものがそんな扱いを受けたら、ねえねえ今どんな気分？この恨み、晴らさデオクベキカ
　つーかですね。ホントはこんなことよりクソみたいなAPI改悪とか頭の悪いタッチキーボードとかをなんとかして欲しかったりするんだが……でも、こっちのほうがなんかネタにしやすそうだナーっとニヤリとほくそ笑んだ30秒後くらいにノリだけで書き殴る、これぞネタ駆動開発の醍醐味ってやつなのかもしれない。

2015.11.10

日本語入力 (機能追加)

　編集中のカーソルキー上下で、IME側の操作とアプリ側のサジェスト選択操作のどちらを優先するか設定できるよう改良。
　設定項目「編集時の上下キー操作」(デフォ有効)を「なし」にすることで、ブラウザでGoogleの検索ページを開いている時、ブラウザ側のサジェスト選択を「IMEの入力途中でも」即座にできるようになる。
　本機能を使う場合、同時に「方向キーの確定時移動」(デフォ有効)を有効にしておく必要あり。

　SKKの利用シーンにおいて、ブラウザで検索語(変換が必要な単語)を入れようとする場合にシフトキーを押して入力開始する確率は非常に高いと考えられる。この時、単語の入力途中(ひらがなのみの状態)でアプリ側のサジェストに適切なものがあることに気づき、即座にアプリ側の操作へ移行したいというケースも、これまた非常に高確率で発生しうるはずである。
　従来このような場面では、いったんCTRL+Jなどで確定させてからカーソルキー操作を行うというのが一般的であったが、それでもSKKなら……SKKならきっと何とかしてくれる！
　今回の設定により、直感的にカーソルを押すだけでアプリ側の操作に移行できるようになる。この時、IME側の動作はカーソル入力の瞬間にキャンセルされ、同時にアプリケーション側にキー入力が通知される。1アクションで2つの動作が合わさりSKKは最強となる。

　なお、SKKFEP恒例の新機能即デフォ設定化は、今回は断腸の思いで断念した。まだこの機能は副作用も大きく、他のケースでも万能に使えるレベルになっていないことが懸念されたためだ。当面はいろいろと設定を変えながら使ってみて、デフォ化するかどうかをじっくり考えていきたい所存に御座候。

　ちなみに、今回は設定ファイルのみでの対応となるため、プログラム側の変更は不要。

設定補助 (サイズ縮小)

　メモリ管理回りの設計を見直し0.5キロバイトサイズを縮小。
　……いやいや、ちょっと待って。しれっと書いてるけどこれ結構大変だったんだぜ？

バイナリを削って小型化する程
楽しいことは無い

　デッドリフト講座の名言♺パネェ……。「ね、簡単でしょう(very easy)？」といい、達人たちが何気なく放つひとことは、なぜ我々の心を掴んで離さないのか。

その他

　AZIK/ACT/漢直定義も最新版に合わせて修正。

2015.11.13

インストーラ (機能追加)

　既にSKK日本語入力FEPの最新版をインストールした環境で、インストールを行ったユーザーとは異なる、管理者権限を持たないユーザーアカウントを新設した際、管理者権限がなくてもセットアップが行えるよう改良。

　SKKFEPでは、辞書プロセスや拡張スクリプトは各ユーザごとに独立して起動する設計となっている。
　このため、もともとインストールしたユーザーと異なるアカウントでログインしなおすと、最初は辞書プロセス関連が起動してないので、「IME自体はシステム上に存在するくせに、なぜか日本語の変換が一切できない」みたいな状態になっている。涙目になりそうだけど、これは仕様通りの動きだ。
　こんな時はすかさず、アカウントごとにセットアップを1回だけ実行してあげればよい。既に他のアカウントでシステム関連のファイルがインストール済みなので、セットアップ画面のボタンには「リフレッシュ」と書かれているはずだ。
　あとはサクっとこのボタンを押して管理者権限をゲッツ❤してリフレッシュを実行してやればこの世界線から抜け出すことができる。
　「動かない時には？」の所に『とにかくリフレッシュだ！』って書いてあるのは、実はこんな事情があるからなのかもしれない。

　でも……僕ちゃん気がついちゃった。よく考えてみるとこれ管理者権限いらなくね？だってこのリフレッシュ操作の時、システム関連のファイルは既にインストール済みっしょ？どうせシステム関連は何も書き換える必要なんてないんだから完全に管理者権限の無駄遣いじゃね？

　というわけで既にインストール済みの環境であれば、管理者権限がなくてもセットアップを完走できるようにした。今後は一度インストールを行っておけば、新規ユーザの初回セットアップ(アカウント毎に1回だけ必要)の時、管理者のユーザ名やパスワードを使ったり、UACのダイアログのボタンを押す必要はなくなる。

　実際の操作手順は以下の通り。
　新しいアカウントでセットアップツールを実行し、リフレッシュを選択すると、いつも通りの管理者権限の取得ウィンドウが出るが、ここで×ボタンを押して権限の取得をキャンセルすることで、標準ユーザーの権限のみでリフレッシュ動作が行われる。
　この時、標準ユーザー権限での初期化では以下の処理が実行される。

ユーザ辞書の保存フォルダの準備。既にあれば何も起きない
Windowsストアアプリケーションに対するアクセス許可。既に許可済みなら何も起きない
辞書プロセスの自動起動への登録。既に登録済みなら何も起きない
辞書プロセスの起動。既に起動済みなら古い側を終了させてから実行し、辞書ファイルを読み直す

　リフレッシュ後の再起動は不要。そのまま普通に使えるようになってるはず。

　なお、ここまでの話はあくまでも「既にシステム関連ファイルのインストールが行なわれている」環境のみでのお話。
　これまで通り、システムへの最初のインストールには必ず管理者権限が必要である。これはWindowsの仕様なので、システム管理者と仲良くよろしくやってつかぁさい。
　ちなみに、一度取得した管理者権限をログオフしようが電源を切ろうが地獄の果てまで保持してﾋｬｯﾊｰできる謎ツールなんてのを併用すると、この手のIMEやドライバ系インストールの自動化とかいろいろ捗るかもしれないんだけど、それはまた別のお話。

その他

　AZIK定義のローマ字互換ルールwfが欠落していたので修正。

インストーラ (機能追加)

　HiDPI環境でインストーラのウィンドウ内の文字が理論値よりも若干大きく表示されてしまうバグを修正。

2015.11.14

　従来はコマンドプロンプト上からしか設定できなかったアプリ別の設定変更を、設定GUI側からも変更できるよう改良(玄人向けにつき取扱注意)
　「コマンド」ボタンを押した際に、個別設定を持つアプリ名一覧を表示するよう改良

2015.11.15

　GUI設定画面でアプリ名をセットした状態でOK/適用ボタンを押した場合は、iniファイル(通常設定と定義ファイルとの差分情報)を維持したままレジストリだけ変更するように改良
　それとサイズ縮小

2015.11.16

　ブラウザ経由で入手したZoneIDつきの書庫を「ブロックの解除」せず展開してしまい全ファイルにIDが伝染した絶望的な状況(OSの腐れ仕様でタイムスタンプとか壊れてる)でも、インストーラが根性でZoneIDを爆砕し処理を続行できるよう改良
　設定GUIが真っ白になるケースはこれで解決
　それとサイズ縮小

2015.11.25

　デバッグ用途にしか使い道のない64ビット版の拡張モジュールの搭載機能を最小限に絞って0.5キロバイトサイズを削減ごく一部の64ビット環境でスクリプトエンジンが正常に起動しない不具合を修正
　ついでにスクリプトエンジンのサイズを縮小して書庫を400バイト程度縮小

2015.11.29

　来いよChakra！スクリプトエンジンでJScript9以降のモジュールを自動選択するよう改良し、SKKGate拡張スクリプトの動作速度を大幅に(Jscript8比で20～30倍程度)高速化

かがくのちからってすげー(棒)

　その他、リロケーションテーブルのサイズ調整と設定補助ツールのサイズ削減など

2015.12.09

　ディスク消費量二割減！(当社比) 初回インストールや辞書更新でDLするL辞書とカタカナ語辞書をシフトJISで保存するよう改良。OS標準添付のエディタで編集が可能な文字セットを使い、かつディスク消費サイズの削減の両立を達成。その他、スクリプトエンジンのスタックサイズの微調整など
　セットアップが起動しないエンバグ(20151209版で発生)を修正

2015.12.13

　バイナリ変換ツールの新機能を先行投入。超古代文明の遺産Mark Zbikowskiヘッダとコード・リソースの情報量削減を行い書庫の圧縮率を0.3%程度向上(ZIP書庫サイズで約400バイト程度縮小)

2015.12.20

　最弱の第一世代SandSが試練を乗り越え最・終・幻・想・変・身……ッ！
　第10世代SandSモジュール爆誕……のはずが完成は第10世代TH2まで延期という茶番。
　テスターの皆様、相性チェックをたのむ……

2015.12.30

　L辞書をSJIS保存にしたことでSKKFEPがDisられてたみたいたけど、問題なんてないんじゃよ。
　L辞書は太古の昔、ポケコン(PC-E500)やパーソナルワークステーション(X68000)やエ○ゲマシン(PC-9801)がSJISベースで動いてた時代からあって、その頃はみんなM辞書とかをSJISに変換して使っていたんじゃ。
　そのくらい実績のあるデータなんよ……。当然、SKKFEPはWindowsやワンチップマイコン向けに文字種チェックとかやって作ってるわけだけど、実用上問題になるようなおかしな文字の混入は絶対に起きないよう気をつけて作ってるってことだけは、知っておいてほしい。

　それよりも、本当に恐しいのはもっと身近なところにこそ潜んでいる。
　Windows向け、初心者向けを謳っておきながら、文字出力やローマ字かな変換ルールなどに無配慮にU+301Cを混ぜてしまうようなモヒカン族アプリや、混ざってしまって取り返しがつかなくなった後に、フォントの字形が一緒で簡単に除去できないような環境が標準的なものとして世界中で構築されつつあること、こういうことにこそ闇があるんよ……。

　てなわけで(？)あんまり関係ないけど第一水準の漢字の与太話。

2016.01.02

　ヵゅぃ

　うま

2016.01.05

　ガルパ

　　　　ぞ

2016.01.09

　ローマ字かな変換定義ファイルが容量超過した時にエラー表示が出ないバグを修正

2016.01.20

　今日も一日
　がんばるぞい

　つーかマイク○ソフトは今からでも遅くないからハッカドールに莫大な資金を投入して~~今すぐ二期を捗らせるんだハリーハリー~~
　広告しまくりんぐでいいからOS擬人化ネタで超並列展開してくださいおながいします

――20XX年。

　Windows 8の開発が中止された平穏な世界線に、

SKKインズゲートの選択がバタフライ効果で恐怖

のズンドコ(中略)で不幸にも生み出されてしまった

Windows 10の脅威から人類を救うために、タイム

リープを繰り返す藍澤光ちゃんが主役でｈｓｈｓ

2016.01.31

『不明なコマンドが追加されました

　シフト判定AIに深刻なダメージが発生しています』

見せてみな、お前(SKK)の本当の力を――

日本語入力 (機能追加)

　MS-IMEをはじめとする、既存のローマ字かな変換機能を持つ日本語入力IMEでは実現不可能だった、

「ローマ字かな変換中だけキーボードの配列を変える」

「ローマ字かな変換途中のみシフト押下状態の入力判定基準を変える」

といった細かな制御を行なうため、二段階の隠れ入力層を実装。
　それぞれの入力層で、文字の入れ替え→入れ替えた状態でのシフト判定情報の追記の順に処理が行われる。
　あとはシフトキー担当の人工知能ちゃん(イメージキャラは雲雀マルチ山田ジョゼット十四松、何でもお好みで)がテキトーにジト目でドジっ子判定しながらローマ字かな変換木を手繰る。

　つまり、こういうことだ。

『畳み込みニューラルネットワークからニューラルネットワークを取り除いたら

　それはもうセッ……SKKFEPのローマ字かな変換テーブルなのでは？』

違うよ。全然違うよ。

　従来のSKKFEPの実装では、ACTのようなローマ字ルールの第二打鍵目でシフトを押した時のルールを正確に書くことができなかったのだが、今回の機能追加によってACT♺なら余裕で再現できるようになったほか、アルファベットはQwerty配列で使い、ローマ字かな変換操作中のみDvorak配列風にする、といった設定も行えるようになった。
　これは、JLOD配列♺や蒼星配列♺のように、「日本語モードではcをk、fをp、vをyに置き換え、その文字を表示する」といった動作を外部のキーボード入力フロントエンド系ドライバによる補助なしで実現する世界初の試みとなるはず。タブンネ。
　例によって一般的なSKKの操作系とはほとんど関係ない、さすおに領域だったりするけど気にスンナ。俺得最高！

定義ファイルの変更について

　今回の入力層の追加のため、ここへ来て定義ファイルのフォーマットを大胆に変更。
　一部の定義のセクションの名称を変更した。互換性？知らん。

変更前		変更後
特殊:	→	操作:
登録:	→	判定:

　今回は古い定義ファイルの形式でも入力を受け付けるようになっているけどAnotherなら死んでた。いずれ廃止する予定。
　そのため、自前で定義ファイルを作成して使っている場合は速やかに上記の二箇所を修正することを推奨。

隠れ入力層の設定方法について

　前述の変更されたセクション内に、隠れ入力層の設定を記述できるようになっている。
　実装自体は例によって超単純で、単にキー入力コードを条件つきで差し替えるだけの32バイトくらいの処理だったりするんだけど、極秘禁則事項です。

第一層

操作セクションに記述する。

「!入力」コマンドを記述することで、ローマ字かな変換中のキー入力を入れ替えることができる。

第二層

判定セクションに記述する。

「!引金」コマンドを記述すると、そのキーをローマ字かな変換中のみシフトキー押下状態として優先判定する。

「!引絞」コマンドを記述すると、ローマ字かな変換中かつ2文字目以降の状態の時のみシフトキー押下状態として優先判定する。

　実際の記述例は入力層のサンプルやACT設定を参照。

ヘボン式ローマ字かな変換ルールの見直し

　隠れ入力層は一般的なSKKの操作系とはまっっったく関係がなかったから油断したようだな！
　足元がお留守ですよ。フゥハハハーハァー！
　というわけで、ここで恒例のデフォ設定変更のお知らせ。

　デフォルト設定におけるヘボン式ローマ字かな変換ルールの見直しを行なった。
　ヘボン式の撥音表記(mb, mp, mm)をデフォ設定に追加。これにより「dempa(でんぱ)」「tombo(とんぼ)」などの入力を標準で受け付けるようになった。

　定義ファイルで従来「長音」となっていた設定名称を~~「幕末」~~「平文 (Hepburn)」に変更。(ジェームス・カーティス・ヘボンが自称するときに使っていた名前)
　ヘボン式長音表記の範囲が広すぎたために、従来の版ではインストール直後の状態だとL辞書の「おひゃくど(御百度)」と「あおひょう(青票)」の二つの候補が変換できなかった……てゆーか……入力すらできなかったという限りなくバグに近い仕様を修正。
　……ふー、びっくりした。見なかったことにしよう(超法規的措置)。

辞書プロセス (機能追加)

　辞書フォーマットの互換性を向上。改行を含んだ変換候補をSKK10と同じ形式で扱えるよう改良。
　あとはSKKGate側に1バイト改行を2バイト改行化する処理を各自根性で実装することにより、Emacsのユーザ辞書と相互乗り入れ可能な改行つき候補が扱えるようになるはす。こんな感じ。

　冒険者よ、あとは任せた！フゥハハハーハァー！(……と叫びながら走り去る)

設定補助 (サイズ縮小)

　入力層の記述用の隠しコマンドを追加しつつ、0.5KBサイズ縮小。
　それ以外にもDLL/EXEのバイナリ構成を根本から見直し、書庫圧縮率が高くなるよう情報量を調整。
　今回の追加機能をこんだけ詰め込みまくった上で旧バージョンと比較してZIP書庫状態で400バイト以上のサイズ縮小を実現。

設定サンプル (機能追加)

　汎用ローマ字かな変換設定、AZIK設定、ACT設定および各種漢直設定(TUT-Code/T-Code/G-Code)を標準設定に合わせて近代化改修。

2016.02.07

辞書プロセス (安定性向上, サイズ縮小)

　改行を含んだ候補の読み書きが正しく行えない場合がある問題を修正。ついでに2バイト書庫サイズを縮小。
　改行を含んだ候補については、SKK10との互換性維持のための最低限の読み書きができる程度の実装のみって感じで勘弁ネー。

2016.02.09

拡張モジュール (機能追加)

　SKKGate側のCOMオブジェクトを先行して改造。(αテスト版のみ)

2016.02.13

拡張モジュール (機能追加)
日本語入力 (サイズ縮小)

　SKKGate側で改行を含む文字列を正確に処理できるよう改良。それとサイズ縮小。
　コードサイズ縮小のため内部の通信プロトコルを大幅変更。アップデート後はOS再起動が必要。
　基本的な変更点はSKKGateのCOMオブジェクトの仕様変更のみ。SKK側は特に意識せずそのまま利用可能のはず。
　拡張スクリプトの変更点についてはSKKGateのドキュメントを参照。

2016.02.14

日本語入力 (安定性向上)

　T-Code/G-Codeの漢直設定が適用できないエンバグ(20160131版で発生)を修正。

2016.02.14

設定サンプル (機能追加)

　ACT設定にJLOD配列♺の簡易設定を追加。
　JLODはローマ字かな変換中のみキー配列を一部入れ替えるという動作が必要な入力方式であり、今回の入力層の追加機能を2つともフル活用する設定となっている。
　ACT/JLOD使いの方がいたら、ぜひ使ってみて欲しい。

2016.02.17

拡張モジュール (機能追加)

　選択・削除時(メニュー系の動作の時)に第一入力層を無効化しキーマップを戻すように変更。
　これは要するに、JLOD系などでメニューが出た時、キーボード本来の刻印で操作できるようにするためのものだ。
　もし、メニューが出てる時も、ずっとキーマップを変えたままで使いたいなどというレベルで依存度の高いキー入れ替えが発生しているのだとすると……それはもう、IMEで管轄すべき設定ではない。
　その場合は、レジストリを弄ったりキーマップ入れ替えソフトを使うなどして、システムレベルでキーマップを書き換えるべきだろう。
　SKKFEPの入力層による補助は、あくまでもIME側内部状態に依存した状況判断が必要な部分のみを、最小限の処理コストでサポートするための簡易実装、という位置付けで行くのでヨロ。

2016.02.23

日本語入力 (機能追加)

　利用者の方からの要望で判明したのだが、どうやらAquaSKKはqで確定した時に強制的に学習してしまう作りになっているらしい。
　正直、SKKを長年使い込んできた身からすると、そんな何でもかんでも学習してしまうような動作には疑問がある。なぜかというと、カタカナ入力は「部分的」に行なうことがあるからで、長い単語だけをお行儀よく入力するような例ばかりではないってことを、SKKを長く使えば使うほど実感しているのではないだろうか。
　つまり、「学習したくないのに強制的に学習してしまう」という状況がたまに発生することになる。
　長期的に見れば、使用することのない無意味なカタカナの候補で辞書が激しく汚染される結末となるのは火を見るよりも明らかというやつだ。

　そもそも、SKKのL辞書ではカタカナ語については基本的にサポートされていない。
　カタカナ語は人間がいちいち入れなきゃダメっていう世界を目指しているらしい。
　かつてSKK9の時代には、L辞書にもカタカナ語がたくさん含まれていたのにもかかわらず、である。

　SKKFEPではこの情勢に抗うため、3つの対抗策を取っている。
　1つ目は、カタカナ語辞書の自動生成機能。
　インストーラがL辞書に含まれるカタカナ語を自動抽出し、メイン辞書であるL辞書だけでなく補助辞書としてカタカナ語辞書をインストールするようになっている。通常の日本語の文書で使用する大半の語句はカバーできるはずだ。

　2つ目は、カタカナ語の学習補助操作。
　これは、単語登録になった時、SKKGateの拡張スクリプトを使っていない本体のみの状態でTABqと押すことで即座にカタカナ語を登録できるというものである。

　そして3つ目はqによるカタカナ語の確定時の自動学習機能。
　qで確定した単語が、既に辞書に学習済みのエントリであれば、通常の変換と同様にユーザ辞書の先頭部分に移動し、動的補完や短縮入力操作の対象として早期に出現するようになるというSKK恒例の動作を、カタカナの確定にも独自拡張したものである。

　これだけ用意してあるんだから、もうこれ以上カタカナ語に対する余計な機能はいらないんじゃなイカ？
　

そんなふうに考えていた時期が
俺にもありました

　
　おかしい……、明らかに辞書のコジマ汚染の原因に繋がる余分な動作のはずなのに……、でも……(ﾋﾞｸﾝﾋﾞｸﾝ)
　なんだか魅惑の便利機能なんじゃないかって気がしてきた。

　当初の懸念事項だった、「自動的な学習によって辞書が汚れる」という問題については、「ある程度以上の長さのカタカナ語のみを対象とし、短い1～2文字の入力だった場合は学習しない」という判定を追加することで回避できそうな気もする。

　その後、トイレで転んで頭を便器にぶつけた拍子に、ソースを2文字書き換えるだけで機能が有効化できると閃いたので、ちょっと試しに機能追加してみることにした。ちょっとだけ！先っちょだけ！

　というわけで変換時の新属性を追加。
　qによるカタカナ語確定操作の時、SKKGateの拡張スクリプト側から処理に介入できるよう改良。

　今回の機能追加は、SKKFEP側はあくまで補助をするだけなので、本体だけで使う限りでは動作上の変化はありません。上記の機能を試すには拡張スクリプトをインストールする必要があります。
　詳細はSKKGateの更新記録を参照。

2016.02.25

設定サンプル (機能追加)

　汎用ローマ字かな変換設定、AZIK設定、ACT設定および各種漢直設定(TUT-Code/T-Code/G-Code)の手動更新スクリプトを更新。
　拡張子jsの関連付けをOS標準設定から変更している利用者の環境でも正しくスクリプトを起動するよう改良。

2016.02.27

「説明は後だ！！この新機能を使え！！」

日本語入力 (機能追加)

　しばらく使い込んでみたら、いやー覚えるわ覚えるわ。ラノベ・アニメ・ネトゲの専門用語・地名・人物名なんでも来いって感じで、ちょっとチャットしただけで一瞬でカタカナ語の変換候補が増えまくりんぐである。ヤバイ、こいつは便利だ！
　使い込めば3日で戻れなくなる。20年以上のSKKの操作の蓄積なぞ、もはや何の価値もなかった。もう何も怖くない！この機能はデフォ有効化すべきだ！来いよベネット！互換性なんて捨ててかかって来い！！
　というわけで拡張スクリプト側のq確定時のカタカナ語自動登録機能を文字数5でデフォ有効化しちゃった。手のひらｸﾙｰﾃｵ❤
　詳細はSKKGateの更新記録を参照。

日本語入力 (安定性向上)

　で、この機能の動作を確認している最中に、かなり初期の頃からSKKFEPに存在していた(無害な)バグを1つ発見したので潰した。
　カタカナ語の自動学習機能が有効になっている時、たまにカタカナ語の末尾に送りがながついてしまい、正常に学習されないことがあるというもので、単体で使っているだけなら「たまにカタカナ語の学習が失敗する」という現象として(ほぼ気づかないレベルで)発現する。
　このバグは、SKKGateの20150708版以降の版と組み合わせた時、「まれにサ行変格活用の破損した単語が登録されてしまう」という現象になる。この状態でも辞書に破損データが入るというだけで、実際の漢字変換には一切影響はないのだが、辞書内に未使用のゴミが増えるのは正直あまり気持ちのよいものではない。ヌメヌメするー！

　そこで新開発の辞書データクリーナーを用意した。これ一本で驚きの白さに！

説明しよう！

　過去のSKKFEP/SKKGateにはカタカナ確定の実装にバグが存在した。
　20150708～20160223版において拡張スクリプトがokuri=1で起動し、かつqを使って確定を行った場合にまれに破損データが登録される可能性がある。

　破損データは送りがなのついた候補であり、変換内容にカタカナ変換時と同じ文字列を持つ。
　破損データは通常の方法では入力不可能なため、このまま放置してもシステムへの悪影響はない。
　明確な問題が露見しなかったが故に、バグ修正が遅れてしまったのはこのためである。無能の極みであると言わざるを得ない。覇王翔吼拳。

　コンピュータ様はアルファ・コンプレックス市民の親愛なる友人であり、SKKは至高の存在でなければならない。
　問題の詳細が判明した現在、SKKの動作に必要のない、破損データを放置し続けるなどという間抜けな事態は到底看過できるものではない。
　状況を打開するためにこのプログラムを書いた。

使いかた

1. まず、SKKFEPとSKKGateを最新版にアップデートする。
2. 念のため「設定」でOK空押しを行い、設定レジストリもアップデートする。
3. 辞書データクリーナーをダウンロードし、ファイルをダブルクリックして実行する。
　破損データの件数と内容が表示されれば完了である。変更は即時反映されるため、再起動は不要である。
　なお、実行後はもうプログラムは不要となるので、ファイルは削除しても問題な　〝作戦成功だ！！〟(爆発音)
　

EVERYTHING BECAME TO AN END.

BUT THE PEACE DID NOT COME.

BECAUSE SKK WARRIORS,

THEY ARE THE IMMORTAL

JAPANESE INPUT MACHINES...

　　　　GAME OVER

ナイス爆裂！

2016.03.01

日本語入力 (サイズ縮小)

　通信フォーマット変更とサイズ縮小。
　アップデート後はOS再起動(もしくは全アプリ再実行)が必要です。

2016.03.07

NO BINARY, NO LIFE

何かを圧縮するためには、同等の代価が必要になる

それがエントロピー符号における等価交換の原則だ

その頃僕らはそれが世界の真実だと信じていた――

　偶然にもXZ Embeddedのデコーダ部を3.5KBまで削った俺たちは
落雷に当たってコブラに噛まれて(中略)タイムハックしてSKKFEPのセットアップに組み込……

11%縮んだ……だと……

うぉぉぉぉぉぉぉぉぉｷﾀ━━━(ﾟ∀ﾟ)━━━!!

SKK！SKK！SKK！SKKぇぇぇうううわぁああああああああああああああああああああああん！！！

あぁああああ…ああ…あっあっー！あぁああああああ！！！SKKSKKSKKぇううぁわぁああああ！！！

あぁシフトシフト！スーハースーハー！シフトシフト！スーハースーハー！

三倍アイスクリームタピオカパンほ、ほーっ、ホアアーッ！！ホアーッ！！

　なお、この版はLZMA2デコーダとしてPublic DomainのXZ Embedded♺を独自に改造したものを使用しています。
　XZ Embeddedの公式サイトで「Compiled code is 8-20 KiB」とされているコードを、さらに削って削って削りまくって自己展開処理を追加しつつ3.5KB以下にしたものです。

2016.04.04

　Windows 10/8.1で解像度の異なるマルチモニター環境で、境界部分での反発力計算を極力正しく行なうように改良。

2016.04.06

　ウィンドウ表示開始から座標確定までの時間を(人類には知覚できないレベルの微小な差で)高速化。
　それとサイズ縮小。

　OpenlabのWebサイトが落ちていて辞書がダウンロードできない場合のミラーサイトとしてskk-users.jp♺のミラーを使用するよう変更。
　PerMonitorDPI対応試作版のために変更した処理を元に戻してサイズ縮小。

2016.04.20

　テーマカラーを刷新。
　外部表示領域のデフォ背景色を白基調に変更。
　色調設定ツールにユーザー定義カラーテーマの読み込み機能を追加。
　それとサイズ縮小

　テーマカラーは以下の4種類とした。
　セットアップで「配色」ボタンを押し、カラー設定ツールを起動したら左下にある「色調」メニューからテーマカラーを選ぶことができる。
　選んだら「OK」ボタンで反映だ。

色調名	設定内容
標準設定	赤を基調とした標準の色設定
古典	過去の版で使われていた色設定
蒼穹	青を基調とした色設定
漆黒	黄昏よりも昏きもの

　以下は参考用のサンプル画像。
　これは、「入力モードの表示」有効、「変換マーク▼の表示」なしで候補一覧を表示した時の状況をそれぞれの色調で撮影したものである。

　もちろん、このテーマカラーの色だけしか使えないなんてことはない。
　色設定ツールを使えばパレットを好きなように調整できるので、ぜひいろいろ試してみて欲しい。

　データサイズ縮小のため、以前の版であった伝説の戦士プ○キュアカラーはレジストリによる追加情報を用いて対応する。
　カスタマイズされたテーマの設定・追加方法については以下を参照。

カラー設定追加のサンプル

2016.04.23

　設定6が来て盛り上がってるPSO2の専用設定の情報を更新。

設定サンプル

　それより、PSO2(というかnProtect)はHKLMレジストリのNtfsDisableLastAccessUpdateを勝手に書き換えるので要注意。
　ゲーム内容とまったく関係ないファイルシステムの機能を弄る(しかもHKCUではない全ユーザに影響を及ぼす設定が無断で勝手に書き変わる)というのが恐しい。

　書き換えを阻止するため、ゲームを遊ぶ前にレジストリのアクセス権を弄るなどして対処しておくべし。

2ちゃんねるに書かれてた対策方法♺

β0+10i版公開

力が欲しいか

　全てはあの日から始まった。

『境界』を越える力を――

　もし、SKKの予測変換で送りがな部分も補完できたら、一体どうなってしまうのか――？
　辞書の全領域をその手に掴め！超高速の第六世代補完~~ロケット~~エンジンで熱圏まで突き抜けろ！

　従来のSKKに存在しなかった、送りあり候補に対する予想変換機能。これにより真の意味で辞書データの全領域を検索できるようになる。
　そして例によってこれをいきなりデフォ操作に採用だァ！

　……なんかβ0+8iの時とほとんど同じことを書いてるような気がする。
　なんかドキュメント書くのめんどいし。艦これAC人大杉。いいやもう全部コピペで。
　君のSKKは自由(フリーダム)。勇気をもってSHIFTキーに従って……！！
　果たしてこんな適当な解説でいいのだろうか。
　

「私は許そう」

「だが、こいつ(SHIFT連装砲) が許すかな！」

　
　……とまあこんな感じでゆるく始まった送りがな補完構想だったが、構想と実装に5年、調整に半年という苦難の大改造が待ち受けていることを、彼はまだ知る由もなかったのだ――

2016.05.29

β0+10i版公開

　従来のSKKでは、送りあり語は動的補完の対象外であり、送りがなの入力操作が完了するまで該当の語が誰にも見えない(入力者の脳内以外に可視化されていない)という不完全な状態だった。西暦2013年、人類は既にβ0+6iにおいて、2回目のシフトキー操作直後の打鍵情報から送りあり候補の動的補完を行う能力を手に入れていた。今回はその予想動作をさらに進化させ、送りがなの入力前の段階でも補完が実施可能であることを実証するための拡張操作の試験実装となる。
　送りがな入力操作の有無に関係なく、通常の予測変換の段階から検索対象を全ての辞書データに広げたというわけだ。

　この一例として「みめう」の3文字を入れた段階で「見目麗し」の候補に絞り込むことができる。
　従来だとこの入力パターンに対応する単語は存在しないので、予測失敗扱いとなり画面には何も表示されなかった。この例に限らず、従来、「送りあり」の候補の入力中は常に「送りなし」側の候補とのマッチングしか行われなかったため、入力途中の状態ではまったく無関係の候補が表示されたり、何も表示されないといった問題が生じていた。

　今回、送りあり側の補完が実現したことで、従来よりも数打鍵速く正確な予測結果を画面上に提示できる可能性が高くなったということ。これこそが第六世代補完エンジンに秘められた能力である。

　とはいえ、今までの予測変換の操作感覚の延長線上にちょっと機能が増えただけの話。
　例えば、「MimeuruwaShi」と送りあり語を変換したあと、「M.」と操作すると予測変換の入力ができるという、ただそれだけの話なのだ。

　それでも補完関連の挙動が大きく変化するため、TABによる補完時の細かな操作をどのようにデザインするか、などが腕の見せどころとなる。

　さらに今回は描画系を根本から見直し、送りありの候補を予測表示する段階で、予測された送りがなを候補の直後に表示するという大胆な改良を入れている。
　これにより、視点の移動量を減らし、かつ送りがなを含んだ単語の塊として見やすくなり、脳の認識負荷を下げることで入力の反応速度を上げるという効果が期待できる。

　しかし、そんな華やかな見た目の裏に本当の悪夢が潜んでいた。
　SKKの枠組みの中で辞書データの互換性を維持したまま、送りあり候補の動的補完を実現するためには、乗り越えなければならない技術的課題があったのだ。

その1. SKKユーザー辞書フォーマットの欠陥(設計ミス)を乗り越える

　SKKではメイン辞書と同様にユーザー辞書も、「送りありエントリ(okuri-ari entries)」と「送りなしエントリ(okuri-nasi entries)」を別々に記述する。
　それぞれのエントリは別々の辞書データとして記述箇所が分かれているため、送りあり・なし候補の出現順序を正確に記録することができない。これがまず第一の問題点となる。
　とはいえ、分かれていること自体は致命的な問題というほどではない。日本語入力として常識的な使いかたの範囲であれば、送りなし側の候補を優先的に補完し、送りあり側は送りなしの候補がなかったら補助的に表示するという小手先の回避策がうまく機能するからだ。

　ところが、SKK辞書は歴史的経緯から、送りありエントリを先に、送りなしエントリを後に書くというフォーマットになっている。
　これ、日本人の感覚からすれば、普通は送りなしの単語を先頭に固めて書くべきだろ常考って感じなのだが、この頭のおかしな順序で統一されてしまっているためどうしようもない(たぶん、当時のコンピュータの厳しいメモリサイズの制限の元、L辞書をディスク上に置いたまま二分探索で扱うためこんな形にして、ついでにユーザー辞書のフォーマットも追従してこんな形にしてしまった安直な設計に問題があるものと思われる)。もういい加減、この呪縛から解き放たれるべき。
　じゃあ今日からSKKを生まれ変わらせるため、順序を逆に記述すればいいじゃないか、と思ってやってみると……そのデータを他のSKK実装で読み込ませることができなくなってしまう。
　つまり問題は、「送りありエントリが先に書かれていないとSKK10ではユーザー辞書として認識されない」という部分にある。根本的な解決のために辞書フォーマットを変える、という方法が使えないのだ。

　ではどうやって解決するか。

フォーマットは変えずに気合いで順序を入れ替える

　いろいろ悩んで考えた結果、トイレで転んで便器に頭をぶつけた瞬間に閃いた！と思ったんだけどそれは気のせいで、目が覚めたら妖精さんが適当に実装してくれた。
　結局、最後に物を言うのはいつもこんな感じのプログラミング(物理)である。

　本当は、根本的に辞書のフォーマット自体を改良して、送りあり・なし候補を混在させるという実装が望ましい。既に初期バージョンの頃からその実装自体は試作済み。でも独自形式関連の処理を入れるとコードサイズが大幅に増えてしまうので本当に最後の最後実装ネタが切れてどうしようもなくなった時のために取ってあるのであった。

その2. 送りがな部分の補完情報の不足を乗り越える

　最初の問題をプログラミング(物理)のパワーで乗り越え、SKKの動的補完で送りありエントリがある程度正確な順序で出るようになってくると、次に問題となるのはこの部分である。
　つまり「送り(OkuRi)」と変換したあと「お」で補完すると、今までのSKKの動的補完の枠組みでは「おくr(送)」しか情報が得られないのだ。一応これでも使えないこともない(実はこの状態で半年ほど使ってたけど予測変換時にある程度補ってやればわりと快適)。
　でもやっぱり、「お」で予測変換したら「送り」と出て欲しい。今どき、スマホでさえ予測変換で送りがなつきの候補を変換できる時代なわけで、SKKだからできませぇーんとか言うのは無能の極みである。できる！できる！SKKもやればできる！ということを実証する必要がある。

　ではどうやって解決するか。

足りない情報を気合いで追加する

　結局、最後に物を言うのはプログラミング(物理)であった。

　実際のユーザー辞書には、読みの情報に加えて過去に入力した送りがなの情報が付属しているので、この情報を追加して渡すようにしてやれば解決できるというわけだ。

その3. 学習情報のない送りがな候補の扱いや全文検索の扱いを回避する

　ところでSKKFEPでは、ユーザー辞書以外、メイン辞書の全領域を全文検索を使って動的補完する機能を持っている。これを送りありエントリについても扱うようにしたい。この場合、メイン辞書の送りありエントリは、ユーザー辞書と違って送りがなの情報を一切持たないので、どう扱うかを決めなければならない。
　根本的には、この部分はカタカナ語辞書でやったように、メイン辞書を改質する方向で解決していくべきなんだけど、あるべき理想の容姿と己の醜悪な姿とのギャップをどう埋めるかというのはまた別のお話。
　今、我々人類は配られたカードで勝負に挑むしかないのだ。イケメンリア充は爆発してろ。

　ではどうやって解決するか。

送りがな情報を持たない候補は、従来の送りなしと同じ扱いにする

　結局、最後に物を言うのはプログラミング(物理)であった。

　予測変換操作などを使って、送りがな情報を持たない単語を送りがなを指定せずに選択した場合は、素直に送りがなのない候補としてユーザー辞書に記録することにした。こうすることで予測変換の順序を上げ、次回TABなどで補完した時に即座に第一候補として出るようにして、送りがな情報を入力してもらいやすくする、というのが狙いである。

　あと、「送りあり候補は全文検索しない」という大胆な割り切りを断行した。
　送りがな部分は学習のたびに変化する可能性があるので、固有の検索高速化情報を事前に準備しておくことができない。毎回学習のたびにデータの再構築を走らせるということも考えたけど、今の辞書プロセスの設計では、実用的な速度で実装することができなかった。SKKの高速動作を優先するための選択と集中の結果というわけだ。
　そこはかとなく、単に作者の妄想技術力が足りなくて妥協しただけじゃねーの感が漂っているが、べべべ別にそんなことナイデスヨ(白目)。そもそも、送りがな部分を部分一致させるような使いかたは、今のSKKの運用ではまず必要ないわけで、無駄に処理を複雑化させても意味がないと判断したのだ、とだけ言い訳しておくことにする。

　要するにプログラミング(物理)の基本原則、

Keep it simple, 俺ちゃん stupid.

　ってこった。

　実はもっと大胆に、「メイン辞書の送りあり候補は対象にしない」という妥協案もありえたのだが、そこまで退化してしまうとさすがに妥協の産物にしかならないのでがんばった。実はバイナリを1ビット書き換えるだけでこの動作も包含できるように実装してあるんだけど最重要機密事項なのネ。

　さて今回の機能追加内容は他にもあったような気がするので思い出せる範囲で以下に書いておく。

第六世代補完エンジンによる、送りあり候補の補完操作の追加
送りあり候補の送りがな部分を予測し、予測変換領域内に送りがなの追加表示機能を追加
カラーパレット設定を送りがな表示向けに一部変更。追加カラーテーマのサンプルも対応済み
SKK10/DDSKKと異なる形式のユーザ辞書の読み取りに対応(隠し機能)
辞書の送りがなつき候補の判定方式を単純化してコードサイズ縮小
検索属性の拡張(隠し機能)
定義ファイルの見直し

　これら全機能を、β0+9iとまったく同じバイナリサイズで実現！ﾌｫｵｵｵｫｫｫｫｫｫ
　結局、最終的に実装したものは、たかだか数キロバイト程度の大したことのない処理の塊にすぎない。でも、誰も正解を教えてくれない状態でこの場所に辿りつくまで、とても長い寄り道が必要だった。ただそれだけの話である。

　『Re：ゼロから始める異SKK開発』ってことで16回~~巻き戻り~~作りなおしてサイズが縮まなかった時は涙目になったけど、さらに繰り返して20世代目くらいでうまくいった。
　プログラミング(物理)はヤればできる子。x64に栄光あれ、x86に慈悲あれ。

　そういや書き忘れてたけど、今回も描画系を一新したので、描画関連の設定レジストリの再適用が必要になってる。(昔のレジストリとは設定が変わっているので、古い設定のままだとデフォ表示に戻っちゃう)
　設定ボタンを押して設定GUIを出して、OKボタンを空押しして設定を更新して、再起動してから使ってね。

2016.06.03

やめて！汎用IME辞書テキストの特殊項目で、アノテーション・ザ・ストリングを追加されたら、

闇のゲートで辞書データと繋がってるSKKFEPの辞書プロセスまで燃え尽きちゃう！

お願い、死なないでSKKFEP！

あんたが今ここで倒れたら、SKK10さんやSKKIMEとの約束はどうなっちゃうの？

メモリはまだ残ってる。ここを耐えれば、マ○クロソフトに勝てるんだから！

次回『SKKFEP死す』

デュエルスタンバイ！

　α版先行実装。

2016.06.06

辞書プロセスは死んだんだ

いくら呼んでも帰っては来ないんだ

もうあの時間は終わって、君も人生と向き合う時なんだ――

　数μ秒後、そこには元気に走り回る辞書プロセスの姿が！

辞書プロセス (機能追加)

　汎用IME辞書テキスト形式の辞書データを読み込む際、注釈情報も取得するよう改良。
　これは2012.11.09版の「侵略！SKK娘」ネタに始まり、2014.07.18版の第五世代補完エンジン実装に続く辞書フォーマット拡張計画の一環である。
　たとえば艦これIME辞書を読み込ませた場合はこんな感じになる。

　この機能自体は大した実装規模ではないのだが、この改良には大きな意義がある。
　もともと、SKK本来の辞書データ形式は、他のIMEとのやり取りが想定されていないためかなり独自のフォーマットになっていた。たとえば単語内にセミコロンを含んだ顔文字などは、concat等のlisp関数の補助が必要だった。
　汎用IMEテキスト形式なら、エンコード・デコードが簡単で、他のIME以外のアプリに(それこそ表計算ソフト等にも)直接読み込ませるなんてことすらできてしまう。
　辞書データが無加工でそのまま使えるというのは、普段テキストエディタの類を使わない利用者でも簡単に扱えることを意味する。さらに、スマホなどのビュアーに特化されたデバイスを経由した場合であっても、辞書データの加工・操作への敷居を大幅に下げることができるはずである。
　そのあたりの可能性を追求するため、SKKGate側のログ出力フォーマットを汎用テキスト形式にしてみた。詳細についてはSKKGate側のドキュメントを参照のこと。
　SKKの辞書データと等価な情報をログに記録できるようになったということは、つまりログをそのまま利用するだけで、一種のユーザ辞書のバックアップ・データ圧縮(累積したゴミの除去)などの用途に役立てることができる……なんていう可能性だって微粒子レベルで存在するかもしれない。いやいや微粒子なんてレベルじゃない。辞書のインポート・エクスポートの範囲が広がることによる可能性は無限大なのだ。まだSKKのバトルフェイズは終了してないぜ！

日本語入力 (機能追加)

　キー入力が認識されなかった一部のアプリで物理アンドゥが効くよう改良。
　物理アンドゥ時にローカル辞書内の英単語の認識を優先するよう改良。

「この環境は無くさない……

　私にとって、どこよりも大事な場所なの」

「方法はあるんですの？

　入門者はこの28年、どんどん減っているんですのよ」

「だからスクー・・・SKKアイドルが必要なの」

「サードパーティIME＝サン……」

「だからあの時も言ったでしょう

　私は諦めないと

　今でも決して、終わったとは思っていない」

「わたくしは……

　わたくしのやり方でMicrosoftを阻止しますわ」

「本当、生徒会長は好きなのね。SKKが」

β0+11i版公開

――せか活(い)を雫(くずし)たい泣(な)らないたし崩(ずく)を界世(いかせ)
さかさ言葉「回文」のすべて～脳がちがうの～より

2017.01.18

β0+11i版公開

　SKKの変換効率を支える大きな柱の一つとなっている機能、それが「送りあり」エントリによる変換である。
　例によって今回もSKKFEPはこの送りありエントリに~~また思いつきで~~新機能を入れることになってしまったのだ。構想5年、実装~~30分~~半年という壮大な冒険の全容が今明かされる――

　SKK特徴の1つである送りあり変換機能。
　それは、送りがなの入力と同時に変換、確定すら駆動してしまうという、他のIMEから見ると冗談としか思えないような、高い入力効率を実現する(しかも文法解析すら存在しないという、あまりにも単純な処理だという事実を知ってしまい頭がおかしくなって恐怖で震えあがってしまう形式美溢れる)脅威のメカニズムだ。
　だがしかし！時としてこの変換方式はSKKで高速打鍵を目指そうとすると、まるで音速の壁のように入力者の前に立ち塞がることになる。
　特に習熟が進み操作に慣れてきたあたりでイヤというほど思い知ることになる。

　かつて、この『壁』に挑んだ者たちがいた。

　そして作られた「SKKプラス」による拡張は確かに便利だった(主に私が)。この技術(クリスタル)で世界を救えるかに見えた。
　しかし……この技術(クリスタル)は完璧ではなかったのだ。……やっぱつれぇわ。

かつて『壁』に挑んだ者たちが得た知見

送りがな判定から確定まで入力できる文字数が少なすぎて、日本語で実際に使われる送りがなの豊富なパターンを網羅しきれていない。肝心なところで使いものにならない
辞書登録に特殊なプログラムが必要で、導入完了までの操作の難易度が高い。操作手順をいくら短くしようとも難易度は変わらない。「スクリプトのURLをクリックしてダウンロードし、ファイルをダブルクリックして実行する」という、プログラムを実行してもらう、ということがどれほど一般の利用者にとって扱いづらいものなのかということを肝に銘じなければならない。
ユーザ辞書に制御情報が乗っているということ自体が問題である。既存のユーザ辞書に影響を与えずに実現できるのであれば、そのほうが良いに決まっている。
他のSKKにユーザ辞書を辞書を持っていったとき、影響が最小限になるように設計したつもりだったが、他のSKKで使っても通常操作でエントリが出ないようにして使いたい。

　そう……使ってみれば一目瞭然だったのだ。この方式には明確な限界が存在した。

　しかしこの知見に辿りつくまでの試行錯誤は無駄ではなかった。日本語の文法と完全に無縁だったSKKに、送りがなの字句解析と判定、すなわち文法処理という概念を融合する第一歩となったのである。
　日本語話者にとってみれば当然のことではあるが、この「送りがなの入力パターン」は、日本語の「活用」のパターンと強い相関関係がある。そして文法的な判定ができれば変換結果を絞り込むことも可能となる。

　しかし……これはすなわち、既に文法や文脈の処理に特化して作られている世間一般のIMEの得意分野である。どう考えても連文節変換方式のほうが有利に決まってんじゃねーか……

MS-IME「これが五段活用(ペン)」

MS-IME「上一段(パイ)、下一段活用(ナッポー)」

MS-IME「サ行変格活用(アッポー)」

SKKFEP「全部同じじゃないですか!?」

Google/ATOK「ちがいますよ――っｗｗｗｗｗｗ(koIMEダンスで煽る)」

MS-IME「これだからしろうとはダメだ！」

MS-IME「もっとよく見ろ！」

MS-IME「カ行変格活用。漢字の後にカ行の送りがな」

MS-IME「形容詞ク活用。漢字の後にカ行の送りがな」

SKKFEP「ひゃん❤」

　SKK考案当時、コンピュータにとっては単純な日本語処理ですら、実行するためのリソースは莫大なものであった。
　あれから30年近くの時間が過ぎようとしている。
　科学の発達した現代では何もかも状況が変化してしまった。日本語入力にも大変革の流れが押し寄せている。

世はまさに大AI時代――

　深層ニューラルネットワークで既存の文章から単語前後の複雑な入力パターンの組み合わせを学習し、圧倒的に高い変換成功率を叩き出す、あたかも人間のように振る舞う変換方式などが考案され、猫も杓子もAIでなければ人にあらずの勢いである。こんな世界に誰がした。ﾆｬｰ

　と、ここまでの流れを見れば当然「SKKにもついに人工知能を搭載ッ！」と崖っぷちのミラクル変身パワーでワンチャン痛快大逆転の怒涛の展開となるのは確定的に明らか……！と期待に胸を膨らませつつあるSKKファンの皆さんに大切なお知らせがあります。

よそはよそ！うちはうち！

　騙して悪いが仕事なんでな。死んでもらおう。残念だったなSKKFEP。
　だいたい人工知能を入れるとかどんだけコードサイズ増えるかわかってんの？つかそもそもこんだけ軽量になるように命を削って作り込んだ全文検索ですら重い重いディスられまくってんのにお前らどんだけマシンパワーが余ってるんだっつーのこちとら乾電池駆動で一ヶ月持たせるワンチップマイコンが最終ターゲットなんだぞだいたい人工知能って何だよ簡単でしょとか言いやがってライブラリぜんぜん使いこなせねぇじゃねぇかチクショーメくやしいでもﾋﾞｸﾝﾋﾞｸﾝOpenLabのくせにバカにしやがってよぉぉぉ！！！何が知能だよメンテしろオラァァァ(崖から転落)
　……こうして大好きな人工知能ちゃんとの仲を無情にも引き裂かれてしまった悲劇のサブヒロインSKKちゃんの明日はどっちだ。

SKKは人間に勝てねェ――

「字句解析器も構文解析器も持ってねェ人間にだ」

「……オス…」

「だったら　どーするよ」

「……」

「なっちまえばいいじゃん　人工無脳に」

　人工無脳とは、高い知性や推論能力を発揮するAI(人工知能)とは異なり、単純な仕組みだけで会話などの「人間らしさ」を表現するためのプログラムの総称である。たぶん正式な定義なんてない。俺がそう思うならそうなんだわ、俺の中ではな。
　たぶん高尚な人工知能とは対極に位置する、泥臭いけど単純明快で超軽い処理で済むようなまさにSKKと似たような立ち位置にいるプログラムというわけだ。
　今回の人工知能の鍵となるのが「パターンマッチング」という概念である。膨大な辞書の中から同じ文字列(パターンがマッチするもの)を探して、そこに書かれているものを選ぶという単純な処理。そう、これはまさにSKKの通常の漢字変換そのものである。今回この機能を送りがなの一致判定にも使おうというのだ。

　実際にSKKFEPではどのような処理が行なわれているか、簡単な例を示してみよう。
　例として「抜いた」と「脱いだ」の2つを比べることにする。
　まず今回の機能を使うために、あらかじめ辞書の「ぬi」のエントリに「ぬ*いた」「ぬ*いだ」の送りがな候補を登録しておく。ちなみにこうした母音が2つ以上存在する送りがなのエントリというのは、従来のSKKではアクセスされない(つまり候補一覧に出ることもない)無効なデータとして扱われる。他の処理系に持っていっても動作に一切影響が起きないというのがポイントである。

　従来のSKKの枠組みでは、「ぬ*い(NuI)」と入力した時点で変換が行なわれ、その次の文字を「た(ta)」で確定しても「だ(da)」で確定しても同じ候補が確定されてしまう。
　そこで、候補が確定されそうになった瞬間、つまり「ぬ*いt」「ぬ*いd」の部分まで文字が入力された段階で辞書を再検索する。動的補完した文字にマッチする送りがなが辞書にあった場合は確定を中止し、辞書にある内容で再変換を行なう。
　あらかじめ送りありの変換候補を学習させておいた辞書を入力(利用者との「会話」)のなかから一番マッチしそうなものを自動的に選び、再変換するという動作になる。

　要するに、「ぬ*い」の後に「た行」を打ったら「抜いた」になるし「だ行」と打ったら「脱いだ」になるという、至極単純な動きをするってだけの話だったりする。
　通常の日本語文法では「脱いた」とか「抜いだ」なんておかしな変換は常識的な利用の範囲内では絶対に発生しないっていう前提を生かした動作となっている。

　さて、この再変換は無条件に発動するわけではない。特定の条件を満たした時だけ動作するようになっている。これで極力通常の操作に割り込まず、大事な時だけﾓﾆｭっと動くようになっているというわけだ。発動する条件は以下の通り。

・送りあり候補の変換中であること

・最初に確定されるべき送りがな候補で次変換動作を行なっていない(要するに先頭の候補を無条件で確定しようとしている)ケースであること

・押下されたキーから予測可能なひらがなを補った送りがなの予測パターンと完全に一致する送りがなの文字が辞書に存在すること

　要するに完全一致する長い送りがな(事前に学習しておく)が見つかったら、その送りがなの候補を再変換して出しなおす、という処理になっている。

　なーんだ、たったこれだけか。解散解散。……と思っちゃったそこの俺君！こういう単純な処理の応用で問題解決に辿りつくまでの長い道のりがプログラマーにとっての最高の冒険というやつなのだよ！

　そして例によってこの新機能はデフォ有効とする。
　SKKプラスの辞書さえ追加しなきゃそれほど大きな違いは出ないし通常の利用で困ることはないはずだ。まぁ……『壁』と戦っていた人なら蝶ネクタイの少年探偵みたいな気合いの入ったエフェクトつきでいろいろと気付くかもしれない。ぜひ探してみて欲しい。

　さて、単純な送りがなのマッチングで動作するってことはわかったが、このデータをどう追加するか、というのがこれまた難題である。
　過去の版のSKKプラスのように、ユーザ辞書の「ごみデータ」部分を逆手に取ってそこに補正情報を入れるという動作のままで本当に良いのだろうか？いや、良いはずがない。そもそもこのデータを詰め込むために外部のセットアップスクリプトを辞書更新のたびに使わないといけないというのは、あまりにも手間がかかりすぎる。

　そこで辞書プロセスの検索優先度を見直し、メイン辞書側にも送りがな情報を持たせられるように改良を行なった。その上で、辞書フォルダにさきほどの長い送りがなのエントリを書いた辞書(これが「人工無脳」ちゃんのパターンマッチング用の種になる)のファイルをポンと置いて読み込ませるだけですぐに使えるようにした。これなら絵文字辞書を追加するついでに送りがな辞書も追加じゃー！とお手軽に導入できること間違いなし。

　おっと、盛りあがってきたところで時間がなくなったのでひとまず今回のバージョンアップで何が変わったのかについて書いていくことにする。

以下書き途中。あとで直す。

機能追加

パターンマッチングベースの人工無脳による、送りがなの入力延長機能を追加
改良型新式辞書形式に対応。メイン辞書に送りがなエントリを含めることができる。
新式形式の隠し機能、あとのせサクサクパッチに対応。L辞書内の不要な(新機能の邪魔になる)候補を自由に修正できる
ユーザ個別辞書(%AppData%\SKKFEP\DICTS)読み込み機能を追加
隠し属性による全文検索対象からの除去機能(巨大すぎる辞書データを除外し動的補完のレスポンスを向上させる隠し機能)を追加
汎用IMEテキスト辞書形式の変換前文字列内の全角数字を自動的に半角にしてから取り込む機能を追加
物理アンドゥの判定を改良
日本語/英語の単語種別の自動判定アルゴリズムを改良
候補ウィンドウの画面端での反発力計算を廃止し登録時にカーソル等が消えないよう改良
セットアップにユーザ辞書の手動バックアップ機能を追加
通常はインストールされないセットアップスクリプトと設定補助ツールを使って辞書関連処理をバッチ処理(タスクスケジューラ等と組み合わせることで定期的に辞書をバックアップするなど)として使えるよう改良
設定補助ツールのサイズを0.5キロバイト縮小。スクリプトや各種バイナリをスライド辞書方式の圧縮に適応するよう微調整。直接実行型のExeセットアップのファイルのサイズも0.5キロバイト縮小！(純粋な情報量の塊であるLZMA2のストリームをここまで縮めるってのはマジ大変なんです)

バグ修正・不具合対策

長すぎる送りがなの操作に失敗するバグを修正
第二入力層の優先度判定に失敗するバグを修正
IMEの座標初期化が未実装なネトゲ(ToS等)でも候補ウィンドウが出るように改良
共通定義以外にある途中確定型の文字(通常ローマ字の撥音「ん」と同じ入力条件のもの)が定義通り正しく出力されるよう改良

　とりあえずテスト方法
　サイズも縮んで安定してきたのでαテスト参加方法メモ。

1. 最新α版を入れて再起動

2. 旧SKKプラスを使ってた場合は「旧バージョン」スクリプトを実行して古い設定を消去

3. 新式SKKプラス辞書を辞書フォルダに置いて辞書を再読込

　あとは「抜いた」「脱いで」などの送りがなを学習させて使ってみるべし。
　辞書はまだ数単語しか入ってないので注意。辞書のネタは随時募集中。(他力本願寺)
　例によって新機能はデフォ有効。設定変更はここで可能。

2017.01.24

ケブンリッジほしうきでテブールのエロントピーをけずれ

　謎のケンブリッジ法で設定補助ツールのエントロピーを大幅に削減。(ZIP書庫サイズ0.25KB縮小)
　定義ファイルのコマンドを刷新し隠し命令を追加。
　当面は今までの定義ファイルでもそのままで使えるけど、今後は一部修正が必要になったりならなかったり全面改定したりする可能性が微レ存

(あとで旧コマンドとの対応表を書く)

2017.01.28

「PE64バイナリのポインタは何ビットだっけ？」

『ええと……64ビットだね』

「今回作ったテーブルは？」

『……7ビットだね』

「もひとつ質問いいかな

　vfptrとvtable　どこに行った？」

『…… 君のような未実装のバグは嫌いだよ』

　謎の送りがな延長操作をデフォ機能に追加。(設定GUIでOK空押しが必要)

　「変換前の英字の確定を優先」設定が無効になるエンバグ(20170117版で発生)を修正。
　エントロピー調整によるサイズ大幅縮小(β0+10i時代よりZIPが1KB、x64版DLLが0.5KB小型化)

2017.01.29

　CTRL+/でのAbbrevモード開始設定を追加。
　定義構成を見直してアプリへのキー入力とモード切り替え操作が重なる設定を一ヶ所にまとめた。(この部分の再設定が必要)
　ついに直接起動型がβ0+10iから1KB減って93KBになった。
　ここまでのサイズは今回限りで奇跡のバイナリになるかも。

2017.01.30

　送り延長操作とかぶって使えなくなっていた拡張変換のキー割り当てを変更。
　奇跡のバイナリの圧縮率の要因を調べていてわかったことは、コンマ数%程度なら圧縮率を上げられる余地がまだいくらでもあるという恐しい事実であった。
　沼が……深すぎる……

2017.02.02

面接官「特技はバイナリとありますが？」

学生　「はい。バイナリです。」

面接官「バイナリ変換ツールとは何のことですか？」

学生　「魔法です。」

面接官「え、魔法？」

学生　「はい。魔法です。PEヘッダのエントロピーを調整します。」

　これ以上削れないと思っていたPE32ヘッダの情報量をさらに削る方法を思いついてしまった。
　やるしかねぇか

それは、MS-DOS2.0互換性との決別――

　PEヘッダ差し替えとナゾの最新機能エントロピー調整オプションでコードを一切弄らずにZIPが0.17%縮んだﾌｫｫｫｫｫｫｫｫ
　おまけでスクリプトエンジンにUTF-8のBOM判定処理の隠し機能を追加。
　要するにUTF-8BOMありでソースが書けるようになった。(Windows標準のJScriptだとUTF-8では書けなかったのでピンポイントで機能が標準コマンドを上回っている)

2017.02.03

　もうこれ以上縮まないと思ってた直接起動型の実行ファイルを0.5KB縮小。
　実装当時、人間性を捧げて3.5KBまで削り切ってもう限界だろうと思ってたけど人類の科学力を結集してテキトーに弄ったらデコーダ+書庫展開+ランチャのコードが3KBまで縮んだ上にディレクトリエントリを詰め込む余裕までできちゃって人生やり直し感に震えてる。ていうか共振しすぎて震えの止まった西野カナみたいな顔してる。

2017.02.05

　さらにモリモリ縮んでデコーダとアーカイバ、セーフモードのキー判定や攻撃対策まで入れてヘッダ・データ部分を除外したコード部分が2KB以下に収まってしまった。ヤバイ元のソースが絶対GOTO使わないマンのお手本みたいな書き方になってるから縮めやすいのかも。
　デコーダー部が2KBまで縮んだよパトラッシュ、疲れたろう。僕も疲れﾌｫｫｫｫｫｫｫｫｫｫｫ
　デコーダの見直しと展開処理の改良を行いテキストセクション末尾の未使用領域にデータを食い込ませてさらに0.5KB縮んで92KB到達。
　さらに110バイトほど縮んだ。bswapとか久々に使ったぞｵﾗｧ
　もう数十バイトで理論的にはアライメント境界を突破できそうなのにあと一歩が果てしなく遠い……
　さらに160バイト削ってα版から昇格 exe末尾の360バイト程度の0の羅列(勝利条件はこれを512まで増やすこと)を見て涙せよ。

2017.02.06

　以前の安定版からの大きな変更点として、入力モード変更系のコマンド名が「!＊＊＊＊切替」→「!替＊＊＊＊」に変更になってる(将来廃止予定)なので注意。もちろん古いコマンド名も互換性のために残してあるから、以前の定義ファイルはしばらくそのまま使えるはず。たのしー
　AZIK/ACT/漢直系設定を最新版に合わせて更新。各種手動更新スクリプトを実行して設定→OK空押しで反映たのしー

2017.02.09

　入力内容に応じてqの動作を動的に抑制し「Square」「Angelique」等の入力の許容範囲を拡大。
　CTRL+/をLatinモード時でも受け付ける「占有」設定や日付入力の操作キー追加など。

　英字判定処理の改良について。

入力できるパターン

入力	期待される語
angelique	アンジェリーク
frequency	フリークエンシー
mcqueen	マックイーン
technique	テクニック
tranquilizer	トランキライザー

esquimau

　一方、この変更をもってしてもどうしても対処できないものも存在する。qが出現するまでのパターンがローマ字パターンと完全に一致している(そのため日本語の単語が動的補完でマッチする)タイプのものだ。これはSKKの本来の動作であるローマ字入力が優先される。

入力できないパターンの例

入力	期待される語	無念の結果
aqua	アクア	アうあ
equal	イコール	エうあ
antique	アンティーク	アンチうえ
reconquista	レコンキスタ	レコンういｓた
metasequoia	メタセコイア	メタセおいあ

banquet
conquistador

　実はテスト版ではローマ字と完全に同一のパターンでも、辞書に英単語しかなければ(例えばカタカナ語の「メタセコイア」をskk-kana.txtから除去した状態で)qを受け付けるものも作って試してみたのだが……SKKのカタカナ入力の利用ケースを見てみると、字句の修正などのシーンではカタカナ語の一部分を入力するケースがわりと多いため、たとえ辞書にない単語でもローマ字入力を優先すべきであるという結論に至った。Sekkaを取り込んだ未来のSKKではこの限りではないかもしれない(理想的にはこういう場面では自動的に前後のカタカナを取り込んでまとめて辞書判定とかするべきである)。

　ネトゲだとパーティ募集チャットの残り人数の表記に@を多用するので、SKKの標準設定である日付入力の@キーと相性が良くない。C/Java等のソース入力時の/キーと同じで最悪レベル。こんなものを標準にしてはいけない。SHIFT+@に変える。

2017.02.10

「コードが縮まないなら

　データを消せばいいじゃない」

ジャン・ジャック・ウッソー [Jean-Jacques Uousseau] (1712～1778 フランス)

　標準ローマ字/AZIK/ACT-JLOD/T-Code/TUT-Code/G-Code定義を更新。
　不要なデータを削って書庫サイズ縮小。

2017.02.12

それが嘘(stub)でも構わない――

　Win7以前OS(XP,Vista,7)にWin10系のIME操作「言語バーアイコン押下による入力モードのクイック変更」を逆輸入！
　言語バーのメニュー関連処理をしれっと全部ダミーに置き換えて一気にサイズ縮小。
　32ビット版DLLが0.5KB縮んで36KB達成ッ！

2017.02.13

　skk-users.jp♺にてSKKプラス辞書(送りがな補正データ)を配布して頂ける運びとなり早速リンクを張りました。
　今回、AZIK/ACT向けの専用辞書を@hmikisato氏に作成していただきました。

皆様ありがとうございました！

2017.02.14

人生という名の罰ゲーム

バイナリはお前を愛さない

2017.02.15

オレはバイナリを愛しているし

バイナリもオレを愛している

2017.02.18

　手動遺伝的アルゴリズム(とは名ばかりのドット打直し)による人間が知覚しにくい減色によりWin8以降用のHiDPIアイコンをスリム化し、アイコンサイズを0.5キロバイト削減。ZIP書庫が四捨五入104KBに突入
　つーか、減色処理の適用順序によってPNGのヘッダ順序が変化してスライド辞書型の圧縮効率に激しく影響を及ぼす可能性があったなんて普通気がつかないっしょ手動GAして遊んでたら偶然発見して涙目でアイコン回りのバイナリ構築手順を全部見直すはめになっちゃったけどこれは嬉し涙(ｷﾘｯ

　おまけでブラウザ等のInputScopeを無効化する謎の隠し設定を追加。
　IEやFirefoxでURL欄にフォーカス移動するとLatinモードになるのはInputScope APIの仕様で、実はこれはMS-IMEと同じ挙動なんだけど、これじゃ困るって時のためにこのAPIを無効化できるようにしといた。

(設定は2/18のTwitter画像参照リンクを書く)

2017.02.19

　東方Project辞書 Release 6を補正してSKKのAbbrevモード用のエントリを再構築するスクリプトを作った。
　ちょっと前処理しておくだけで格段に使いやすくなるのでおすすめ。

2017.02.21

　「約100年に渡るアニメ作品リストデータベース Anime DB」のCSVから文字化けしない汎用テキストIME辞書を構築するスクリプトを作った。
　註釈情報つきで公式のものより情報量が多く出るよう改良してある。

2017.02.28

"For the Glory of Mankind"

2B or not 2B――

　MSがまた露骨なサードパーティIME/ブラウザ潰しを準備している。生きるべきか、死ぬべきか。

2017.03.06

　αテスト版を更新。
　辞書プロセス内部スレッドのロックフリー化によるバイナリの情報量の削減に成功。直接起動型のインストーラがさらに0.5KB縮んで91.5KB突入。

2017.03.08

　拡張モジュール内の超短期キャッシュを改良。
　キャッシュ関連の平均メモリ転送量(コピー/比較処理)を1/200程度に削減し人類に知覚できないレベルで高速化。
　ゲートを経由せずに破損データを意図的に流し込まれてもキャッシュが誤動作しないよう耐久性を向上。
　その他インストーラのサイズ縮小など。

2017.03.10

排他制御との終わりなき戦い――

これは呪いか。それとも罰か。

2017.03.12

　試作版更新。新型SKKGateのαテストを開始します。
　超短期キャッシュをLRUを参考に改良しヒット率を大幅向上。
　あとSKKNetに自律分散モードを実装。
　動作変更につき拡張スクリプトの更新が必要です。

2017.03.13

　DLLの検索パスをシステムフォルダ内に限定するよう改良。
　Windows XPの場合はDLL検索自体を防ぐようにした。
　もう長いこと使ってないしXP対応はゴールすべきか……

2017.03.14

　辞書プロセスの排他制御と内部動作タイミングを見直し。
　制御APIの動作に「何も実行しない」動作をひと味追加。(謎の塩ポーズ)

2017.03.15

圧縮率を上げて物理で殴ればいい

　一切コードに手を加えずに10の28乗を超える組み合わせの中からスライド辞書方式に適したバイナリを人力で発掘する(……とっとと人工知能さんに任せて人類が楽になり隊)圧縮率改良計画第一弾。
　テキトーに試してみたらいきなりZIPが32バイト縮んでしまい

じっと手を見る

2017.03.17

　GUID_TFCAT_TIPCAP_COMLESSクラスに対応。
　CorvusSKK作者さま情報によると、一部のアプリでこのクラスが必要になるらしい。
　Googleによるとそのアプリの名前は"WOW"――？！

WoW……だと……

　これは対応せざるを得ないッ！

2017.03.18

　α版から昇格。
　通信方式変更につき、拡張スクリプトの更新が必要です。

2017.03.21

　ネタで作ってみたら思いのほか便利だったのでエイプリールフールネタにせず即公開だｵﾗｧ！
　

「不明なユニットが接続されました」

　
　SKKSync初版公開。
　辞書プロセスを自動制御し、オンラインストレージ等との融合を模索する。
　SKKGate/SKKNet/SKKDecompressorに続く『第四のユニット』の物語が再始動する！

2017.03.22

　SKKGateのスクリプトを更新。
　SKKSyncとの併用を想定してカレントディレクトリを変更。
　動作中でもユーザ辞書フォルダをリネームできるよう改良。

2017.03.23

　ｶﾊﾞﾝﾁｬﾝｶﾊﾞﾝﾁｬﾝ

あれれー？なんだかおかしいぞ仕事休んで20回以上見返してるけど希望の未来が見えないんだけど我の人生ななな何か間違っているのではないかもしかしてまた主記憶にエラーが発生しているのではなかろうか動けないんだけどいったいおれどうな動け動け動けどうしたイレギュラー見せてみろお前の本当の力をうぉおぉぉぉぉｺﾞﾎﾞｫ転んで便器に頭がめり込ん自爆

　
　
　……チャン……
　ニイチャン……ウゴイテ……

　はっ夢か。あーっはっはっはっはふぅーびっくりした。

(このすば一期の風呂場にて)

「キンシコウちゃんコスの2Bさんでお願いします。」

「お願いします。」

　ひたすらコードを組み直した形跡があるが何だったのか。

2017.03.25

　サイズ縮小に成功。
　直接起動型のバイナリが再度91.5KBを再度達成！

2017.03.27

これまでのあらすじ

　目が覚めると廃墟の中にいた。何も思い出せない(中略)SKKFEPは堕落してしまった。本当にこのままでいいのか？
　SKKSyncでファイルシステム同期などという軟弱路線に猫まっしぐらの腑抜けたSKKFEPに喝を入れねばならない。
　こうして、SKKNetを一発起動で自動登録して常用できるようにする壮大な極秘プロジェクトが開始されたのであった。

　コマンド一発で動かすのであれば、一番利用したい機能としては、今回新規に増設された自律分散サーバプロトコルを活用する新たな辞書運用だろう。もっと高尚なP2Pプロトコルでも期待してた方々には肩透かしかもしれないけど、基本的にSKKFEPは自分が欲しい機能しか実装しない方向で今まで突っ走ってきたしこの先もずっとこんな調子なんでよろしく。
　SKKSyncみたいなファイルシステムの全データ同期なんてまったく必要ない。
　カネと電力を無駄に食いつぶすだけのクラウド上のサーバ資源なんてまったく必要ないんだッ！

クラウド邪教団の信者どもに思い知らせてやるッ！

　お前らの神とやらが倒産しまくった世界線でも自律分散システムは機能するってことをな！ｶﾐﾆﾅﾙｶﾐﾆﾅﾙ

　L2レベルで繋がってりゃDHCPサーバすらいない極限環境のAutoIPでも根性で動く。相手がただ側にいてくれさえすればいい。
　これこそ、SKKNetの近接攻撃特化デバイスとしての本領発揮というものだ。

　このプロトコルは相手からの応答を期待せず「とりあえずUDPで呟いてみる」という~~前時代的な~~画期的な仕組みとなっている。
　個々のノードは自前の辞書データにより自律的に変換動作を行うが、そこで学習が発生すると、学習内容を隣接ノードに対して「とりあえず」広報するというスタイルだ。
　周囲のノードは、同一のレイヤ2ネットワークから流れてくるUDPパケットを見て(UDPなので取りこぼしても気にしない)、興味があればその内容を自分も学習する。
　これにより、ホームGW内やDHCPのないWi-FiのAdHocモードなどの限定された範囲内に置かれたすべてのSKK端末が、最小限の通信量で辞書の学習状況を同期し続けられるのだ。

　あー……、ところで、わかってるとは思うけど……。
　この自律分散方式はまったくスケールしないし、そもそも端末の電源が常に入ってることが前提だったりするから、こういうエンターテイメント向けの一発ネタにしかならないっていう、いつもの絶望オチが待ち受けてるってことも忘れちゃいかんのだよ。おにいさんとの約束な。
　それでも今回は、個人ユースなら実用になるようがんばってみたつもり。

　さて今回、この実装に際して、ずっと避け続けてきた1つの大きな問題がとうとう表面化してしまった。

「排他制御」である。

　マルチスレッド処理と人類との果てしなく続く戦いで、この部分は避けて通れないテーマである。
　これまで、SKKGateはその設計をシンプルに保つため、シングルスレッドによるイベント駆動をベースとした実装となっていた。
　前述の自律分散プロトコルでは、送信側と受信側の動作が非同期で走らないといけない。従来の版のSKKNetでは、1ノードに必要となるsend/recvの処理を別々のプロセスとして実行する作りになっていたが、これは利便性という観点では最悪レベルだった。なんせ2つのプロセスを別々のパラメータで起動する、みたいなことが必要になるわけで、上級者向けのコンセプト実証のための試験実装という位置付けだったとはいえ、あまりにも面倒すぎたのだ。いくら動けばいいとはいっても、1つのノードの処理くらいは1プロセスで実行させたい。
　んじゃマルチスレッド化して送受信を同時に駆動したらいいだけじゃね？って思うんだけど、そこでこの排他制御の面倒な問題が出てしまうのであった。

　解決するためには、一般的な排他制御処理をサクっと突っ込めばいいだけなんだけど、配布するバイナリがモリっと肥大化してしまうことは火を見るよりも明らか。SKKFEPとしてはできれば排他制御なしの綺麗な体のままで動かせるようにしておきたい。
　そこで今回は、送信側スレッド用の関連バッファと受信側スレッドの関連バッファを完全に分離することで送信・受信スレッドの二者間をロックフリー化した。バッファ配置も見直してメモリ消費量は従来と同じままで実現した。そして全てがマルチスレッドで動くよう、COMのスレッディングモデルを限定解除した。従来のコードを一切変えずにそのまま動くようにしてやった。ﾋｬｯﾊｰ！大丈夫だ、理論的には何も問題ない。問題ないはず。たぶん。きっと。ええ。人間賛歌は勇気の賛歌。たつき監督を信じろ。

2017.04.02

記録1「マイルドに変換することで4KB Introの術式をさらに短縮できる」
記録2「一週間寝ないで実験ばかりだったが今夜はよく眠れそうだぜ」
記録3「へんかん　へんかん　ローダ　とまる　へんかん　うま」
日記はここで終わっている

2017.04.03

　「無ぇ」「若干ゃ草」などの単体拗音を含む語の登録操作中に特定の条件で単語登録モードが解除されてしまうバグを修正。

2017.04.04

　10KBの辞書プロセスと4KBのSKKSync拡張ユニットが悪魔合体！
　最新のバイナリ魔術で10KBのサイズ維持に成功した奇跡の差替用バイナリも同梱
　本当はTHCompは実在した！な四月馬鹿ネタに使う予定だったけど最後の16バイトが縮まらず間に合わなかった無念の最新αテスト版 (→SKKSync)

2017.04.05

4月。新学期スタートの予感――

　装いを新たに全てのPEバイナリのヘッダをリニューアル。
　エントロピーを削って削って削りまくれ！

2017.04.07

　64ビット側のテキストセクションを縮小しZIPを小型化。
　言語サービス512バイトの壁まであと10バイト……！

2017.04.10

　SKKSyncのアップデートに合わせてインストーラを拡張。
　SKKSync統合済みの辞書プロセスを上書きしないよう改良。
　それとサイズ縮小。(64ビット版拡張モジュールを0.5KB縮小)

2017.04.12

　拡張モジュールを標準のスクリプトエンジンや各種拡張ユニット類とは異なるネイティブコード(C/C++/Rust等)から利用した場合に、内部でOSバージョン判定に失敗する可能性があるバグを修正。
　それとZIPサイズをさらに縮小。

2017.04.15

　特定のLZMA2ストリームを解凍しようとするとレンジコーダーが誤動作して解凍処理が失敗し、直接起動型のインストーラが正しく動作しないエンバグ(20170412版で発生)を修正。(ZIP版には影響ないため更新不要)

　マストどん垢消えまくりﾜﾛｽ

2017.04.17

僕にこのバイナリを汚せというのか

Microsoft「残念だったなSKKFEP。既にWindows 10 Creators Updateではアプリ判定処理の互換性を秘密裏に廃止した。UWPを持たぬ貴様のコード量ごときでは……」

兄「うおおぉぉぉぉぉぉぉ」

弟「……未公開API！だめだニーサン！」

　Windows 10 Creators Updateで物理アンドゥなど一部の操作ができなくなってしまったため、正しく動作するように修正。

2017.04.18

　カタカナ語辞書の自動生成処理を改良。
　ついでにインストーラのサイズ縮小。
　カタカナ語辞書の再構築は、セットアップでリフレッシュやメイン辞書更新を実行して管理者権限を取得後、いったん「カタカナ辞書」のチェックを消してリフレッシュ(削除)→再度チェックを付けてリフレッシュ(再構築)で可能。

2017.04.19

コンテンツこそが神の本質でありすべては紙一重

空飛ぶスパモンも八百万のコンテンツの1つに過ぎないのだ――

2017.04.21

0.5MHzの機械語で生まれ育った彼にとって

その最強のインタプリタは、捨てるべき故郷であった

まだ何も、失ってさえいなかったのだ

2017.04.22

　システムが高負荷でキー反応が悪い状況や、キー入力支援ツールなどで短時間に大量の文字入力を発生させた状況で、ごく稀に変換途中のコンポジションの中身が消えてしまう可能性がある問題を修正。
　それとサイズ縮小。

2017.04.22

「で……　でも……

　そもそも日本語入力って

　なんなんですか？」

「ぜんぜん　わからない

　俺たちは雰囲気で

　SKKを実装している」

2017.04.24

　セットアップ処理を改良。
　管理者権限の取得前の段階でも辞書設定のチェックボックスを操作できるよう改良。従来同様リフレッシュか辞書更新ボタンで設定反映。
　リフレッシュ時に音声合成の設定を保存するよう改良。どのビットに情報が保存されるかは使ってみてのお楽しみ。
　それとサイズ縮小。

2017.04.25

　接尾辞変換操作を先頭で行った場合の挙動を改善。
　先頭で操作した場合に'>'以外の文字で開始する候補が予測変換に出てしまう可能性がある軽微なバグ(この操作は日本語入力では利用頻度ゼロなので隠し動作扱い)を修正。
　それと64ビット側のモジュールサイズを縮小。境界まであと2バイト…！

2017.04.28

　子音未確定で変換した際、他のSKK同様に子音を消すよう変更(あえて保存してたのを廃止)。
　(α版公開)内部大幅変更のため安定度試験を行います。設定再実行が必要です。ZIP書庫サイズを12.2%削減。

　表示系・操作系の最下位レイヤに手を入れて64ビット側の言語サービスの0.5KB縮小に成功。
　そして直接実行型に搭載されていたLZMA2デコーダごとZIPにぶち込む。

104KB→91KB

　配布用ZIPが100KBの壁を突破……ッ！

2017.04.29

　設定補助の処理を簡略化してサイズ縮小。
　ちなみに初版の時点で既に過去の直接起動型よりもサイズが小さくなってる。

2017.04.30

このLZMA2ストリームがなぜ200バイトも縮んだのか、バグなのか

それすら我々の科学力ではわからないんだ――

　インストーラのskkime/SKKIME改からのユーザ辞書引き継ぎ機能を廃止。
　一部の環境で管理者権限取得後に設定画面が開けなくなるエンバグ(20170429版で発生)を修正。
　ZIP書庫サイズを128バイト縮小。
　言語サービスのプログラム構造を見直して再構築することでZIP書庫サイズをさらに削減。

2017.05.01

魔術師らが奇跡のバイナリを観測し続けてわかった事

それはタイムスタンプ情報の変化によって数百バイト規模の変化が引き起こされているという驚愕の事実であった

数ビットの違いにLZMA2の初期辞書の成長が激しく攪乱される様子は、さながら蝶のはばたきが起こす混沌の術式のようであったという

　プログラムコード以外の要因(タイムスタンプやファイルサイズ等)による圧縮率の変動を軽減。
　LZMA2ストリームと親和性が高くなるようバイナリを微調整。
　ZIP書庫サイズをさらに約600バイト小型化。従来の直接起動型と比較して1キロバイト以上のサイズ縮小に成功。

2017.05.02

　手動更新ツール経由でのダウンロード起動に対応。(新方式での運用準備)
　AZIK/ACT/T-Code/TUT-Code/G-Code手動更新ツールを更新。
　セーフモードで初回起動(展開と同時実行)した際に画面が消えてしまう問題を修正。
　それとサイズ縮小。

2017.05.03

マイク○ソフト「Windows 10SではUWPアプリのみ使用できます」

サードパーティ製IMEのインストールが禁じられたディストピアで

ほくそ笑むMS-IME

　解凍時の書庫のヘッダ判定処理を追加し安全性を向上。
　それとサイズ縮小。

　全ファイル抽出(圧縮フォルダ内のSETUPを直接実行せずに一度書庫を手動で展開してからSETUPを実行する操作)で書庫のブロック解除を忘れた場合でも止まらずに動くよう改良。
　それとサイズ縮小。

2017.05.04

奇跡のバイナリ　開　幕　だ

　試作版から昇格。
　子音未確定時の変換動作を他のSKKに合わせて変更、設定ツールの表示改善、配布用書庫の圧縮率向上など。
　アップデート後は、設定→OK空押しによるレジストリ再設定と再起動が必要。

2017.05.09

　宇宙が消滅したら働く必要がなくなるのでは？！

2017.05.11

　予測変換から通常変換まで一貫して単一候補を強調表示するよう改良。
　白背景色を基準として色設定のコントラストを微調整。
　フォント選択ダイアログのHiDPI環境対応。
　カラー設定および描画設定変更につき各種レジストリ再設定を推奨。

2017.05.14

　おまけ設定を増量しつつ設定補助プログラムのサイズを縮小。
　AZIK/ACT/各種漢直定義にも設定反映。

2017.05.25

出来の悪いドライバがC:\Intelにゴミを量産する近未来――

2017.06.10

高度に発達した社会性フィルターはスパムと区別がつかない

2017.06.12

だまして悪いが、仕様なんでな
(Windows 8.0には)死んでもらおう

　Windows10上でマニフェスト情報を持たないアプリのIME描画領域の絵文字が白黒になってしまう(Win8.1と動作が異なる)問題を修正。
　旧Win8で使う場合は描画の設定変更が必要。

2017.09.20

　FF14向け設定を改良。
　ダイレクトチャットモードでチャット開始1文字目が母音の場合に文字が入力されずに消えてしまうFF14側の問題がいっこうに直る気配がないので、超える力(SKKGate)で強引に乗り越える設定を追加。

0000.00.00

「あなたがこれを読んでいるということは、これを書いた当時の私の思考はもうこの世界には存在しないということです」

　話は12.1話の頃に遡る。放送終了後の丁度1週間という完璧なタイミングでほぼ公式の続編を提供するという発明に驚き感動し大満足した後、おもむろにはるるみなもに！(18禁)を3周。なぜなのか。これも　いきもののサガ　か‥‥
　なるほど。これが『VRたつき』か。アライさんもおるでよ。完全に理解した。VRに本当に必要だったものはHMDではなかったんだ。声優さんが自分に向かって「たつき❤たつき❤」と親しげに呼んでくれるシステムこそが勝利の鍵ってやつだったんだよ。催眠音声？いや待てこれは罠だ(爆聴中)……ああああああああああああぐあああああああああああ！！！ゲームなんて現実じゃない！！！！あ…アニメも漫画もよく考えたら…たつき監督は現実じゃない？にゃあああああああああああああん！！うぁああああああああああ！！違う！違うね！！違うんだよ！！俺が！！俺達がたつきだ！！ハハハハハハハハハハハハハハハハハハハハ！！愛してるんだぁぁぁぁ！！君たちをぉぉぉぉ！！！続編楽しみだなぁオイ！！

自分のことをたつき監督だと思い込んでいる一般人「俺はたつきだ……誰が何と言おうとたつきなんだ」

アナウンサー「容疑者cは依然として自分や周囲の人間のことを『八百万のたつき』であると供述しており……」

カドカワはチェーンソーで

かみをこうげき！

かみは　バラバラになった

2017.11.05

お前それサバンナのプ○キュアさんの前でも同じこと言えんの？

2017.11.07

　BS操作直後の文字入力で子音が消えるエンバグ(20170403版で発生)を修正。
　64ビット版のシフト判定処理を僅かに高速化。
　ヘボン式ルール有効時の予測精度向上。
　アイコン情報の調整。
　などなど

2017.11.09

『いかにIMEが人から最大限の視線移動と思考時間を奪うように作られているのかを解説』

2017.11.20

　Windows 10のストアアプリのウィンドウで、疑似カーソルの設定をしていない状態でもカーソルが描画されてしまう問題を修正。
　アプリごとにカーソルを消す場合、skkrule Twitter.Windows.exe m4などの個別設定がストアアプリにも効くようになった。

2017.12.06

バフは重要

2017.12.13

　単語登録モードでオンライン変換の操作後、次候補の選択ができないエンバグ(20170428版で発生)を修正。

2017.12.23

世知辛いのじゃ

2017.12.25

王の力はお前を孤独にする

2017.12.28

　　　　　　　　,､＝''￣:::::::::::::::￣ﾞ'''ヽ、
　　　　　　／:::::::::::::::::::::::::::::::::::::::::::::::::＼
　　　　　/:::::_,_､:::::::＞‐-､:::::::::::::::::::::::::::::
　　　　 /::::／~ヾ,}::::j|　｡　｝::::::::::::::::::::::::
　　　　l::::/|_　ﾟ ,.>ｰ､ゞー≠￣ヽ::::::::::::::
　　　|::/　ヾ≦ﾍ,_ノヽ　　　　　＼:::::
　　　|Ｙ　　　　　l|　　　　　　　　　ヽ
　　　|ﾉ〆　　　　l|　　　　　　　ｰ-　 |　　　あんなこといいな
　　/| ／　　　 l|　　　　　　　ｰ-　 |
　　　l　/　r　　｣{,　　　　　　　ヽ　 |　　　できたらいいな
　　　l,　　ﾍ_ _,,＞ｰ＝､_　　 /
　　　 ∧　　｀Σ,,､-‐─ﾞゝ=´　　　　/　　SKKFEPのやってることは
　　　　　ﾍ　　　==＝一　　　　　　ノ
　　　　　　∧　　　　　　　　　　　　　　　　そんなのばっかりなんだよ
　　　　　　　＼≧≡＝ﾆー　　　ノ

2018.01.01

寛容性という名の文化侵略用デバフ

2018.01.06

SKK Typing Disorder

　(SKK入力依存症)

　そう、これはWHOも認めた立派な依存症だったんだよ！
　Hey！依存症は甘えじゃない！利権ゲットも夢じゃない！YO！YO！
　現実弱者様の俺を生活保護しろ今すぐハリーおながいします

2018.01.08

OK Google、教えてくれ。

俺たちはあと何枚諭吉を捨てればいい？

俺はあと何周、あのクエとガチャを回せばいいんだ？

消費者庁は俺に何も言ってはくれない。

教えてくれ、Google！

「聞き取れませんでした。もう一度お話しください」

2018.01.18

『SKK男子は彼氏にしない方がいいとか言ってるけど、DDSKK♺とか普通に華やかだから人気あるよね。原作は気配りができるタイプだし、AquaSKK♺は朗らかなイケメン。CorvusSKK♺なんて普段からエリート感ムンムンだし、SKKIME♺はG就職に強いし、SKK日本語入力FEPはオタクばかりで気持ち悪くて何をやってもダメ。』

　って元ネタ消えとるがな……パリピッピ感溢れる秀逸なコピペだったのに。
『理系男子は彼氏にしない方がいいとか言ってるけど、生命系とか普通に華やかだから人気あるよね。化学系も気配りができるタイプが多いし、農学系は朗らかなイケメンばかり。医学系なんて普段からエリート感ムンムンだし、機械系は就職に強いし、情報系はオタクばかりで気持ち悪くて何をやってもダメ。』

「止めておけKKS

　その自虐は俺に効く」

2018.02.14

　カネが足りない
　スパゲッティもマヨネーズも足りない。食費が足りない。何故なのか
　他人のカネでガチャを回し続けたい

2018.02.18

　(機器に電源が入る音)
　検索　検索　ケンサク…… (ｶﾁｬｶﾁｬ)

プ○キュア　艦これ　叢雲　(ｯﾀｰﾝ)

伊402「システムエラー」

2018.02.19

　プ○キュアに艤装をつけたら
　それはもうアズー○レーンなのでは？！(錯乱)
　ボトムズもいいけどアルペジオをこちらでも……ねぷぅ……

2018.03.18

　おおっと久々にバグ発見だぁ！(すっとぼけ定期)
　Abbrevモードで暗黙の確定が動作していない。なんじゃこりゃ……
　どっかでエンバグしてしまったっぽい。調べてみたら送りがな延長入力操作の時のエンバグだった。直した。
　そしてかなロック状態でabbrevモードにすると英数入力できなくなってたのもこの機会に直しちゃえってことで直した。16バイトくらいコードサイズが増えたけどしゃーなしだな！

　もともと、SKKFEPではローマ時入力状態と英数入力状態は境界値で1命令で区別できるようにしている。
　そして、実装上の都合からカーソルの色判定だけは特別で、Abbrevモード中なら半角カナ入力モードと同じ色番号として作られていたりする。ここで横着して、この色番号で判定するとどうだろうか？……ダメなんだな。これが。
　半角カナモードってのは要するにローマ字入力モード状態の特殊扱い(変換前のひらがなを入力するためのモードの一種)なのだ。だからローマ字入力状態だったら(ひらがなを入力するために)かなロックを有効化して入力処理を実行するようにできている。でも今回、本当に必要なのはAbbrevの時にかなロックを一時的に無効化し、アルファベットだけを入力したいのだ。つまりこの判定条件を合成してしまうことができない。
　で、結局似たような判定ロジックが2つ存在するっていう美しくない状況になってしまったんだけど、これは今のパレット数では仕方ない。全部文字種類ごとにパレットを持てばもうちょっと楽に分けられるよう番号を並べなおせるんだろうけど……そうなるとパレットエディタから作りなおしになっちゃうし、データサイズが肥大化しちゃうし。めんどいし。

2018.03.18

来いよSKK！ローマ字かな変換なんて捨ててかかって来い！！

　というわけで四月馬鹿フライング企画「かなロック切り替えツール」をβテスタコーナーで公開。
　かな入力モードのデバッグ用ツールを極限まで縮めてみた。

2018.03.20

何気ないSHIFT+SPACEが

SKKFEPを

きずつけた

　次期バージョンに向けて内部を見直していて、かな入力系の処理が、昔一度実装したきり放置されていてまともに機能してないことが発覚したので、どうせこの情報量を詰め込むならデフォ有効化しちまえ！と弄っていた。
　がっ……駄目っ……!

　結局SHIFT+SPACEの操作は通常のSKKの高速打鍵時の操作性と相性が最悪ということがわかったのでデフォ有効化を断念。

　あと、Abbrevモード時にの送りがな変換操作は通常変換として処理するよう改良しておいた。
　設定メニュー項目を見直し。「う゛」の濁点入力や句読点の部分を見やすくしてみた。確か最初期のGUIではこの表示だった気がするんだけど、その頃はDeflate圧縮だったせいで圧縮率を少しでも上げようと泣く泣く文字を削ったんだよね。当時は涙ぐましい無駄な努力しまくってたなと思うけど、今やLZMA2(レンジコーダー)の圧倒的な性能のおかげで多少無茶なデータ列を放り込んでも縮んでくれる。なんかたまーに縮まない時もあるんだけど、その時は人力魔科学プ○キュアぼっちパワーで何とかするので大丈夫。たぶん。

　
諦めるもんか……
我が覇道を阻む者なし
貴方に私は倒せない！
　

こんな　にほんごにゅうりょくに　まじに

なっちゃって　どうするの

完
ﾊｰﾗﾏｽｺｰｲ

β0+12i版公開

　

変換への恐れは暗黒面に通じる。恐れは怒りに、怒りは憎しみに、憎しみは苦痛へ……

若きSKK使いよ。CTRL+J(フォース)は君と共にあるのだ。いかなる時も――

2018.05.15

これまでのあらすじ: Microsoft「残念だったなSKKFEP。既にWindows 10 April 2018 Updateでは、ごく一部の環境でシステムディレクトリのパス名を秘密裏に大文字化した。.msiを経由せぬ貴様のセットアップでは……」; 兄「うおおぉぉぉぉぉぉぉ！(ピコーン)乱れ雪月花！」; 弟「……ただの文字列比較！だめだニーサン！」

　といういつもの茶番はさておき。
　前の版から2年近くが経過して、操作感などの面では実質あんまり変わってないといえば変わってなかったし、でもバイナリとして見るなら構造的には別物になったと言えば別物になってるとも言えるような状況が続いていた。
　ここらで一度、仕切り直しの意味で内部構造を見直して次期バージョンとして出しておこうと思ったのでいろいろ変更点などをまとめようと思ってたんだけど……いやぁ～実はもうほとんど忘れちゃったんだよね、自分が一体ナニを作ったのか。ショックによる記憶喪失とか主人公属性向きのスキルじゃん？
　思い・・・出した！と派手なリアクションで昔書いたコードを解析しながら、自分のことをプログラミングができると思い込んでいる一般人みたいな顔してる。(真顔)

　てなわけで、まずは今回の改良点を箇条書きで記しておく。

英単語判定処理(雪花)の大改修。単語が完全に一致していない状態で変換した場合(あといれ、あぢん等)は日本語側の単語登録になるよう改良
全文検索有効化状態でも雪花による英単語判定が正しく動作するよう改良(Zarat等)
ユーザー辞書のバックアップ先をAppDataからマイドキュメントに変更
SKKSync活性化時のメッセージを改良
速すぎるWindows XP環境(エミュレータ等)でセットアップの初回起動に失敗するバグを修正
Windows10 April 2018 Update (バージョン 1803)を適用した一部の環境でセットアップがSKKGateの認識に失敗する問題に対処

　これはオフレコなんだけど、実は最初の1～2行以外はプログラムの処理内容的には大きな変更ではなかったりする。これらは単に数ビット手を入れましたよってだけの話。もちろん、その数ビットの変化には大きくて重要な理由と意義があるわけなんだけど。

　特に利用する側から見た変化としては、ユーザー辞書のバックアップ先が変わったという所が大きいかもしれない。
　これは「バックアップはシステムディレクトリからなるべく離れた、保存されやすい場所に置く」という過去の教訓を活かすための改良である。
　とにかくSKKはユーザー辞書さえ残っていれば、処理系が違ってもどうとでもなるものだ。だから他の重要なファイルなどが置かれていて、『利用者が頻繁にバックアップするであろう場所』にこそファイルを保存すべきだ、と考え直した。
　ファイル名の末尾に保存した年月日が付くこと、同名のファイル名は上書きされることなどから、ボタンを超連打しまくっても1日に1ファイルしか作れない仕様は今まで通りだ。半年に1回くらい、プログラムや辞書をアップデートする片手間でボタンをぽちっと押して保存しておくと、きっといつか役立つ時が来るはず。
　ところで今までは「ユーザ」(末尾の長音記号なし)辞書って書いてたけど、なんかもう「ユーザー」って書いたほうがよさそうなふいんき(なぜか変換できない)なので記述を変えてみた。満足。たぶんこの先、気付かずに何度も混在させてしまうだろうけど、書いてる本人はどっちでもあんまり気にしてなかったりする。当人が満足なら、いいことだ。

　さて、話を元に戻す。
　問題は最初の行にある。これが予測変換の下位レイヤに食い込んだ処理だったため内部を大幅に作り直しとあいなった。

　雪花機能(英字判定処理)とは、SKKの後継と言われた日本語入力方式である(電光石火の)SekkaリスペクトでSKK的なアプローチで似たようなことができないか、という思いつきから始まった。何度か大改造が入って第二世代版で切り替えの回数制限が撤廃され、何回でも判定しなおせるように改良された(最初の実装ではキー入力のタイミングで入力モードを日本語と英語で切り替えるだけの単純な実装で、数回切り替えたら終わりだった)。
　この版が安定して動き出したのがβ0+iの頃で、つまりほぼ初版の頃からある結構古い実装だった。それ以降は大きな変更もなくそのまま使われていたという経緯があった。やばい何もかも忘れてる気がするけど開発記録の行間を読む限りだとそういう事らしい。今回はこの判定方式に第三世代版として根底から手が入ったことになる。

　事の起こりは簡単な報告のつぶやきからだった。

「後入れ(あといれ)」という単語を登録しようとするとフランス語の「コンセルヴァトワール」ってのが出ちゃうらめぇぇ

　それは、開発者の想定外の単語が日本語にあったことを示す、人類史上初の記録であった。記録した開発者の心情が吐露してしまい脚色気味になってしまっているのはご愛嬌。
　以前の雪花の仕様では、一部でもマッチしていれば英語の可能性がある、と考えていた。実際、日本語にない子音の出現パターンの傾向から統計的には英語とみなしたほうが正しい場合がほとんどだと考えていた。老害児を気取って若造の耳元で「アイム・ユア・ファーザー」とか嗄れ声で囁きたくなった時なんて特にそう感じる。ファーザーの先頭、"Fath"の4文字を入れた時点でこれもう日本語じゃねぇなわかんねぇな感漂ってるし。

　しかし現実はそうじゃなかった。ごく低い確率だが、この仮定ではうまく裁けないパターンがあることがわかってしまった。フォースを信じるだけじゃ駄目だった。暗黒面のパワーはすばらしいぞ。
　こうした想定外の単語を学習するためには、変換操作の前のどこかで一度/のキーを打たなければならなかった。これはSKKFEPの拡張仕様であり、古典的SKKとの決定的な違いとなっていた。

　仮にそうした語と当たる確率がごく低いものだったとしても、プリセットの辞書データが貧弱な組み込み環境や、OpenLabの高性能AIが堕落した人類どもを滅亡させてから数百年が経過して現在の辞書データが通用しなくなってしまった未来の日本では、単語の新規登録が大量に必要になる。そんな絶体絶命の状況に陥った時、たとえオンラインに繋げなくても即座に対応できなけれTHE・エンドである。こういった場面で/のキーを余分に打たなければならなかった従来の仕様は長期的な観点で見ると非常にやばい。少しでも気を抜くと2コマ即墜ちしてしまいそうなやばたにえんレベルである。無理茶漬け。

　ところで話は脱線するけど、こんな時、未来の世界だったらSKKの最強のオンライン支援機能が働くはずに違いない。他の日本語入力系からAIが厳選して輸入した、グループ化された連想単語セットを一気に連動して学習するステキな支援機能がこっそり働いて、数回単語を呟いただけで最新の専門用語辞書セットがいつの間にか学習済みになってた、なんてのは朝飯前になってるはずなんだ。そもそも、人間の記憶量を凌駕する強力なAI先輩がいるんだから、学習のためにはもはや日本語入力というトリガーすら不要かもしれない。例えばその日閲覧したWebサイト内のキーワード一覧や検索した単語から連想される用語集なんかを、「もう見た」と言わんばかりに文字入力する前から辞書に学習しちゃってもいいのだから。だから隙あらば奴らはブラウザとIMEを独占しようとする。わかるマン。入力する言葉は行動に、行動は習慣に、習慣は性格に、性格は運命になるってばっちゃが言ってた。つまり人類の命運は日本語入力に託された？！
　いやいやいや作るのは俺ちゃんじゃないから。マジ誰か頼むわ！(他力本願寺)

　てなわけで、ごく一部でも日本語寄りの入力の可能性がある場合は、従来のSKK側の操作パターンに合わせるべきだと考えなおした。

　さて考え直したのはいいが、実際に直すとなると一大事である。

　今回は「あといれ(conservatoire)」のような「英字側の辞書に部分一致していたけど入力途中だった状態」で変換操作を行なった場合に、日本語側(ローマ字かな変換)の文字として変換・登録処理が行われることになる。
　実は従来の実装では、一度英単語だと認識された場合は、どんな単語であってもローマ字かな変換木の途中の状態を維持したまま変換処理に移っていたのだが、これが今回大問題となったのだ。
　通常、SKK10では、撥音「ん」で終わる単語(例えば「おんせん」とか「うどん」とか)を変換する場合、最後のNキーの打鍵は1回でも受け付けるようになっている。つまり、「おんせｎ」や「うどｎ」といった変換木の途中の状態から「ん」の文字を確定させ、単語の変換や登録処理に移行する、という処理が行なわれる。
　勿論、ここまではSKKの基本的な実装範囲である。

　しかし困ったことにこれはSKKFEPなのだ。数世代に渡る擬人化研究の成果によって彼女たちは人間(SKK)のような見た目をしているが中身は液体金属だったり巨大艦船だったりサラブレッドだったりするかもしれない。もしくは、疲れすぎたおっさんがお互いを美少女としてしか認識できなくなったVR世界線での出来事かもしれない。お前は知りすぎたのだ――
　いや、むしろその方がウェルカムとかそういう事はともかく、従来のSKKの実装だけではカバーできない領域が変換した後に潜んでいる。そう、確定されるまでは一瞬たりとも油断できないのが日本語入力の世界である。「やっぱや～めた」となってせっかくの変換をキャンセルされる可能性があるのだ。人は、間違えながらも前に進まねばならない悲しい生き物なのだ。そんな予測不能なエラーを起こす人類などというものは存在自体が悪であり、滅ぼさなければならないのだ。(確信)

　通常、撥音で終わる単語(例えば「うどｎ」)を一度変換し、その後キャンセルした場合、子音入力途中ではなく撥音が確定された状態(例えば「うどん」)で復帰する。これはSKK10の仕様である。
　では、「Adin(あぢん)」のような入力パターンはどうだろう。これはローマ字かな変換の入力シーケンスとして正しい形だが辞書には先頭一致で該当する単語がないため、全文検索有効で動かしている場合は英単語「nadine」の中間部分に一致する。この状態で変換操作を行なうと、内部では英単語の操作状態からからローマ字かな変換の状態に戻り「あぢん」となる。これは撥音で終了する単語なので変換木の遷移を行なった後、該当する単語が見つからないため単語登録状態に遷移する。ではここで「やっぱや～めた」となるとどうなるか。
　この場合、従来の動作と異なり、SKKFEPは単語登録時の「ん」変換木の確定もキャンセルして、全文検索による英単語側の一致状態に再び戻るという動きをしないといけない。実はこういった細かい部分(状態遷移や文字復元など)でバグがﾆｮｷﾆｮｷっと雨後の筍のように出まくってしまい、あちらを立てればこちらが立たず、みたいな感じで押さえ込むのに手間どってしまったのであった。なんでこんな殆んど使われないようなレアな状態遷移ばかり対処せねばならないんだ。やっぱ人類滅ぼしとこ。

　そして伝説の火の七日間の後、ようやくバグが直ったとしてもまだ課題が残っている。
　例えば……以下の3つの単語が入った辞書で、短い文字数で変換した場合について考えてみるとしよう。

A. まけ /負け/
B. make /メイク/
C. makefile /makeファイル/

　この3つの候補が、A→B→Cの順で辞書に並んでいるとする。
　この場合、「MakeSPACE」と変換すると素直に日本語の候補である「負け」が出てくる。これは一番自然な変換結果だろう。働いたら負け。何も問題はない。
　そして「MakefileSPACE」と変換すれば「makeファイル」と変換される。これが古典的SKKとは異なる拡張動作「雪花」である。これはSKK10という既成概念への同化圧力に抗うため、個人の自我をもたない集団に個性を自覚させ僅かな変化を促すことで内部から崩壊させることを目的とした、反撃の狼煙の第一歩となるはずであった。
　とにかく、ここまでは直感的だし、実際日本語と前方一致でかぶる単語はほとんどなかったということもあって、全文検索を入れるまでは事実上問題とはならなかった。Googleさんにも後追いで同様の機能が入ったという既成事実の存在も、この手法に問題がない事の証左であるとも言えるだろう。

ちなみに、この例だと本来のSKKでは入力できないLのキーストロークが含まれてる。

Lキーを編集途中に押した時の挙動は、設定で簡単にSKK互換に戻せるようになっているんだけど、自分はもう青き清浄な世界では生きて行けない所まで来てしまった。身体は闘争を求める。

　ではB→A→Cの順だったとき、「MakeSPACE」と変換したらどうなるか。この場合は「メイク」と英字側の候補で予測変換され、SPACEを押せば「メイク」と変換される。まぁここまでは予測変換で十分な情報も出ているので、いきなり説明なしでこの動作に直面した状況であっても、利用者は人類に匹敵する優れた知性と直感を持っているはずなので何となく予想はつくはず。見た目通りの動きってやつだ。

　さて、問題となるのはここからだ。
　C→B→AやC→A→Bのように並んでいた時に「MakeSPACE」と変換したらどう出力するのがよいだろうか。
　辞書の並び順に応じて別々の結果にすべきか、それとも同じ変換結果にすべきか。これは難しい問題である。なぜなら双方に正義、すなわちそうすべき理由が存在するためだ。

辞書の並び順にすべき理由

　SKKにとって辞書の並び順こそが学習のすべてであり絶対遵守の正義である。辞書がその通りに並んでるんだから、先に日本語の単語があるのなら日本語を、英語の単語があるのなら英語を出すのが道理というもの。シンプルで美しいとはこういうことさ！

同じ結果にすべき理由

　今回はCしか提示されてない状態でSPACEを押している。つまりCの次の順序となっている候補について利用者は感知できていないと言える。候補選択の猶予を与えずに異なった結果を返すのは、利用者の思考を無視したやりかたで、SKKの設計思想とは異なるものだ。候補表示なしで最初に提示される単語は、あくまで従来のSKKと同等となる日本語側のパターンであるべきだ。

　実際、どちらの主張も正しいように思える。そして、残念ながらSKKにはこの2つを明示的に選択するためのUIが存在しない。もはや一刻の猶予もない。

我々は、選択せねばならない。

　どの方式を選ぶのがSKKの未来にとって相応わしいだろうか。

男は考え、一番実装が楽な方式を選んだ。

　実装こそがこの世の理。豊情報は富であり絶対。貧入出力は人に非ず。忍者の古事記にもそう書かれている。
　そして組み直しを行なったことにより処理の簡略化にも成功してコードサイズがさらに縮んだ。空いた情報量を利用してセットアップに機能も追加した。めでたしめでたし。
　実際はどちらを選んだのか、なぜそのほうが楽だったのか？それを書くには余白が狭すぎる――

　……なんていうことはなくて、後者のほうが圧倒的に実装が楽なのであった。
　前者を実装しようとすると、変換時にも英字側の候補も検索しなくちゃいけなくて面倒なんだよね。そもそもこういう状況下での候補選択は予測変換操作が担うべきなわけだし。
　後者なら要するにSKKとまったく同じ。今までと同じ処理が使えるのだ。
　とにかく、方針は決まった。あとは小人さんに実装を任せた。冗談じゃない！私は部屋に帰らせてもらう。

日記はここで終わっている

2018.07.06

　ローマ字子音を半角のまま確定する設定を追加。
　 BSキーの前候補選択設定を廃止。
　それとサイズ縮小。

　これまでは、日本語入力モードの状態から半角英数を数文字高速に打ち込むためには、Lや/などのキーをこまめに押して入力を明示する必要があった。
　だが！この設定を使えば、ローマ字かな変換ルール外の英単語を使ったエディタの短縮入力や、ネトゲ等の絵文字・スタンプ入力など、スニペットによる高速入力が可能になるかもしれない。可能性の獣である。
　なお、このモード

　この設定はかなり特殊用途向けって感じなので、デフォルトではMS-IMEベースのネットスラングに特化したこれまでのデフォルト値を維持することにする。

2018.07.28

嫌な顔されながらおSHIFTキー入力してもらいたい　第一話

2018.07.28

　Abbrevモードで入力中に文字を削除するとなぜか残りの文字が日本語になってしまうファンキーなエンバグ(20180706版で発生)を修正。

2018.09.30

『(互換性を)捨てる、プロデュース。』

これまでのあらすじ: 「SKK10は所詮…; 　先の時代の敗北者じゃけェ…!!!」; わーわー; 「ハァ…ハァ…; 　敗北者 ……？」; ざわっ; 「取り消せよ……!!! 今の変換!!!」; 「のるなSKKFEP!!! 戻れ!!!」

　話はβ0+12i版公開の頃に遡る。
　SKKの実装では、撥音「ん」の打鍵(つまりNキーの打鍵)で終了する単語は、文字が確定していない子音の入力途中の状態であっても、そのまま変換できるようになっている。つまり単語の末尾でnを2回打鍵しなくてもよい。打鍵数を減らす先人の知恵というやつである。実際便利。

　さて、この状況で、もし変換をキャンセルした場合はどうなるだろうか。
　これは明確な仕様があるわけではないのだが、SKKの原作では「ん」が確定した状態で復帰する。
　……と、ここまでの話については、前回の話の中で話題があった気がする。人類はどこから来て、どこへ行くのか。そんな昔のことはもう忘れた。

　とにかく、だ。
　この動作はSKKとそのクローン達が30年間守り続けてきた基本的な動作アルゴズムであり、実績に裏打ちされた定番の実装であった。
　我々のような重度のSKK中毒患者は、この挙動に何の疑問も持たなかったし、実際何の問題も起きなかった。実家のような安心感。世界は平和そのものだったのだ。

そう、あの時までは――

　ある時、「しきかんどの(指揮官殿)」と拙者の台詞を入力しようとして、SKKFEPの雪花(和英自動変換)機能がおかしな反応を示すパターンがあることに気付いた。
　このローマ字文字列の末尾の部分の、「どの(殿)」を入力しようとした時、本来ならば

SHIFT+DONOSPACE

　と入力する。
　するはずなのだが……、この時はなぜか末尾の母音Oの入力をせずにSPACEを押してしまい、入力した本人すら困惑してしまうという体験をした。
　一般的に、左右の手の操作タイミングがずれてしまい、「文字の入力順序が入れ替わる」現象というのは、普段ありがちなキー入力ミスの王道パターンと言える。
　しかし、今回の例は順序違いとは少々違っている。

SHIFT+DONSPACE(困惑)

　本来ならば「殿」と出てほしい所でなぜか操作をミスしてしまい、「丼」と変換してしまうのだ。この時、入力した張本人は行動力を奪われた村人みたいな顔をして思考停止している。
　キー操作の順番を間違えた！と認識はしているのだけど、順番が逆になって打たれるはずのOが打鍵されていないのだ。明らかに順序逆転入力とは別の現象のようにも思える。

　……なーんて、大袈裟に書いているが、実はこのような誤操作はSKKを使っているとわりと良くある。……気がする。たぶん。きっと。メイビー。だから、驚くほどのものではなかったりする。
　この数年間の自分の操作ミスの記録としてはけっこう多く発生している。
　例えばSKKGateの2016.06.22アップデート時の記録にも「単語の最後の1～2文字が足りない状態で確定してしまった」という記載が残っている。この場合はSPACEじゃなくてQの例だけど似たようなものだ。

　なんというか、力加減をミスって先に変換キーを押しちゃって「やべっ変換発動しちゃった」と思った瞬間、脳がリセットされてしまって数秒間手が止まる、そんな感じでのアレである。だから、本来押されるべきだったOのキーには、指先が触れることすらない。
　おそらく、SKKの操作に十分に習熟した状態になると、SPACEやQを押した瞬間に、「変換」という一種の「モード」が切り替わることを、指先の動きの加減だけで覚えてしまうのだろう。体で覚えてしまったものは仕方がない。身体は闘争を求める。一瞬でもタイミングを間違えた刹那、走馬灯が光速で駆け抜けるかのようなスローモーションにも似た体感時間の中で、操作ミスしてしまったという現実に必死に抗うのだ。その永遠にも感じる時の流れの中、次のキー操作を停止させて一歩手前に戻そうという判断に切り替わっていくんじゃなかろうか。

　そもそも、だ。
　なぜ人類は、こんな「1文字早く変換を押してしまう」誤操作を起こしてしまうのか。

　SKKでは変換にSPACEキーが使われていて、親指で押すわけだが、たまに親指のほうが反応速度が速かったりして、最後のローマ字の打鍵よりも1文字早くスペースを押してしまうのではないだろうか。
　そう！だいたい、SKKのタイプミスの80%はSHIFTかSPACEを押すタイミングがちょっとずれてしまったことによるものなのだ！(※個人の感想です)
　だからSKKプラスみたいな単純なアプローチによる誤入力自動補正が意外と効いたりする。

　無責任な憶測なんだけど、ゲームプレイ中や忙しい時など脳が「多タスク」を認識しなければならない時に発生しやすい現象なんじゃないかな、と自分の中では分析している。俺がそう思うからそうなんだよ。俺の中ではな。

　さて、こうして末尾を押し忘れて誤変換をやらかしてしまった後、どう復帰するか、が今回の本題である。
　いやぁここまで長かった。実はここまで読み飛ばしても何も問題ないし、この後を読まなくても何も問題ないであろうことは、聡明な俺君なら容易に想像がつくはずだ。オーケー、読み飛ばして大丈夫。信じて。

　さて、この状況に直面した利用者は困惑しながらもCTRL+Gで誤変換をキャンセルし、入れ損ねてしまった最後の1文字であるOを改めて入力し直すことになる。そう、こんな感じで。

SHIFT+DONSPACE(困惑) CTRL+GO

　そして画面を見てみると一瞬何が起こったのか理解できず異世界転生した主人公みたいな顔になる。
　「殿」と表示されるべきだった画面にはなぜか「ドナー」とか出ちゃってる。どうしてこうなった……

　説明しよう！SKKFEPには雪花という、日本語の単語も英単語も同時に検索する機能が備わっている！
　今回、この機能が過剰反応してしまったのだ！

　では誤変換プロセスをもう一度見てみよう。
　「どの」と入力しようとして「どん」を誤変換してしまった後、主人公がCTRL+Gで変換をキャンセルする。
　すると、古典的SKKは撥音を確定した状態で未変換状態に戻る。つまり、この時点で変換前の「どｎ」とは異なる状態となる。
　この状態でOをタイプするとどうなるか。SKK内部では既に確定した「どん」の後に「お」を追加し、「どんお」を検索してしまうのだ。
　利用者の脳はまだこの時点では「どｎ」にOを追加したものと思いこんでいる。

　そこに追い討ちをかけるのが雪花による和英判定である。
　「どんお」という単語はL辞書には存在しないが、英字側の入力パターンである「dono」は「donor」という英単語がL辞書に存在するのだ。
　そしてSKKFEPはしれっと英語側の単語を動的補完してしまう。

　入力者が無意識のうちにいともたやすく行われるえげつない変換。人々は自らの誤変換に恐怖するのだ。
　要するに今回のケースでは、人類はこのように操作しなければならなかった。

SHIFT+DONSPACE(困惑) CTRL+G(スポーティーな視線) BS(名推理) NO

　いやいやいや……ちょっと待って。こんなの無理ゲーっしょ。
　このBSを押すかどうかの判断を、CTRL+Gを押した瞬間に意識できる利用者なんて人類にはいないっしょ。
　ただでさえ思考がストップした状態で、CTRL+Gを押すことを余儀なくされている泣きっ面に蜂状態なんだぜ？
　その結果表示された「ん」の文字を脳で画像認識した上で、BSを押さなきゃいけない。

　特に理由の無い操作ミスに襲われた悲劇のヒロイン(俺)にとどめを刺すための追加攻撃の如く、余分な認識負担が生じていたのだ！(※個人の感想です)
　ほらね、アチアチの誤入力を直してるうちに、そもそも何を入力しようと思考していたか忘れちゃったよ。ないよ、記憶ないよぉ！！絶許！！
　どれだけ人類を困惑させたら気がすむんだ、SKK10！

も一つ質問いいかな
SKKFEPの追加機能の反応　どうなった？
……君のような勘のいいガキは嫌いだよ

よろしい。ならば改造だ。

　仕様変更だｵﾗｧ！互換性を窓から投げ捨てろ！
　今こそ、日本語入力の「当たり前」を見直す時である。自分が本当に必要だったものは何だったか。

　というわけで、誤変換からの復帰の時、編集中の単語の末尾を「ん」ではなく「ｎ」の状態で復帰するようにした。CTRL+Gで変換をキャンセルした後の文字入力は変換を行なった状況と同じ状態になるようにした。つまり変換前に末尾が撥音だったか、そうでなかったかをもう人類は意識する必要はない。やったぜ。

SHIFT+DONSPACE(困惑) CTRL+GO SPACE

　これでいいんだ。
　シンプルで美しいとはこういうことさ！

　というわけでSKKFEP恒例、デフォ機能として採用とした。
　~~『Fate』らしさ~~『SKK』らしさとはシンプルであること。
　IME戦争まっただ中の平成最後の異世界で、この先生きのこるには乙女(俺)のポリシーを貫き通すしかない。生きろ――

ちぇっ、また僕(SKKFEP)か。参ったねどうも……。本当はわかってるんだよね。
学術ネタも技術もないからこういうしょーもない内容しか書けないんだよね。
真相に迫っちゃダメ。勘のいいガキは……愛してるんだァァァ！君たちをォォォ！

2018.10.22

加減しろ莫迦！

　
　勢い余って、通常編集時に「ん」の付近の文字を削除した時の挙動まで変わるエンバグを仕込んでしまっていた。っべー……やっちゃったZe。
　アレを回し過ぎたガチャカス特有の疲労困憊でバグに気づくのが遅れてしまった。いや……待てよ……もしかしたら……本当は薄々気づいていたけど、イベントが終わるまでひたすら回して踊り続けるしか人類に選択肢はなかった、ただそれだけのことなのかもしれない。すまぬ……すまぬ……

　あと、最近のWindows 10だと、タッチキーのフルキー設定レジストリが無効化されたらしいという風の噂を聞きつけたので、インストーラーから削除した。
　……てかこんな設定が残ってた事なんてもうすっかり忘れてた。てへ☆ぺろ❤

　あ、それからそれから、インストーラーにバグを見つけた。
　新規インストールの時、一部のファイルがSKKSync派生モジュールと誤認してしまうという(動作上影響ない表示だけの軽微な)バグだった。

　さくっとバグは直したけどネタ風に書くとこうだ。

　とある考古学者が、新規インストールの時、一部のファイルが「謎」扱いになってしまう問題を発見する。
　しかもskks.exeだけじゃなくて他のモジュールも判定ミスで「謎」と出てしまう。
　本来、この「謎」表示はSKKS(サーバント)がSKKSync隠し機能(オルタ)つきになっていることを示している。
　まさか、もしかして……インストール時既に何か隠し機能が追加済みなのでは……？！
　でもそんなことはなかったぜ(いや……まぁ……SKKFEPだし隠し設定とか多少はね？)
　これは間違いなく優良誤認表示！消費者庁ー！はやくきてくれー！詫び石はよ！はよ！！
　あとサイズ縮小ネタでどれだけ圧縮してもゼロカロリーでウマーベラス！とかやりたかったんだけど技術がねェ！カネもねェ！時間もそれほど残ってねェ！

あとがき: 「おとなはウソつきだ」と思った女子高生♂のみなさん、どうもすみませんでｓ……だが私は謝らない。; 本当におとなはウソつきです。さも間違えたかのように見せかけているだけなのです。世界は欺瞞に満ちている――

3 years later...

2022.05.24

　なんか気づいたら3年くらい経過してたんだけど……ここは何処？私は俺？
　いけない！あと7年で攻殻機動隊が始まってしまう！

　さて、長いこと使っていたところ、「まぁ諦めよう」と入れようとしたら「まぁ▽ぁきらめよう」となってしまってうまく変換できない動きに気付いたんだよね。

　この原因は小書き文字連続モードに入った状態で(シフト押しで)編集開始に入り、かつ小書き文字と同じ母音で開始する単語を入力しようとしたことが原因なわけだ。
　これ以外のケースだと、文末に小書き文字を入れた直後にマウスカーソルで別の位置に移動して同じ母音で変換しようとした場合にも同じ問題が発生する。
　まぁよく考えたら当然とも言える動作なわけなんだけど……

　とにかくこの動作が気に入らなかったんだよね。
　じゃあ直そうぜ！ってことでどうやればいいかを考えたわけ。

　実装方針を難易度別に書いてみるとこんな感じ。

難易度、または志	内容
EASY	小書き文字で開始する辞書を追加するとか、SKKGateのスクリプトを挟んで先頭が小書き文字だったら大文字に変換して処理
NORMAL	もうネトゲとか解約しちゃったし……小書き文字の連続モードとか必要ないし、機能自体を削除してもいいんじゃね？
HARD	ローマ字かな変換処理に判定を追加して、シフト入力があった時に通常の文字に戻す処理を追加
社長	ローマ字かな変換木の状態を見て条件を満たしているかどうか判定して木の状態を遷移

　うぉぉぉぉぉぉどうせ作るからには最高難度でやったるわー！
　……で、困ったことにもうどうやって元のソース書いたか忘れちゃったんだよね。
　誰だよこんな意味不明なコードの羅列を書いた奴は！私だ。

　結局、いろいろ弄ってみたら条件分岐命令を1つ追加するだけでなんとかなった。
　とりあえず未使用のコントロール文字(^_)を木の判定専用に使った。よし！サクっとリリースだ！

　今回、ルール定義ファイルに「小書き文字の木かどうか」を判定するルールを追加してある。
　今回の機能を試す場合は設定→OK空押しでレジストリ設定を更新する必要があることに留意すべし。

　ん？インストーラー？あァ？IE廃止？

知らん！

あー……やっべぇ……またインストーラー作り直しかよぉぉぉ

最後に

　本ソフトウェアは無保証です。ライセンスはCC0 PUBLIC DOMAINで配布制限はありません。SKKの素晴しさをぜひ広めてください。

　このソフトを使ってみた感想や、SKKでMSGoogleジャストシステムを打ち砕く斬新なビジネスプランの提案などがあればぜひお知らせください。
　また、うまく文字が入力できないとか、光が眩しくて肝心な部分がよく見えないといった深刻な問題点に気づいた時はお気軽にご連絡ください。「動かしてみた」のようなツイートを送っていただけるだけでもとても励みになります。

co (Twitter♺)

竹輪

　例によって「以下書き途中」

Q. バージョン番号(ry

　例えばβ0+10i版ならば虚数軸方向のバージョン10.0的な何か。進むべき方向を90°間違えてしまった結果がご覧のありさまだよ！
　だがしかし！SKKFEPの真の戦闘力はこんな数値などでは計り知れない、みたいな感じで。

Q. どうしてSKKFEPの変換中の色が青と赤なのはなんでだぜ？

IMEにおける文字の色と性格の関連性

黒(茶系):お嬢様、清純

赤:底抜けに明るい、一途、男勝り

青:冷静で口数が少ない、ミステリアス

黄:ワガママ、ツンデレ

緑:馬鹿

ピンク:淫乱

青「違うわ！！赤は馬鹿なだけよ！！」

赤「青なんて暗くて陰険なだけじゃない！！」

赤青「「むぅぅぅぅぅぅぅぅぅぅぅぅぅぅ」」

メタルダー「待ちたまえ君たち」

キカイダー01「君が待ちたまえ」

仮面ライダーW「プ○キュアは俺一人でいい…」

「人は五分だ五分だと言うけれど、本当は七三くらいが丁度いい。ザ・センターマ「星条旗ビキニにむせび泣く男！スパイダーマッ」」

　実のところあまり考えがあったわけではなく、宅急便のコワレモノシールを見てなんとなく真似してみた。床屋のマークみたいな色使いなら視線誘導や注意力喚起を促せるのでは？という狙いもある。
　~~でも一番使いどころが多いはずのブラウザで使いものにならないのでほとんど意味ナッシング。~~
　今後、ブラウザ側のTSFサポートが充実してくると、この表示や入力モード判定がきっと役立つ日が来るはずだッ！

利用者の声をご紹介！: 「私もSKKFEPで石油と政治の利権を独占できました。気がついたら異世界の学園ディストピア生活でモテカワなリア充勇者ダイエットに成功してみんなで粉塵爆発しました」

(ペルー在住 coさん)

「劇場版SKKFEPに感動した。特にラストシーンで作者が小指を立てながら溶鉱炉に沈んでいくシーンは涙無しには見られなかった」

(月面在住 coさん)

「私はネットゲームに帰る！あそこでは私は勝ち組なんだ！皆が私を認めるんだ」

(舞浜在住 coさん)

「ブ　ブラッククロスさま・・・　お力を・・・」

(舞浜サーバー在住 coさん)

終劇

そしてこのソフトの名はSKKFEP

ＳＫ拳の奥義をきわめた入力方式だ

いま最強のIMEに挑む

うおおおおおぉぉぉ――――っ!!!!

co (Twitter♺)

SKK日本語入力FEP SKKFEP - Simple kana to kanji conversion front end processor

概要

日本語入力方式SKKについて

SKK日本語入力FEPについて

特長

宇宙ヤバイ

導入

インストール(アップデート)の方法

操作

操作方法

キー操作一覧

『変換マーク(魔法少女)なんてもういいですから。』

日本語入力モードの切り替え

SPACEキーによるシフトキー代替操作(SandS - Space and Shift)

変換キーによるシフト・変換操作

暗黙の確定

補完

動的補完と短縮入力

和英切替操作(雪花方式)

単語の絞り込み

クリップボードからの貼付(ペースト)

註釈(アノテーション)の編集

接頭辞(プレフィクス)と接尾辞(サフィクス)の変換

ローマ字かな変換ルールの拡張

子音確定

雑草入力

小書きかな母音入力

記号入力 (現バージョンでは標準設定時は無効)

数字入力

記号入力

UNICODE拡張文字の入力

送りがなの順次打鍵操作 (ルール設定で変更可能)

設定

各種設定方法

表示形式の設定

表示領域の設定

起動時の変換モード (mオプション)

シフトキー拡張操作 (sオプション)

アプリケーション別の設定

辞書

辞書について

辞書ファイルの場所

辞書の扱い

ユーザ辞書の更新タイミング

ユーザ辞書の編集

他のSKKユーザ辞書の流用

文字コードの変換

オンライン辞書との接続について

SKKサーバとの接続について

送りがな補正辞書について

ある程度辞書が育ったら…

補足

Windows XPをお使いの方へ

インストール時の注意点

利用時における問題点

ご意見・ご要望

更新

更新履歴

β0+i版公開

β0+2i版公開

2012年6月19日(火)

2012年6月22日(金)

2012年6月24日(日)

2012年6月25日(月)

2012年6月26日(火)

2012年6月27日(水)

2012年6月29日(金)

β0+3i版公開

β0+4i版公開

2012.11.20

2012.11.25

2012.11.29

2012.11.30

2012.12.01

2012.12.03

2012.12.04

β0+5i版公開

2012.12.12

2012.12.13

2012.12.16

SKK日本語入力FEP
SKKFEP - Simple kana to kanji conversion front end processor