[要望]GREPのNTFS対応No.38917
fzok4234 さん 21/05/17 14:54
 
毎度お世話になっております。

さて、現状のGREPでNTFSに関するいくつか不便な点がありました。

1. NTFS代替ストリームを検索対象に含めることができません。「grepの実行」ダイ
アログにて
   「検索するファイル」の欄に
   foo.txt:bar
   と指定しても、
   「該当するファイルがありません。」
   とエラーになってしまいます。また、代替ストリームも含めて全てのファイルを
検索することを
   意図してワイルドカードを使って
   *.*:*
   としても上記と同じエラーになります。このため、
   A. 「検索するファイル」の欄の書式で
      foo.txt:bar
      という風に明示的に個別の代替ストリーム名を指定できるようにする。
   B. 全ての代替ストリームを検索対象に含める/含めないを切り替えるオプション
を新設する。
   といった改善をしてもらえれば助かります。

2. ディレクトリへのリパースポイント(ジャンクション/シンボリックリンク/ドライ
ブへのマウント
   ポイント)が必ず参照されてターゲットのディレクトリの中まで検索されてしまい
ます。例えば、
   C:\foo
   というディレクトリがあってその中に
   link
   という名前のジャンクションがあり、そのターゲットパスが親ディレクトリを指す
   C:\foo
   であった場合、見かけ上
   C:\foo\link\link\link\link\link\link\link\....
   と無限に深いディレクトリツリーが出来上がります。この時、「grepの実行」ダ
イアログにて
   「検索するフォルダ」欄に
   C:\foo
   を指定すると、ジャンクションを必ず参照して
   C:\foo\bar.txt
   C:\foo\link\bar.txt
   C:\foo\link\link\bar.txt
   C:\foo\link\link\link\bar.txt
   C:\foo\link\link\link\link\bar.txt
   ...
   という風に同一の
   C:\foo\bar.txt
   ファイルを繰り返して検索が行われます。このデフォルトの動作だと困ることと
して、
   A. ファイルパスが長くなりすぎてWindowsのMAX_PATH(259文字)の制限に引っかか
る。
   B. 上記のような無限ループのパターンだと同一ファイルを無駄に繰り返し検索し
てしまう。
   があります。このため、
   ・ディレクトリのリパースポイントを参照する/参照しないを切り替えるオプショ
ンを新設する。
   といった改善をしてもらえれば助かります。

上記1.のB.と2.の切り替えオプションの実装場所として確認できたものを挙げると
・grepの実行。
・grepして置換。
ダイアログのチェックボックスおよびマクロの
・searchoption/searchoption2キーワードのフラグ。
・setsearch文のフラグ1またはフラグ2。
・grep/grepdialog/grepdialog2/localgrep/grepreplace/grepreplacedialog2文の各
種フラグキーワード。
となります。どうかよろしくお願いします。



[ ]
RE:38917 [要望]GREPのNTFS対応No.38920
でるもんたいいじま さん 21/05/18 08:20
 
でるもんた・いいじまです。

> さて、現状のGREPでNTFSに関するいくつか不便な点がありました。

> 1. NTFS代替ストリームを検索対象に含めることができません。

こちらは「代替ストリームって何?」という状況なのでパス。
確かにこれは、使っている人にとっては便利かもしれません。

#当座の対策として、対象の代替ストリームに対してドライブレターを
#割り当てる、という方法はありそうですが、さすがに *.dsk:*.* は
#この方法では無理ですね。

> 2. ディレクトリへのリパースポイント(ジャンクション/
> シンボリックリンク/ドライブへのマウントポイント)が必ず参照されて
> ターゲットのディレクトリの中まで検索されてしまいます。
...
> ・ディレクトリのリパースポイントを参照する/参照しないを切り替える
> オプションを新設する。
> といった改善をしてもらえれば助かります。

これは
「秀丸が対処すべき範疇の話ではない」
「そもそも無限ループになるようなリンクを作るのが悪い」
と考えます。

NTFSはよく分かっていないのでとりあえずFreeBSDで実験してみましたが、
ls -lR、bsdtar -H、grep -R はとりあえずループがあれば停まるようです。

ループを作っているという時点で既に運用上の問題があるように思えるのですが、い
かがでしようか?

示して頂いた「実験用のミニマムサンプル」ではなく、実運用に極力近いシステム構
成をご紹介いただければ何かご提言ができるかもしれません。

[ ]
RE:38920 [要望]GREPのNTFS対応No.38921
秀丸担当 さん 21/05/18 09:01
 

