Mery 3.1.0 試してみました

1. 腱鞘炎のなか、開発お疲れさまです。

   v3.1.0 を早速試してみました。
   左右の文書の遷移コマンドの追加、ありがとうございました🙇‍ タブバー上のスクロールでの遷移も以前のようになり、助かります。

   当バージョンの私の環境で気付いた点をご報告しておきます。

   ※いずれも Win 10 x64, ATOK で確認しています。Microsoft IME だと発生しません
   ※いずれも Mery 3.0.4 だと発生しません

   ■全角スペースをキー押しっぱなしで入力した場合の挙動について

   キャプチャ
   https://imgur.com/a/sBQuNq0

   全角文字を入力→Enterで確定した直後、キーを押しっぱなしのリピート入力で全角スペースを入力すると、ラグが起きたような挙動をします。

   上記キャプチャの3行目での入力が、その挙動です。
   全角スペース3文字目以降のリピート入力が、キーを離したタイミングで ﾄﾞﾊﾞｯ と表示されるような動きです。

   ■ATOK の IME 状態の小窓表示がカーソル位置に追従しない

   キャプチャ
   https://imgur.com/a/GylN9F8

   ATOK では全角／半角キーを押して IME 状態が切り替わると、状態を示す小窓が表示されます。
   この小窓の位置がカーソル位置に追従せず、直前の変換位置に固定されてしまいます。

   2020年9月17日 11:09  |  yuko  |  返信

2. ちなみに、今回 DirectWrite に大きく手が加わったようなので DirectWrite On/Off で状況を確認してみましたが、いずれの場合でもご報告と同じ動きになりました。

   2020年9月17日 16:12  |  yuko  |  返信
3. yuko さんの投稿 (2020年9月17日) への返信

   ご報告ありがとうございます。

   タブ関連の操作、うまく動いているようで安心しました😊

   ATOK を持っていないため、検証不足ですみません。とりあえず ATOK の体験版 Ver 31.1.9 をインストールして試してみました。

   > ■全角スペースをキー押しっぱなしで入力した場合の挙動について

   これは Ver 3.1.0 以前でも発生するようで、今回の修正内容とは関係なさそうです。

   調べてみたところ、ATOK は全角スペースを入力したときの負荷が非常に高く、そちらにリソースを奪われてしまい、画面の描画が追いつかない状態 (Windows 側から「再描画してイイヨ」のメッセージが来ない) になっているようです。

   全角スペースの入力だけでも高負荷なのですが、いただいた情報の通り「全角文字を入力 → Enter で確定した直後」という条件下ではさらに高負荷となるようです。

   同様の現象は Windows 標準のワードパッド、Sublime Text、Notepad++、Brackets などでも再現しました。

   上記以外のエディターでも、一応、描画はされるのですが、やはり全角スペースの入力速度は遅く、「全角文字を入力した直後」という条件下だとさらに遅くなる、という現象は発生するので、ATOK 側の問題である可能性が高いと思います。

   Mery 側で対応するとしたら強制的に再描画すればできないことはないのですが、Windows アプリとしては OS から「再描画してネ」というメッセージを受け取ってから再描画するのがお作法なので悩ましいところです。

   > ■ATOK の IME 状態の小窓表示がカーソル位置に追従しない

   これは心当たりがありました。

   今回、「その他、細かい修正」の中で、MS-IME の変換ウィンドウが微妙に入力中の文字に重なっていたので 3 ピクセルだけ下にずらしたのですが、どうやらそれで ATOK 先生のご機嫌を損ねてしまったようです😅

   元に戻したら小窓が正常にカーソル位置に追従するようになったので、なんだかスッキリしませんが、次のバージョンでは元に戻しておきますね。

   2020年9月17日 21:12  |  Kuro  |  返信
