berryzplus

外部ライブラリの適用先としては 2Kbytes未満 の小さいテキストの解析を想定していましたが、 エディタ本体への適用も「不可能ではない」と考えています。 ■エディタ本体への適用が難しい理由 * プログラム言語でない「ただのテキスト」に「構文」を定義するのは難しい。 * 「表示範囲のみ」など「ドキュメントの一部」に対してレイアウト解析する機能があまり使われていないので、最大2G文字分を一括で解析できる仕組みが必要（不可能だと思います。） * 時間のかかる処理の一部をワーカースレッドで実行させる仕組みがないので、UI操作に対してごく短い時間で応答しなければならず、構文解析のような処理に向かない。 色々課題はあるにしろ「解決できなくはない課題」だと思うので「不可能ではない」になります。

導入イメージを持ちやすくするために、検証中ブランチをpushしてみました。 自分も最近はあまり触っていないので、実はそれほど詳しくないです。

ちなみに、 コマンドライン解析だけを対象とするなら[boost::program_options](https://www.boost.org/doc/libs/1_78_0/doc/html/program_options.html)という選択もあると思ってます。→[解説ページ](http://www.02.246.ne.jp/~torutk/cxx/boost/program_options.html) `boost::program_options`はUNIX系の`getopt`のBoost版にあたるものです。 コマンドラインオプションを扱うためのライブラリとしては本来こっちなはずです。サクラエディタがもしCUIツールであったなら、こっちを推したかもしれないです。 `boost::spirit`はUNIX系の `lex + yacc(=flex + bison)`のBoost版にあたるものです。 サクラエディタのコマンドライン解析には、「構文解析」よりも下位レベルの「字句解析」が必要な気がしているので、こちらでないと移植できないのではないかと思ってます。

Win10ならコンパネで入力言語を追加できるはず。物理的には英語キーボードじゃなくてもOSがエミュレートしてくれます。 ぼくもまだ試せてないんですが :cry: ちょっと追記: Win7以降でproならコンパネから言語パックをDLして、簡単に英語環境を用意出来たはずです。色々改善されてきた機能なのでwin10になるとビビるくらい簡単です。試す場合は、英語版windowsが日本語版と少し違うことを覚悟した上で試すことをオススメします。

実は英語版がなんかおかしいのは前々から気付いておりました。主に切り替え時の処理のことを言ってますが、翻訳が？なところも多々あります。 この先どこかで、多言語対応をもう一度考え直す時が来ると思っています。そんなに遠くない未来に。 それまでは、対応すべき既知の課題として据え置きたいというのが現段階での所感です。

> 噛み合いませんね。 すみません。どこで食い違っているのかよくわかっていません。 > 人的リソース以外の理由で、現状に即した対応をせずに据え置きたい理由があるとは飲み込めません。 据え置きたい理由は人的リソースがもったいないからです。 @ds14050 さん の指摘通り対応すれば、見た目動いてそうな状態にできると思います。 しかし、ぼくは現在の sakura_lang_en_US.dll と CSelectLangクラス の方式が、 今後英語以外の言語に対応していくうえで正しいかどうか検証すべきだと考えています。 その過程で、せっかく対応した内容が無駄になってしまうようではもったいないなぁ、という話です。 正確な情報ではないかも知れないんですが、 windowsは接続されたキーボードが日本語なのか英語なのか判別できていません。 判別できない代わりに、入力された物理キーコードをキーボードレイアウトに従って仮想キーコードに変換する機構を持っています。 考えてみてください。 もし判別できるのであれば、何故インストール時にキーボードの種類をきかれるんでしょうか？ 106/109キーボード(日本語)なのか、[101キーボード(英語)](https://ja.wikipedia.org/wiki/Template:101%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%81%AE%E9%85%8D%E5%88%97)なのか。 コンパネから入力言語を追加して英語モードに切り替えた場合、 キーボードの入力レイアウトが101キーボードになります。 画面表示は日本語のまま、入力モードだけが英語になります。 逆もあります。英語表示の状態で入力言語「日本語」を追加して日本語モードに切り替えた場合、 キーボードの入力レイアウトは106キーボードになります。 画面表示は英語のまま、入力モードだけ日本語になりIMEが有効になります。 物理キーコードを仮想キーコードに変換する、という処理の性質上、 windowsは現在の入力レイアウトにどんなキーがあるかを把握しています。...

@ds14050 さん ぼくも ds14050 さんもプロジェクトのメンバーです。 みんなが同じ考えで同じ方向に向かって進むのもチームの在り方の一つだと思います。 ぼくは、同じチームに別な考え方の人がいたっていいと思っています。 誠意をもって相手の言葉を理解するように努めれば、お互いにメリットがあると考えています。 ぼくもGitHubでのやり取りには慣れていません。 他の人のやり方を参考にして探り探りやってます。 https://qiita.com/umanoda/items/93aec41213f8e3ce14c8 結論を繰り返します。 > 多言語対応と切り離して本件の対応を進めることを止めはしないです。 > いまここでぼくが語ったような内容をさらに整理して、何が問題か、どんな対処策があるか、どの方法を採るか、何故そうするかを具体的に説明していただければ受け入れもできると思ってます。 書き方がよくないのかも知れませんが「俺がやる！」で進めていただいて大丈夫です。 ぼくは自分がいま心配していることに基づいて「いまやるべきじゃない」と書きました。 現状PRのレビューをしているメンバーの中では、ぼくの基準はゆるい方だと思っています。 ぼくは、原因と対策、対策の効果と副作用が説明されている PR は受領すべきと考えています。

ぼく自身はこのやり取りに意義はあったと考えています。 @ds14050 さんのおかげで本件について理解を深めることができました。 本件の課題内容: 英語配列のキーボードで Alt + ; を入力すると 日付挿入ではなく時間挿入になる 原因: 日本語と英語でキーボードのスキャンコードが異なっているが、 アクセラレータの定義は仮想キーコードで指定されており、 スキャンコードの違いが考慮されていない。 ※物理キーコード → (デバイスドライバが変換) → スキャンコード 　スキャンコード → (TranslateMessageが変換) → 仮想キーコードという関係 対策: アクセラレータテーブルを作成する処理を変更すれば、おそらく対応可能。 https://github.com/sakura-editor/sakura/blob/b03ddd7acaa1a6f4cc1783a5dfbe3690b44db39b/sakura_core/func/CKeyBind.cpp#L92-L111 ここで [MapVirtualKey 関数](https://msdn.microsoft.com/ja-jp/library/cc410909.aspx)を使って仮想キーコード...

キー割当の要件は考え直す必要があると思っています。 やるとしたら提案1の対応になります。アクセラレータ作成は元々動的作成なので、日本語セミコロンを英語コロン+shiftに動的に再構成する処理を組込みます。でもこれは、日本語キーボードで見た時のセミコロンにshiftキーとの組み合わせを使っていたら破綻します。日英で割当が違うキーはこれだけじゃないので、他のキーでも同じ問題が起こり得ます。 対策案として書きかけたことは、この問題を多言語対応の一部として捉え総合的に仕様を見直すということです。例えば、英語レイアウトのキー割当を用意して切替できるようにすれば動的振り替えで起こる衝突を回避できます。 割当が被ったらどうするか、現在のレイアウトであり得ない組み合わせが来たらどうするか、を決めておけば動的変換の対応はすぐに着手できます。 提案2については基本同意ですが、やるなら別件として話したいです。

説明してなかったので説明します。 > 割当が被ったらどうするか、現在のレイアウトであり得ない組み合わせが来たらどうするか、を決めておけば動的変換の対応はすぐに着手できます。 この中の、 > 現在のレイアウトであり得ない組み合わせ がどういうことかについて。 セミコロンに割り当てられた機能の一覧 key | 機能名 | 関数名 | 機能番号 | マクロ記録可否 ---- | ------ | ------ | -------- | -------------- Shift + Ctrl+; |...