grepでは、確かに代替ストリームの検索はできないです。
できたらいいということで、ご意見参考にします。
代替ストリームはダウンロードしたファイルなどたくさんある可能性があるので、ド
ライブレターを割り当てるのは現実的ではないと思います。
ちなみにファイルを開くときに、コマンドラインのファイル名として「:」付きで代
替ストリームを開く方法がありますが、もともと特に何もしていなかったのが、やっ
てみたらできていたので、禁止することなくできるようにしているままという感じに
なっています。
個人的には、どちらかというと秀丸ファイラーClassicで一覧表示できたらいいと思
うことがあります。

ディレクトリへのリパースポイントを禁止するといったようなオプションもあったら
いいということで、ご意見参考にします。
例のような無限になるのは、でるもんたいいじまさんも言われるように避けたほうが
いいと思います。
ちなみに秀丸ファイラーClassicでは、フォルダサイズ表示のオプションでジャンク
ション/シンボリックリンクを計算に含めるかどうかのオプションがあります。
検索枠の検索はgrepと似ていますが、どちらかというと秀丸ファイラーClassicの検
索枠にも同様のオプションがあったらいいかもしれないです。

[ ]
RE:38921 [要望]GREPのNTFS対応No.38923
fzok4234 さん 21/05/18 12:32
 
対応の検討ありがとうございます。

> ちなみにファイルを開くときに、コマンドラインのファイル名として「:」付きで
> 代替ストリームを開く方法がありますが、もともと特に何もしていなかったのが、
> やってみたらできていたので、禁止することなくできるようにしているままという
> 感じになっています。

先ほど気づいたのですが、
foo.txt:bar
という代替ストリーム名付きのファイルを秀丸エディタで開いた状態で
「ファイルタイプ別の設定」ダイアログを開くと、拡張子を
.TXT:BAR
という風に末尾に代替ストリーム名が付いた状態で誤認識して設定を登録しようと
する挙動が見られました。これがバグなのか意図的な仕様なのかは当方では判断
できませんが、もし仮にバグであったならば
・秀丸エディタ上での全てのファイルの取り扱いで代替ストリームの存在を
  全く考慮していない。
という可能性が考えられます。もし仮にそうであったならば、ユーザーが
代替ストリーム名付きでファイル名を指定することで発生する、まだ確認できていない
深刻なバグが眠っている可能性があります。一度全てのファイルがらみの処理で
代替ストリームに対応できているか検証したほうがよいかもしれません。

> 例のような無限になるのは、でるもんたいいじまさんも言われるように
> 避けたほうがいいと思います。

リパースポイントの無限ループはトラブルの元になるので「わざと」構築することは
まずありません。しかし、他のソフトウェアのバグで「勝手に」できることは
十分考えられます。実際、一昔前のAdobe Readerが%TEMP%ディレクトリ中に
無限ループ構造を作っていたことがありました。現在は解消されていますが、
当時はディレクトリを再帰的にスキャンするいろんなアプリが%TEMP%ディレクトリを
参照しただけで落ちてしまって、その都度Adobe Readerが作ったリパースポイントを
削除するというイタチごっこに悩まされたものです。

また、Windowsのユーザープロファイルディレクトリ内には、
"Application Data" => "AppData\Roaming"
とか
"My Documents" => "Documents"
という風にレガシーアプリがWindows XP以前のディレクトリ名を指定しても正しく
動作するための互換性を維持するためのリパースポイントがたくさんあります。
これらをGREPが回避できず重複して検索してしまうのはやはり不便に感じます。



[ ]
RE:38923 [要望]GREPのNTFS対応No.38924
fzok4234 さん 21/05/18 14:06
 
補足です。

「名前を付けて保存」ダイアログで明示的に
foo.txt:bar
と代替ストリーム名を付た名前を指定すると、
「ファイル名は有効ではありません。」
との警告メッセージが表示されて保存できません。多分、秀丸エディタ側で
パス文字列を解析してブロックしているものと思われますが、そうであれば
解除したほうがよいのでは、と思います。



[ ]
RE:38924 [要望]GREPのNTFS対応No.38926
moppu さん 21/05/18 21:15
 
いちユーザの moppu と申します。

>「名前を付けて保存」ダイアログで明示的に
>foo.txt:bar
>と代替ストリーム名を付た名前を指定すると、
>「ファイル名は有効ではありません。」
>との警告メッセージが表示されて保存できません。
Windows10のメモ帳でも同じメッセージが表示されるので、
WindowsOSの「名前を付けて保存」機能の制約かと思われます。

本スレッドの内容と無関係ですが、投稿される際に"極め困難"とか"深刻"のような
強い表現を多用されることに違和感を感じます。
内容拝見しても秀丸エディタにそんなに大きな瑕疵があるとは思えません。

fzok4234様の投稿でなるほどそんな技術情報があるのだ、と勉強には
なるのですが、世の中の技術動向をあまねく本エディタに要求するのは
サポートの範疇を超えていると思います。
※ そもそも代替ストリームをテキストエディタでメンテせねばならない
開発業務や運用を造像できません。

