ishikawa それって、IRC的にコマンドだと解釈されちゃってるだけじゃないですか？
limechatとかでも'/'から始まる言葉は入力出来ないです。
ishikawa ふつーの発言用の input も / ではじめると コマンドとして解釈する仕様だっけ?
/join #aaa
とふつーに発言したら #aaa に join した。
だとすると、チャネル一覧に出してる 「コマンド入力」のあれって、要らなくないだろか?
今は普通の発言でも / で始まるものはコマンドとして解釈してしまっています。
チャンネル一覧画面のコマンド送信は、どのチャンネルにも join していない状態や、 わざわざチャンネル表示まで行かなくてもコマンド送信出来るようにと追加しました。
一覧画面にコマンド送信があるので、チャンネルでの発言をコマンドとしては解釈しないようにしてもいいのかもしれません。
「"/"で始まる文字列はコマンドだと解釈する」ってのは多くのIRCクライアントで実装されている機能だと考えるのが一般的であｈないかと思います。考え方はいろいろあると思いますが、keitaircもIRCクライアントでしょうから、実装されていてもなんら不思議はないです。少なくともこのチケットのタイトルにある「できない」のは、そういう仕様だから、いうのは間違いないでしょう。
「コマンド送信が別途できるんだから、そんな機能はいらない」というのは正しいと思いますが、それと同じくらい「"/"で始まる文字列はコマンドと解釈されるのが当然であり、機能が無くなるのは困る」というのも正しいと思ってます。
個人的にはあまり使わない機能ですが、無くなったら（ごくまれに）困るだろうな、とは思います。これさえ使えたら、最悪なんとでもできるので：）
ishikawa nyan_ への返信
今は普通の発言でも / で始まるものはコマンドとして解釈してしまっています。 チャンネル一覧画面のコマンド送信は、どのチャンネルにも join していない状態や、 わざわざチャンネル表示まで行かなくてもコマンド送信出来るようにと追加しました。 一覧画面にコマンド送信があるので、チャンネルでの発言をコマンドとしては解釈しないようにしてもいいのかもしれません。
ふむ、なるほど つまり「仕様である」ということですね。
で、そうするとじゃぁ 現状だと
/dev/zero
とだけ発言したい場合は現状どうすればいいんでしょう? (まさか priv コマンドでとかいう話になってしまう?)
ishikawa matusita への返信
「"/"で始まる文字列はコマンドだと解釈する」ってのは多くのIRCクライアントで実装されている機能だと考えるのが一般的であｈないかと思います。考え方はいろいろあると思いますが、keitaircもIRCクライアントでしょうから、実装されていてもなんら不思議はないです。
はい、それはそう思います、不思議ではないです。
ただ、個人的にはあのUIは最悪(というか、現時点では必然性がないUI)だと思ってます。
少なくともこのチケットのタイトルにある「できない」のは、そういう仕様だから、いうのは間違いないでしょう。
nyan_さんが言ってるように、現時点で仕様なのは了解です。
「コマンド送信が別途できるんだから、そんな機能はいらない」というのは正しいと思いますが、それと同じくらい「"/"で始まる文字列はコマンドと解釈されるのが当然であり、機能が無くなるのは困る」というのも正しいと思ってます。
んー? 後者は「当然」なんでしょうか?
古くからある今となっては必然性がないUIをひきづってる/こだわってるだけじゃないんですか?
個人的にはあまり使わない機能ですが、無くなったら（ごくまれに）困るだろうな、とは思います。これさえ使えたら、最悪なんとでもできるので：）
「これさえ使えたら、最悪なんとでもできる」のにはもちろん同意(わら
なんですが、「無くなったら困る」という状況がわかりません。 そのために、(最悪どうにかできるように)チャネルリストに「コマンド入れるとこ」があるんだと思ってたのですが、 「/ではじまる通常の発言をコマンドとして解釈する機能が無くなったら困る状況」を具体的に教えてください。
また 逆に、「/ではじまる通常発言をコマンドとして解釈する」になってることで / で始まる語を発言できない (もちろん /privmsg コマンドとか入れればできなくはないでしょうが、それは本末転倒でしょう)状況になってる 「困る状況」が発生しちゃってるように思うんですが、これはどうなんでしょう?
そもそもkeitaircでircコマンドを発行しないといけない状況がそうそうあるとは思えないのに対して、 一部の発言を特殊に扱ってしまう結果、素直には発言できない状況が発生しちゃってる ってのは、 generic な irc クライアントならともかく keitairc という、想定使用状況をだいぶ絞っているircクライアント として考えると、仕様としてバランスがわるいように思えます。
ishikawa への返信
{{{ /dev/zero }}} とだけ発言したい場合は現状どうすればいいんでしょう? (まさか priv コマンドでとかいう話になってしまう?)
たとえばlimechatとかだと、はじめに一個スペース入れたりしてますが、それでいいのではないかと個人的には思います。
ishikawa None への返信
ishikawa への返信
{{{ /dev/zero }}} とだけ発言したい場合は現状どうすればいいんでしょう? (まさか priv コマンドでとかいう話になってしまう?)
たとえばlimechatとかだと、はじめに一個スペース入れたりしてますが、それでいいのではないかと個人的には思います。
まず、「(スペース)/dev/zero」を入力した場合はkeitaircだと「/dev/zero」にはならずに、「(スペース)/dev/zero」になってしまうので (つまり 「/dev/zero」と入力する方法がないので)仮にそういう解決をするなら現状の動作を要修正ってのが一点。
あとそもそもそのUIって、ircIIとかいにしえのirc clientがそうだったのをひきずってるだけですよね? (で、まぁ CUI ベースというか GUI 的ではないというかの時代だったので、いにしえのそのころは、 そのUIに必然性はあったけど、現時点では「かつてそうでした」という意味以上のものはない)
「一文字多く入力する」
という操作は ケータイ においては コストの高い操作なので それをディフォルトにすることには強い抵抗を感じます。
「一文字多く入力する」 という操作は ケータイ においては コストの高い操作なので それをディフォルトにすることには強い抵抗を感じます。
これに関してはすごく同意ですが、 一般的なIRCクライアントで、
「入力欄ではコマンドが使える」
という機能があるので、それを消してまでそこにこだわる必要はないのではないかと思います。
コマンドが使えるのがIRCクライアント界隈（そんなのあるのか？）では常識だと僕は思っているので。
ishikawa この None さんはいったい誰だろう?
まず、若干話がずれてきた(オレがずらしてしまった部分も大きいが(わら)ので、現状のまとめ。
ここまでは確認された事実ってことでいいんですよね? で、そうすると後者はオレはバグ(仕様バグ)だと 思うので、なんらか直すべきだろうというのは OKですよね?
たぶん、ここまでは異論がないでしょう。
で、じゃぁ どう なおしましょう? なんだけど おそらく3つ。
ちなみに 1の方法の場合「(スペース)/dev/zero」が入力される(表示される)ようにするには、どう打つんでしょう?(limechat だとどうなってるんでしょ? 例えば)と、いま別の疑問も浮かびつつ...「(スペース){1,n}/」が「(スペース){n-1}/」に置き 換えられる感じ?なんでしょうか?
None への返信
「一文字多く入力する」 という操作は ケータイ においては コストの高い操作なので それをディフォルトにすることには強い抵抗を感じます。
これに関してはすごく同意ですが、 一般的なIRCクライアントで、 「入力欄ではコマンドが使える」 という機能があるので、それを消してまでそこにこだわる必要はないのではないかと思います。 コマンドが使えるのがIRCクライアント界隈（そんなのあるのか？）では常識だと僕は思っているので。
で、さっき書いたようにオレの主張は「それを『ディフォルトにすること』には強い抵抗を感じます」です。 (消しちゃってもいいとは思ってるけど、どーしても欲しい人もいるようだというのもわかるので)積極的に 消そうという主張ではありません。
上記でいうところの 3 (ただし、ディフォルトは 2 になる挙動にしておきたい) です。
で、いずれにせよ / で始まる単語を入力する術がない仕様バグは直す必要があるので、だれもやらないようで あれば、上記 3 (ディフォルトは2の挙動)でこの週末くらいまでになおしちゃいますけど、反対の人いますか?
ishikawa あぁ というか もう一つ方法があった(というか、さっき某チャネルでとある人に言われた)のを忘れていました。
※try catch 的にしないでコマンド一覧をなんらか持って、コマンドとして実行するまえにフォールバックしてもいいけども
たぶん、/ でコマンド入力できる機能を残しつつ、/ ではじまる単語を入力できるようにするには この挙動が一番自然でわかりやすいですかね? (でも ircコマンドにあたる単語は発言できなくなるので 4. の場合でも 1.相当も実装しないとダメか)
とくに異論がでなければ、これにしたい(これで実装しよう)と思いますが よい?
ちなみに 1の方法の場合「(スペース)/dev/zero」が入力される(表示される)ようにするには、どう打つんでしょう?(limechat だとどうなってるんでしょ? 例えば)と、いま別の疑問も浮かびつつ...「(スペース){1,n}/」が「(スペース){n-1}/」に置き 換えられる感じ?なんでしょうか?
今試してみましたが、limechatでは スペースがいくつあろうともそのまま表示されます。 「 /hoge」と入力したら、「 /hoge」ではなく「 /hoge」と表示されます。
で、さっき書いたようにオレの主張は「それを『ディフォルトにすること』には強い抵抗を感じます」です。 (消しちゃってもいいとは思ってるけど、どーしても欲しい人もいるようだというのもわかるので)積極的に 消そうという主張ではありません。 上記でいうところの 3 (ただし、ディフォルトは 2 になる挙動にしておきたい) です。
これはすごく賛成です。 切り替えられる仕様であれば理想的だと思います。 かつ、デフォルトは２がいいかと思います。
ishikawa ishikawa への返信
あぁ というか もう一つ方法があった(というか、さっき某チャネルでとある人に言われた)のを忘れていました。 4. / で始まってたらコマンドとみなして try! で、エラーになったらそれはコマンドじゃなかったのでフォールバックして privmsg (ふつーの発言とする)
ぐあ.. 4. て書いても 1. とこのwikiパーサは表示するのね...これ 4. ですよ じゃないと、一つ前のコメント意味が分からない...
ishikawa への返信
あぁ というか もう一つ方法があった(というか、さっき某チャネルでとある人に言われた)のを忘れていました。 4. / で始まってたらコマンドとみなして try! で、エラーになったらそれはコマンドじゃなかったのでフォールバックして privmsg (ふつーの発言とする) ※try catch 的にしないでコマンド一覧をなんらか持って、コマンドとして実行するまえにフォールバックしてもいいけども
それいいですね。 コメント書いてる間に投稿されてたので、前に書いたコメントと内容が変わってしまいますが、 try!するのはかなりいい感じがします。
try catch 的にしないでコマンド一覧を持つ方がいい気がします（コマンド自体そんなに多くはないので）
noblejasper うあ。今気づいた。Noneは僕です。noblejasperです。。。
ishikawa None への返信
ちなみに 1の方法の場合「(スペース)/dev/zero」が入力される(表示される)ようにするには、どう打つんでしょう?(limechat だとどうなってるんでしょ? 例えば)と、いま別の疑問も浮かびつつ...「(スペース){1,n}/」が「(スペース){n-1}/」に置き 換えられる感じ?なんでしょうか?
今試してみましたが、limechatでは スペースがいくつあろうともそのまま表示されます。 「 /hoge」と入力したら、「 /hoge」ではなく「 /hoge」と表示されます。
なるほど んー 要するに
って感じなんですかね。
あと行頭の「//」が「/」となるクライアントもあるようなんですが、これも一般的なんでしょか?(こっちの方がスマートではある)
で、さっき書いたようにオレの主張は「それを『ディフォルトにすること』には強い抵抗を感じます」です。 (消しちゃってもいいとは思ってるけど、どーしても欲しい人もいるようだというのもわかるので)積極的に 消そうという主張ではありません。 上記でいうところの 3 (ただし、ディフォルトは 2 になる挙動にしておきたい) です。
これはすごく賛成です。 切り替えられる仕様であれば理想的だと思います。 かつ、デフォルトは２がいいかと思います。
切り替える必要もなさそうな 4. にいきついたのですが、どう思いますか ^^;;
ishikawa None への返信
try catch 的にしないでコマンド一覧を持つ方がいい気がします（コマンド自体そんなに多くはないので）
いや、標準的なコマンド自体はたしかにそうなんですが irc サーバによっては独自拡張のコマンドを受け付ける 場合があるので(というか例えば debian.org とかがぶらさがってる ircネットワークのサーバは独自拡張 されまくってて、標準じゃないコマンドをいっぱい受け付けるので)一覧をもつだけだと入力できないコマンドが できてしまう可能性があるんですよね。
個人的には 2 でいいと思いますが、3 に出来るならなおいいですね。
4 の IRC コマンドかどうかで挙動が変わるというのは混乱の元かと思います。 コマンド入力しようとして typo して発言されてしまうという事故も 起こる気がしますし。
morimoto plan2「発言用の入力では / でコマンド入れられるようにするのやめる(コマンド入力するところは別にあるので)」に賛成です。
plan3「1と2の両方(切り替えられるようにする)」はちょっとオーバースペックに感じて、あまり賛成しません。コード、テスト項目、ドキュメントが増えちゃうし。
plan4「/ で始まってたらコマンドとみなして try! で、エラーになったらそれはコマンドじゃなかったのでフォールバックして privmsg (ふつーの発言とする)」は賛成しません。賛成しない理由は
ishikawa まず plan4 ですが、これやっぱナシですね。
nyan_さんからもmorimotoさんからも指摘がありますが事故の可能性はちょっと頭になかったですし、その通りだと 思います。
うんで、実装/メンテナンスのコストを考えると plan3 が(ついでにいうと、plan4も同様に実装はだいぶ複雑に なるはず)オーバースペックなのにも同意。
これを実装することで得られるメリットとつりあわないと思います(さらにいうと、そもそも その「メリット」も 古くからあるダメUIをひきずって使えるようになりますなので、メリットと言えるかどうかもどうかなーとも思う)。
というあたりで、やはり plan2 が適当かな(実装コストも小さいし)
出遅れてますが...
私は「現状がそうなってるのには意味があったはずなので、それを無視して考えるのはよくない」と思って先の文章をかいています。現状を変えない方が良い、と思っているわけではありません。ただし、（すでに出ているいろんな理由により）コマンド入力が全く出来なくなるのは良くない、とは思っています。
「コマンド入力を行う（比較的分かりやすい）方法がある」ので、現状の仕様（入力行の先頭に/があった場合、後ろに続く文字列はIRCプロトコルを直接書かれているとみなして処理を行う）を変えてもいいのではないか、という提案については（これがそもそもの主題だと思いますが）、とっても賛成です。この場合、悩むことなく「この機能は無くす」ってのが一番単純かつ明快でしょう（前述のplan2にあたると思います）。
plan3,4はあまり良い選択ではないと考えます。両者の問題点はすでに指摘されている通りですが、plan4は加えて「失敗したかどうか、を判断する方法に困るので、そもそも実装したくてもできない」はずです（proxy等、独自実装コマンドを持つサーバに接続したときのことを考えれば、「失敗したかどうか」を判断するのが困難であることを理解していただけると思います）。
ishikawa ということで plan2 で修正していま commit しました。
クローズします。
Fork
たとえば「/dev/zero」とか発言しようとしても 最初が / だと発言がどこかに 消えてしまう(発言されない)