秀丸 v6.12 一部ヒストリ使用できず - 秀丸エディタ関連ソフト会議室 - スレッド23220, 2007/07/04

秀丸 v6.12 一部ヒストリ使用できず

yuu さん　07/07/04 20:55

お世話になります。

Version 6.12 としてから、以下の現象が起こっていますのでご報告します。

[状況]

・検索ヒストリ、置換ヒストリ、grepファイルヒストリ他が保持されない

具体的には、

1. 検索ダイアログ内の「検索(S):」
2. 置換ダイアログ内の「検索(S):」と「置換(E):」
3. grepの実行ダイアログ内の「検索する文字列(S):」、
「検索するファイル(N):」、「検索するフォルダ(D):」

で、右端のプルダウンボタンから過去の内容が表示されません。

[確認した事]

・Version 6.11 では発生せず
・分割禁止拡張 Version 1.03 と同時に秀丸を更新したので、
分割禁止拡張の以前のバージョン、またはこれを導入しない状態に
してみたが、発生する (無関係のようです＞分割禁止拡張)

・一部の macro (sleep-walker さん：grep行情報削除 Ver.0.02)が
誤動作する

といったところです。

macro の動作は本体のバージョンに依存する場合が多いでしょうし、秀丸側の
問題として捕らえるのは無理があるかとは思いますが、今回のケースでは、
その結果がヒントとなりそうですので、以下も参考までに。

[Version 6.12 上の grep行情報削除 macro の動作結果]

例えば、

http://www.maruo.co.jp/hogehoge01/index.html
http://www.maruo.co.jp/hogehoge02/index.html
http://www.maruo.co.jp/hogehoge03/index.html

の内容のテキストファイル(仮に hoge_url.txt)で、これに「hoge02」で
grep を掛けると、

hoge_url.txt(2): http://www.maruo.co.jp/hogehoge02/index.html

となります(ここまで正常)が、ここで上記 macro を初期設定で実行すると

/index.html

のみ出力されます。即ち、「行頭から grep で使用した key word を含む
部分までの文字列すべてが消去」されます(本来は http:～より前のみ)。

この macro の場合「正規表現を使った参考例」なるロジックもあり、
(ファイル名が行中にない対象も処理可能になる)その場合の出力結果は

hoge_url.txt(2): http://www.maruo.co.jp/hoge/index.html

と、「grep で使用した key word の文字列のみが消去」に変化します。
key word が macro の出力結果に関与している事、macro のロジックで
それが異なる点から、秀丸本体との相関関係も考えられるのでは？と思い
ます。本当は macro のソースから動作を類推できるスキルがあれば、
もう少し簡単にお話できるかとは思いますが・・・(汗)。

[確認環境]

マシン：NEC PC-9821 CX3 改 (AMD K6-III アクセラレータ, 128MB RAM)
Ｏ　Ｓ：Windows98 SE 4.10.2222 A

秀丸の[動作環境]-[パフォーマンス]および[トラブル対策]はデフォルト
(但し常駐秀丸は OFF)

比較的目に付きやすい現象にも思えますが、未だ他の例を見ないとなると、
9x 系の OS 依存があるのでしょうか？
ともあれ、旧環境もなおサポート対象とされている開発姿勢には、頭の下がる
思いです。レジストしてから早10年ですが(笑)。

それでは、よろしくお願い致します。

RE:23220 秀丸 v6.12 一部ヒストリ使用で

秀丸担当 さん　07/07/05 13:12

>[状況]
>
> ・検索ヒストリ、置換ヒストリ、grepファイルヒストリ他が保持されない

報告ありがとうございます。
言われている通りでして、V6.12でWin9x系で検索ヒストリ等が覚えていないバグ
を出してしまいました。
早いうちに修正させていただきます。
ご迷惑をおかけして申し訳ありません。

RE:23224 秀丸 v6.12 一部ヒストリ使用で

yuu さん　07/07/05 17:30

>早いうちに修正させていただきます。

早速に対応(予定)との事、ありがとうございます。
macro の動作までは秀丸本体側の関知する範疇にないでしょうが、次版では
改善されていると良いなぁと、個人的に経過を見守るつもりです。