[ ]
RE:38926 [要望]GREPのNTFS対応No.38927
fzok4234 さん 21/05/19 04:19
 
> Windows10のメモ帳でも同じメッセージが表示されるので、
> WindowsOSの「名前を付けて保存」機能の制約かと思われます。

Windows備え付けの機能の問題ならどうしようもないということで、大変失礼
致しました。

> 本スレッドの内容と無関係ですが、投稿される際に"極め困難"とか"深刻"のような
> 強い表現を多用されることに違和感を感じます。
> 内容拝見しても秀丸エディタにそんなに大きな瑕疵があるとは思えません。
>
> fzok4234様の投稿でなるほどそんな技術情報があるのだ、と勉強には
> なるのですが、世の中の技術動向をあまねく本エディタに要求するのは
> サポートの範疇を超えていると思います。

後述した不具合報告
https://www.maruo.co.jp/hidesoft/2/x38925_.html?a=6#38925
では、代替ストリームを用いたある条件を満たすパスを開こうとしたら
おかしな動作になったことを報告しています。もし仮にユーザーが意図したファイルと
別のファイルを上書きで破壊してしまうような事態が生じたら、それこそ眠ってた
「深刻」なバグが目を覚ましたといえるのではないでしょうか。

また、NTFSの代替ストリーム自体が10数年前から用いられている「古めの技術」であ
り、
IEでダウンロードしたファイルに自動で作成されるなどエンドユーザーにとって
身近な存在でもあります。さすがに「Windows 10 21H2に搭載予定の新機能に今から
対応する」とも
なれば無茶な話であるといえますが、古くて身近な技術に対応させて上記のようなバ
グを
治すことは自然なことだと思います。

> ※ そもそも代替ストリームをテキストエディタでメンテせねばならない
> 開発業務や運用を造像できません。

上記でも述べましたがIEやEdgeでダウンロードしたファイルには自動で代替ストリー
ムに
メタ情報が保存されます。これをテキストエディタで閲覧/修正する権利は当然ユー
ザーに
あります。Windowsのメモ帳でもできることが秀丸エディタではできないというのは
ちょっと
おかしな話です。

あとそれからこれは持論ですが、現在、周りを見渡せば
・サクラエディタ
・Notepad++
・VS Code
・vim
・Emacs
といった「強敵」で溢れかえっており、テキストエディタ競争は「戦国時代」の真っ
只中という
状況です。油断すれば大きくシェアを奪われて大敗を期して最悪「秀丸エディタの開
発打ち切り」と
という結果を招いて多くのユーザーに迷惑がかかる事態につながりかねません。生き
残るためには
「メモ帳でもできることが秀丸エディタではできない」とかは論外で、ある程度枯れ
た技術には
しっかりと対応した上で、他のエディタにはない独自色を前面に出していくという戦
法を維持する
必要があります。当方でも以前いくつか別のエディタを使用していましたが、「Unic
odeに対応できない」と
いう理由で開発中止となったため、最終的に秀丸エディタに落ち着いたという経緯が
あります。
このように、「ある程度枯れた技術に対応できないといとも簡単に敗戦となる」とい
う厳しい
現実をユーザーの立場で見せつけられてきました。秀丸エディタには今後も頑張って
もらいたいと
思うところであります。



[ ]
RE:38923 [要望]GREPのNTFS対応No.38928
fzok4234 さん 21/05/19 05:25
 
先ほど、
> foo.txt:bar
> という代替ストリーム名付きのファイルを秀丸エディタで開いた状態で
> 「ファイルタイプ別の設定」ダイアログを開くと、拡張子を
> .TXT:BAR
> という風に末尾に代替ストリーム名が付いた状態で誤認識して設定を登録しようと
> する挙動が見られました。
と申しましたが、この状態でファイルタイプを選択してOKをクリックしたら本当に拡
張子
.TXT:BAR
として登録されてしまいました。レジストリを見ると、
HKEY_CURRENT_USER\Software\Hidemaruo\Hidemaru\.TXT:BAR
キーが作成されていました。


[ ]
RE:38927 [要望]GREPのNTFS対応No.38930
h-tom さん 21/05/19 06:45
 
h-tom です。

>上記でも述べましたがIEやEdgeでダウンロードしたファイルには自動で代替スト
>リームに
>メタ情報が保存されます。これをテキストエディタで閲覧/修正する権利は当然ユー
>>ザーに
>あります。Windowsのメモ帳でもできることが秀丸エディタではできないというのは
>ちょっと
>おかしな話です。
現状でも、秀丸エディタで閲覧も修正も出来ますよ。メモ帳と同じ方法で。
(新規作成とgrepは出来ませんけど)

