なるほどー超漢字やMS-DOSで困りますねーこれは大変だ
確かに判定基準が微妙だなと思っていたので何か考えたいですね。

httpから始まることを条件にするのは一見完璧なんですが、現状相対パスでも実は動いてしまうので、影響がないか確認する必要があります。あとはanonymouse ftpとか行けたと思うんですが、これは多分使ってないと思うのでいいかな…

FileTestもうまく動くとは思うんですが、存在しないファイルを指したローカルパスの時に判定を誤るのと、このためにファイルの存在確認するのなんか変な感じがします。

明日なんか実装してみますね

ちょっと待って。0.04時間で解決は無理ぃ。

・kagura1050 ておさんのパッチについて＆所感

頂いたパッチはこのチケットに対するもので間違いないです。

改善点としては、ドライブレターが小文字の場合も対応したいなと言うところです。

Windowsのパスという観点だとUNC(\\localhost\dir)の対応も必要だと思ってます。
また、Windowsでは頭にパス区切りが来た場合、カレントドライブのルートを示す（相対パスの一種）ので、そこも救う必要があるなぁとか思いました。

真面目に考えると結構深い問題です。（こだわりすぎかも）

・今後の対応について相談

チケット切っておいてなんなのですが、本件はWindowsへの対応ということで、原則Windowsはサポートしないと言うmikutter開発のポリシーに反するかと思っています。

マージにあたり、どんなアプローチがお好みでしょうか。

　(1)えいやっとmikutterの一部にしてしまう。

　(2)Plugin::Photo::Photo::[]の中のメソッド分割をいい感じにしておいて、Windowsの対応はmikutter-windowsの様なサードパーティプラグインがモンキーパッチすることにする。

　(3)Plugin::Photo::Photo::[]の中の処理をgemに切り出して、mikutter本体にWindows依存の処理が入らないようにする。

・Plugin::Photo::Photo::[]の仕様について確認

現状、相対パスを渡すとnilになっちゃいますけど、意図した挙動でしょうか。（絶対パスのみサポートみたいな）

チケット切っておいてなんなのですが、本件はWindowsへの対応ということで、原則Windowsはサポートしないと言うmikutter開発のポリシーに反するかと思っています。

Windowsだから対応しないというわけではなくて、個別のOSへの対応はサードパーティプラグインでやるべき（できるようにすべき）と考えています。そのうえで、今のローカルファイルパスの判定は雑すぎると思っているので、何らかの修正を行ってもいいかなと思いました。

(2)Plugin::Photo::Photo::[]の中のメソッド分割をいい感じにしておいて、Windowsの対応はmikutter-windowsの様なサードパーティプラグインがモンキーパッチすることにする。

これいいですね。もっと極端なOSでもなんとかなりそうです。
ローカルパスの判別を行いたいのは将来Photo以外でもありそうなので、このチケットを見てどうしようかなと思っていました。
細かい話をすると、メソッドではフィルタを作り、OS毎のプラグインでカスタマイズさせるのが良いと思います。そういうことですよね。

・Plugin::Photo::Photo::[]の仕様について確認

現状、相対パスを渡すとnilになっちゃいますけど、意図した挙動でしょうか。（絶対パスのみサポートみたいな）

そのとおりです。相対パスを考慮する必要はありません。

ちょっと待って。0.04時間で解決は無理ぃ。

https://twitter.com/toshi_a/status/917861085293682688

0001-Retriever-URI-URI-uri_filter-refs-954.patch を適用したところ、起動できるようになりました。
Windows 向けの拡張を用意していないため、投稿アイコンなど一部アイコンが notfound.png に正しくなっています。

クラッシュしないようになったのはいいですね。 #954-8 ではWindowsむけの対応は入れていませんが、画像がないならないでnot foundになったほうがいいと思います。
しかし、特にこの変更で振る舞いが大きく変わることはないと考えていたのですが、どうしてこのような振る舞いの違いが発生したかちょっと気になりますね。
Windows持ってる人で追いかけられる人がいたら調べてほしいです。

拙いRuby力(+pデバッグ)で見た感じではload_pixbufでifnoneが(少なくとも)一部のパスとあひる焼きの飯テロ画像で出力されてる感じですかね
それ以上のことはちょっとわかんなかったです

