URL中の ( )	No.22467
tomtom さん　07/01/29 13:57
リンク機能についてですが、URLの中に「()」が含まれる場合、そこから先がURLとして 認識されません。RFC的には「()」も問題ないと思うのですが。 wikipediaなどでは頻繁に「()」を含むURLが存在しており、メールに引用してある 場合など不便を感じますので、修正して頂けるとありがたいです。 例: http://ja.wikipedia.org/wiki/%E3%81%B2%E3%81%8B%E3%82%8A_(%E5%88%97%E8%B B%8A)

[ △ ]

RE:22467 URL中の ( )	No.22468
tomtom さん　07/01/29 14:04
書き忘れました。 カスタマイズで()を加えればもちろん正常に認識されます。 デフォルトでの設定がRFCと違っている、ということで修正をお願いしたく。 (実は再インストール時に、この件を忘れてて「あれ?」となっただけなんですが)

[ △ ]

RE:22468 URL中の ( )	No.22470
秀丸担当 さん　07/01/29 14:59
>書き忘れました。 >カスタマイズで()を加えればもちろん正常に認識されます。 >デフォルトでの設定がRFCと違っている、ということで修正をお願いしたく。 >(実は再インストール時に、この件を忘れてて「あれ?」となっただけなんですが) 修正の記録によればV4.10β31で括弧も認めるように修正していたようです。 ですがたぶんすぐに苦情があって、V4.11で括弧は認めないようにしました。 そして様々な要望にも応えられるようにカスタマイズできるようにしたという経 緯なので、カスタマイズを既に使われていたのなら、カスタマイズのほうを使っ てほしいです。

[ △ ]

RE:22470 URL中の ( )	No.22474
tomtom さん　07/01/29 23:03
>修正の記録によればV4.10β31で括弧も認めるように修正していたようです。 >ですがたぶんすぐに苦情があって、V4.11で括弧は認めないようにしました。 >そして様々な要望にも応えられるようにカスタマイズできるようにしたという経 >緯なので、カスタマイズを既に使われていたのなら、カスタマイズのほうを使っ >てほしいです。 既に決定事項となっているならば仕方ありませんが、「本来ならば」RFC準拠の方を 優先すべきで、「そこから外れる使い方」の方を各自がカスタマイズするべきなので は…… 経緯を知らない者から見ると、なんか本末転倒という印象がします。

[ △ ]

RE:22474 URL中の ( )	No.22475
EA11R さん　07/01/30 00:18
EA11R＠一般ユーザです。 >既に決定事項となっているならば仕方ありませんが、「本来ならば」RFC準拠の方を >優先すべきで、「そこから外れる使い方」の方を各自がカスタマイズするべきなので >は…… >経緯を知らない者から見ると、なんか本末転倒という印象がします。 「本来の」エディタとしての「編集機能」に不便が生じてもRFC準拠の方を優先 すべきですかね? 「本来の」エディタとしての「編集機能」に優先すべきだと思いますが。 ってことで、とんがったオプションとして、 「URLの選択はRFC完全準拠(カスタマイズ不可)」 ってなオプションを用意する、ってのはどうでしょうかね? これを選択したことで、編集時にURL箇所の誤認識をするなど、編集能力に不便 が生じたとしても、RFC準拠を選択したことによる弊害だから、本人の責任って ことになるんじゃないでしょうか。

[ △ ]

RE:22474 URL中の ( )	No.22477
アルビレオ さん　07/01/30 00:49
ユーザーのアルビレオです。 >既に決定事項となっているならば仕方ありませんが、「本来ならば」RFC準拠の方を >優先すべきで、「そこから外れる使い方」の方を各自がカスタマイズするべきなので >は…… >経緯を知らない者から見ると、なんか本末転倒という印象がします。 世の中にはRFC準拠になっていないURLに満ち溢れていますから… webブラウザがRFC準拠のURLしか受け付けなければ「とても使い物にならない」 という評価になってしまうのが現実です。 インターネットにアクセスする機能を持たないテキストエディタがRFCにこだわ っても大した影響力はなく、不便になるだけだと私は思います。

[ △ ]