(以下別スレッドの方が適当かも知れませんが、ついでとして)

実は今回の件は、macro の不正動作がきっかけで気付きました。ヒストリの
保持のみの問題ならば、利便性にやや難程度だったのですが・・・。

以前本フォーラムで「grep 出力をファイル・行情報なしにできないか」の
問いに「ニッチな要望なので他にあれば・・・」(要旨)の答えがあったのを
記憶しています。なるほど、確かにそれもあればと思った一人です。

目的は様々ですが、HTML を整形し継続的な URL リストを作成する作業に、
置換→ grep →前出の macro の工程を多用する傾向にあります。
この場合元ファイルを置換しないので、行情報の出力は必須ではありません。
ネックは、処理件数が多いと macro での行情報削除が長時間になる点です。
(もちろん macro の意義は否定しませんし、恩義は感じていますが・・・)

「行情報を出力しない grep 」は、一部他のエディタや整形ツールにある
ようですが、手馴れた秀丸で、ある程度のスピード作業が実現できればとは
思います。が、やはりニッチな(個人的な)話に変わりはなし(汗)。

(一部の)要望として、この点留め置かれていただければ幸いです。

今回は重ねてお手数をお掛けしました。それでは。

RE:23227 秀丸 v6.12 一部ヒストリ使用で

秀丸担当 さん　07/07/05 18:12

>「行情報を出力しない grep 」は、一部他のエディタや整形ツールにある
>ようですが、手馴れた秀丸で、ある程度のスピード作業が実現できればとは
>思います。が、やはりニッチな(個人的な)話に変わりはなし(汗)。

grepの行情報の削除は置換をするとそれなりに高速だと思いますがどうでしょう
か。
検索文字列「^.+\([0-9]+\): 」
置換文字列「」
正規表現ON
という感じでいけるのではないかと思います。

マクロだと以下のような感じでどうでしょうか。

disabledraw;
$search = searchbuffer;
$replace = replacebuffer;
#flag = searchoption;
replaceallfast "^.+\\([0-9]+\\): ", "",regular;
setsearch $search, #flag;
setreplace $replace;

RE:23228 秀丸 v6.12 一部ヒストリ使用で

yuu さん　07/07/06 00:43

私の前発言と新版告知が前後してしまったようですが、Version 6.13 では
本表題の件、改善されている事を確認しました。また、macro 動作の点も
支障無くなりました。お手数をお掛けしました。

>grepの行情報の削除は置換をするとそれなりに高速だと思い(以下略)

参考例まで頂いて、ありがとうございます。

以前にも正規表現の構文を工夫したり、今回の例で再検証してみましたが、
数千程度のエントリならば有効なものの、それを超えるとちょっと苦しい
かなぁというのが偽らざる実感です。本質的には劇的改善は望めないと。

URL リストを作る場合、日常的には差分を取れば大した作業量ではないの
ですが、まれにそのものドカン(笑)を一気に行おうとすると、そこまで
秀丸、あるいは macro に任を負わせるのは酷かとも思います。

例えば、日付毎数百のエントリで数年に及ぶログから、絞り込み考慮せずに
URL 情報のみを取り出すようなケースでは、ピックアップ対象が十万単位と
なる場合も珍しくありません。

意図的にリストを用意し試してみましたが、約13万の整形に参考のマクロで
約35分と、K6-III 333 MHz + 旧環境の実力を思い知らされます。ところが
同ファイルを専用ツール(秋田稔さん：Speeeeed)では、正規表現の構文に
よりますが最速約35「秒」と桁違い。ただ、秀丸での正規表現と一部解釈が
異なる点と、別ツール故に作業に段付き感が生じるのが(個人的)難点です。

申し上げたかったのは、秀丸の整形機能の強化ではなく、最終出力に向けて
柔軟に素材としての出力方法を選べるのならばとの発想からです。macro +
変換モジュール採用のコンセプトには、この方向で感銘も受けましたし。

内部的には実現困難な機能も多々あるかと思います。あくまでニッチな用途
からの「雑音」ですので、気を悪くされないで下さい。

それでは。