代替ストリームなんて、ZoneId意外に使われている事例は見たことないですし、
ZoneId はプロパティから操作(削除)できるから、エディタで編集しようと思った
こともないです。
また、代替ストリームに対応しているソフトもすくないので、どこで欠落するか
わからなくて、代替ストリームは使い道がないという認識です。
(バックアップツールやアーカイバを使った場合の話)

[ ]
RE:38930 [要望]GREPのNTFS対応No.38931
秀丸担当 さん 21/05/19 08:49
 

名前を付けて保存のダイアログについては、Windowsの開くダイアログでエラーにな
りますが、エラーにならないようにしたり、秀丸ファイラーClassicの開くダイアロ
グであれば自前で何かしらの対応は不可能ではないと思います。
ですが名前を付けて保存だとタイプミスやコピペなどで容易に入力できてしまうので、
一般的なユーザーにとって見えない情報が簡単に出来てしまうことになるので、やめ
ておこうと思います。

[ ]
RE:38928 [要望]GREPのNTFS対応No.38932
秀丸担当 さん 21/05/19 08:53
 

ファイルタイプについては、コロンもファイルや拡張子として除外していないという
だけですが、.txt:barになってしまうと思います。
.txtとするのも変なので、.txt:barという別のファイルタイプとするほうが適切なの
ではないかと思います。

[ ]
RE:38932 [要望]GREPのNTFS対応No.38935
fzok4234 さん 21/05/20 02:31
 
> .txtとするのも変なので、.txt:barという別のファイルタイプとするほうが適切な
>のではないかと思います

さらにいくつかのパターンで動作を検証しました。ファイル名とその時の「ファイル
タイプ別の設定」上での
拡張子です。
1. abcd:efgh              => (拡張子なし)    <- 正しい
2. abcd:efgh.ijkl         => .IJKL           <- (拡張子なし)となるべき
3. abcd.efgh:ijkl         => .EFGH:IJKL      <- 正しい
4. abcd.efgh:ijkl.mnop    => .MNOP           <- .EFGH:IJKL.MNOPとなるべき
1.と3.は期待通りの動作だと思います。しかし、代替ストリーム名に「.」が含まれ
ている2.と4.のケースでは
代替ストリーム名内の「.」以降を拡張子として認識してしまいました。本来、ファ
イル名内の「.」以降を
拡張子として扱わないといけないためおかしな動作です。実際、Edgeなどでダウン
ロードしたファイルに付く
メタデータの代替ストリーム名は
Zone.Identifier
であり、「.」が含まれた名前であるため拡張子を
.IDENTIFIER
誤認識してしまいます。


[ ]
RE:38930 [要望]GREPのNTFS対応No.38936
fzok4234 さん 21/05/20 02:45
 
> 現状でも、秀丸エディタで閲覧も修正も出来ますよ。メモ帳と同じ方法で。
> (新規作成とgrepは出来ませんけど)

後から出てきた不具合を見ると、代替ストリーム付きパスに正式に対応しているとい
うよりかは
「たまたま問題なく動いているように見える」だけのような気がします。

> 代替ストリームなんて、ZoneId意外に使われている事例は見たことないですし、
> ZoneId はプロパティから操作(削除)できるから、エディタで編集しようと思った
> こともないです。
> また、代替ストリームに対応しているソフトもすくないので、どこで欠落するか
> わからなくて、代替ストリームは使い道がないという認識です。
> (バックアップツールやアーカイバを使った場合の話)

もちろん、NTFS限定の機能であるためexFatなどの別のファイルシステムフォーマッ
トにコピーすれば
簡単に失われます。このため、エンドユーザーが自発的にデータの保存先に用いるの
は不適切だと
思います。


[ ]
RE:38935 [要望]GREPのNTFS対応No.38937
fzok4234 さん 21/05/20 03:35
 
マクロのfiletypeキーワードも同様の結果となりました。
1. abcd:efgh              => "."             <- 正しい
2. abcd:efgh.ijkl         => ".ijkl"         <- "."となるべき
3. abcd.efgh:ijkl         => ".efgh:ijkl"    <- 正しい
4. abcd.efgh:ijkl.mnop    => ".mnop"         <- ".efgh:ijkl.mnop"となるべき


[ ]
RE:38931 [要望]GREPのNTFS対応No.38938
fzok4234 さん 21/05/20 08:10
 
> ですが名前を付けて保存だとタイプミスやコピペなどで容易に入力できてしまうの
>で、一般的な
> ユーザーにとって見えない情報が簡単に出来てしまうことになるので、やめておこ
>うと思います。