4. Kuro さんの投稿 (2020年9月17日) への返信

   > ATOK を持っていないため、検証不足ですみません。とりあえず ATOK の体験版 Ver 31.1.9 をインストールして試してみました。

   とんでもないです～
   むしろ、備え付けの Microsoft IME もだいぶ改善されてきた今、ATOK 使っている方が稀だと思いますｗ (こちらこそ ATOK ですみませんって感覚すらあります)

   > これは Ver 3.1.0 以前でも発生するようで、今回の修正内容とは関係なさそうです。
   > 同様の現象は Windows 標準のワードパッド、Sublime Text、Notepad++、Brackets などでも再現しました。

   あら、確認不足でしたね。すみません…😅
   当初再現しなかった気がするのですが、改めて確認したところ、その他のエディタでも再現しました。

   > Mery 側で対応するとしたら強制的に再描画すればできないことはないのですが、Windows アプリとしては OS から「再描画してネ」というメッセージを受け取ってから再描画するのがお作法なので悩ましいところです。

   上述の通り、ATOK ユーザーでかつ Mery を使っていて、全角スペースのリピート入力を多用する人の方が稀ですから、とりあえず他のユーザーさんからも声が上がるようなら検討、という立ち位置でよさそうな気がします。

   > 今回、「その他、細かい修正」の中で、MS-IME の変換ウィンドウが微妙に入力中の文字に重なっていたので 3 ピクセルだけ下にずらしたのですが、どうやらそれで ATOK 先生のご機嫌を損ねてしまったようです😅

   ええっ、そんなことあるんですね…。
   ATOK 先生、お厳しい。

   > 元に戻したら小窓が正常にカーソル位置に追従するようになったので、なんだかスッキリしませんが、次のバージョンでは元に戻しておきますね。

   ありがとうございます。お手数おかけします。

   2020年9月17日 22:52  |  yuko  |  返信
5. yuko さんの投稿 (2020年9月17日) への返信

   > むしろ、備え付けの Microsoft IME もだいぶ改善されてきた今、ATOK 使っている方が稀だと思いますｗ (こちらこそ ATOK ですみませんって感覚すらあります)

   そんなことないですよー。「入れた手のお茶」世代なので、ATOK にはずっと憧れています😁

   > 上述の通り、ATOK ユーザーでかつ Mery を使っていて、全角スペースのリピート入力を多用する人の方が稀ですから、とりあえず他のユーザーさんからも声が上がるようなら検討、という立ち位置でよさそうな気がします。

   ATOK に限ったことではないですが、テキストエディターとしては描画を優先するか、入力を優先するか、がポイントだと思います。

   当時は PC のスペックが低かったこともあって、テキストエディターの開発では、キーリピートの負荷をいかに軽減するか (数回に一度、描画を抑えるとか) は、ちょっとした技術でもありました。

   が、さすがにこのご時世、まさかキーリピートの負荷で描画が遅延することがあるとは思っていなかったので、興味深く、ちょっと色々なアプリに全角スペースを入力して確認してみました。

   ▼ 入力優先 (描画に遅延が発生する)
   Visual Studio 2019
   Sublime Text 3
   Notepad++
   ワードパッド
   Windows 10 のタスクバーの左側にある [ここに入力して検索]
   Chrome のアドレスバー
   Edge のアドレスバー
   Edge のテキストエリア
   Brackets (数回に一度、強制再描画？)
   Delphi の IDE
   OneNote
   Word
   Mery

   ▼ 描画優先 (描画に遅延が発生しない)
   Visual Studio Code
   Atom
   メモ帳
   E○Editor
   秀○
   サク○エディタ
   Chrome のテキストエリア
   エクスプローラーのアドレスバー
   一太郎

   と、こんな感じでした。

   入力優先のものは描画よりも入力を優先するため、キー入力の取りこぼしは最小限に抑えられると思います。

   描画優先のものは画面の描画が何らかの理由で遅延した場合は、キー入力の取りこぼしが発生する可能性があるのではないかと思います。

   しかしながら、最近のスペックの PC でそんなことがあるのかどうかはわかりません😅

   そういうわけで、アルファ版ですし強制再描画に変更してみるか、隠しオプションで切り替えられるようにするかといったところで検討してみたいと思います。

   2020年9月18日 23:54  |  Kuro  |  返信