RE:22477 URL中の ( )	No.22478
秀丸担当 さん　07/01/30 10:01
>既に決定事項となっているならば仕方ありませんが、「本来ならば」RFC準拠の方を >優先すべきで、「そこから外れる使い方」の方を各自がカスタマイズするべきなので >は…… >経緯を知らない者から見ると、なんか本末転倒という印象がします。 括弧は、例えば 　秀まるおのホームページ(http://hide.maruo.co.jp/) というような書き方をする人もいるようなので、不便なことがあるのではないか と思います。 RFC準拠という話であれば、プレーンテキスト中に書く場合は<>や""で囲うこと が推奨されているようで、秀丸エディタもそれに対応します。 囲えば括弧もURLとして認めます。 囲った場合半角空白や改行を無視して次の行と連結して解釈するべきのようです がそれには対応してないです。 まあ、<>の判断と似た方式で、逆にhttpの前の文字が「(」で始まる場合だけ認 めないというのもありかもしれないですが。

[ △ ]

RE:22475 URL中の ( )	No.22479
tomtom さん　07/01/30 13:01
まぁ、あまり長々議論しても仕方のない話ですが、意図が伝わっていないようなので >「本来の」エディタとしての「編集機能」に不便が生じてもRFC準拠の方を優先 >すべきですかね? >「本来の」エディタとしての「編集機能」に優先すべきだと思いますが。 誰もカスタマイズ機能を無くせ、などとは書いてませんよ。 私は単に初期インストール時点でのデフォルト設定の話をしているだけで、「()」を URLから 外したい人はそうすればいいでしょう。 「編集機能」には何も変わりはありません。 >ってことで、とんがったオプションとして、 >「URLの選択はRFC完全準拠(カスタマイズ不可)」 >ってなオプションを用意する、ってのはどうでしょうかね? >これを選択したことで、編集時にURL箇所の誤認識をするなど、編集能力に不便 >が生じたとしても、RFC準拠を選択したことによる弊害だから、本人の責任って >ことになるんじゃないでしょうか。 全く意味がありません。 この選択肢を用意しても誰にも「メリット」は発生しません。 むしろ、「ことの経緯」を知っている既ユーザにとっては、「RFC準拠仕様」をデフ ォルトに しても何の不都合も内容に思えるのですが……? そういう用途のためにカスタマイズ機能が装備されたことを知ってるんですし。 私が書いたのは、これが例えばフリーソフトだったら、作者の好みでどのような仕様を 採用しようが自由なのですが、有料の商用ソフトで「非標準」な仕様をデフォルトと して 採用しているってのはどうかな、と感じたためです。 古くからのユーザの要望に答えた結果が現在の仕様で、それなりに意味はあるものだと 理解しますが、逆に新規のユーザから見れば直感的に受け入れられる仕様でないことも 事実でしょう。 (URL抽出の仕様がRFC非準拠であることはヘルプにも書かれていませんし、カスタマイズ の方法も直感的にはたどり着きにくい場所になってしまってると思いますし……これは 超多機能化の弊害ですが) 私自身、96年以来秀丸エディタを使用している「古いユーザ」ではありますが、「商用 ソフト」である以上、デフォルト設定を「非標準既ユーザ要望仕様」にしてしまうこ とには ちょっと抵抗を感じた次第。 ともあれ、この辺の判断はメーカーの「商品」に対する考え方の問題なので、「そう 決定した」 ということでしたら、どちらでもいいと言えばいいんですけどね。 私自身には特に実害はないので。 最近 OSから再インストールしたことろ「あれ? おかしいな」と感じた 疑問を尋ねただけの話です。 前述のとおり、「そういう(特殊な)仕様にしている」とはどこにも書かれていないの ですから、 バグを疑うのが自然かと。

[ △ ]

RE:22479 URL中の ( )	No.22480
秀丸担当 さん　07/01/30 14:11
なんだか秀丸エディタだけ標準ではないかのようですが、他のソフトをいろいろ 見てみても、括弧をURLに認めないのが一般的のようです。 代表的なものではOutlookExpressやVista標準のメールソフトでも括弧はダメで した。 <>で囲う書き方に対応しているのは秀丸エディタ以外には確認できませんでした。 そんでもってここまでカスタマイズできるのも秀丸エディタくらいのものではな いでしょうか。 （あと秀丸メールも） 秀丸エディタだけ標準ではないと思わずに秀丸エディタユーザーだからこそいろ いろできると思っていただけたらと思います。 別のコメントにも書きましたが括弧を認めると弊害はあります。 秀まるおのホームページ(http://hide.maruo.co.jp/) http://hide.maruo.co.jp(秀まるおのホームページ) とか。 ついでに現在β版のV6.50βでは http://日本語.jpという書き方にも対応してい ます。

[ △ ]

RE:22479 URL中の ( )	No.22481
EA11R さん　07/01/30 14:20
僕の意図も伝わってませんね。 >>「本来の」エディタとしての「編集機能」に不便が生じてもRFC準拠の方を優先 >>すべきですかね? >>「本来の」エディタとしての「編集機能」に優先すべきだと思いますが。 > >誰もカスタマイズ機能を無くせ、などとは書いてませんよ。 >私は単に初期インストール時点でのデフォルト設定の話をしているだけで、「()」を >URLから >外したい人はそうすればいいでしょう。 >「編集機能」には何も変わりはありません。 あくまでもエディタだ、と言う認識をしなきゃいけないってことなんですが。 エディタである以上、URLなどの判断に厳格性を求めるなきゃいけませんか。 だったらメモ帳を使えって言われるかも知れませんけど。 ()もデフォルトで判断させることで、英単語の判定に影響がでない、とあなたは 言えますか? 実際、書く文書の90%以上が英文の人間にとっては、()が含まれた時点でのβで は非常に不便でしかありませんでしたから。 シェアウェアだから、といって、RFCで規定されているカテゴリはRFCに準拠すべ きだ、なんてのは、いきすぎでは? >>ってことで、とんがったオプションとして、 >>「URLの選択はRFC完全準拠(カスタマイズ不可)」 >>ってなオプションを用意する、ってのはどうでしょうかね? >>これを選択したことで、編集時にURL箇所の誤認識をするなど、編集能力に不便 >>が生じたとしても、RFC準拠を選択したことによる弊害だから、本人の責任って >>ことになるんじゃないでしょうか。 > >全く意味がありません。 >この選択肢を用意しても誰にも「メリット」は発生しません。 >むしろ、「ことの経緯」を知っている既ユーザにとっては、「RFC準拠仕様」をデフ >ォルトに >しても何の不都合も内容に思えるのですが……? >そういう用途のためにカスタマイズ機能が装備されたことを知ってるんですし。 RFC準拠の厳格なURL判定を要求するユーザにとっては、メリットはありますね。 メリットがない、と言うのは、そう言うユーザが少ない、と言う事を認識してい るからでは? むしろ、「ことの経緯」を知っている既ユーザにとっては、「RFC準拠仕様」を デフォルトにしなくても何の不都合も内容に思えるのですが……? そういう用途のためにカスタマイズ機能が装備されたことを知ってるんですし。 と言いかえます。 # カスタマイズ箇所を探すのに非常に疲れますけど。 何かうまく対応死すると言うことなので、そのベータを見て、使って見て、それ からですけど。 >私自身、96年以来秀丸エディタを使用している「古いユーザ」ではありますが、「商用 >ソフト」である以上、デフォルト設定を「非標準既ユーザ要望仕様」にしてしまうこ >とには >ちょっと抵抗を感じた次第。 ブラウザなら同感ですけどね。 しょせん僕は、Windows3.1初期の頃からの新しいユーザですから、より古いユー ザのあなたの意見が強いかもしれません。

[ △ ]

RE:22478 URL中の ( )	No.22482
Iranoan さん　07/01/30 17:04
秀丸担当さん今日は、Iranoan です。 > まあ、<>の判断と似た方式で、逆にhttpの前の文字が「(」で始まる場合だけ認 > めないというのもありかもしれないですが。  「RFC に出来るだけ準拠」という意見も解らないではないので、これを機会 に一度見直しても良い気もします。 　現状ですと、括弧の扱い以外にも (1) 例えば、       http://hide.maruo.co.jp/, http://www.hidemaru.interlink.or.jp/       を御覧ください     と文章があった場合、最初の「,」も URL の一部の扱いになる     +空白が無ければ、行全体が一つの URL に (2) 逆に       sample0.txt, sample1.txt を参照     とあった場合、最初はファイル名の扱いにならない (3) ファイル名だけをカスタマイズをした場合、優先順位の関係で       hoge@hoge-hoge.co.jp       ^^^^^^^^^^     とあった場合、下線部だけがメールアドレス扱いになる     　カスタマイズの有無にかかわらず優先順位は     URL > メールアドレス > ファイル名     の方が良い気がする。全てを上手く設定すればよいのでしょうが...。 といった違和感があります。 　(1), (2) の句読点については、改行や空白の直前にあるなら、その句読点 自身の直前までも URL やファイル名の扱いにしても問題無い気がします。 　実際はどうなんでしょう?→特にアルファベットのみの文章を多用する人 　どちらにしても、理論的に正確な判定が出来ても、速度が遅ければ実用的で ないので、現状のままでも仕方がないとは思います。

[ △ ]

RE:22482 URL中の ( )	No.22483
EA11R さん　07/01/30 20:48
EA11R@一般ユーザです。 >　現状ですと、括弧の扱い以外にも >(1) 例えば、 >      http://hide.maruo.co.jp/, http://www.hidemaru.interlink.or.jp/ >      を御覧ください >    と文章があった場合、最初の「,」も URL の一部の扱いになる >    +空白が無ければ、行全体が一つの URL に >(2) 逆に >      sample0.txt, sample1.txt を参照 >    とあった場合、最初はファイル名の扱いにならない >(3) ファイル名だけをカスタマイズをした場合、優先順位の関係で >      hoge@hoge-hoge.co.jp >      ^^^^^^^^^^ >    とあった場合、下線部だけがメールアドレス扱いになる >    　カスタマイズの有無にかかわらず優先順位は >    URL > メールアドレス > ファイル名 >    の方が良い気がする。全てを上手く設定すればよいのでしょうが...。 >といった違和感があります。 > >　(1), (2) の句読点については、改行や空白の直前にあるなら、その句読点 >自身の直前までも URL やファイル名の扱いにしても問題無い気がします。 >　実際はどうなんでしょう?→特にアルファベットのみの文章を多用する人 (1) は http://hide.maruo.co.jp/ と http://www.hidemaru.interlink.or.jp/ の方が良いですけどね。 こう言うケースは、ほとんど扱わないので、なんとも言えませんけど。 (2) は、関連付けがうまくいってないせいか、ダブルクリックしてもファイルが 開かないので、OFFにしてますが、(1)と同様にファイル名として扱ってあげた方 が便利な人は多い気はしますが。 (3) のケースは使ったことがないので分かりません。 ただ、少なくとも、エディタである以上は、文章として見た場合に、URL/メール アドレス/ファイル名などの判定範囲の扱いは、あくまでも文章の一部として見 た場合に、自然なケースが多い方をデフォルトとして選んだ方が良いと思います が。

[ △ ]

RE:22483 URL中の ( )	No.22484
秀丸担当 さん　07/01/31 09:46
>>(1) 例えば、 >>      http://hide.maruo.co.jp/, http://www.hidemaru.interlink.or.jp/ >>      を御覧ください >>    と文章があった場合、最初の「,」も URL の一部の扱いになる >>    +空白が無ければ、行全体が一つの URL に これは微妙なところですね。 別のコメントでOutlookExpressは括弧を認めないと書きましたが、句読点などの 記号が最後の文字かどうかで判断しているようでした。少し勘違いでしたすみま せん。 そうだとしてもやっぱりtomtomさんの最初に示されたURLは正しく認識できない わけですが。 「,」の場合は、()で囲われているかどうかで判断するという案も適用できない ので、これこそ両立させるのは困難のようです。 >>(2) 逆に >>      sample0.txt, sample1.txt を参照 >>    とあった場合、最初はファイル名の扱いにならない これは「,」があってもファイル名と判断したほうがよさそうです。 修正します。 >>(3) ファイル名だけをカスタマイズをした場合、優先順位の関係で >>      hoge@hoge-hoge.co.jp >>      ^^^^^^^^^^ >>    とあった場合、下線部だけがメールアドレス扱いになる >>    　カスタマイズの有無にかかわらず優先順位は >>    URL > メールアドレス > ファイル名 >>    の方が良い気がする。全てを上手く設定すればよいのでしょうが...。 これは現時点においてはうまいことカスタマイズしてファイル名先頭より前に@ がある場合は認めないとか、そういうふうにするしかないです。 自動判定においても優先順位が変動しているわけではなく、そういった感じで判 定していたと思います。

[ △ ]

RE:22484 URL中の ( )	No.22486
Iranoan さん　07/01/31 13:53
秀丸担当さん今日は、Iranoan です。 > >>(2) 逆に > >>      sample0.txt, sample1.txt を参照 > >>    とあった場合、最初はファイル名の扱いにならない > > これは「,」があってもファイル名と判断したほうがよさそうです。 > 修正します。 　有り難うございます。 > >>(3) ファイル名だけをカスタマイズをした場合、優先順位の関係で > >>      hoge@hoge-hoge.co.jp > >>      ^^^^^^^^^^ > >>    とあった場合、下線部だけがメールアドレス扱いになる <snip> > これは現時点においてはうまいことカスタマイズしてファイル名先頭より前に@ > がある場合は認めないとか、そういうふうにするしかないです。 　そうなんですよね。 > 自動判定においても優先順位が変動しているわけではなく、そういった感じで判 > 定していたと思います。 　ファイル名をカスタマイズしなければ起きないので、優先順位で変化が起き ているかと思いました。出来ればこれらは URL やメール・アドレスで最長一 致させると自然な印象になるのではないでしょうか?

[ △ ]

RE:22486 URL中の ( )	No.22489
秀丸担当 さん　07/01/31 17:54
>　ファイル名をカスタマイズしなければ起きないので、優先順位で変化が起き >ているかと思いました。出来ればこれらは URL やメール・アドレスで最長一 >致させると自然な印象になるのではないでしょうか? あまり特別なルールを作るとややこしいことになりそうなので、このままとして おきたいです。 やるとしたら、たまに要望のある優先順位の変更をできるようにしたほうがいい です。

[ △ ]

RE:22489 URL中の ( )	No.22491
Iranoan さん　07/02/01 02:07
秀丸担当さん今日は、Iranoan です。 > あまり特別なルールを作るとややこしいことになりそうなので、このままとして > おきたいです。 　解りました。

[ △ ]

---