フォーラムの返信を作成しました。
- 投稿
ちょっと訂正です。
よく考えたらピリオドは不要でした（あっても今の場合は OK ですが）。
(\w+) を @\1 に置換すればいいですね。また，( ) を使わずに \w+ で検索して @\０ に置換してもいいでしょう。
「\０」 は検索でヒットした文字列全体を意味します。※どうもこのフォーラムはバックスラッシュゼロを入力すると消されるようなので，上記では便宜的にゼロを全角で入力していますが，実際には半角のゼロを使ってください。
こちらも Windows 7 Professional SP1 でした。
「Windows の言語の設定」というのは，「システムロケール」でいいのでしょうか。でしたら「日本語」になっていました。
四ヶ月くらい前に新規購入したマシンです。以前教えていただいた，レジストリーの FontLink\SystemLink の設定を「Inconsolata」というフォントについて変更した以外は，とくに何か変わった設定を行った記憶がありません。
EmEditor のバージョンは Version 14.4.0（64bit）です。濁点がちょうど 1 字ぶん右にずれるのは，
- MS明朝，MSゴシック
- IPA明朝，IPAゴシック，IPAmj明朝，IPAex明朝，IPAexゴシック
- ヒラギノ角ゴ Pro W5
- ＤＦＰ平成ゴシック体W5
- A-OTF 新ゴ Pro R
- Rg本明朝M
などなど，試したほとんどの和文フォントが当てはまります。OpenType フォントも，古い TrueType フォントもですね。
一方，「は」の右あたり（さほど悪くない位置）に濁点の来るフォントとしては，メイリオ，Meiryo UI，Koruri（小瑠璃）などがありました。
結論を先に述べると，試行錯誤の末，うまくいきました。たいへんありがとうございました。
フォントリンクは，該当フォントにグリフがなかった場合に使用される代替フォントを指定する機能と理解しました。
フォントファイル名とフォント名をカンマで区切ったものを，改行を挟みながら一つ以上記述するのですね。
そこで，Inconsolata に無い文字は IPAmj明朝かIPAex明朝にしようと思って，「ipamjm.ttf,IPAmj明朝」とか「ipamjm.ttf,IPAmjMincho」とか「ipaexm.ttf,IPAexMincho」などとやってみましたが，グリフはそれらの明朝になるものの，ピッチがぐちゃぐちゃで，全然ダメでした。
しかし，それらの仲間である「ipaexg.ttf,IPexGothic」と「ipam.ttf,IPAMincho」はなぜか正しいピッチで表示されました。
とりあえず深入りは避け，IPAMinchoでやることにしました。t2 さんコメントありがとうございます。
専門用語とくに外来語をやたらに使うのはいかがなものかという疑問ももっともですね。
しかし，「マッチ」は正規表現の最も基本的で重要な概念および用語でして，正規表現を学んだ人が「マッチ」を知らないということはちょっと考えにくいのです。
十分確立している用語を無理に日常語に置き換えると却って了解しづらくなることがあるので，「マッチ」がいいでしょう。マイクロソフト言語ポータルを検索してみました。
http://www.microsoft.com/Language/ja-jp/Search.aspx
こんなサイトがあるって知りませんでした。
英語→日本語で「match」を検索すると，「製品別用語」のほうに，確かに「一致」「完全一致」「一致したもの」がたくさん出てきました。
言語ポータルの位置づけやこれらの用語の文脈が分からないので何とも言えませんが，単純に技術用語の対訳を表示しているのだとすれば，不適切な訳語と言い切っていいと思います。一般に，「一致」はぴったり重なり合うことを意味し，イコールの関係です。
一方，英語の match は「釣り合う」とか「対等である」「匹敵する」「調和する」という意味，日本語の「マッチ」は「釣り合う」「似合う」「調和する」といった意味ですが，いずれも正規表現の用語としては文字列が検索パターンに当てはまるという意味です。イコールではありません。
「正規表現 [0-9] は数字に一致する」という言い方は日常語の感覚でもおかしいですよね。「正規表現が改行文字に一致することができる」の意味ですが，これはメタ文字 .（ピリオド）の意味を切り替えるオプションです。
ON だとピリオドは〈改行を含む全ての文字〉という文字クラスになります。
OFF だとピリオドは〈改行以外の全ての文字〉という文字クラスになります。「正規表現が改行文字に一致することができる」は名称と意味が合っていないため改善を提案しましたが，受け容れられませんでした。
※何がおかしいかというと，ピリオドの意味を変えるオプションなのに「正規表現が」となっている点，もう一つは，マッチするかどうかというオプションなのに「一致する」という表現になっている点です。単に「ピリオドが改行文字にマッチする」にすればいいと思うのですが。そもそもグローバルな設定で正規表現の解釈が変わるというのは危険な仕様だと思っています。今書いた正規表現が正しいかどうかが，「カスタマイズ」ダイアログを見ないと判断できないわけです。
他のエディターでは検索ダイアログについてたりしますね。試してみました。
［ツール］→［カスタマイズ］→［検索］で，「正規表現が改行文字に一致することができる」にチェックが入っていると，そういう動作になりますね。外すと正常です。正規表現は ^ に限らず，検索でヒットする文字列が空文字列の場合は軒並みダメなようです。
平仮名・片仮名のコード範囲が微妙に間違っていますが，それはともかく，とりあえず漢字についてだけ。
U+3400-U+9FFF は「CJK 統合漢字」と「CJK統合漢字拡張A」を合わせたものですね。
U+F900-U+FA2D ってのは「CJK 互換漢字」の一部分ですが，全体は U+F900-U+FAFF です。
Unicode の漢字領域は，これらの他に CJK 統合漢字拡張B～D および CJK 互換漢字補助の四つがあります。
部首（U+2F00-2FDF）も漢字に含めてほしいですね。
それに，漢数字の〇（U+3007）はこれらの領域にありませんが，れっきとした漢字です。
などなど。こんなものをいちいち書いてられるか，というのが当初の投稿の意図でした。
「統合漢字，拡張A，互換漢字に含まれない漢字なんて，ごく特殊な字じゃないの？」と思われるかも知れませんが，そうではありません。
人名などに使われる平凡な漢字「𡈽（U+2123D）」「𠀋（U+2000B）」（いずれも JIS 第三水準）はCJK統合漢字拡張Bに入っています。なので，漢字が p{Han} と書けないと大変困るのです。
で，いま気づきましたが，x{ } の形式って，4 桁までなんですね。となると，基本多言語面（BMP: Basic Multilingual Plane）の文字しか検索できません。
さきほどの「𡈽」「𠀋」を含む CJK 統合漢字拡張 B～D は BMP 外なので，[x{20000}-x{2FFFF}] といった書き方すらできません。EmEditor では漢字の検索ができない，という話になってしまいます。
Windows XP SP3 の EmEditor Version 12.9.12 で再現しました。
17 KB のクラッシュレポートが出来たので，あとでお送りします。とにかくタブを挟んで二つの文字列を置き，一方の文字列を選択状態にして，Shift+Alt を押しながら他方の文字列をクリックすると確実に落ちるようです。
欲張りマッチになっているわけではなく，まず「1t」を空文字列に置換したあと，「hogefuga1」の先頭から次の探索を始めるのですが，その際に「hogefuga1」の左端を行頭とみなして，「hogefuga1t」を空文字列に置換してしまう，その繰り返しなのだと思います。
最初の置換のあと，新たに〈行頭〉になってしまった箇所を行頭とみなすかどうかは，ツールによって違うようですね。
どちらが正解ということはないと思います。
たぶん，プログラミング言語や正規表現ライブラリー自体の動作は，これを行頭とみなさないほうが普通ではないかと思います。
テキストエディターではこれを行頭とみなすものも少なくない気がします。しかし，ちょっと調べたところ，EmEditor の現在の動作は確かに不可解なところがあります。
こんな実験をしてみましょう。
「A3A3A3」というテキストを用意します。
・「^A3」を空文字列に置換すると「A3A3」になります。
・「^.3」を空文字列に置換すると「A3A3」になります。
・「^A.」を空文字列に置換すると「A3A3」になります。
・「^..」を空文字列に置換すると「A3A3」になります。
・「^Ad」を空文字列に置換すると空文字列になります。
・「^w3」を空文字列に置換すると空文字列になります。
・「^wd」を空文字列に置換すると空文字列になります。
どうも，検索パターンに「」が含まれているか否かで動作が違っているのではないか，という気がします。さらに調べを進めたところ，［ツール］→［カスタマイズ］→［検索］で，「正規表現が改行に一致することができる」を ON にしたときは上記のいずれの場合も空文字列になりました。
理由のあることなのかも知れませんが，ユーザーにとっては混乱の元なので，現状の仕様は望ましくないと思います。
otsd 様，アドバイスありがとうございます。
エンコードの定義をいじるのは「あとで試してみよう」と思ってそのままになっていました。
いまごっそり削除してみたら，確かに「あの長ったらしいリスト」がぐっと短くなり，十分快適になりました。
ありがとうございました。この結果をもとに，v14 への要望事項をまとめてみたいと思います。
もしよろしければ，その「自動検出ができない」場合というのがどういう場合か教えていただけませんか。
作業効率に大きく影響するところなので。
毎回あの長ったらしいリストから選ばされるのは勘弁してほしいです。
WZ EDITOR も秀丸もこの点，あまりストレスを感じません。
（もっとも，日本向けの両ソフトと，世界相手の EmEditor とでは事情が異なるのだろうなとは思いますけど）続きです。
0x61 0xC0 の 2 バイトからなるテキストファイル「a.txt」を自動検出で開くと「UTF-8（BOM無し）」のみが候補に挙がります。
しかし，このバイト列は UTF-8 とは解釈し得ません。それゆえ，そのまま UTF-8 で開こうとすると，「指定したエンコードで変換できない文字が含まれています。」と警告が出て，改めて文字コードを選ばされます。0x61 0xC0 は，ISO 8859-1～4 などにおいて，「aÁ」と解釈できますし，CP932 では「aﾀ」と解釈できます。これらが候補に挙がるべきでしょう。
※それはそうと，開くときも保存するときも ISO 8859-1 が選べないのは何故なんでしょうか？
戻せましたが，ベータ版と両立させることはできないんですね？
12.0.11 が入った状態で，ベータ版を別ディレクトリーにインストールしてみたところ，12.0.11 が消されてしまいました。(T_T)ベータ版で実データを扱うことには抵抗があります。
それに，仕様変更を確認したりバグを発見したりするには，旧版とベータ版を比較しながら試用する必要があります。v14 のときでいいので，ベータ版は製品版と別にインストール・起動できるようにすることをご検討いただければ幸いです。
v13 の新機能は試してみたいので，しばらくベータ版を実作業に投入することにします。
既存ファイルを開いたときになぜ「標準」になるのかは分かりました。
また，「エンコードの定義」でなぜ Unicode 系のコードが設定できないかは，恐らく Unicode が特定の言語群に結びついていないためだろうと推察します。しかし，不可解なのは，「新規作成時」の「フォント分類」という設定が何のためにあるのか，です。
新規作成時に「日本語」になっていても，一度閉じて再び開いたときに「標準」になってしまうなら意味が無いのではないでしょうか。おっしゃるとおり，「標準」と「日本語」で別のフォントを指定していました。
そして「新規作成時」の「フォント分類」は「日本語」になっており，「テンプレートを使用する」になっていました。［ファイル］→［新規作成］でファイルタイプを指定してファイルを作成した場合，確かに「日本語」ではなく「標準」で指定したフォントで表示されました。
この動作が異常ということですか？［ファイルを開く］で存在しないファイル名を入力して新規作成した場合に，「日本語」で指定したフォントで表示されましたが，こちらはむしろ正常ということですね？
で，よく分からないのは，既存のファイルを開いたときに「標準」のほうのフォントで表示されるんですが，これでいいんでしょうか？