「開く」や「名前を付けて保存」などのダイアログで、「ファイル名」の欄での
foo.ext:bar
形式の指定の禁止は継続する一方で、代替ストリーム名を指定するための「オプショ
ンの別欄」を
設ける、というのはどうでしょうか。つまり、「ファイル名」欄には
foo.ext
とユーザーに入力させて、新設の「代替ストリーム名」欄に
bar
と入力させることで対応するということです。


[ ]
RE:38938 [要望]GREPのNTFS対応No.38939
秀丸担当 さん 21/05/20 09:14
 

代替ストリームを使うこと自体があまり無いと思うので、そこまでやらなくてもいい
かなとは思います。
必要な場合、現状のようにコマンドラインに書くか、マクロでopenfileやsaveasはで
きるので、マクロでする方法も考えられます。

[ ]
RE:38937 [要望]GREPのNTFS対応No.38940
秀丸担当 さん 21/05/20 09:14
 

確かに言われている通りになります。
たぶんですが、Zone.Identifierを考えた人が、代替ストリームを開けるアプリがあ
ったとしたら、.以降を拡張子とするだろうという思惑で、そういう名前にしたので
はないかという気がします。
実際Zone.Identifierを開いたら、拡張子があっても無くても違っても、同じ設定で
あったほうが都合がよさそうです。

[ ]
RE:38938 [要望]GREPのNTFS対応No.38941
でるもんたいいじま さん 21/05/20 09:21
 
でるもんた・いいじまです。

> 「開く」や「名前を付けて保存」などのダイアログで、「ファイル名」の欄での
> foo.ext:bar
> 形式の指定の禁止は継続する一方で、代替ストリーム名を指定するための
> 「オプションの別欄」を設ける、というのはどうでしょうか。つまり、
> 「ファイル名」欄には
> foo.ext
> とユーザーに入力させて、新設の「代替ストリーム名」欄に
> bar
> と入力させることで対応するということです。

そこまでおっしゃるのなら、代替ストリームって何それ美味しいの?という99.999%
以上のユーザーさんへの影響との兼ね合いを考えると、下記のような実装が現実的で
しようか。

@そもそも代替ストリームを使うためには、その他(O)→動作環境(E)→「上級者向け
設定(A)」オン の状態で、ツリーのどこか(「ファイル→保存」?「その他のコマ
ンド」に新しい葉をる?)で「代替ストリームへのアクセスを有効にする」にチェッ
クを入れておくことにする。

もちろん、普通にインストールしただけの場合はこのチェックは絶対にOFFにしてお
く。また、現状で抜け道的に代替ストリームにアクセスできてしまう場所については、
今のうちに洗い出しておいて、今後のことについては個別に検討する。

A上記「代替ストリームへのアクセスを有効にする」のチェックが入っている場合の
み、fzok4234さんご指摘のような「オプションの別欄」をウィンドウ内に作り込む。
ウィンドウのデザイン的には、改行コード選択のプルダウンを少し狭めれば、BOMの
有無を指定するチェックボックスとの間にテキストボックスを一つ置けそうです。

あるいは、「名前を付けて保存」ダイアログの高さを手元の環境(Windows 10、拡大
倍率100%)で測ったところ、Windows2000タイプで435px、Windows95タイプで330pxで
すから、「改行コード(R)」のプルダウンの下側に平時から1行ぶんの余白をあけてお
いて、代替ストリームに限らず各種の特殊設定項目を表示するために活用する、とい
ったデザイン変更も考えられそうです。

☆ ☆ ☆

なお私は代替ストリームについては
「自分は詳しいことを今のところ知らないし、それをデータハック用アプリの類で直
接編集したり自作アプリで読み書きしたりすることもないから、使いたい人たちの間
で好き勝手にやってくれ」
「ただ、一般人に迷惑がかかるような状況になるのは断固反対」
という立場です。

もう一つの論点、「fzok4234さんの持論」については別途。

[ ]
RE:38927 テキストエディタ「戦争」? Re:No.38942
でるもんたいいじま さん 21/05/20 10:42
 
でるもんた・いいじまです。

> あとそれからこれは持論ですが

ということで、そもそもこういう神学論争を hidesoft.2 でやるべきなのかどうか、
疑問に思います。

とりあえず turukame のほう
https://www.maruo.co.jp/turukame/
で当面は3番会議室が使えそうですし、将来的にはここで空いている8番・9番を使っ
て新しい会議室を作ってもいいかもしれません。
(1・2・7番の既存の内容をアーカイブサイトに移して、そこをまっさらにしてもい
いかも。外からリンクされているケースがどれだけあるのか検証が必要ですが…。)

☆ ☆ ☆

> 現在、周りを見渡せば
> ・サクラエディタ
> ・Notepad++
> ・VS Code
> ・vim
> ・Emacs
> といった「強敵」で溢れかえっており、

