D.Miwa

> 前と同じ設定でやりたいと思った場合に履歴を見てもぱっと見でどれが該当するのか思い出せない これは私も同じことを思うことがあります。 置換前のパターン文字列をコンボボックスの履歴から選んだ時に、当時ペアだったパターン文字列 (の最も新しいもの) が置換後コンボボックスに自動的に入るようにする ~~(逆もしかり)~~、というような方法でも不便を解消できそうな気がしました。 これは例えば、過去に A -> Alpha, B -> Bravo, C -> Charlie という 3 セットの置換が実施されていたとして、置換前コンボボックスで「B」を選択したら置換後コンボボックスは「Bravo」が選択された状態になる、 ~~逆に置換後コンボボックスで「Charlie」を選ぶと置換前は「C」が選ばれる。~~ という動作を想定しています。 →逆の動作は不要ですね

> 前と同じ設定でやりたい ある一連の操作に対して名前を付けて保存しておき後で再利用する。これは既存機能の「キーマクロ」で実現できそうですね。 ※キーマクロという名前ですが置換ダイアログから実施した内容も記録されます 初回： 1. 「キーマクロの記録開始」(メニュー -> ツール) を選択 2. 置換ダイアログを使って置換を実施 3. 「キーマクロの記録終了＆保存」を選択 二回目以降： 4.「キーマクロの読み込み」を選択 5.「キーマクロの実行」を選択

良いと思います。 VisualStudio のフォント設定画面は現在のフォント設定が一覧できない点は不便だと思うため、ListView にして項目名と共にフォント名やポイント数を表示したいですね。 あと、リストの各項目にチェックボックスがあり選んだ項目をまとめて変更する機能があると「改善したいこと」の「2」がさらに解消されそうです。

@beru さん @kazasaku さんにコメント頂いたアイデアを取り込みつつ、ダイアログのイメージを作ってみました。 ※「まとめて変更機能」は一旦保留にしました  イメージの補足： * 「システムフォント」はタイトルバーやメニューで使われているフォントのことです。 * 「メイン」は現在のフォント設定ダイアログで設定されたフォントのことです。 * 「エディタと同じフォント」は現在表示中のファイルに対するタイプ別設定で個別指定があればそれ、なければメインのフォントになります。 思っていること： * このダイアログ上で直接フォント名やポイント数を設定できる UI だと便利そうですが、まずは既存のフォント設定ダイアログを呼び出す形でもそれほど不便はないのではと思いました。 * 題名は「フォント設定集約」としているものの、例えば印刷ページ設定がそうですが、それぞれの場所で設定できた方が使い勝手の良いケースもあると思いますので、既存の設定箇所を必ずしも廃止する必要はないと考えています。

セルフツッコミですが、「メイン」の設定をしている時にラジオボタンで「エディタと同じフォントを使う」が選択できてしまうと設定参照が無限ループしてしまうので、これは無効にすべきですね。

> 改めて考えると、タイプ別設定のスクリーンタブにあるフォント設定を、メニューバーにあるフォント設定からできるようにしたいということではないかと思いますので、印刷ページやタブバーはこのままで良いのかもしれません。 ユーザーが「○○のフォントを変えよう」と思い立った時に、真っ先に向かうだろう場所が「設定->フォント設定」かなと考えていまして、そこではタブバーも含めアプリケーション内で扱うすべてのフォント設定が一覧でき変更も可能であって欲しいなという思いがありました。 ただ、「すべての」とは書きましたが印刷ページのフォント設定については印刷しようとする時にはほぼ目にするものと思いますので、これは含めなくても良いかもしれません。

> #1644 (comment) でコメントした際には std::vector を使う事でメモリの動的確保の頻度を減らせると考えていましたが、アウトライン解析 データ要素の関数名とファイル名のメンバーが文字列型でメモリを動的確保するので、あまり減らないかもしれません。 CFuncInfoArr::AppendData を多数呼び出す CDocOutline::MakeTopicList_txt へ CRunningTimer を使った計測処理を入れ、反映前後での処理時間を比較してみました。 ばらつきあるものの 10% 程度は速くなったようです。 (CDlgFuncList::SetData が圧倒的に時間がかかる (8秒程度) ので誤差のような処理時間ですけど……) CDocOutline::MakeTopicList_txt の処理時間 (ms)： | | PR 反映前 (2e01db296 + 計測処理)...

主題から少しずれますが…… 既定の上限値である 8 個はちょっと少ないかなと思ってしまいました。 この制限機能はおそらくユーザーがうっかり大量のファイルをドロップした時に、サクラエディタがハングアップ状態になることを防ぐためなのかなと思っていますが、現代の PC スペックを考慮するともう少し多くても良さそうな気がしました。

「問題内容」に掲載の画像の場合は `10 文字 (1 行) 選択中` が適当と思われます。 もし修正しても問題なさそうであれば PR を作ろうと思います。

> 実際に数えているのはwchar_tの数なので正しいと言えるか怪しいです。 絵文字を含むとおかしくなってしまいますね。。