僕の環境でも同様になることを確認しました
同じ例として一応報告します。

1. パッチ（0001-Retriever-URI-URI-uri_filter-refs-954.patch）が当たったmikutterむけにwindowsのパスを解決できるプラグイン
   作りました。
   windows_local_file_path
   ただし、これを適用しても現状は動きません。
   問題は2つあります。
   1. mikutter内部のファイルパスの正規表現が間違っている
      これに関してはすでに解決済みなので、私の環境では起きませんがパッチを当てないとそもそもこのプラグインまでuri文字列が渡されることはありません。
   2. URI 文字列がメタ文字として処理されてしまっている
      

      >>> uri = "C:\Users\ahiru\.mikutter\plugin\windows_local_file_path" 
      uri.match(%r<^[a-zA-Z]+:>)
      #<MatchData "C:">
      >>> uri = "C:\Users\ahiru\.mikutter\plugin\windows_local_file_path" 
      uri.match(%r<^[a-zA-Z]+:\\>)
      nil
      >>> uri = 'C:\Users\ahiru\.mikutter\plugin\windows_local_file_path'
      uri.match(%r<^[a-zA-Z]+:>)
      #<MatchData "C:">
      >>> uri = 'C:\Users\ahiru\.mikutter\plugin\windows_local_file_path'
      uri.match(%r<^[a-zA-Z]+:\\>)
      #<MatchData "C:\\">
      

      
      バックスラッシュ一つで区切られている場合、ruby がメタ文字として処理してしまい C:Users\ahiru\hoge が C:Usershiruhoge と豆腐に変換されてしまい区切り文字はメタ文字とともに亜空間に消えます。
      これが解消されればプラグインとしては正常に動くことを確認しています。
      今はこれの解消方法をどうしようか悩んでいるので、この辺わかりそうな人はヘルプをお願いします。
2. 議論
   ここでやってる