ふむ…私はどれも「強敵」だとは思っていないのですが。

たとえば、日本語の特定の新聞・雑誌のための記事を毎日仕事として書いている、と
いう人は、おそらくその仕事用にVS Codeやvimは使わないでしょう。その出版社のハ
ウス・ルールを忠実に反映した記事専用のエディタとか、一太郎とか、出先ではエデ
ィタ機能に特化した製品(上記の中ではサクラエディタやNotepad++、この中に出て
いないものではWZ、あるいはもちろん秀丸も候補ですね)を使用、というのが普通だ
と思います。

逆に、シェルスクリプトの類を記事用エディタや一太郎で書こうという人も、まずい
ないはずです。

☆ ☆ ☆

> テキストエディタ競争は「戦国時代」の真っ只中という状況です。

そんなもの、コンピュータへの文字入力が「パンチカード」から「コンソール+キー
キーボード」へと切り替わった時期(だいたい1970年ごろでしょうか…私はまだ生ま
れていません)から今までずっとそうですよ。

その時代に生まれた「歴史上最古のテキストエディタ」ことedが、今の最新OSでも現
役です:
cf. https://www.freebsd.org/cgi/man.cgi?query=ed&manpath=FreeBSD+13.0-current

そのあとUNIX界では今でもVim派とEmacs派が意地の張り合いをしている、ということ
も、fzok4234さんなら当然ご存知でしょう。私は普段のUNIX系OSでのモノカキは基本
Emacs派ですが、vi系でもそこそこ操作できますし、特にシングルユーザーモードの
場合、Vimならカーネル周りのファイルの書き換えに使っても大丈夫だろうと考えま
すが、そういう目的ではEmacsは絶対に使いません。

☆ ☆ ☆

> 油断すれば大きくシェアを奪われて大敗を期して

テキストエディタみたいに目的が決まっている製品については「シェアを奪われ」る
とか「大敗を期(ママ)」するとかいう概念は存在しません。「プラスネジ陣営が油
断していればたちまちマイナスネジやY字ネジ・六角ネジなどにシェアを奪われて
…」なんていう詭弁と全く同次元の話です。

> 最悪「秀丸エディタの開発打ち切り」という結果を招いて
> 多くのユーザーに迷惑がかかる事態につながりかねません。

いつになるのかは全く予想がつきませんが、私の存命中に「Windows版の秀丸エディ
タは、次の正式リリースとそのバグフィックスのみで開発終了となります」というア
ナウンスが出ても全くおかしくないだろう、と考えています。

でも開発が打ち切られても、ユーザが即座に秀丸を使えなくなるわけではありません。
ストアアプリみたいにセキュリティアップデートの名目で自動的に消されることもあ
りませんので、インストーラーのバイナリ(と既に発行済の鍵)があれば、些細な不
具合が放置されていることを承知の上でそのまま使い続けることができます。

実際私も、サポートが打ち切られて配布も終わっているアプリをいくつも使っていま
すし、不具合があることも分かっていますが「このアプリにしかない利点を享受する
ためには仕方がない」と割り切って使い続けています。

☆ ☆ ☆

> 生き残るためには「メモ帳でもできることが
> 秀丸エディタではできない」とかは論外で

実際問題、そんな実例はいくらでもありますよ :-)

たとえば、今はメモ帳をCOMで呼び出して色々と操作できるようですが、そのすべて
のメソッドの呼び出しに対して秀丸はメモ帳と全く同じ結果を返しますか?仮に全く
同じ結果は返さないとして、「メモ帳の挙動にすべて合わせろ」と要求するおつもり
がありますか?

> ある程度枯れた技術にはしっかりと対応した上で、

「ある程度枯れ」ていて、かつ「広く使われるようになった」技術、でしょうね。枯
れているけどほとんど誰も使っていない技術(たとえば今のご時世ならItanium系CPU
のコード最適化技術?)をわざわざサポートする理由はほとんどありません。

下で挙げておられるUnicodeはまさに「広く使われるようになった」技術の典型例だ
からクリティカル・ポイントになったのです。

(ご承知のようにローマ字世界・キリル文字世界・ギリシャ語世界のそれぞれだけで
も8bitではコードポイントが不足するというのと、日本でもNEC・DOS/V・Mac・携帯
電話各社の間での非互換の問題があったのとで、Unicodeはまさに「時代の要請」だ
ったわけで…)

☆ ☆ ☆

> 他のエディタにはない独自色

そうです。ここが最大のキーポイントです。秀丸は既に数多くの「独自色」を持ち合
わせていますし、他のエディタと比べてマイナーな機能(ここで「マイナーとは「需
要が少ない」という意味です)が1つや2つ足りない程度で簡単にお先真っ暗になると
は到底思えません。

