直近で閉じたファイルを見つけやすくしてほしい
-
Kuroさん
メンテお疲れ様です。
ふと思い立った点があり、要望をしに来てしまいました。お暇なときに眺めていただければ幸いです🙇♂️
使用しているMery: ver 3.7.0
閉じたファイルを再度開きたい場面で、「最近使ったファイルの一覧」([ファイル] メニューから見られる履歴) が役に立つと思います。
この仕様としては、「開いたファイル順にトップに追加」になっていると推察しています。ただ以下のように、直近で閉じたファイルが見つけづらいケースがありました。
~仕事の場面を想像しつつ~
1. 朝イチに、ファイル A (本日のタスクリスト) を開く
2. 一日を通して、ファイル B、ファイル C、ファイル D.... と数多くのファイルを開いては閉じて、を行う
3. どこかのタイミングでうっかりファイル A を閉じてしまう
4. ファイル A を開き直したいが、ファイル B、ファイル C、ファイル D.... の履歴に埋もれてしまい、なかなか見つからないこれを解消するために「最近使ったファイルの一覧」に載る順序を調整していただけるとよさそうだと想像しました。
具体的には、現在の「開いたときに履歴のトップに載せる」にプラスして新たに「閉じたときにも履歴のトップに載せる」ようにする、といった仕様ですが、いかがでしょう?
(ちなみにサクラエディタと秀丸を観察してみたところ、上記の仕様になっているように見えました)
| yuko | 返信 -
関連の要望、失礼します。
ショートカットキーで「閉じたファイルを開く」というのが欲しいと思ってました。うっかり閉じてしまったものをすぐに復旧するためです。
現状では、ファイル履歴から選択しています、| TN24 | 返信 -
>> yuko さん、TN24 さん
ご意見ありがとうございます。
サク〇エディタさんと秀〇エディタさんを試してみました。なるほど、ファイルを開いた時と閉じた時に履歴の先頭に来るようですね。
個人的には少し使いづらいかもしれません…😅
ファイルを開いた順番はなんとなく覚えていますが、閉じた順番までは把握する習慣がないもので、次回作業を再開するときに混乱してしまいそうです。
また、[全終了] を選択してしまった場合、開いた順番が機械的に閉じられた順番に並び替わってしまい、戸惑いました。
ちなみに、VS Code、Visual Studio 2022、E〇Editor さんは開いたときの履歴のみを保持。Sublime Text は閉じたときの履歴のみを保持しているようです。
開いた順番や閉じた順番、片方だけならわかりやすいですが、両方が混在すると、使い勝手が落ちるように感じました。
もちろん、誤って閉じてしまった場合は、履歴の一番上に表示されるのは助かると思いますが。
ただ、ファイルを閉じるというのは、もう使用しないからということですので、必要のないファイルが最近開いたファイルを押しのけて先頭に上がってくるのは少し微妙な印象です。
特に、誤操作という特殊な状況への対応という観点から考えると、履歴をごちゃごちゃにするよりも、TN24 さんのアイデア、[最近閉じたファイルを開く] コマンドの方がシンプルで分かりやすいかなと感じました。
| Kuro | 返信 -
Kuroさん
> 個人的には少し使いづらいかもしれません…😅
> ファイルを開いた順番はなんとなく覚えていますが、閉じた順番までは把握する習慣がないもので、次回作業を再開するときに混乱してしまいそうです。おや、そうでしたか🙄
私の場合はファイル履歴は「直近で閉じたもの」に対して利用する意識なので悪くない仕様に思えましたが、個人的な感覚の差が出る部分なのかもしれませんね。> また、[全終了] を選択してしまった場合、開いた順番が機械的に閉じられた順番に並び替わってしまい、戸惑いました。
なるほど、「開いた順番で見たい」といった意識でいる場合には、確かに違和感出ますね。
> ちなみに、VS Code、Visual Studio 2022、E〇Editor さんは開いたときの履歴のみを保持。Sublime Text は閉じたときの履歴のみを保持しているようです。
> 特に、誤操作という特殊な状況への対応という観点から考えると、履歴をごちゃごちゃにするよりも、TN24 さんのアイデア、[最近閉じたファイルを開く] コマンドの方がシンプルで分かりやすいかなと感じました。たしかに、それでも全然アリかと思います!
VSCodeでは「表示: 閉じたエディターを再度開く」という Ctrl+Shift+T で割り当たっている機能に近いイメージでしょうか。これはブラウザの Ctrl+Shift+T と同様の動作なので、割と好みです。
VSCodeだと複数タブを閉じた場合にはLIFO順で取り出すキューになっているようですね。ウィンドウを開いている間のみ保持する一時キューになっており、ウィンドウを閉じるとこの「閉じたエディターの履歴」はクリアされるようです。| yuko | 返信 -
Tag機能を使えばマクロでも実現できそうだなと思い、作ってみました。
標準機能となればそちらの方が誰でも簡単に使えるので、もしMery側で実装されれば不要ですが、ちょっと試してみましたということで。■ファイルを閉じたタイミングでファイルパスを記録・保持するマクロ
※[マクロ > カスタマイズ > イベント] で [文書を閉じた時] に設定する前提#title = 閉じたファイル履歴を記録する var TAG_NAME = 'ClosedFileHistory'; main(); function main() { var closedFile = document.FullName; // 閉じたファイルが存在しない場合は何もしない if (closedFile == '') { return; } if (!Tag.exists(TAG_NAME)) { // 閉じたファイルを記録する (初回) Tag(TAG_NAME) = [closedFile]; } else { // 閉じたファイルを記録する (2回目以降) var closedFileHistory = Array.prototype.slice.call(Tag(TAG_NAME)); closedFileHistory.push(closedFile); // 特定個数以上になったら古いものから削除する if (closedFileHistory.length > 30) { closedFileHistory.shift(); } Tag(TAG_NAME) = closedFileHistory; } }
■上記で記録されるファイル履歴を元にファイルを開き直すマクロ
※こちらは上記と違い、直接マクロを実行する前提#title = 閉じたファイル履歴からファイルを開き直す var TAG_NAME = 'ClosedFileHistory'; main(); function main() { // 閉じたファイル履歴が存在しない場合は何もしない if (!Tag.exists(TAG_NAME) || Tag(TAG_NAME).length == 0) { return; } // 最後の要素を取り出して開く var closedFileHistory = Array.prototype.slice.call(Tag(TAG_NAME)); path = closedFileHistory.pop() // ファイルが存在しない場合は次のファイルパスを取得 while (!shell.FileExists(path) && closedFileHistory.length > 0) { path = closedFileHistory.pop(); } editor.OpenFile(path, meEncodingNone, meOpenAllowNewWindow) // 最後の要素を取り出した後の配列を保存する Tag(TAG_NAME) = closedFileHistory; }
>> Kuroさん
上記を設定するにあたり、いくつか文言周りで気になった点があったので一応共有させていただきますね。
(1)
[マクロ > カスタマイズ > イベント] で、[文書を閉じた時] のように "文書" という表現がありますが、イベントの並びに [ファイルを開いた時] のように "ファイル" という表現もあります。
何らか仕様的な違いがあって表現を分けているなら問題ありませんが、同じ意味合いならどちらかに寄せた方がよさそうです (個人的には "ファイル" の方が好み)(2)
[マクロ > カスタマイズ > イベント] の [文書を閉じた時] イベントについて、表現から受けた印象で「閉じた後にマクロ発動かな?閉じた後の発動であれば、閉じたファイルのファイルパスを取ることはできないかも…」と考えたのですが、実際には問題なく閉じたファイルのファイルパスを取ることができました。
ということは、実際には、「閉じる直前にマクロが発動するイベント」なんだと推測しています。それならば [ファイルを保存する前] イベントに似た表現を使って [文書を閉じる前] OR [ファイルを閉じる前] というイベント名の方が厳密だと思いました。(3)
以下のWikiの表現が、やや仕様と合っていないように思いました。https://www.haijin-boys.com/wiki/マクロリファレンス:3:Editor_オブジェクト#OpenFile_メソッド
> OpenFile メソッド
> meOpenAllowNewWindow 現在の文書が変更されている場合に新しいタブまたはウィンドウで開きます。使ってみたところ、実際には、現在の文書の変更有無に関わらず新しいタブで開きました。
現状の動作が望ましいと思いますので、Wikiの方を修正いただくのがよさそうかと思います。| yuko | 返信 -
> VSCodeでは「表示: 閉じたエディターを再度開く」という Ctrl+Shift+T で割り当たっている機能に近いイメージでしょうか。
なるほど、VS Code にはそのような機能があるんですね。
単に直前に閉じたファイルを再度開くだけかなーと思っていましたが、VS Code は閉じたファイルの履歴を保持しているんですね。
思ったよりも複雑そうですね…😅
> これはブラウザの Ctrl+Shift+T と同様の動作なので、割と好みです。
もしもこれでご希望の仕様を代替できるなら、[閉じたエディターを再度開く] の機能追加を検討してみたいと思います。
> Tag機能を使えばマクロでも実現できそうだなと思い、作ってみました。
早いですね!😂 私はまだ何もできていません。今から Mery の様子を見てみようかと思っていたところでした。
> (1)
> [マクロ > カスタマイズ > イベント] で、[文書を閉じた時] のように "文書" という表現がありますが、イベントの並びに [ファイルを開いた時] のように "ファイル" という表現もあります。Mery では、「ファイル」と「文書」の表現が使い分けられており、「ファイル」は物理的なファイルを指し、「文書」は編集中の画面を指します。
「文書」という表現は、「次の文書」コマンドなどでも使われています。
[文書を閉じた時] のイベントは、ファイルだけでなく無題のタブを閉じた時にも発生するイベントなので、そのような名前になっています。
> (2)
> [マクロ > カスタマイズ > イベント] の [文書を閉じた時] イベントについて、表現から受けた印象で「閉じた後にマクロ発動かな?閉じた後の発動であれば、閉じたファイルのファイルパスを取ることはできないかも…」と考えたのですが、実際には問題なく閉じたファイルのファイルパスを取ることができました。閉じたファイルのパスを取得できないと、[文書を閉じた時] イベントの活用の幅が制限されてしまいますので、その点は柔軟に対応しています。
たとえば、他にも、[ファイルを保存する前] イベントはファイルを保存する前に発生しますが、新規のファイルのパスも取得できるようになっていたりします。
ちなみに、[文書を閉じた時] イベントは、閉じた後に発動で合ってます。正確に言うと、閉じた後、破棄される直前に呼ばれるイベントです。
文書を閉じた後のイベントなので、たとえば、editor.documents.Count は、文書が閉じた後の数を返しますし、もちろん、閉じる処理をマクロからキャンセルすることもできません。
[文書を閉じる前] イベントにするなら、[文書を閉じた時] イベントとは別に、閉じる前のタイミングで適切に呼ばれるイベントを用意する必要があります。
> (3)
> 以下のWikiの表現が、やや仕様と合っていないように思いました。
> OpenFile メソッド
> meOpenAllowNewWindow 現在の文書が変更されている場合に新しいタブまたはウィンドウで開きます。
> 使ってみたところ、実際には、現在の文書の変更有無に関わらず新しいタブで開きました。具体的には、現在の文書が無題でないか、変更されている場合には新しいタブまたはウィンドウで開きます。
つまり、現在の文書が新規に作成された無題の文書で、かつ、変更されていない場合は、現在のタブで開きます。
簡単に言うと、通常のメニューからファイルを開いた場合と同じ動作ですね。
上記の説明でもわかりにくいかもしれませんが、Wiki に追記しておきますね。
| Kuro | 返信 -
> もしもこれでご希望の仕様を代替できるなら、[閉じたエディターを再度開く] の機能追加を検討してみたいと思います。
はい、TN24さんの希望もありましたし、そちらでお願いできれば嬉しいです😊
> Mery では、「ファイル」と「文書」の表現が使い分けられており、「ファイル」は物理的なファイルを指し、「文書」は編集中の画面を指します。
ああー、なるほど。無題ドキュメントも含めた、「物理ファイル+α」な表現ということだったんですね。これは思い至らず失礼しました。
> 閉じたファイルのパスを取得できないと、[文書を閉じた時] イベントの活用の幅が制限されてしまいますので、その点は柔軟に対応しています。
こちらもなるほどですね。利便性のためにほどよく柔軟にしているということで了解しました。
> 簡単に言うと、通常のメニューからファイルを開いた場合と同じ動作ですね。
> 上記の説明でもわかりにくいかもしれませんが、Wiki に追記しておきますね。お手間をおかけします。ありがとうございます🙇♂️
| yuko | 返信 -
Kuroさん、こんにちは。
Mery Ver 3.7.1でキーボード ショートカットの [ファイル] カテゴリに [最後に閉じたファイルを開く] コマンド (Ctrl + Shift + T) が追加されましたが、よく誤クリックしてファイルを閉じてしまうので、このキーボードショートカットは便利ですね。
それで、1点気になったことがあります。
それは、複数ファイルを開いている状態で、ある1つのタブの×ボタンをクリックした後、1度何かの操作(左クリックなど)をしてから「Ctrl + Shift + T」を使用しないと、最後に閉じたファイルが開きません。
なお、2回連続でタブの×ボタンをクリックした後であれば、何かの操作を挟まなくても「Ctrl + Shift + T」が発動しました。
よって、確認したいのですが、ある1つのタブの×ボタンをクリックした後、1度何かの操作を挟まないと「Ctrl + Shift + T」が発動しないのは仕様でしょうか?
【環境情報】
Mery: 3.7.6 (x64)
Onigmo: 6.2.0
C/Migemo: 1.3
Tidy: 5.8.0
Hunspell: 1.7.1
アウトライン: 3.2.1 (Outline.dll)
OS: Windows 11 (Version 23H2, OS Build 22631.4169, 64-bit Edition)| MSY-07 | 返信 -
こんばんは。ご報告ありがとうございます。
いただいた条件で現象を再現できました。どうやらこれは仕様ではなさそうですね。
> Mery Ver 3.7.1でキーボード ショートカットの [ファイル] カテゴリに [最後に閉じたファイルを開く] コマンド (Ctrl + Shift + T) が追加されましたが、よく誤クリックしてファイルを閉じてしまうので、このキーボードショートカットは便利ですね。
開発になかなか苦労した機能なので、そう言っていただけると嬉しいです。
ただ、私自身は実装してから一度も使ってなかったので、全然気づいていませんでした… ^^;
次のバージョンで修正できるよう、調査してみますね。
| Kuro | 返信 -
Kuroさん、ご返信ありがとうございます。
> 開発になかなか苦労した機能なので、そう言っていただけると嬉しいです。
Google Chromeでも同じキーボードショートカットをよく使っているので、同じ感覚で使えるのはいいですね。
> 次のバージョンで修正できるよう、調査してみますね。
ご対応よろしくお願いします。
| MSY-07 | 返信 -
Kuroさん、Ver 3.7.7のリリースお疲れさまでした。
Ver 3.7.7を確認しましたが、タブを閉じた直後に [最後に閉じたファイルを開く] コマンドが動作するようになり、誤って閉じたファイルをすぐに開けるようになりました。
ご対応いただきありがとうございます。
| MSY-07 | 返信 -
ご確認ありがとうございます。少し手間取ってしまいましたが、無事に動作していると聞いて安心しました。
| Kuro | 返信 -
Kuroさん、こんにちは。
[最後に閉じたファイルを開く] コマンド (Shift + Ctrl + T) を使用していたら、気になる動きがあったので報告します。
Ver 3.7.7でタブの×ボタンをクリックしてファイルを閉じた後に [最後に閉じたファイルを開く] コマンドを使用すると、ファイルの先頭部分が一瞬だけ見えた後、前回ファイルを閉じたときのカーソル位置に移動します。
https://imgur.com/gallery/mery-ver-3-7-7-UIiEWhr
なお、Ver 3.7.6で [最後に閉じたファイルを開く] コマンドを使用した場合、ファイルの先頭部分が見えることはなく、最初から前回ファイルを閉じたときのカーソル位置に移動します。
https://imgur.com/gallery/mery-ver-3-7-6-37Luvhq
[最後に閉じたファイルを開く] コマンド自体は正常に機能するので問題はないのですが、画面がちらついて見えるので少し気になります。
よって、[最後に閉じたファイルを開く] コマンドを使用したとき、ファイルの先頭部分が見えないようにできないでしょうか?
【環境情報】
Mery: 3.7.7 (x64)
Onigmo: 6.2.0
C/Migemo: 1.3
Tidy: 5.8.0
Hunspell: 1.7.1
アウトライン: 3.2.2 (Outline.dll)
Markdown プレビュー: 1.0.7 (MarkdownPreview.dll)
OS: Windows 11 (Version 23H2, OS Build 22631.4460, 64-bit Edition)| MSY-07 | 返信 -
ご報告ありがとうございます。
これは不具合ではなく、Ver 3.7.7 での仕様変更によるものですね。
これまでは、ファイルを開いた際にカーソル位置までスクロールするとき、画面を一時的にフリーズさせていました。
ただ、この方法だと、ファイルの読み込みが遅く感じられる場合があったり、バイナリファイルを開いて警告ダイアログが表示される際に画面が真っ白な状態になるケースが発生していました。
こうした問題を解消するため、Ver 3.7.7 ではフリーズ処理を廃止し、よりスムーズに画面が動くよう仕様変更しました。
気になるということでしたら、従来の仕様に戻すことも検討してみたいと思います。
| Kuro | 返信 -
> これは不具合ではなく、Ver 3.7.7 での仕様変更によるものですね。
仕様変更でしたか、失礼しました😅
> これまでは、ファイルを開いた際にカーソル位置までスクロールするとき、画面を一時的にフリーズさせていました。
>
> ただ、この方法だと、ファイルの読み込みが遅く感じられる場合があったり、バイナリファイルを開いて警告ダイアログが表示される際に画面が真っ白な状態になるケースが発生していました。
>
> こうした問題を解消するため、Ver 3.7.7 ではフリーズ処理を廃止し、よりスムーズに画面が動くよう仕様変更しました。確かにVer 3.7.7の方がファイルの読み込みが早いですね。
また、バイナリファイルを開いて警告ダイアログが表示される際に画面が真っ白な状態になるのは使い勝手が良くないですね。
> 気になるということでしたら、従来の仕様に戻すことも検討してみたいと思います。
気になるといっても多少というレベルですし、それよりは上記の問題への対処の方が大事ですので、Ver 3.7.7の仕様の方が良いですね。
| MSY-07 | 返信 -
ご返信ありがとうございます。
> 気になるといっても多少というレベルですし、それよりは上記の問題への対処の方が大事ですので、Ver 3.7.7の仕様の方が良いですね。
そうなんですよね。その後、ちょっと気になることがあったので、もう少し詳しく調べてみました。
まず、ファイルを開いたときに「ファイルの先頭がチラッと見える」現象ですが、これって [最後に閉じたファイルを開く] に限らず、普通にファイルを開くときでも起きるんですよね。
前回もお伝えしたように、ファイルを開いたときに画面を一瞬フリーズさせる仕様のおかげで、スクロールが見えなくなっていたのは事実なんですが、実はこの仕様が効いているのは「新しいタブでファイルを開いた場合」だけなんです。
なので、Ver 3.7.6 でも無題タブでファイルを開いた場合には、Ver 3.7.7 と同じように「ファイルの先頭がチラ見えする」現象は起きていました。
ここからが本題ですが、アウトラインプラグインをオフにした状態だと、この現象が発生しないみたいなんです。
どうやら、ファイル読み込み中にプラグインにイベントメッセージを送信しているのですが、このイベントを受けたアウトラインプラグインの処理がトリガーになっているようです。
ただ、これはアウトラインプラグインだけの問題ではなく、他のプラグインでも起こりうる話なので、プラグイン側を直せば解決!ってわけにもいかないんですよね…。
そこで、本体側の仕様をちょっと変更してみてはどうかなと考えました。
具体的には、ファイル読み込み中ではなく、読み込み完了後にプラグインイベントを呼び出すようにする方法です。これなら、少なくともこの現象をある程度は回避できそうです。
とはいえ、プラグイン側で割り込み処理をされちゃうと防ぎきれないので、完全な解決策ではないのですが…😓
| Kuro | 返信 -
ご返信ありがとうございます。
> ここからが本題ですが、アウトラインプラグインをオフにした状態だと、この現象が発生しないみたいなんです。
私の方でもアウトラインプラグインをオフにして確認してみましたが、確かに上記の現象が発生しないですね。
> そこで、本体側の仕様をちょっと変更してみてはどうかなと考えました。
>
> 具体的には、ファイル読み込み中ではなく、読み込み完了後にプラグインイベントを呼び出すようにする方法です。これなら、少なくともこの現象をある程度は回避できそうです。
>
> とはいえ、プラグイン側で割り込み処理をされちゃうと防ぎきれないので、完全な解決策ではないのですが…😓完全な解決策ではないとしても、上記の現象が少しでも解消されるのであれば嬉しいです😊
| MSY-07 | 返信 -
Kuroさん、Ver 3.7.8のリリースお疲れさまでした。
プラグイン イベントの EVENT_MODE_CHANGED を遅延呼び出しに変更したことで、アウトラインプラグインがオンの状態で「新しいタブでファイルを開いた場合」に「ファイルの先頭がチラ見えする」現象が発生しなくなりました。
これで、[最後に閉じたファイルを開く] コマンドを快適に使用することができるようになりました😄
ご対応いただきありがとうございます。
| MSY-07 | 返信 -
ご確認いただきありがとうございます。
うまく動いているようで安心しました😊
> これで、[最後に閉じたファイルを開く] コマンドを快適に使用することができるようになりました😄
いえいえ、こちらこそ。ご報告のおかげで、フリーズ処理の廃止によるファイル読み込み速度の高速化に加え、チラつきも解消され、快適な動作が実現しました。
それに、動画付きでご説明いただいたおかげで、アウトライン プラグインの影響だと気づけました。本当に助かりました🙇♂️
| Kuro | 返信 -
> それに、動画付きでご説明いただいたおかげで、アウトライン プラグインの影響だと気づけました。本当に助かりました🙇♂️
文章だけだと現象が分かりづらいですからね。
今回、画面録画を撮るために初めてClipchampを使用しましたが、撮影した後の編集が楽で良かったです😊
| MSY-07 | 返信