Sakura: 英語配列のキーボードで Alt + ; を入力すると 日付挿入ではなく時間挿入になる

[beru]

[kobake]

英語キーボードが手元にないので再現できない……(´Д｀)

[berryzplus]

Win10ならコンパネで入力言語を追加できるはず。物理的には英語キーボードじゃなくてもOSがエミュレートしてくれます。

ぼくもまだ試せてないんですが :cry:

ちょっと追記:
Win7以降でproならコンパネから言語パックをDLして、簡単に英語環境を用意出来たはずです。色々改善されてきた機能なのでwin10になるとビビるくらい簡単です。試す場合は、英語版windowsが日本語版と少し違うことを覚悟した上で試すことをオススメします。

[ds14050]

日本語キーボード(設定)では [;+], [:*] の刻印がある日本語キーボードのキーに対して仮想キーコード 187, 186 に対応するコマンドが TranslateAccelerator により送られてきます。英語キーボード(設定)では同じキーに対して 186, 222 の仮想キーコードに対応するコマンドが送られてきます(ちなみに 187 は [^~] の刻印があるキーに対応する)。

国により多様性があるキーボードのキーを、Unicode で文字を扱うように 256 種類の ID(※) で識別することはできないのでしょう。※CommonSetting_KeyBind.m_VKeyToKeyNameArr[] のサイズが 256+10。