3. パッチを書き換え
   0001-Retriever-URI-URI-uri_filter-refs-954.patch では ファイルパスの正規表現に誤りがあったため、手元で修正しています。あとでこのスレッドに追加パッチとしてアップします。
   変更内容的には以下の通りです。
   

   - if uri.is_a?(String) && uri.match(%r<\A\w+:>)
   + if uri.is_a?(String) && uri.match(%r<\A\w+://>)
   

   
   上記変更を二か所に追加することでfilterにuri文字列が来るようになりました。
   詳しくはパッチ投げた時に説明します。

パッチ 0001-Retriever-URI-URI-uri_filter-refs-954.patch で進みそうなので topic/954-generic-path-to-uri-converter を作成しパッチを適用しました。
#954-17 のパッチの変更は妥当だと思うので、このブランチにmergeしてpushしてください。

#954-16 1.b.

URI 文字列がメタ文字として処理されてしまっている

これはRubyの仕様で、コード内に文字列リテラルをダブルクォートを用いて書くと、バックスラッシュ記法が有効になります。

https://docs.ruby-lang.org/ja/latest/doc/spec=2fliteral.html#string

\a はこれによるとベルです。バックスラッシュそのものをStringに含めるには \\ という記法を用いるため、 C:\Users\ahiru\hoge を内容として持つ文字列をRubyの文字列リテラルを用いて表現するには "C:\\Users\\ahiru\\hoge" と記述するか、バックスラッシュ記法を無視するシングルクォートを利用します。

puts "C:\Users\ahiru\hoge" 
puts 'C:\Users\ahiru\hoge'
puts "C:\\Users\\ahiru\\hoge" 

C:Usershiruhoge
C:\Users\ahiru\hoge
C:\Users\ahiru\hoge

これはRubyの文法であって、IOやGtkウィジェットによる入出力には当然影響しないので、そもそも問題は発生していないんじゃないでしょうか。

マージしてプッシュしました。

URI 文字列がメタ文字として処理されてしまっている

なるほど
出力がそう見えてただけなんですね。

Windows 用のプラグインの修正もして、読み込みエラーになっていたものは全て解決されたようです。

Windows 用のプラグインの修正もして、読み込みエラーになっていたものは全て解決されたようです。

となると、最後に残るのは、各プラットフォームに対応するプラグインをどのように提供するか、という話になってきますね。

私の意見では、unixパス向けに uri_filter フィルタをhookする新たなプラグインを作成しバンドルすべきだと思っています。
そのプラグインは file_path のような、プラットフォームの名前（unixなど）を含まないslugにしておいて、display_requirementsのように、ユーザやディストリビュータが必要に応じて同じslugをもつサードパーティプラグインで上書きするのが良いと思います。

この変更によってWindowsやその他プラットフォームで発生している問題があれば教えてください。とくに、この変更によってLinuxでの動作に問題が出てはいけないので、Linuxでの報告も欲しいです。

unix向けのパスフィルタプラグインというと、現在のphotoに実装されているものを１プラグインとして外に出すという認識でいいですか？
それでいい場合はサクッと作ります。
ついでにWindowsのファイルパスプラグインのスラグを変更して統一します。

unix向けのパスフィルタプラグインというと、現在のphotoに実装されているものを１プラグインとして外に出すという認識でいいですか？

そのとおりです。俺がやろうと思ってましが、週末はあまり余裕なさそうなのでやってみてもらっていいですか

プラグインを作るだけ作りました。
UNIX用ファイルパスプラグイン
Windows用ファイルパスプラグイン

あとで動作検証します。

UNCは知らなかったです。
GitHubのリポジトリもできたことですし、そちらのissueとします。

1. topic/954-generic-path-to-uri-converter ブランチに unixファイルパスの実装をはずすパッチを適用
2. UNIX, Windows環境で動作しない部分が出てくるのを確認
3. UNIX環境にプラグインを入れて動作することを確認
4. Windows環境にプラグインを入れて動作することを確認

上記動作確認したらブランチにプッシュしといた方がいいですかね（UNIXパスの記述削除

あとプラグインの.mikutter.ymlの方は対象のmikutterバージョンを厳密に定義しようと思うのですが、3.5.14でいいしょうか。（リリースされるまでは検証のため3.5.13とかにしておきます

上記動作確認したらブランチにプッシュしといた方がいいですかね（UNIXパスの記述削除

これは俺がやります。Divaとのmerge作業が単純にはできないためです。

あとプラグインの.mikutter.ymlの方は対象のmikutterバージョンを厳密に定義しようと思うのですが、3.5.14でいいしょうか。（リリースされるまでは検証のため3.5.13とかにしておきます

これは実際にリリースできるまではバージョン分かりませんが、specファイルに書くのはロードしてほしくないバージョンを指定するためで、今回のプラグインは古いmikutterでロードしてもエラーになったりしないので、厳密に書く必要はないと思います。

確認作業完了しました。
問題なく動いているようでした。

1. topic/954-generic-path-to-uri-converter ブランチに unixファイルパスの実装をはずすパッチを適用
   面倒だったので該当箇所をコメントアウト
2. UNIX, Windows環境で動作しない部分が出てくるのを確認
   Linux環境でも #954-13 と同様の現象を確認できた
3. UNIX環境にプラグインを入れて動作することを確認
   通常どおり画像が読み込めるようになったのを確認
4. Windows環境にプラグインを入れて動作することを確認
   Windows環境でも念のため上記の確認をしたが、想定通りの動作でプラグインを入れることで動作を確認

Retriever::URIでのパスの評価結果忘れてたので後でやります。

Retriever::URIも意図したスキーマが取得できたので問題ないようです。

• Windows系
  

  Retriever::URI("c:/perl").scheme #=> 'file'
  Retriever::URI("c:\\perl").scheme #=> 'file'
  Retriever::URI("/tmp").scheme #=> not URI
  Retriever::URI("http://example.com/").scheme #=> 'http'
  

• UNIX系
  

  Retriever::URI("c:/perl").scheme #=> not URI
  Retriever::URI("c:\\perl").scheme #=> not URI
  Retriever::URI("/tmp").scheme #=> 'file'
  Retriever::URI("http://example.com/").scheme #=> 'http'
  

hotfix/3.5 確認しました。
akkiesoft, kagura1050, shibafu528 も確認してくれました。
このチケット閉じるタイミングで #1071 も閉じておきますか？