上記のedがいまだにUNIX系OSに残っているのも、「あらゆるテキスト編集作業を、改
行(とタブ?)以外のバイナリデータを一切含まないASCIIテキストのみでリアルタ
イムに指示できる」という利点があり、逆に、廃止しないことに特段のデメリットが
ないからです。今の時代にどれだけedの需要があるかは分かりませんが。

☆ ☆ ☆

最後に、もういちどfzok4234さんの文章からキーワードを抜粋しています。

「強敵」
「テキストエディタ競争」
「戦国時代」
シェアを「奪われ」て「大敗を期(ママ)し」
「生き残る」ためには
…という「戦法」
いとも簡単に「敗戦」

こういう言葉、はっきり言ってしまえば「アナタの主観でしかないコトバ」が大量に
ちりばめられています。

大昔から今までのテキストエディタ間の競争は、たとえばWindows98のころの「Word+
Excel vs 一太郎+Lotus123」競争とは全く違うものです。どちらか片方を選んだらも
う一方は現実味を考えると諦めなければならない、という類のものではありません。

テキストエディタの世界では既にシェア争いのステージを通り過ぎて、成熟の域に達
しています。つまり、特定少数のものが「勝者=繁栄普及していくもの」でその他大
多数か「敗者=消えていくもの」になるという類のサバイバル競争に陥る心配はない
と私は考えます。

もう少し冷静になっていただきたいと思います。

[ ]
RE:38940 配信に漏れが発生したNo.38943
Iranoan さん 21/05/20 15:23
 
秀まるおさん、秀丸担当さんこんにちは、Iranoan です
本題とは全く関係ないのですが、どこに投稿すべきかわかないのでここに書き込ませ
ていただきます

メールの配送漏れが発生しました
ここの 38933-38937 が配送されてきませんでした

ご連絡までに

[ ]
RE:38943 配信に漏れが発生したNo.38944
秀まるお2 さん 21/05/20 15:56
 
> メールの配送漏れが発生しました
> ここの 38933-38937 が配送されてきませんでした

 すみません。実は僕の所にも秀丸担当の方にもその辺のメール届いてなくて、たぶ
ん全員に配信されなかったんだと思います。一応を書き込んでおきます。

[ ]
RE:38943 配信に漏れが発生したNo.38946
Leo さん 21/05/20 16:06
 
 Leoです。

>ここの 38933-38937 が配送されてきませんでした
Iranoanさん、わたしのところは、38933までは届いています。

[ ]
RE:38946 配信に漏れが発生したNo.38947
Iranoan さん 21/05/20 16:32
 
秀まるおさん、Leo さんこんにちは、Iranoan です
> >ここの 38933-38937 が配送されてきませんでした
> Iranoanさん、わたしのところは、38933までは届いています。
38933 は私のチェック・ミスでした

[ ]
RE:38942 テキストエディタ「戦争」? Re:No.38948
fzok4234 さん 21/05/20 21:40
 
> テキストエディタの世界では既にシェア争いのステージを通り過ぎて、成熟の域に
>達しています。
> つまり、特定少数のものが「勝者=繁栄普及していくもの」でその他大多数か「敗
>者=消えていくもの」に
> なるという類のサバイバル競争に陥る心配はないと私は考えます。

ただ1つだけ気になることがあって、それは近年コードエディタ競争に「VS Code」が
参入して急成長を
遂げてきていることです。viやEmacsといったLinux界の重鎮は当面安泰と思われます。
しかし、Windows用の
コードエディタとしてはVS Codeが急激にシェアを伸ばしており、他の零細エディタ
を駆逐するのではとの
不安を覚えるほどです。


[ ]
RE:38936 [要望]GREPのNTFS対応No.38949
h-tom さん 21/05/20 21:54
 
h-tom です。

>後から出てきた不具合を見ると、代替ストリーム付きパスに正式に対応していると
>いうよりかは
>「たまたま問題なく動いているように見える」だけのような気がします。
その通りすよ。
どちらかというと「問題なく動いている所もある」というところでしょう。
(で、そこを使えば閲覧と編集・保存は可能)

そもそも、秀丸エディタが代替データストリームに正式に対応しているとの記述はあ
りませんし。
(対応してないという記述もないけど)

[ ]
RE:38948 テキストエディタ「戦争」? Re:No.38950
moppu さん 21/05/20 23:53
 
moppu です。

fzok4234様の懸念は多分杞憂に終わると思いますよ。
なぜなら秀丸エディタを含むテキストエディタと VS Codeは同じ土俵になっていない
から。
・あちらはプログラム開発用途
・秀丸エディタはプログラム開発”にも使える”高機能なテキストエディタ
生まれからして違います。
でるもんた・いいじま様の仰るようにテキストエディタはあちらが立てばこちらが立
たずという代物ではありません。