現在の取り扱いに準じた対応としては、キー割り当ての設定に「^(英語')」「@(英語`)」とあるように、ラベルを「:(英語;)」にすることかなと思います。

[ds14050]

「;(英語=)」もかな。

[berryzplus]

実は英語版がなんかおかしいのは前々から気付いておりました。主に切り替え時の処理のことを言ってますが、翻訳が？なところも多々あります。

この先どこかで、多言語対応をもう一度考え直す時が来ると思っています。そんなに遠くない未来に。

それまでは、対応すべき既知の課題として据え置きたいというのが現段階での所感です。

[ds14050]

噛み合いませんね。仮想キーコードを介するアクセアレータキーの処理により、各言語キーボードに配された物理キーを識別することができています(※日本語キーボード(物理)で英語キーボード(設定)を利用すると[変換]キーと[カタひら]キーの識別ができませんが、これはあるはずのない余分なキーがあることによる例外的状況)。そして、日本語キーボードの [;+] キーと英語キーボードの [;:] の間に仮想キーコードの共通性が期待できないというのが今回の原因。そういう期待を抱かせないために、仮想キーコードにどう紛らわしくないラベルを貼り付けるかというのが課題。UI の多言語対応とは切り離されるべきキーボードの使い分けに関する問題で、でも現在は STR_KEY_BIND_HAT_ENG_QT や STR_KEY_BIND_AT_ENG_BQ という識別子に見られるようにおそらく UI の多言語対応とくっついてしまっている。その結果の苦肉の策が「^(英語')」「@(英語`)」という、日本語のラベルに付随する英語キーボードの刻印です。

人的リソース以外の理由で、現状に即した対応をせずに据え置きたい理由があるとは飲み込めません。

[berryzplus]

噛み合いませんね。

すみません。どこで食い違っているのかよくわかっていません。

人的リソース以外の理由で、現状に即した対応をせずに据え置きたい理由があるとは飲み込めません。

据え置きたい理由は人的リソースがもったいないからです。
@ds14050 さん の指摘通り対応すれば、見た目動いてそうな状態にできると思います。
しかし、ぼくは現在の sakura_lang_en_US.dll と CSelectLangクラス の方式が、
今後英語以外の言語に対応していくうえで正しいかどうか検証すべきだと考えています。
その過程で、せっかく対応した内容が無駄になってしまうようではもったいないなぁ、という話です。

正確な情報ではないかも知れないんですが、
windowsは接続されたキーボードが日本語なのか英語なのか判別できていません。
判別できない代わりに、入力された物理キーコードをキーボードレイアウトに従って仮想キーコードに変換する機構を持っています。

考えてみてください。
もし判別できるのであれば、何故インストール時にキーボードの種類をきかれるんでしょうか？
106/109キーボード(日本語)なのか、101キーボード(英語)なのか。

コンパネから入力言語を追加して英語モードに切り替えた場合、
キーボードの入力レイアウトが101キーボードになります。
画面表示は日本語のまま、入力モードだけが英語になります。
逆もあります。英語表示の状態で入力言語「日本語」を追加して日本語モードに切り替えた場合、
キーボードの入力レイアウトは106キーボードになります。
画面表示は英語のまま、入力モードだけ日本語になりIMEが有効になります。

物理キーコードを仮想キーコードに変換する、という処理の性質上、
windowsは現在の入力レイアウトにどんなキーがあるかを把握しています。
当然、この情報にプログラムからアクセスすることは可能です。
アクセラレータの情報を、入力レイアウトによって動的に組み替えるような処理も可能です。
現状は、表示情報の日英切替を試みるのに精一杯でそこまで手が回っていない状態です。

UI の多言語対応とくっついてしまっている

結局、それが本質なのかも知れません。

鍵面に「つ」と出てるなら「つ」でいいじゃん、といえばそれまで。
英語モードに変わったとたん「Z」に変換する必要はないような気もします。
そのあたりは、どっちで出したいか個々のユーザが決められるのが理想なはず。
入力レイアウトはロケール情報の一部でもあるので、
多言語対応を考えるなら話題に出るものだと考えています。

自分で探したものじゃないんですが、旧掲示板にこんなログがあったみたいです。

http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=dev&tree=s5723#5723
[5715] Re2:英語版 (求むreviwer)

多言語対応と切り離して本件の対応を進めることを止めはしないです。
いまここでぼくが語ったような内容をさらに整理して、何が問題か、どんな対処策があるか、どの方法を採るか、何故そうするかを具体的に説明していただければ受け入れもできると思ってます。

[kobake]

Win10ならコンパネで入力言語を追加できるはず。物理的には英語キーボードじゃなくてもOSがエミュレートしてくれます。

ちなみに僕の環境はPCはハードウェア的には日本語キーボードですがOSのシステムロケールは英語にしてます。キーボード配列とシステムロケールは別軸の概念という認識。

P.S.
USキーボード興味あったので安いやつ買っちゃいました (`ェ´)ﾋﾟｬｰ

[ds14050]

見た目動いてそうな状態にできると思います。

見た目(キー割り当てのラベル)の修正提案ですから当然です。

そしてそこからですけれど、UI の多言語対応はこの問題と無関係だと考えていますが勘違いでしょうか。無関係の問題を持ち出して問題を大きくしているように感じます。

先のコメントで STR_KEY_BIND_HAT_ENG_QT という識別子を持ち出して UI の多言語対応と関連があるかのように書きましたが、その定義を確かめたところ "^(英語')" と "^(EN KBD ')" を切り替えるだけのものでした。「英語」と「EN KBD」を切り替えるだけでその内容は同じ。

仮想キーコードの下に物理キーコードというものがあることを自分は認識していませんでしたけれど、berryzplus さんは物理キーコードを読んで TranslateAccelerator に渡す前に独自に仮想キーコードに変換することを目論んでいるのでしょうか。これも先の見通しのない大きな問題を持ち出して、目前の小さな問題を先送りしているように感じます。

サクラエディタは日本語キーボードにしか対応していないのではないですか？ おそらく VK_XXX などと事前定義された以外の仮想キーコードを利用した時点でキーボード言語依存性が生じるでしょう。STR_KEY_BIND_HAT_ENG_QT と STR_KEY_BIND_AT_ENG_BQ がそうですし、; と : にも事前定義がありません。そしてキーボードの切り替えに対応して仮想キーコードをあれこれするコードは全くありませんよね？ 日本語キーボードに固有の仮想キーコードしか想定していない。

多言語対応と切り離して本件の対応を進めることを止めはしないです。いまここでぼくが語ったような内容をさらに整理して、何が問題か、どんな対処策があるか、どの方法を採るか、何故そうするかを具体的に説明していただければ受け入れもできると思ってます。

対応策は最初に書きました。原因と解決すべき課題は１つ前に書きました。大それた考えは持っていません。(自分もちょっとだけ触れましたが)無関係な多言語対応を持ち出してストップをかけ、端緒にもついていない大きな話(物理キーコード)を持ち出したのは berryzplus さんです。これが「噛み合わないね」ということです。お互いに明後日の方向を向いて自分がそこにあると信じている問題だけを論じているんです。どちらが焦点を外しているかは知りません。

[berryzplus]

@ds14050 さん
ぼくも ds14050 さんもプロジェクトのメンバーです。

みんなが同じ考えで同じ方向に向かって進むのもチームの在り方の一つだと思います。
ぼくは、同じチームに別な考え方の人がいたっていいと思っています。
誠意をもって相手の言葉を理解するように努めれば、お互いにメリットがあると考えています。

ぼくもGitHubでのやり取りには慣れていません。
他の人のやり方を参考にして探り探りやってます。
https://qiita.com/umanoda/items/93aec41213f8e3ce14c8

結論を繰り返します。

多言語対応と切り離して本件の対応を進めることを止めはしないです。
いまここでぼくが語ったような内容をさらに整理して、何が問題か、どんな対処策があるか、どの方法を採るか、何故そうするかを具体的に説明していただければ受け入れもできると思ってます。

書き方がよくないのかも知れませんが「俺がやる！」で進めていただいて大丈夫です。

ぼくは自分がいま心配していることに基づいて「いまやるべきじゃない」と書きました。
現状PRのレビューをしているメンバーの中では、ぼくの基準はゆるい方だと思っています。
ぼくは、原因と対策、対策の効果と副作用が説明されている PR は受領すべきと考えています。

[berryzplus]

ぼく自身はこのやり取りに意義はあったと考えています。

@ds14050 さんのおかげで本件について理解を深めることができました。

本件の課題内容:
英語配列のキーボードで Alt + ; を入力すると 日付挿入ではなく時間挿入になる

原因:
日本語と英語でキーボードのスキャンコードが異なっているが、
アクセラレータの定義は仮想キーコードで指定されており、
スキャンコードの違いが考慮されていない。
※物理キーコード → (デバイスドライバが変換) → スキャンコード
　スキャンコード → (TranslateMessageが変換) → 仮想キーコードという関係

対策:
アクセラレータテーブルを作成する処理を変更すれば、おそらく対応可能。

https://github.com/sakura-editor/sakura/blob/b03ddd7acaa1a6f4cc1783a5dfbe3690b44db39b/sakura_core/func/CKeyBind.cpp#L92-L111

ここで MapVirtualKey 関数を使って仮想キーコード → スキャンコードの変換を行い、アクセラレータには変換で得られたスキャンコードを渡すようにすれば現在の入力ロケールに対応したショートカットが作れるようになるはず。もちろん、起動中に入力言語が変更されたときにアクセラレータを再作成する処理の追加も必要ですが。

多言語対応とはまったく切り離して進められそうですね・・・ :cry:
ぼく自身は保留になってるバグ修正の対応をすすめたいので
どなたか時間をとれそうな方に対応をお願いしたいです。> @ds14050 さん お願いできませんか？

[ds14050]

初めて話が噛み合った気がします。自分は MapVirtualKey 関数の存在を今初めて知りました。スキャンコードや物理キーコードについてもです。これが自分にとっての意義です。

@ds14050 さん お願いできませんか？

これですが、卑怯と言われようとも自分はやるとは言いません。それは意欲と知識と問題意識のある人が新機能としてインプリメントするものであって、これまでのサクラエディタの延長にはなく、この Issue のスコープからも外れていると考えるからです。

報告者は「日付挿入ではなく」という表現で望む結果を示していますが、キーボード種別が区別できるようになったとして、日本語キーボードの [;+] キーと英語キーボードの [;:] キーなど、一部の記号キーをあえて同一視することにハック以上の必然性や合理性が見いだせるでしょうか(反語ではありませんが否定的に見ています)。

berryzplus さんの考える対策は、日本語キーボードと US ASCII 配列のキーボードのどちらかが使えるだけでは満足できない、典型的日本人からは外れる人達の使い勝手を改善する、根本的に正しい処理かもしれませんが、それは別の話です。

[ds14050]

訂正。使い勝手が改善される対象は「典型的日本人からは外れる人達」ではありませんでした。(典型的日本人も含めて)複数種類のキーボードを切り替えて使う人達でした。

[ds14050]

いつか何かの参考になるかなと置いていきます。

たとえばキーボードの切り替えによりコロンの入力方法が [：＊] キー単独入力から [Shift]+[；：] の２キー入力に変わったとします。そのとき [Alt]+[：＊] に割り当てられていた機能が [Alt]+[Shift]+[；：] へ割り付けられるように、仮想キーコードを変換の上アクセラレータテーブルに登録します。こういう変換です。

仮想キーコード@日本語キーボード
→ 記号文字
→ 仮想キーコード@現在のキーボード

キートップの文字 (+[Ctrl]) (+[Alt]) で呼び出される機能が決まるため、[Alt]+[；：] や [Alt]+[Shift]+[；：] の実行結果が予測可能なものになります。

また、キー割り当て画面の「^(英語')」「@(英語`)」という、実用的ではあるがアドホックな併記が無用のものになります。しかしこれは仕様変更を意味します。

「キー割り当て」の GUI が、日本語キーボードの配列が目の前にない人にとっては使いにくいものになりますが、(^ を Shift すると何になるんだっけ？)、これまでは日本語キーボードの使用を要求していたようなものなので、一概に悪くなったとは考えていません。

translate_vkeycode.r1.txt

[kobake]

えーと、手元に英字キーボードが無かったものでこれまで傍観してましたが、最近USキーボードを入手しましたのでこの議論に参加させていただきます。

技術的な話がずいぶんと多く交わされているように見受けられたのですが、「要件がどうあるべきか」について意識は合っていますでしょうか。

まずは要件についての合意をとり、その後に技術の話をしたいです。

現在のサクラエディタのショートカットキーの割り当て

• Alt + ;　…　日付
• Alt + :　…　時刻

現在のショートカットキーの割り当て根拠

上述のような割り当てになっている根拠は、おそらく Microsoft Excel のショートカットキーの慣習を真似たものと想像しています。以下に Excel のショートカットキーを載せておきます。

Excel 日本語版でのショートカットキー割り当て

https://support.office.com/ja-jp/article/excel-for-windows-%E3%81%AE%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88%E3%82%AB%E3%83%83%E3%83%88-%E3%82%AD%E3%83%BC-1798d9d5-842a-42b8-9c99-9b7213f0040f

• Ctrl + ;　…　日付
• Ctrl + :　…　時刻

Excel では Ctrl との組み合わせになっているのに対して、サクラエディタでは Alt が用いられている根拠については良く分かりません。

Excel 英語版でのキーボードショートカット割り当て、、を紹介する前に

まず先にUSキーボードの外観を共有しておきます。
まぁこれはググればすぐ分かるのものでもあるのですが、この画像は僕の手元にある実際のUSキーボードのものです。

画像を見て分かるとおり、USキーボードでは「;」と「:」が同一キーに割り当てられています。
単純にこれらの文字を入力したい場合、「;」を入力したい場合には「;」をそのまま押下、「:」を入力したい場合には「Shift + ;」を押下することになります。

Excel 英語版でのショートカットキー割り当て

上記の話を踏まえた上で、Excel 英語版でのショートカットキーの割り当てを紹介します。
https://support.office.com/en-us/article/keyboard-shortcuts-in-excel-for-windows-1798d9d5-842a-42b8-9c99-9b7213f0040f

• Ctrl + ;　…　日付
• Ctrl + Shift + ;　…　時刻

上記を踏まえての対応方針の提案

提案1

USキーボード利用の際には以下のようなショートカットキー挙動をとるように対応する。

• Alt + ;　…　日付
• Alt + Shift + ;　…　時刻

提案2

本題よりややスコープを広げた話になってしまいますが、そもそもこれらのショートカットキーに Alt が用いられていることに違和感があります。

やや破壊的変更が許されるのであれば、今回の話に挙がっているショートカットキーについては完全に Excel に合わせてしまいたい気持ちが強いです。

• 日本語キーボードの場合の挙動
  
  
  
  • Ctrl + ;　…　日付
  
  
  • Ctrl + :　…　時刻
  
  
• USキーボードの場合の挙動
  
  
  
  • Ctrl + ;　…　日付
  
  
  • Ctrl + Shift + ;　…　時刻
  
  

ご意見ください

以上、どうでしょうか。

要件について既に暗黙的な合意がとられていたのだとしたらご容赦ください。
ただ、要件の意識はできるだけ自明に合わせた上で、技術の話に移りたいです。

[kobake]

たとえばキーボードの切り替えによりコロンの入力方法が [：＊] キー単独入力から [Shift]+[；：] の２キー入力に変わったとします。そのとき [Alt]+[：＊] に割り当てられていた機能が [Alt]+[Shift]+[；：] へ割り付けられるように、仮想キーコードを変換の上アクセラレータテーブルに登録します。こういう変換です。

ds14050 さんのこのコメントを見る限りは「Alt + Shift + ;　…　時刻」の意識を持っていることは汲み取れました、ということを追記しておきます。（それ以外の方が同じ意識を持っているかについては今の時点では自分から見ると不明）

[berryzplus]

キー割当の要件は考え直す必要があると思っています。

やるとしたら提案1の対応になります。アクセラレータ作成は元々動的作成なので、日本語セミコロンを英語コロン+shiftに動的に再構成する処理を組込みます。でもこれは、日本語キーボードで見た時のセミコロンにshiftキーとの組み合わせを使っていたら破綻します。日英で割当が違うキーはこれだけじゃないので、他のキーでも同じ問題が起こり得ます。

対策案として書きかけたことは、この問題を多言語対応の一部として捉え総合的に仕様を見直すということです。例えば、英語レイアウトのキー割当を用意して切替できるようにすれば動的振り替えで起こる衝突を回避できます。

割当が被ったらどうするか、現在のレイアウトであり得ない組み合わせが来たらどうするか、を決めておけば動的変換の対応はすぐに着手できます。

提案2については基本同意ですが、やるなら別件として話したいです。

[kobake]

対応は分割するとしても、提案2を見据えておくかやめておくかは早めに考えておきたいです。

というのは提案2を採用する場合には、対応順序としては先にCtrl対応をしてからその次に英字キーボード対応をしたいとかんがえているからです。

[ds14050]

Ctrl 対応というのが EXE 埋め込みの初期設定を変更することであれば特に意見はありません。

バージョンアップではエディタの使用に際して影響はありませんし、独自の設定を出すよりも長いものに巻かれておいたほうが覚えることが少なくて済みます。

コード上の変更点が静的データまわりに留まるので、先に Ctrl 対応をしたいという動機につながらず勘違いしているかもですが……。

提案１が実現しなければキーボード別に対応する手段がないので、提案２の Ctrl 対応はこういう結果にならざるをえません。

日本語キーボードの場合の挙動
    Ctrl + ；　…　日付
    Ctrl + ：　…　時刻
USキーボードの場合の挙動
    Ctrl + ＾　…　日付
    Ctrl + ；　…　時刻

これだけを先にやってしまいたい理由はわかりかねます(反対はしません)。

[kobake]

Ctrl 対応というのが EXE 埋め込みの初期設定を変更することであれば特に意見はありません。

EXE 埋め込みの初期設定ということで合ってます。

これだけを先にやってしまいたい理由はわかりかねます(反対はしません)。

言葉が足りてませんでした（というかまったく説明してませんでした）が、理由は以下です。

• (1) サクラエディタのユーザは日本語ユーザが多いはず
• (2) 結果、日本語キーボード利用者が多いはず
• (3) 「独自の設定を出すよりも長いものに巻かれておいたほうが覚えることが少なくて済みます」という意見に完全に同意で、そういう理由で Excel のショートカットキーに合わせておいたほうが嬉しい人が多い気がする
• (4) 英字キーボード対応についてはそれの恩恵を受ける人の数がそれほど多くない気がする
• (5) 上記理由により、(4) よりも (3) のほうを優先度高と考えたい

あと、おまけの情報としては「Alt + Shift + キー」というショットカットキーをあまり見たことがなかったので実装でハマったら嫌だな、という気持ちがあり、それも Ctrl 対応を先にやりたい理由のひとつでした。ですが、そういえば VS Code のショートカットキーで Alt + Shift + F でコード整形というのがあったのでこれについては懸念としては考えなくて良いところでした。

キーボードの特性上、確か同時押下が認識できない組み合わせというのがあった記憶があり、そういう理由であまり実績の無いキー組み合わせを採用したくない気持ちがありましたが、少なくとも上に挙げたように「Alt + Shift + キー」については問題なさそうなので、まぁこの理由については「こういうことを考えていたよ」程度のメモ程度に捉えてください。

[ds14050]

「Excel に合わせる」ということから Excel 英語版を除外せずに考えていましたが、それは参考情報で、Excel 日本語版が第一なんですね。それは納得できることです。自分の手元には参考画像を撮れるキーボードがありませんから。

こういう説明がありました>「キーボードの同時押しについて - forPCActionGamer Wiki*」 心配するほどのことではない気がしますし、修飾キーの組み合わせが認識できないようなキーボードは投げ捨てた方がいいでしょう。

[berryzplus]

説明してなかったので説明します。

割当が被ったらどうするか、現在のレイアウトであり得ない組み合わせが来たらどうするか、を決めておけば動的変換の対応はすぐに着手できます。

この中の、

現在のレイアウトであり得ない組み合わせ

がどういうことかについて。

セミコロンに割り当てられた機能の一覧

key | 機能名 | 関数名 | 機能番号 | マクロ記録可否
---- | ------ | ------ | -------- | --------------
Shift + Ctrl+; | 縦横に分割／分割解除 | SplitWinVH | 31312 | ×
Alt + ; | 日付挿入 | InsertDate | 30790 | ○

日本語レイアウトなキーボードのセミコロンは単独で押せるキーです。
英語レイアウトなキーボードのセミコロンは、Shift＋コロンで入力します。単独で押せないキーです。
言いたかったことは、日本語「Shift＋セミコロン」は英語キーボードではあり得ないってことです。
英語セミコロン＝「Shift＋コロン」で既にShift使ってるので、追加のShift+はどうする？になってしまう。

1. 捨てる（＝割り当てない）
2. ランダムに空いてる拡張キーの組み合わせにシフトさせる（＝動的に避ける）
3. 妥当なキー割り当てを検討する（＝被らないような初期値を決め直す）

個人的には「捨てる」が一番自然な動きと考えています。

懸案の変更 [Alt + ;] → [Ctrl + ;]については定数値を書き換えるだけなので、決めの問題の認識です。
https://github.com/sakura-editor/sakura/blob/cc8a4bd170174bd5e386dd290956dc3b68567c1f/sakura_core/func/CKeyBind.cpp#L800-L801

すでに割り当てられてる機能はどうしましょ？の議論なり、変更宣言なりが必要です。

[ds14050]

日本語 Shift+[：＊] は ＊記号を生成しますので、英語キーボードの Shift+[８＊] に割り当てます。Shift+コロン(：)を英語キーボードで割り当てることはできません。仮想キーコードを割り当てる対象としてそういう物理的なキーが存在しないためです。つまり最初から考える必要がない。

いかがでしょうか。

[ds14050]

キー割り当てをキーボード毎に持つことを避けたい理由について書きます。

• ini 形式が変わる。(仮想キーコードにキーボード種別を表すプリフィックスが付く。スキャンコードにするならなおのことキーボードを識別しなければコード値が意味を持たない)
• 
  
  • 項目を追加するのは簡単だが、割り当てのマイグレーションのために追加コードが必要。
  
  
• 
  
  • 盲腸のごとき旧データ形式を読み書きするコードをメンテナンスするのは楽しくないし、ミスが入っても発覚しにくい。
  
  
• 柔軟性とのトレードオフとして、キー割り当てをキーボード毎にカスタマイズしなければいけない。日本語キーボードの [A] キーと英語キーボードの [A] キーが区別できるとして、区別したいとは思わない。同一視するためにマッピングするならそれは Windows に任せたい(それって仮想キーコード)。
• 
  
  • 用意できるマッピングデータは日本語と英語(Dvorakではないスタンダードな配列)の間に留まるのではないか。
  
  
• キーボード種別毎の初期設定をでっちあげることもメンテナンスすることもできる気がしない。マッピングにより省力化するならそれは Windows に任せたい(それって仮想キーコード)。
• 
  
  • 用意できるマッピングデータは日本語と英語(Dvorakではないスタンダードな配列)の間に留まるのではないか。その他のキーボードで最低限の機能を維持できるだろうか。
  
  

今思いついたのは以上です。

[berryzplus]

言語別のレイアウトはメンテが大変そうですね。
INIのレイアウトを変えるのも大変そう。

現実案として、先頭から順に変換しつつ割り当てていき、被ったりあり得なかったりしたら「捨て」がいいのかな、と。

時間があいたら作って見ます。

[ds14050]

このコメントは FYI ということでよろしくお願いします。

セミコロン(；)とコロン(：)を正しく区別してください。最初から気になっていたので必ず記号を併記してきました。

被ったりあり得なかったりしたら「捨て」

これがどういう状況を指すのかがわかりません。#issuecomment-399733166 と同じことを指すのだと思いますが、それについて書いた #issuecomment-399738565 を理解してくだされば、少なくともどちらかが勘違いして間違っていることがわかります。ただ無視されたのなら悲しい。通じなかったのなら説明します。

サクラエディタのキー割り当ての設定画面を見てください。Shift を使って入力する以下の記号 !"#$%&'()=~|``{+*}<>? に(直接)機能を割り当てることができません。日本語キーボードのためにフィルタリングしているのではありません。機能を割り当てる対象となる仮想キーコードがないからです。記号の種類は変わりますがこれと同じことが英語キーボードでも起こります。「被る」や「あり得ない」状況がどのようにして起こるのか、本当に起こるのか、考えてみてください。

英語セミコロン＝「Shift＋コロン」で既にShift使ってるので、追加のShift+はどうする？になってしまう。

この漠然とした疑問を自分も最初は持っていましたが、berryzplus さんの一番最初のコメントよりも前に解消していました。コメントする前に時間をかけて CreateAcceleratorTable のドキュメントを読み、テストプログラムを書き、実験していたのです。時間があるからできることですが。

[berryzplus]

リンクをクリックしても該当コメントに飛んでくれないのでどのコメントの話をしてるか分かりませんでした。ブラウザのせいかなぁ…。

Shift+コロン(：)を英語キーボードで割り当てることはできません。仮想キーコードを割り当てる対象としてそういう物理的なキーが存在しないためです。つまり最初から考える必要がない。

~このコメントとほぼ同じことを考えています。~
「考える必要がない」を「捨て」と表現しました。

[ds14050]

「考える必要がない」を「捨て」と表現しました。

通じていてなによりです。

リンクをクリックしても該当コメントに飛んでくれない

ページ内リンクです。Firefox 52.8.0 では機能しています。[#issuecomment-399733166](#issuecomment-399733166) と書くよりスマートなコメントの参照方法があれば教えてください。

[KENCHjp]

Firefox 52.8.0 では機能しています。
Windows Chromeでも機能してます。

[berryzplus]

まとめときます。

課題内容

英語配列のキーボードで Alt + ; を入力すると 日付挿入ではなく時間挿入になる

絵で説明するよ！

1. サクラエディタには、日付挿入って機能があるっす。
   
   見たら分かると思うんですが、Alt + ; で発動できます。
2. 日付挿入機能を発動した場合、本来はこうなります。
   
3. ところが、入力言語が英語である場合に Alt + ; すると、こうなります。
   
   この現象に対する なんでやねん！ がこのissueの主題でした。

結局、なんでそうなるのよ？

https://github.com/sakura-editor/sakura/issues/116#issuecomment-397794665

原因:
日本語と英語でキーボードのスキャンコードが異なっているが、
アクセラレータの定義は仮想キーコードで指定されており、
スキャンコードの違いが考慮されていない。
※物理キーコード → (デバイスドライバが変換) → スキャンコード
　スキャンコード → (TranslateMessageが変換) → 仮想キーコードという関係

ん？引用してみたけど、この説明じゃ分かってない気配ですよね？

物理的な世界
キーボード　⇒　（電気信号）　⇒　パソコン

パソコンの中の世界
ドライバ　⇒　（スキャンコード）　⇒　ウインドウ
　　　　　　　　👆これが日本語と英語で違う。