フォーラムの返信を作成しました。
- 投稿
「設定がまるごと効いていない」と思いこんでいたのですが，これは私の勘違いでした。
改めていろいろ実験してみたところ，「フォント」が効いていないことが分かりましたが，他にもあるかどうかは分かりませんでした。
※フォントは見た目の印象ががらりと変わるので，設定全体が効いていないと勘違いしてしまったのでした。不思議なのは，［ツール］→［設定の選択］→［設定の定義］で特定のものを選んだときに表示される設定内容が，開いているテキストの状態（既存ファイルを開いたのか，ファイルを開くで新規作成したのか）によって変わることです。
[シングル クリックで開く] を外したら確かにフォルダーにもフォーカスするようになりました。ありがとうございました。
ただ，シングルで開くかダブルで開くかということと，フォーカスするかどうかは必然的関係があるように思えないのですが…。また，[左カスタムバー] にショートカットを割り当てて，うまくいきました。快適です。ありがとうございました。
プロジェクトのツリーに D&D でできました。ありがとうございました。
この操作はマニュアルに書いてないようです。エクスプローラプラグインは存在すら気づいてませんでした（なぜか OFF になってたため）。
使ってみると，私がやりたかったことはプロジェクトプラグインよりもエクスプローラプラグインのほうが近いようでした。
つまり，ディレクトリー内でファイルが追加になったりファイル名が変わったりしたら，簡単な操作でツリーに反映させたいのです。ただ，「除外」がファイル名のワイルドカードでしか行えないのが難点です。
編集しないフォルダーがたくさんある場合，フォルダー単位で見えないようにしたいですね。
Git の .gigignore ファイルのようなものを記述して，それに従って除外されるようになっていると非常にありがたいです。昨日まで試みていたのは，自作のスクリプトでプロジェクトファイルを生成することです。これ自体はたいへんうまくいきましたが，ファイル構成が変わるたびにスクリプトを動かさなくてはならないのは仕方ないとしても，プロジェクトを一発でファイルから読み直す手段が無い（ぽい）のが面倒でした。
Alt + F4 でできました。ありがとうございました。
これが自力では見つけられなかったんです。これって，どうしてメニューに無いんでしょうか？
また，キーボードマップで「F4」で検索しても「閉じる」で検索しても出てこないのですが…？Unicode 照合アルゴリズム（UTR #10）に基づくってことでしょうか。
基底文字列（大文字／小文字，付加記号などを無視した文字列）が同じだった場合の判定に大文字／小文字を区別するかどうかを決めるオプションだというわけですね。
それでなんか納得しました。現バージョンの場合、安定ソートになっているため、4 カラム目でソートを行った後、2 カラム目でソートを行えば、ご希望の動作になるかと思います。
うっ，確かに。これは気づきませんでした。
ただ，要望は「複数カラムで CSV のソートができるように」ということではなく，ソーティングの基準になる評価値が自由に（スクリプトで）定義できる汎用の仕組みです。
たとえば，単語と読みからなるデータを，百科事典的に
・読みの音引き「ー」を削除して
・小書きの仮名を並字にして
・濁音を清音化して
ソートするなど，ソートの方法は多種多様ということですね。手順，ありがとうございました。
プラグインとマクロを無効化しても再現しましたので，ご指示のアドレスあてにデータ一式をお送りしました。改行を 99 個含んだだけのテキストのペースト＋Undo でもクラッシュします。98 個だと正常です。
（他の方の参考のため）
Windows XP ではクラッシュレポートは
C:Documents and SettingsAll UsersApplication DataEmurasoftEmEditorError
に出来ていました。修正後の文言も論理的にあまり素直でなく，ちょっと考えないと意味が取れないと思います（少なくとも私にはそうです）。
また，true のときの動作がこれではよく分かりません。この引数は，要するに
・true のときは，カーソル移動に合わせて選択範囲が拡縮する。（非選択状態でも選択状態になる）
・false（既定値）のときは選択を解除する。
ということだと思うので，そういう風に書いていただいたほうが分かりやすいのではと思いました。bExtend を持つ関数っていっぱいあるんですね。
※ところで，マニュアルについての指摘は各ページの「フィードバックを送信」でやるのですね。次回からそうします。
確かに賛否両論ありそうですね。
タブが入りきらないときの動作変更は知らなかったので，「何もしない」「幅を調節する」をやってみましたが，タブが多いときはちょっとどうかな，と思いました。
のちほど別スレッドを立てたいのですが，EmEditor は「ファイルから検索」を繰り返すとあっというまにタブが溢れかえってしまいますので。幅が問題なのでしたら，「*」以外の手段で示すとか，アイコン・ファイル名の前後の空きをもう少し詰めるとかなどご検討いただければ幸いです。
「鬱陶しい」と書きましたが，単にヤダということではなくて，一文字タイプしただけなのに全体が動くと，何か操作を誤ったかと思って，確認したりして，ストレスを感じるんです。（人によるでしょうけど）
ありがとうございます。
新しい判定基準ですが，それで十分でしょうか。
置換ダイアログボックスの入力欄は改行を直接入力することができるので，素の改行の有無も判定条件に入れないといけないような気がします。[正規表現が改行文字に一致することができる] の「正規表現」は「”.”」とかに変えたほうがよさそうですね。
それと「一致することができる」は日本語としてやや変です（「一致する」は動作でなく状態を表すので）。[“.” が改行文字にマッチする] でどうでしょうか。ヘルプの記述から，[正規表現が改行文字に一致することができる] は .（ピリオド）の意味だけを変更するのかと思っていたのですが，違うということですね？
それから，マニュアルページありがとうございました。
見てみましたが，s は [[:spaces:]] に等価であると書かれているのみですね。
正規表現の初心者は，これが文字クラスの POSIX ブラケット表記であると分からないでしょうし，分かってもその正確な意味（どの文字が該当するのか）を調べるのはちょっと大変かと思います。
やはり EmEditor のヘルプに直接書いていただくのがありがたいですね。そのオプションで問題の大部分が解決しそうな気がします。
それともう一つご検討いただきたいのが，既に挙げた Ruby の case 文です。以下のように書きます。
if hoge
case foo
when x
aaa
when y
bbb
end
endこの最初の when を打ったときに，case ではなく if に揃う位置にされてしまいます。この問題は，たぶんそのオプションの導入や正規表現の工夫では解決しないのではないかと思います。
それと，インデントがどのように決定されるかをマニュアルに記載していただけると非常に嬉しいです。
実際はもっと複雑な気がします。
一文字タイプしたとき，自行が終了行とみなされると，自行のインデントが -1 される。
開始行とみなされ，かつ前行が開始行でない場合は自行のインデントが前行に合わせられる。
開始行の末尾で Enter を入れると，次行のインデントが +1 される。
というような感じでしょうか？それから「ステートメント終了」というのは何でしょうか？
ともかく，完璧に動作する自動インデントが不可能である以上，既に入力した行を修正したときにインデントが変化してしまうのはやめてほしいです。
たとえば，
case foo
when /[a-zA-Z]/
puts “Alphabet”
when /d/
puts “digit”
end
のようなものを打って，4 行目の正規表現を変更すると，この行がぴょこんとインデント +1 されてしまいます。
EmEditor が誤ったインデントを手作業でせっかく直しても，一文字修正しただけでまた誤ったインデントにされてしまいます。いたちごっこというか，賽の河原というか。Python や CoffeeScript のようにインデントに意味を持たせた言語の編集では，一時的にせよ勝手にインデントがゆがめられるのは非常に危険でストレスを感じます。
横からすみません。
いま広く使われている正規表現エンジンの多くでは，? * + { } などの量指定子は最長一致になり，セレクター（A|B）はそうならないようですね。。
セレクターが最長のものを探索する仕様だと速度が遅くなるので嬉しくないです。どちらか選べるのならいいですが。それはそれとして，正規表現エンジンに鬼雲（Onigmo）か鬼車も選べると嬉しいです。
https://github.com/k-takata/Onigmo/blob/master/README.ja設定はそうなっていたのですが，「ファイルを開く」ダイアログにおいて「HTML/XMLのCharsetを検出」がオフになっていました。
CSS でも自動検出してほしいと思います。CSS の @charset 宣言はファイルの先頭（第1バイト～）に置かなければならないと規定されているので，HTML 以上に楽に検出できると思います。
残っていたダウンロードファイルから無事にアップデートできました。
同じ現象に遭われる他の方の参考のために詳細を書いておきます。
まず，ダウンロードファイルはC:ProgramDataEmurasoftEmEditorupdatesupdate32
には無かったので，「EmEditor のヘルプ メニューの「更新チェッカーのカスタマイズ」」から辿りましたが，すぐに見つかりました。
ダブルクリックしても「セキュリティの警告 ダイアログ」は出ませんでしたので，念のため，いったん中止しました。そして，ファイルのプロパティーで「デジタル署名」→「詳細」を見たところ，「このデジタル署名は問題ありません。」とあったので，再び実行しました。
以上です。
あっ，ホントですね。すみません。調べが足りませんでした。
動作を確認し，概ねそのとおりと分かりましたが，バグがあるようです。
最初に開くファイルについてはこの設定が生きません。◎再現手順
以下，拡張子 .js の設定「JavaScript」は，BOM 無し UTF-8 と仮定します。[1] EmEditor を起動。
[2]「ファイルを開く」で存在しない「foo.js」を指定。
→ BOM 付き UTF-8 になる（異常）
[3] さらに「ファイルを開く」で存在しない「bar.js」を指定。
→ こんどは BOM 無し UTF-8 になる（正常）
[4] EmEditor を終了し，再び起動。
[5] 何か存在するファイルを開く。
[6]「ファイルを開く」で存在しない「baz.js」を指定。
→ こちらも BOM 無し UTF-8 になる（正常）
[7] すべてのタブを閉じる（EmEditor は終了しない）
[8]「ファイルを開く」で存在内「hoge.js」を指定。
→ BOM 付き UTF-8 になる（異常）つまり，ほかにタブが開いていない状態で存在しないファイルを指定したときだけ BOM の設定が生きないようです。
なお，JavaScript の文字コードが「システム既定」となっていますが，JavaScript を UTF-8 以外で書くことは稀なので，BOM 無し UTF-8 をデフォルトにするのが良いのではないでしょうか。
同様に，XML が BOM 付き UTF-8 になっているのも，BOM 無し UTF-8 にするのが良いと思います。すみません，知りたかったことは，「ファイルから検索」の場合に同じ原因で動作が遅いことがあるのかどうか，です。
ファイルを開いて検索をかける場合，ファイルの中身全体を正規表現の関数に渡すのでは動作が遅くなることがあるわけですよね？ であれば，「ファイルから検索」の場合も遅いのかな，と思ったわけです。