6. Kuro さんの投稿 (2020年9月18日) への返信

   > 「入れた手のお茶」世代なので、ATOK にはずっと憧れています😁

   初めて聞きましたがアンサイクロペディアに載ってしまうくらい有名な揶揄みたいですねｗ

   アンサイクロペディアから引用

   "入れた手のお茶（いれたてのおちゃ）とは、マイクロソフトから発売された新しいお茶である。"

   > 当時は PC のスペックが低かったこともあって、テキストエディターの開発では、キーリピートの負荷をいかに軽減するか (数回に一度、描画を抑えるとか) は、ちょっとした技術でもありました。

   へぇ～、エディター開発、奥が (闇が？) 深そうです。
   それにエディターによっても考え方が異なるんですね。面白い。

   > 描画優先のものは画面の描画が何らかの理由で遅延した場合は、キー入力の取りこぼしが発生する可能性があるのではないかと思います。
   > そういうわけで、アルファ版ですし強制再描画に変更してみるか、隠しオプションで切り替えられるようにするかといったところで検討してみたいと思います。

   おおー、ありがとうございます。

   ちなみに描画優先によるキーの取りこぼしって、実際それが起こっているユーザー側からの見え方としては「リピート入力が少し遅くなる」って感じでしょうか？
   (「取りこぼし」って仰っているくらいなので、キーから手を離しても遅れてスペース入力が続く…ってことはないですよね)

   Kuro さんが調査してくださった、メモ帳、VSCode あたりで確認してみましたが、リピート入力が遅くなっているのか、体感では正直分かりませんでしたｗ
   この辺は PC スペックも影響するのかもしれませんが、そこれそ最近の PC では強制再描画でも影響がほぼ感じられないのかもしれませんね。

   私としては、少々の入力遅延がある程度ならば「リピート入力で今、何文字くらい入力しているか」が視認できる分、入力優先時の描画遅延の挙動よりも扱いやすいかなと思いました。

   2020年9月19日 8:25  |  yuko  |  返信
7. yuko さんの投稿 (2020年9月19日) への返信

   > 初めて聞きましたがアンサイクロペディアに載ってしまうくらい有名な揶揄みたいですねｗ

   ほんとだw なんだこれと思いましたが、読んでみるとそういう意味か！と思いました🤣

   MS-IME のこの誤変換を揶揄した ATOK のテレビ CM が普通に地上波で流れてたんですが、今じゃ怒られそうですね。

   > ちなみに描画優先によるキーの取りこぼしって、実際それが起こっているユーザー側からの見え方としては「リピート入力が少し遅くなる」って感じでしょうか？

   はい、再描画のためにリピート入力が少し遅くなることで、例えば同じように 10 秒間、キーを押しっぱなしにしたとすると、入力されるキーの数に差が出るのではないかと思った次第です。

   すみません、取りこぼしというと語弊がありますね。

   > 私としては、少々の入力遅延がある程度ならば「リピート入力で今、何文字くらい入力しているか」が視認できる分、入力優先時の描画遅延の挙動よりも扱いやすいかなと思いました。

   開発側としては、本来、キーリピートで入力されるべき数になるべく近づけたいと思ったのですが、おっしゃるとおり、別に時間を計ってキーリピートするわけでもないので、入力される数に差があったとしてもユーザーさんからすると関係ないですよね😅

   2020年9月19日 10:18  |  Kuro  |  返信
8. Kuro さんの投稿 (2020年9月19日) への返信

   > 開発側としては、本来、キーリピートで入力されるべき数になるべく近づけたいと思ったのですが、おっしゃるとおり、別に時間を計ってキーリピートするわけでもないので、入力される数に差があったとしてもユーザーさんからすると関係ないですよね😅

   入力と出力をあるべき姿に、というのを目指したくなる気持ちはお察ししますｗ

   VSCode では遅延が体感できなかったんですが、今、秀○で見てみたらやや遅くなってるのが分かりました。とはいえ気になるかと言われると、気にならないくらいでしたが。

   これ、日本語を始め IME が必要な言語特有の問題だから E○Editor、秀○、サク○エディタと、老舗日本語エディターでは表示優先の実装になってるのかもですね。(たまたまかもしれませんけど)

   > MS-IME のこの誤変換を揶揄した ATOK のテレビ CM が普通に地上波で流れてたんですが、今じゃ怒られそうですね。

   今では考えられない尖り方ですねｗ
   それにスタンドアロンなソフトで CM ってのも、今日日聞かないですねぇ…

   2020年9月19日 12:19  |  yuko  |  返信