RE:23232 秀丸 v6.12 一部ヒストリ使用で

アルビレオ さん　07/07/06 02:04

ユーザーのアルビレオです。

>以前にも正規表現の構文を工夫したり、今回の例で再検証してみましたが、
>数千程度のエントリならば有効なものの、それを超えるとちょっと苦しい
>かなぁというのが偽らざる実感です。本質的には劇的改善は望めないと。
>
>URL リストを作る場合、日常的には差分を取れば大した作業量ではないの
>ですが、まれにそのものドカン(笑)を一気に行おうとすると、そこまで
>秀丸、あるいは macro に任を負わせるのは酷かとも思います。
>
>例えば、日付毎数百のエントリで数年に及ぶログから、絞り込み考慮せずに
>URL 情報のみを取り出すようなケースでは、ピックアップ対象が十万単位と
>なる場合も珍しくありません。

そこまでの規模になるなら、grep自体を秀丸ではなく外部のコマンドラインツー
ルにやらせた方が効率がいいように思えます。
オプションも豊富なので出力結果の変換も最小限にできるし、そのツールを呼び
出す秀丸マクロを書いてしまえばあまり外部ツールを意識せずに使えるのではな
いでしょうか。
田楽DLLあたりと組み合わせれば、設定ダイアログを出すこともできます。

windows用のgerpはフリーのものもけっこうあるので、いくつか試せば目的に合
ったものが見つかると思います。
http://search.vector.co.jp/search?query=grep+windows&x=15&y=5

RE:23233 秀丸 v6.12 一部ヒストリ使用で

秀丸担当 さん　07/07/06 10:46

>意図的にリストを用意し試してみましたが、約13万の整形に参考のマクロで
>約35分と、K6-III 333 MHz + 旧環境の実力を思い知らされます。ところが

これは時間がかかりすぎだと思います。
grep行情報削除 Ver.0.02 のマクロが遅いのではないでしょうか。
Win95のPentium150MHzのマシンで10万行の処理時間は以下の通りでした。

grep出力(最小化で実行)　1分39秒
全置換(スピードアップ)　1分19秒
grep行情報削除 Ver.0.02 10秒で570行処理、10万行ではたぶん30分

RE:23235 秀丸 v6.12 一部ヒストリ使用で

yuu さん　07/07/08 02:22

レスポンス遅くなりました。申し訳ありません。＞各位

＞アルビレオさん

> そこまでの規模になるなら、grep自体を秀丸ではなく外部の

言われると思っていました(汗)。

ただ、現状の秀丸が持つ grep 機能に、パフォーマンス面の不満
がある訳ではありませんし、対象ファイルの大小にかかわらず、
オプション次第で出力形態が自由に選べるのなら、作業の連続性
とでも言ったら適当でしょうか。その辺りがより向上するのでは
ないか？との観点からも発言した次第です。ご了解下さい。

引用が前後しますが、

> http://search.vector.co.jp/
> オプションも豊富なので出力結果の変換も最小限に

8 ビットマシンの頃から経験しつつも、本格的には Win95 から。
後追いで DOS を憶え、GUI に馴れ切り、バッチファイルなぞは
結構複雑なものを組んだりする割には、コマンドラインと聞くと
やはり何となく・・・でしたので、ツールの存在は承知していま
したが、細かい機能面までは突っ込んで考えていませんでした。

今回のご指摘でハッとさせられ、認識不足を痛感しています。
今後改めて、この方面のツールの活用も視野に入れて行こうと
考えます。ありがとうございます。

＞秀丸担当さん

> これは時間がかかりすぎだと思います。
> grep行情報削除 Ver.0.02 のマクロが遅いのでは

指摘されて「え～っ」と＞ K6-III

ただこの結果は grep行情報削除マクロではなく、アドバイスを
頂いた方の macro のものでした。

加えて長くなりますが、作業行程と再検証結果をご報告します。

1. リンク情報を含む HTML ファイルをディレクトリ構造を保持
しつつ保存 (今回は対象 1333)

2. 文字・改行コードを Shift-JIS CR+LF で統一

3. 取得すべきリンクの前後に改行を挿入
(この時点で総計 997323 line 92419926 Bytes)