ユーザが駆逐を気にしなければならないのは、独自フォーマットの保存形式のツール
です。
例えばデータベース設計用のER図作成ツールなどですが、開発停止・サポート打切り
により
当時作った図面のメンテナンスに支障をきたす場合ですね。
幸いテキストエディタはあくまでテキストエディタなので代替ツールはいくらでもあ
ります。

ユーザとしては気に入ったツールを適材適所で使えばいいと思いますよ。

[ ]
RE:38948 テキストエディタ「戦争」? Re:No.38951
でるもんたいいじま さん 21/05/21 02:50
 
でるもんた・いいじまです。

> Windows用のコードエディタとしてはVS Codeが急激にシェアを
> 伸ばしており、他の零細エディタを駆逐するのではとの
> 不安を覚えるほどです。

「コード」エディタとしては、ですよね。

ということは、VS Codeを手元のマシンにインストールする人は、同時に
@何らかの言語の処理系(典型的にはVisual Studio一式?)
Aその処理系で標準提供されている大量のライブラリ
B大規模なプロジェクトのソースコード、および画像等のリソース
Cそれらの内容に関する大量のヘルプ、ドキュメント類
を同じマシンの上に保管するわけで、それだけのスペックがあるマシンしか動作対象
としては想定していないわけです。

一方で秀丸の場合、手元の環境たと
  @c:\Program Files (x86)\hidemaru の中身 13.8MB
  Aローカルのマクロフォルダ 200KB(ストレージとしては256KB)
だけしか食っていません。
しかも秀丸には「持ち出しキット」という便利なものもあります。

あと、fzok4234さんはご存じないかもしれませんが、秀丸はいまだにWindows98/Meの
サポートを続ける方針を掲げておられます。

(以前、本体はいじらないままで秀丸のインストーラーを98/Me非対応のものに乗り
換えた際に、窓の杜さんが「とうとう秀丸も98/Me打ち切り」と大々的に記事を書い
たほどです。今のインストーラーは98/Me対応のものに戻っていて、ただしその代償
として、インストール時に使用するTempフォルダのパスに非ANSI文字が入っていると
不具合が生じます。)

このあたりからも、VS Codeが他のエディタをことごとく駆逐していくようなことは
完全に杞憂と考えます。各家庭に朝刊を届けるのに、20トン積みトレーラーを各家庭
の玄関先まで乗り付ける人がどこにもいないのと同じことです。

[ ]
RE:38948 テキストエディタ「戦争」? Re:No.38953
こみやんま さん 21/05/22 15:46
 
>コードエディタとしてはVS Codeが急激にシェアを伸ばしており、他の零細エディタ
>を駆逐するのではとの
>不安を覚えるほどです。
>
VSCodeはマイクロソフトが片手間ではなく、ガチで制作しているのと
リモートやSAAS化あるいはSAASとのハイブリッド化にも圧倒的適性を持っているので
短・中・長期 のどのスパンでみても、ユーザーが拡大し続けるのはまぁ間違いない
でしょう。

私も1998年ごろから毎日のように秀丸を使い続けていましたが、
5年ほどまえからVSCodeも並列で使うようになり、いまではほぼVSCodeです。

Githubのプライベートリポジトリが、個人、チームともに無料になったのも
めちゃくちゃデカいポイントだったでしょう。
マイクロソフトのVSCodeは、エディタと密接に連携するでかいプライベート資料サー
バーを
個人、チームに対して無料で提供しつづけます、という形になったからですね。


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

さて、代替ストリームですが、一般的にはエディタの「ファイル」としては
代替ストリーム自体を指定して読むようなものではないような。

秀丸で名指ししてオープンするなら、
代替ストリームはシェルとは比較的相性があるので、hmPSを使って
(hmPS=https://秀丸マクロ.net/?page=nobu_tool_hm_powershell)

$target_filestream = input("ファイルもしくはストリーム", "");

#PS = loaddll( hidemarudir + @"\hmPS.dll" );

#_ = dllfuncw( #PS, "DoString", R"(
$target_filestream = $hm::Macro::Var['$target_filestream']
$stream = Get-Item $target_filestream;

if ($stream.GetType().Name -eq "AlternateStreamData") {
    $hm::Macro::Var['$target_filename'] = $stream.FileName;
} elseif ($stream.GetType().Name -eq "FileInfo") {
    $hm::Macro::Var['$target_filename'] = $stream.Name;
} else {
    $hm::Macro::Var['$target_filename'] = $target_filestream;
}

)"
);

if ($target_filename != "") {
    openfile($target_filename);
} else {
    message "ERROR";
}

//----------
とかにしますかねぇ。



[ ]