9. Kuro さんの投稿 (2020年9月19日) への返信

   Win7 で Mery と秀○を併用している者です。 Win10 は未開封放置。
   全角スペースのキーリピートを両者で比べてみましたが、
   私には違いが全く分かりませんでした。

   ATOKの小窓表示も、下の行に「ひらがなで入力します」と出て、
   今の行に被さることはありませんでした。

   2020年9月21日 1:01  |  tisi  |  返信
10. tisi さんの投稿 (2020年9月21日) への返信

    追記です。
    カーソル移動調整は、Win7の場合、コントロールパネル⇒表示方法：アイコン⇒
    ⇒キーボード　で、速度調整が出来ます。Win10でも同じ機能があるのでは
    無いでしょうか?
    http://neo.vc/uploader/src/neo46630.png

    2020年9月21日 7:40  |  tisi  |  返信
11. tisi さんの投稿 (2020年9月21日) への返信

    IME や ATOK の挙動は OS によっても異なるので検証が大変なんですよね。

    Windows 7 だと問題ないとのことで、ご報告ありがとうございました。

    手元にある Windows 7 は Mery の開発環境のみで、ATOK 体験版などを入れることができない状態だったので助かりました。

    > ⇒キーボード　で、速度調整が出来ます。Win10でも同じ機能があるのでは無いでしょうか?

    キー入力の速度ですが、Windows 10 + ATOK の場合、全角スペースの入力だけやたら遅いという現象です。

    IME や Google 日本語入力だとすごく速い (ATOK の 5、6 倍ぐらい？) ので、OS の設定というよりは ATOK 側で何かしらの不具合が発生しているのではないかといった気がするのですが、謎ですね。

    2020年9月23日 22:23  |  Kuro  |  返信
12. Kuro さんの投稿 (2020年9月23日) への返信

    そういえば遅れてしまいましたが、白源のご紹介ありがとうございました！

    スクショを見る限り、バージョンアップに追随してインストールしていただいているようで、ありがとうございます🙇‍♂️
    これからもちまちまと更新していきます～

    2020年9月25日 15:33  |  yuko  |  返信
13. yuko さんの投稿 (2020年9月25日) への返信

    いいえ～、こちらこそ白源にはいつもお世話になっており、もはや白源のない生活なんて考えられないぐらいです。

    スクショだけでバージョンが分かるのはさすがです！

    ツイッターでチラっと拝見しましたが、カタカナとひらがなの「へ」が区別できるようになるのは素晴らしいことだと思いました。

    更新、楽しみにしています😊

    2020年9月25日 22:05  |  Kuro  |  返信
14. Kuro さんの投稿 (2020年9月25日) への返信

    ホームページの CSS、ダークテーマ対応したんですね！
    目に優しい😊

    これは Mery のダークテーマ対応にも期待が高まりますね！

    2020年10月2日 8:55  |  yuko  |  返信
15. yuko さんの投稿 (2020年10月2日) への返信

    > これは Mery のダークテーマ対応にも期待が高まりますね！

    うは、鋭いですね😁

    Mery のダークモード対応のため、しばらくの間ダークモードを使っていたところ目が慣れてしまい、ライトモードのアプリやサイトを見ると「目が！目がぁぁぁ！」となる体になってしまったので、当サイトもダークモードに対応しておきました。

    次のバージョンは、ダークモード対応です👍

    2020年10月2日 20:35  |  Kuro  |  返信
16. Kuro さんの投稿 (2020年10月2日) への返信

    > Mery のダークモード対応のため、しばらくの間ダークモードを使っていたところ目が慣れてしまい、ライトモードのアプリやサイトを見ると「目が！目がぁぁぁ！」となる体になってしまったので、当サイトもダークモードに対応しておきました。

    とても分かりますｗ
    背景暗いと目に優しいって、本当だったんだ…って実感しますよねｗ

    ダークな Mery、すごい楽しみです😊

    2020年10月4日 10:19  |  yuko  |  返信