4. 秀丸で行頭「http:」を条件に総階層を grep

※ 出力は 115494 line 10491914 Bytes (約10MB)となり、
所要時間 2分20秒(最小化で実行) ですので、ご提示の
Pentium150MHz マシンのスコアには劣りますが、まず
許容できる結果だと思います

5. 便宜上、上記のものを保存、ファイル化

(以下はファイル化したものに対する処理結果ですが・・・)

a. 本スレッドで頂いた例での、正規表現による行情報削除
(置換は当初からスピードアップ固定)

HMJRE.DLL V1.80：27分30秒
JRE32.DLL V1.17：27分37秒

b. 同上のサンプルマクロ (DelGrep_test.mac)

30分19秒

c. grep行情報削除 Ver.0.02 (デフォルト)

1時間35分20秒

d. grep行情報削除 Ver.0.02 (正規表現を使った参考例)

32分17秒

「c.」の結果が突出して遅いですが、ロジックが異なる事と、
行単位の結果を常にステータス表示するような仕様ですので、
これは問題にできないでしょう。他の項目は、正規表現の応用と
見れば、多少の差こそあれ概ね同じレベルと言えるかと思います。

にしても、検証されたのが Pentium150MHz マシンでとなると、
何故こうも差が出るのかは謎です。最近の XP + GHz マシンに
触れる機会が無い訳ではないのですが、管理上秀丸その他の
ツールの使用が許されないとの堅物(人が)でして。

強いて不利な要因を挙げれば、多階層を対象にするため行情報に
PATH を含み、また URL の記述に付き、それが長い部分もある事
くらいでしょうか。ちなみに、平均すると今回の資料の場合では
grep 行情報部分で一行あたり約34バイト。続いての内容部分は
同じく約67バイト(それが約11万5千行)の内訳になります。

CPU の命令セットや PC-98x1 のハードウェア依存などまで考え
られるとしたら、「旧環境マシンはさっさとあきらめろ」などと、
これではどこかのサイトの回答例になってしまう・・・(汗)。

こんなユーザーだけの為に「行情報出力を～」と言い出したら、
ツールを開発される立場の方には、迷惑かとも思えてきました。
当初のスレッドの話題から外れて来てますし、何かお気づきの
点があるようなら、その場合にはコメント頂ければと思います。

何度も申し訳ありませんでした。それでは。

RE:23239 秀丸 v6.12 一部ヒストリ使用で

アルビレオ さん　07/07/08 04:43

アルビレオです。

>8 ビットマシンの頃から経験しつつも、本格的には Win95 から。
>後追いで DOS を憶え、GUI に馴れ切り、バッチファイルなぞは
>結構複雑なものを組んだりする割には、コマンドラインと聞くと
>やはり何となく・・・でしたので、ツールの存在は承知していま
>したが、細かい機能面までは突っ込んで考えていませんでした。

自分でもすっかり忘れていたんですが、以前GUIつきの外部grepを呼び出すマク
ロを作っていたんでした。
http://hide.maruo.co.jp/lib/macro/qgrepif.html

