hkcomori

Would you accept PR that solves this issue?

Sorry to bother you. Please review it, just a simple one.

機能追加してみたところ、以下のことは実現できました。 つまり、マウス操作に対して、キーボード操作を割り当てできます。 - 戻る/進むボタンに対応していないアプリにおいて、戻る/進む相当のキーボードショートカットを割り当て - 修飾キー+戻る/進む → タブや仮想デスクトップの切り替え等の機能を割り当て 一方、以下のような、マウス操作に別のマウス操作を割り当てることは、実現が難しそうです。 その理由は、 #39 が発生するためです。 回避策として紹介されている、マウスフックしたスレッドと異なるスレッドでSendInputする方法を試しましたが、キー操作から割り当てた操作が実行されるまでの遅延が大きく、実用するのは厳しいと感じました。 - 修飾キー+ホイール上下 → 通常のN倍速でスクロール - 修飾キー+ホイール上下 → 別の修飾キー+ホイール上下 に変更

@berty-b Thanks, it works fine! But language name is hidden...

I want this feature very much too. If we only write `H1`, it will work fine. Then, "YAML Title" creates `title` frontmatter key and "YAML Title Alias" adds same value...

@pjkaufman Yes, it would be great if the option could be one of `Title key`, `First H1`, `Filename`, `Title key or First H1 if Title key is missing or Filename...

@crftwr 様 内部ログは以下のとおりです。 ``` IN : D-LShift TRU : D-LShift IN : D-LS-LWin TRU : D-LS-LWin IN : D-LS-LW-Left OUT : [KeyDown(162), KeyDown(164), KeyUp(160), Key(37), KeyDown(160), KeyUp(162), KeyUp(164)] IN :...

ご検討ありがとうございます。 キー押下を優先している理由は理解しました。 `setInput_Modifier` のコードを拝見しましたが、キーリリースの前に Win と Alt の単体押しをキャンセルする処理が実装されています。 キャンセルの発動条件は、変換前後の修飾キーが以下の条件を満たすときになっています。 - Altのみ → 修飾キーなし - Winのみ → 修飾キーなし この発動条件を以下のように拡張すると、キーリリースを優先してもスタートメニューやメニューバーにフォーカスが移ることは無いと考えられます。 - Altのみ → Altを含まない - Winのみ → Winを含まない 私の環境で実際に試したところ、ご指摘の問題を発生させることなく、本問題を解消できることが確認できました。 この変更内容を Pull Request...

> I have done some refactoring. Please double-check. Thanks, nice refactoring. I found some descriptions that are no longer used and I removed them. I think it is a good...