iniファイルを書き換えればダイアログを開いたときのデフォルト設定も変更で
きます。
設定などでわからないことがあれば、公開マクロサポート会議室で聞いてくださ
い。
http://www.maruo.co.jp/turukame/4/index.html
grepツール自体は私が作ったものじゃないんで、解決できるという保証はできま
せんが(^^;

RE:23239 秀丸 v6.12 一部ヒストリ使用で

白雲斎 さん　07/07/08 19:37

こんにちは“yuu”さん、白雲斎です。

Rubyの極めて単純なスクリプト例：
-- url_map.rb --------------------------

#!ruby -Ks

Dir.glob("**/*.{htm,html}"){|f|
html = File.read(f)
puts html.scan(%r!href\s*=\s*["'](s?https?://.+?)["']!)
}

----------------------------------------

...>ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]

...>ruby url_map.rb >output.txt

...>type output.txt
http：//...
http：//...
　：

私の非力な環境での実験：
dir(710), file(9700) => 130秒前後

RE:23239 秀丸 v6.12 一部ヒストリ使用で

秀丸担当 さん　07/07/09 11:39

>ただこの結果は grep行情報削除マクロではなく、アドバイスを
>頂いた方の macro のものでした。

そうでしたか。なぜここまで差がでるのでしょうか。
とりあえず思いつくことを書いてみます。

・見出しバー、アウトライン解析の枠、折りたたみ用の余白を非表示にしてみる。
・ステータスバーも非表示にしてみる。
・[その他]→[ファイルタイプ別の設定]→[表示とカラー]→[複数行コメント]で
言語指定の「なし」にしてみる。
・[その他]→[ファイルタイプ別の設定]→[表示とカラー]→[強調表示]の「強調
表示」チェックをOFFにしてみる。
・[その他]→[ファイルタイプ別の設定]→[体裁]で折り返しを最大にしてみる。

これらのことで速度に変化があるかもしれません。
あとは、[その他]→[動作環境]→[パフォーマンス]→[詳細]で、メモリを使用す
る最大サイズを、大きくしてみたり小さくしてみたりすると変化があるかもしれ
ません。
どうでしょうか。

RE:23243 秀丸 v6.12 一部ヒストリ使用で

yuu さん　07/07/10 22:50

度々のコメントありがとうございます。＞各位

＞アルビレオさん

>（略)以前GUIつきの外部grepを呼び出すマクロを作っていたんでした。

なるほど、秀丸入手先のドメイン名が(笑)。＜ xaxon.co.jp

QGREP も含め試用してみましたが、なかなか良さげです。ツール本体は良い
意味で「枯れている」のでしょう。動作は安定してますし、これ以上の
ものも予想できるものの、機能はまぁ十分。速度もまずまずと感じました。

他ツールでまま見られ、不自由を感じていた点に対し、このマクロのウリに
されている「マクロ実行時のみの設定を独自保存」は確実に二重丸です。
強いて気になる点を挙げれば、QGEP 側から見れば最終出力である、マクロ
で読み込んだ作業結果が、今回のような試料対象だとMB単位で %temp% に
残ってしまう事くらいですが・・・まぁ、これは仕方がないですね。

ファイル化された物しか対象にできない。grep に grep を多重するような
使い方には不向きなど、秀丸の機能を代替するところまでは行きませんが、
かなり強力な補助ツール＆マクロとなりそう・・・いや、なりました。

有益なアドバイス、ありがとうございます。
にしても、今まで何を見ていたんだと言いたくなる(汗)。＞ぢぶん

＞白雲斎さん

>Rubyの極めて単純なスクリプト例：

Ruby は正直全くの素人なのですが、推するに、HTML から URL 記述部分を
抜出し output.txt に出力の例なのか？あるいは grep行情報削除のみの話
なのか・・・と、乗っけから話の腰を折るような返礼で申し訳ないです。

>dir(710), file(9700) => 130秒前後

dir 数に分散した file 数を処理した結果なのか、それとも出力エントリが
file 数であるのか・・・(汗)。

前処理なしに一気にそれができるのなら理想的ですが、HTML の記述次第で
全く整形内容が異なるために、なかなかややこしい話になっている訳です。
現段階では前出のロジックを理解していませんので、130秒前後のスコアを
どう解釈すればと。

突っ込み出すと多分に教えてクン的になりそうですので、Ruby そのものは
今後の課題にします。何しろ、学生時代の電算機実習が FORTRAN(無印)＋
パンチカードの世代ですので、何ともお恥ずかしい(と、歳がバレる)。

＞秀丸担当さん

>とりあえず思いつくことを書いてみます(以下項目略)

元々無効設定が多かったので、ステータスバーの表示と[複数行コメント]の
言語指定、折り返しの設定のみ試してみました(メモリ関係はそのままです)。

その結果、折り返し設定が大きく結果を左右する事が分かりました。今回の
資料に限れば、他項目での変化は僅少です。よって、ステータスバーは表示。
複数行コメントは自動判定のままで行った結果が以下のものです。

[対象] 行情報付き grep ファイル(115533 line 11494648 Bytes) ＜既出

[結果]

a. 正規表現置換 (本スレッド提示のサンプル)

折り返し固定(80)：27分30秒＜既出
最大： 49秒

b. 本スレッド提示のサンプルマクロ

折り返し固定(80)：30分19秒＜既出
最大： 2分56秒

c. grep行情報削除 Ver.0.02 (デフォルト)

折り返し固定(80)：1時間35分20秒＜既出
最大： 50分38秒

d. grep行情報削除 Ver.0.02 (正規表現を使った参考例)

折り返し固定(80)：32分17秒＜既出
最大： 4分23秒

あ然とするしかないようなこの差。Windows のメモ帳と違い、折り返しを
当たり前としていた事が、思わぬ落とし穴であったと・・・今回ご指摘を
受けなければ、こんなものかで済ませていたのが恥ずかしくなります。

ちょっとした作業ならば、一般の置換で十分実用的なのが分かりましたが、
他のマクロでの場合を含め、正規表現の手法による以上、本文の内容次第で
誤ヒット・置換の危険が全く無い訳ではないのが注意点かと思われます。
今回のように対象が10万超エントリにおよぶとなると、論理的なエラーでは
ないが故にそれを発見・修正するのは、手作業かつそれなりの注意力を要求
されることでしょう。

そのような点からも、grep行情報を「削除」ではなく最初から「出さない」
考え方があって良いのではないか？とも思っていました。ここで別ツールを
使えば一応解決するのですが、そこは作業性に若干の違和感が・・・という
のが、敢えて秀丸の話題としてお話して来た所以でもあります。

ひょっとして FAQ？とも思われる部分に気が付かなかった点、反省至極です。
またツボを得た見方とアドバイス。改めて御礼します。

今回もありがとうございました。それでは。

RE:23256 秀丸 v6.12 一部ヒストリ使用で

秀丸担当 さん　07/07/11 10:50

折り返しが遅い原因でしたか。確かに、置換によって折り返しが無くなって見た
目上の行数が変化することが多くて、かつ全体の行数がとても多いと遅くなるか
もしれません。

>他のマクロでの場合を含め、正規表現の手法による以上、本文の内容次第で
>誤ヒット・置換の危険が全く無い訳ではないのが注意点かと思われます。

この点の配慮がありませんでした。
正規表現で、ものぐさ指定（最短一致）をすると、おそらく解決するのではない
かと思います。

　検索文字列「^.+?\([0-9]+\): 」

または、マクロの場合、

　replaceallfast "^.+?\\([0-9]+\\): ", "",regular;

「.+」の部分を「.+?」にすると、最短部分がマッチするようになります。

例えば、以下のようなテキストがある場合、?を付けない場合は(100):の部分ま
でマッチしますが、?を付ければ(1):の部分までがマッチするようになります。

例：
c:\folder\file.txt(1): xxxxxxx(100): yyyyyyy

>そのような点からも、grep行情報を「削除」ではなく最初から「出さない」
>考え方があって良いのではないか？とも思っていました。ここで別ツールを
>使えば一応解決するのですが、そこは作業性に若干の違和感が・・・という
>のが、敢えて秀丸の話題としてお話して来た所以でもあります。

最初からファイル名を出さないというオプションもあると使い道はあると思いま
す。
オプションが増えすぎるのとマクロの互換性などが心配な点ではあります。
そういう意見もあるということで参考にさせていただきます。

RE:23259 秀丸 v6.12 一部ヒストリ使用で

yuu さん　07/07/15 22:11

こと細かに及んでのアドバイス、ありがとうございます。途切れ途切れの
レスポンスで、度々申し訳ありません。

>(略)確かに、置換によって折り返しが無くなって見た目上の行数が変化
>することが多くて、かつ全体の行数がとても多いと遅くなるかも

行番号の計算方法を「エディタ的」にしているのがデフォルトなので、
行数が増えたとは感じていなっかたニブい本人がおります(汗)。

>この点の配慮がありませんでした。
>正規表現で、ものぐさ指定（最短一致）をすると、おそらく解決(以下略)

いえ、ごく基本的な動作の概念をご説明いただいているつもりでしたから、
この場で完全なものを求める筋でもない旨、承知していたつもりです。と、
言いますか、そこまで立ち入ってご返事いただいた事、有難く思います。

改めての例でも試用してみましたが、当然のごとく意図した動作をしてくれ
ました。簡便には、この手の構文を用いるのが有効かと思います。

実はこのものぐさ指定、過去に自身でも試してみた事がありました。ただ、
自身の使い方の悪い癖から、かえって仇になる事がありましたので、どう
したものかとも考えていました。

それは、grep の出力結果に、行情報を削除しないで再度 grep (絞り込み)
を掛けてしまう事がままある点です。そうなった場合の行情報削除は、最短
一致をしない方が良い事になりますが、結果的に、まともな場合も含めて
二種類の構文を使い分ける必要が生じてしまう点に加え、誤ヒット・置換の
危険も作ってしまうトホホな話でして・・・。

前回「誤ヒット・置換の危険が全く～」のお話をした点、このような面での
問題も頭の中にあったのですが、思い返してみると少しエラそうな言い方に
なってしまったかとも反省しております。

>オプションが増えすぎるのとマクロの互換性などが心配な点ではあります。
>そういう意見もあるということで参考にさせていただきます。

ご配慮感謝します。
カラー化される以前から使い始めたせいか、かえって目的やマシンパワーの
点からも、キャリアは長い割にまだまだ秀丸を使い切っているとは言えない
ようなユーザーのたわごとですが、片隅にとどめ置かれれば幸いです。

(10年来の実感と余談) 「秀丸が落ちたら、システムの方を疑え」(笑)

今回は長々とありがとうございました。それでは。

RE:23268 秀丸 v6.12 一部ヒストリ使用で

yakira さん　07/07/18 15:47

>こと細かに及んでのアドバイス、ありがとうございます。途切れ途切れの
>レスポンスで、度々申し訳ありません。
>
>>(略)確かに、置換によって折り返しが無くなって見た目上の行数が変化
>>することが多くて、かつ全体の行数がとても多いと遅くなるかも
>
>行番号の計算方法を「エディタ的」にしているのがデフォルトなので、
>行数が増えたとは感じていなっかたニブい本人がおります(汗)。
>
>>この点の配慮がありませんでした。
>>正規表現で、ものぐさ指定（最短一致）をすると、おそらく解決(以下略)
>
>いえ、ごく基本的な動作の概念をご説明いただいているつもりでしたから、
>この場で完全なものを求める筋でもない旨、承知していたつもりです。と、
>言いますか、そこまで立ち入ってご返事いただいた事、有難く思います。
>
>改めての例でも試用してみましたが、当然のごとく意図した動作をしてくれ
>ました。簡便には、この手の構文を用いるのが有効かと思います。
>
>実はこのものぐさ指定、過去に自身でも試してみた事がありました。ただ、
>自身の使い方の悪い癖から、かえって仇になる事がありましたので、どう
>したものかとも考えていました。
>
>それは、grep の出力結果に、行情報を削除しないで再度 grep (絞り込み)
>を掛けてしまう事がままある点です。そうなった場合の行情報削除は、最短
>一致をしない方が良い事になりますが、結果的に、まともな場合も含めて
>二種類の構文を使い分ける必要が生じてしまう点に加え、誤ヒット・置換の
>危険も作ってしまうトホホな話でして・・・。
>
>前回「誤ヒット・置換の危険が全く～」のお話をした点、このような面での
>問題も頭の中にあったのですが、思い返してみると少しエラそうな言い方に
>なってしまったかとも反省しております。
>
>>オプションが増えすぎるのとマクロの互換性などが心配な点ではあります。
>>そういう意見もあるということで参考にさせていただきます。
>
>ご配慮感謝します。
>カラー化される以前から使い始めたせいか、かえって目的やマシンパワーの
>点からも、キャリアは長い割にまだまだ秀丸を使い切っているとは言えない
>ようなユーザーのたわごとですが、片隅にとどめ置かれれば幸いです。
>
>(10年来の実感と余談) 「秀丸が落ちたら、システムの方を疑え」(笑)
>
>今回は長々とありがとうございました。それでは。