twmode-users Mailing List for twittering-mode

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello!

 

You have a new message, please read <http://iknowfirst.com.br/case.php?6tea>

 

ora...@ya...


  井汲です。twmode で、URL やタグについたハイパーリンクや色の場所がずれ
ることがあって、その原因と対処法を報告します。

  時折 RT でハイパーリンクや色の場所がずれたツイートが流れてくることがあっ
て、そういうのは決まって凝った顔文字が使われていました。何か unicode が
らみで普段あまり使わないような文字が含まれると変なことになるようだな、と
当たりをつけていたのですが、先日ちょっと余裕があるときにまたその現象が起
きたので当該のツイートを捕捉して色々調べることができました。その結果、現
象を再現可能な顔文字の抽出に成功しました。これです:
http://twitter.com/ikumikeita/status/610472271916855296
現行の twmode だと、URL についた下線・ハイパーリンクがずれているのがわか
ると思います。

（以下、unicode 正規化については、ここ数日で web 検索で仕入れただけの付
け焼き刃の知識で書いているので、誤りや不備等あるかもしれません。まずい点
があったらご指摘ください）

  ずれが発生する原因は、twmode が使っている unicode 正規化での文字数の変
化の評価に、ちょっと不十分な点があることです。文字数の変化に合わせて下線
や色等の text property を付ける位置を補正する必要があって、その補正値を
計算しているのが関数 twittering-make-gap-list なのですが、その出だしはこ
うなっています。
----------------------------------------------------------------------
    (let ((result nil)
	  (regexp
	   (if (require 'ucs-normalize nil t)
	       (concat "\$?:\\([<>]\$\\|\$"
		       ucs-normalize-combining-chars-regexp "\$\\)")
	     "\$[<>]\$"))
	  (pos 0)
	  (gap 0))
      (while (string-match regexp text pos)
	(let ((shift (if (match-beginning 1)
			 3
		       1)))
----------------------------------------------------------------------
この一番最後で、if 文の else 節が返す値を 1 で決め打ちにしているのがまず
い点です。この返り値は、正規化を行っている関数
twittering-normalize-string の実体 ucs-normalize-NFC-string が
「結合文字がある場合に、正規化で結合した結果減らす字数」と一致するべき値
です。
  「ひらがな・カタカナ」+「結合用濁点・半濁点」のような場合は確かにちょ
うど１文字減るのですが、上の例の顔文字ではそうなりません。結合の前後で文
字数に変化がなく、「結合した結果減る字数」は 1 ではなく 0 です。このずれ
が、text property の位置のずれとなって現れています。
  上の例の顔文字がなぜそんなことになるのかと言うと、「点の下に丸が３つぶ
ら下がっている」という絵面を表現するために、顔文字の開発者は「半角カナ」
の中黒に unicode の結合文字を３つ続けるということをしているのですが、
「それを結合した結果の１文字」というのが存在しないため、正規化結合を行っ
ても結局正規化前の文字列がそのまま残されている、ということになっているわ
けです。
  このような「絵面を再現するためだけに結合文字を使い、実際にそれを結合し
た結果の１文字というのが存在するかどうかはまったく気にしない」というのは、
凝った顔文字ではおそらくしょっちゅう使われているやり方でしょう。

  また、http://nomenclator.la.coocan.jp/unicode/normalization.htm を見る
と、アルファベットの母音にアクセント記号等の結合文字が２つ以上続いたもの
が正規化結合の結果１文字にまとまるということも普通にあるようなので、そう
いう場合は逆に「正規化で減る文字数」は 1 よりも大きくなるはずです。したがっ
て、その場合も twmode では text property の位置がずれると予想されます。

  以下、この問題の対処法を２通り述べます。
［その１］
  正規化で減る文字数を１ヶ所毎に計算するようにしてみたのが添付パッチ１本
目の修正です。この修正で、私の所ではずれは出ないようになりました（正規化
を行う範囲を、結合文字の連続が始まる直前の１文字からと決めつけている所が
ちょっと自信なし）。

  さて、この問題を調べている間に、unicode 正規化には別の副作用があること
を知りました。twmode が使っている NFC 正規化では、
http://tama-san.com/unicode%E3%81%AE%E5%90%88%E6%88%90%E9%99%A4%E5%A4%96%E3%81%A8hfs%E3%81%AE%E6%AD%A3%E8%A6%8F%E5%8C%96/
にあるように、漢字によっては別の字形の文字に変わってしまうことがあるよう
です。これも実例を作ってみました:
http://twitter.com/ikumikeita/status/611531576241815554
ここに並んでいる２つの「神」という文字は、現行の twmode で見ると同じ文字
に見えるはずですが、元々は１つ目の方はしめすへんが「示」の方の字で、２つ
目の方が普通の「ネ」の方の字です。twmode が行っている NFC 正規化を通じて、
後者が前者に化けてしまっているという状況です。
  上に掲げたページで、mac のファイルシステム HFS+ で使われているという
「Modified NFD」に基づく正規化は、emacs 上では
ucs-normalize-HFS-{NFD,NFC}-* という関数として提供されているようなので、
twmode でもこれを使うと文字化けの問題は解消します（よくわかっていないの
で、完全に解消するわけではなくて「緩和」なのかもしれませんが）。添付パッ
チ２本目の修正を追加することで、手元では２種類の「神」が別々に表示される
ようになりました。
（ただ、このタイプの文字化けで変身してしまう文字は、unicode の規格的には
非推奨のものらしく、もしかしたら同一性を気にせず積極的に別の文字に変えて
しまった方がむしろ望ましい類のものかもしれません）

［その２］
  ここまで述べてきた問題は、すべて unicode 正規化に起因するもので、その
処理が twmode に入ったのは 2014/4/21 の
f139102d02afb60c937b19c300d90fcd134d438f
の commit でした。添付パッチを使う代わりに、この commit を元に戻すことで
も、
o text property の位置のずれ
o 正規化に起因する文字化け
は共に解消するはずです。この commit を必要とした理由が私にはわからなかっ
たので、疑問をつぶやいたところ、松尾さんが次のように教えてくださいました:
http://twitter.com/cvmat/status/611352469893808128
----------------------------------------------------------------------
@ikumikeita 問題はテキスト端末上の表示です。テキスト端末では合成文字をうまく
表示できず、合成文字以後の表示が乱れます。また、表示上は合成されても「幅0の
文字」が残るので、そこにカーソルが合う問題もあります。
----------------------------------------------------------------------
http://twitter.com/cvmat/status/611547264809447425
----------------------------------------------------------------------
… 添付の画像(それぞれxterm, GNU screen)のように末尾が欠けたり余計な文字
が表示されたりします。 http://t.co/bgHhCc4AUa
----------------------------------------------------------------------
  この文字端末上の問題についての私の考えは、次のように進んで結論が出てい
ません。
(1) これだと「twmode だけ」が対応していることになるので、別の経路から
    emacs 内に「分離した濁点・半濁点」が入ってくると、この文字端末上で同
    様の問題が起きることに変わりはない。
(2) だとすると、twmode の側で対処するというのはあんまり筋がいい解決法で
    はなくて、本来なら「分離した濁点・半濁点がどこから入ってきても、自分
    の端末で適切に扱える」ような設定を別個に行うのが筋なのではないか。
(3) とは言え、それを実際にきちんと行うのは結構難しそうだ。（表示だけなら
    display table や terminal coding system の細工で何とかなるかもしれな
    いが、「幅0の文字」にカーソルが合ってしまうという件はそれでは回避で
    きないだろう）
(4) となると結局、現行のように twmode が正規化合成を行うのが全体のコスト
    を最小に抑える現実的な対処法かもしれない。実際、私も「凝った顔文字」
    なんてものが流入してくる経路は現状 twmode しかないような使い方をして
    いるし。

  という訳で、対処法その１、その２はどちらがいいのか自分の中で結論が出ま
せんでした。両論併記という形で報告を締めくくります。

						井汲 景太


  multi tty に即した変更を twittering-mode に加えませんか、という提案を
してみます。

  emacs 23 から multi tty という機能が有効になり、ひとつの emacs session
内で graphic terminal と tty terminal の両方が使えるようになりました。
（この機能を未体験で試してみたい方は、X window で動かしている emacs で
M-x server-start としてから、kterm や xterm 等の適当な terminal emulator
上で emacsclient -t としてみてください。バッファを切り替えてみたりすれば、
ひとつの emacs の「中味」に X window と文字端末の両方からアクセスできる
ことがわかると思います。なお、NTEmacs はまだ multi tty には未対応のよう
です）

  この状態で、twittering-mode の timeline をグラフィック端末の方で表示し
ておいて、tty terminal の方でしばらく作業していると、作業中に新たに取得
した tweets の表示が、以下のような点でしょぼくなってしまうのがちょっと悲
しいです。
o twittering-icon-mode をオンにしてあっても、アイコンがつかない
o ユーザー名やアカウント名、ハッシュタグに色が着かず、下線や太字等の代替
  装飾による表示になってしまう

  これは、tty で作業してる間は twmode に「使ってるのは文字端末である」と
判定されて、グラフィック端末用の装飾が新たに取得した tweets には適用され
ないためです（multi tty 機能が有効な emacs では、window-system の値は
emacs session ごとに一意に決まるものではなくなり、「評価時点で focus が
当たっているのがグラフィック端末か文字端末か」に依存して変わってしまうも
のになっている）。
  添付のパッチは、これを解消する試みです。このようにすると、twmode のバッ
ファはグラフィック端末と文字端末のどちらで表示しても然るべき姿で表示され
ます。つまり、グラフィック端末上ではこれまで同様アイコンや色のついた文字
が表示され、文字端末上ではアイコンは省略されて色の代わりに下線や太字等の
代替装飾がつくようになります（グラフィック端末と文字端末で同時に表示する
ことも可能で、その場合はちゃんと別々の表示になる）。

  よかったら取り込んでやって下さい。手許では数ヵ月使っていますが、特に問
題は発生していません（ただし試したのは emacs 24.4, 24.5 で、それ以前のバー
ジョンでの動作は未確認。一応、multi tty 未対応の場合も考慮した作りにはし
てありますが…）。また、twittering-****-face は defcustomでの定義は廃止
して defface に一本化してしまった（elisp reference に

People are sometimes tempted to create a variable whose value is a
face name.  In the vast majority of cases, this is not necessary; the
usual procedure is to define a face with `defface', and then use its
name directly.

と書いてあったので）ので、変数としての twittering-****-face をカスタマイ
ズしていた人は face としてのカスタマイズをやり直すことになります。ただし、
プログラム中でこれらを実際に変数として使っていた箇所はごく僅かで、添付パッ
チで修正した twittering-timeline-{header,footer}-face の２ヶ所を除けばす
べて face がそのまま使用されていたので、この変更の影響はほとんどないと思
います。
  また、twittering-icon-mode がオンのとき、文字端末上ではアイコン用のプ
レースホルダの「_」が表示されます。不格好だと思われる方は適当に修正して
ください。

						井汲 景太

※ ちなみに、最初に emacs を起動するときに emacs --daemon とすると特に
frame を持たないサーバーモードで動き始め、その後で emacsclient を -c オ
プション、-t オプションをつけて実行する度にそのサーバーモードの単一の
emacs session にグラフィック端末と文字端末の frame をいくつでも attach
していけます。つまり、.emacs などの初期化コード内で「この emacs が動作し
ているのはグラフィック端末か文字端末か」を判定することは、もはやほとんど
意味がなくなってしまっています。


松尾です。

>   GitHub アカウントは持っていないので、そちらで取り込みお願いいたします。
> 名前の掲載は差し支えありません。
ありがとうございます。
先程GitHubにパッチを取り込んだ版をアップロードしました。

---
松尾 直志 <ta...@my...>



松尾です。

井汲さん、パッチありがとうございます。

sit-forが入力待ちかどうかをチェックするのに使っている
input-pending-p のドキュメント
( http://www.gnu.org/software/emacs/manual/html_node/elisp/Event-Input-Misc.html#index-waiting-for-command-key-input-1454 )
を見ると、

> On rare occasions it may return t when no input is available.

のようにありました。この状況が起こると無駄に待ち続けることに
なってしまいそうです。

ご指摘のように、sleep-forに置き換えるのが良さそうです。
同様の症状で使えなかった方もおられたようですがsit-forとsleep-for
の置き換えで回避できたようです。こちらでもしばらく置き
換えて使っていましたが特に問題はないようなので取り込ませてくだ
さい。

GitHubのアカウントをお持ちでしたらpull requestしていただければ
取り込みます。面倒でしたらこちらでcommitします。また、その際
ChangeLogにお名前を載せていただきたいのですが、構いませんでしょ
うか。

なお、送っていただいたpatchの2つ目の、関数twittering-wait-while
の第4引数を t から(twittering-account-authorized-p)に変更する
ものですが、この変更は必要ありません。
継続条件は第3引数で (twittering-account-authorization-queried-p)
のように指定されていますので認証の成功/失敗が確定した際にループは
終了するようになっています。
第4引数はループの際に実行すべき内容を書く部分ですが、この場所では
特に行うべきことがないのでtとしてあります。
(optionalな第5引数を設定するために必要になります)

---
松尾 直志 <ta...@my...>



  $B0f5b$G$9!#(B

> $B$4;XE&$N$h$&$K!"(Bsleep-for$B$KCV$-49$($k$N$,NI$5$=$&$G$9!#(B
> $BF1MM$N>I>u$G;H$($J$+$C$?J}$b$*$i$l$?$h$&$G$9$,(Bsit-for$B$H(Bsleep-for
> $B$NCV$-49$($G2sHr$G$-$?$h$&$G$9!#$3$A$i$G$b$7$P$i$/CV$-(B
> $B49$($F;H$C$F$$$^$7$?$,FC$KLdBj$O$J$$$h$&$J$N$G<h$j9~$^$;$F$/$@(B
> $B$5$$!#(B

  $B$o$+$j$^$7$?!#$"$j$,$H$&$4$6$$$^$9!#(B

> GitHub$B$N%"%+%&%s%H$r$*;}$A$G$7$?$i(Bpull request$B$7$F$$$?$@$1$l$P(B
> $B<h$j9~$_$^$9!#LLE]$G$7$?$i$3$A$i$G(Bcommit$B$7$^$9!#$^$?!"$=$N:](B
> ChangeLog$B$K$*L>A0$r:\$;$F$$$?$@$-$?$$$N$G$9$,!"9=$$$^$;$s$G$7$g(B
> $B$&$+!#(B

  GitHub $B%"%+%&%s%H$O;}$C$F$$$J$$$N$G!"$=$A$i$G<h$j9~$_$*4j$$$$$?$7$^$9!#(B
$BL>A0$N7G:\$O:9$7;Y$($"$j$^$;$s!#(B

> $B$J$*!"Aw$C$F$$$?$@$$$?(Bpatch$B$N(B2$B$DL\$N!"4X?t(Btwittering-wait-while
> $B$NBh(B4$B0z?t$r(B t $B$+$i(B(twittering-account-authorized-p)$B$KJQ99$9$k(B
> $B$b$N$G$9$,!"$3$NJQ99$OI,MW$"$j$^$;$s!#(B

  $B$J$k$[$I!"$h$/$o$+$C$F$J$/$F8+Ev30$l$J$3$H$r$7$F$7$^$C$?$h$&$G$9!#N;2r(B
$B$7$^$7$?!#(B

  $B$G$O$h$m$7$/$*4j$$$7$^$9!#(B

						$B0f5b(B $B7JB@(B



  twmode で (setq twittering-use-master-password t) として master
password を使っている皆さん。emacs を起動して最初の M-x twit で、認証デー
タを読み込んだ後に無限ループに入ってしまうという方はいらっしゃるでしょう
か。私はしょっちゅう起こっています。
  無限ループになっても、C-g で中断すると認証済み情報がセットされて、もう
一度 M-x twit とすると問題なく使えるので、実用上は困ってなくてこれまでそ
うやって利用していたのですが、昨日業を煮やして調べてみたところ、一応ある
程度の原因はわかって修正もできたので、情報共有のため報告します。これが正
しい対処法なのかどうかもよくわかってないので、詳しい方からのご意見やご指
摘が頂けましたら幸いです。

(1) 無限ループは twittering-verify-credentials の中の
	;; wait for verification to finish.
	(twittering-wait-while nil 0.1
			       (and
				(twittering-account-authorization-queried-p)
				(twittering-process-alive-p proc)))
    の箇所で起こっている。
(2) ここに debug code を挿入して、twittering-debug-mode をオンにして試し
    てみたところ、無限ループの最中は (input-pending-p t) が t を返す状態
    が続いていることがわかった。
(3) このためマクロ twittering-wait-while の展開結果に現れる sit-for が入
    力待ちにならずに直ちに帰っている。その結果、バックグラウンドで呼んだ
    curl の出力を emacs が受け取れる状態にならない（ここは推測。elisp
    reference の「Output from Processes」の節に

   Output from a subprocess can arrive only while Emacs is waiting: when
reading terminal input ... in `sit-for' and `sleep-for' ..., and in
`accept-process-output' (*note Accepting Output::).

    とあることと、sit-for の実装を見ると (input-pending-p t) が non-nil
    を返す時は実際に入力待ちを担っているらしき read-event まで処理が回ら
    ずに終了してしまう所から見て、process の出力を受け取れる状態にならな
    いまま sit-for が終わってしまっているっぽい）。
(4) そのため、curl が取得した認証確認情報が処理されたり、curl の process
    が終了して status が変化するタイミングがないので、終了条件がみたされ
    ずに無限ループとなる。

  そこで、添付 patch のように、twittering-wait-while 中の sit-for を
sleep-forに置き換えて確実に待機を起こすようにしてみると、どうやらこちら
では問題はなく動作するようになりました（patch 中のもう１点の修正は、事情
がよく解ってなかった頃この辺りの処理を追っていて、「ここ無条件で認証成功
の結果を返しちゃまずいんじゃないの？」と思ってついでに入れたものです。何
か思い違いをしていたらすみません）。
  ただ、「(input-pending-p t) がずっと t を返す状態になる」というのが正
しい動作なのかどうかはよくわかりません。ひょっとしたら emacs の bug だっ
たりコンパイルに失敗していたりするのかもしれず、そこら辺は判断できる知識
がないので、この sit-for→sleep-for という置き換えが本当に正しい処置なの
かどうかはイマイチ自信が持てない所です。

						井汲 景太


松尾さん
情報ありがとうございます

twitter側の仕様なのですね。

ふだん emacs -nw で CUI環境で使用しているので
ずっとxAuthで使っていました。
とりあえず、最初にWEBブラウザを使って
OAuth認証でDMのpermissionをつけておけば
その後はxAuthでも問題ないようです。

ありがとうございました。

     でかいの企画  佐々木茂彦
	ss...@de...

> 松尾です。
> 
> xAuthでread, writeのpermissionしか付かないのはTwitter側の仕様です。
> 2011年6月の仕様変更時に権限が変更されてしまいました。
> 
> https://dev.twitter.com/docs/application-permission-model
>   Applications that use "Sign-in with Twitter" or xAuth will only
>   be able to receive Read or Read/Write tokens.
> 
> GnuPG 1.xとEasyPGもしくはalpaca.elが使える環境でしたら
> (setq twittering-auth-method 'oauth)
> (setq twittering-use-master-password t)
> としておくとOAuth tokenをローカルに暗号化して保存します。
> 一度tokenを保存すれば次回以降の起動時は暗号化時のpassphraseを入力
> するだけで認証をクリアできるので、xAuthに近い感覚で使えると思います。
> 
> Emacs21ではEasyPGは動かないと思いますが、山本和彦さんのalpaca.elでし
> たら動作すると思います。こちらのURLからダウンロードできます。
> http://www.mew.org/~kazu/proj/cipher/ja/
> 
> いかがでしょうか。



松尾です。

xAuthでread, writeのpermissionしか付かないのはTwitter側の仕様です。
2011年6月の仕様変更時に権限が変更されてしまいました。

https://dev.twitter.com/docs/application-permission-model
  Applications that use "Sign-in with Twitter" or xAuth will only
  be able to receive Read or Read/Write tokens.

GnuPG 1.xとEasyPGもしくはalpaca.elが使える環境でしたら
(setq twittering-auth-method 'oauth)
(setq twittering-use-master-password t)
としておくとOAuth tokenをローカルに暗号化して保存します。
一度tokenを保存すれば次回以降の起動時は暗号化時のpassphraseを入力
するだけで認証をクリアできるので、xAuthに近い感覚で使えると思います。

Emacs21ではEasyPGは動かないと思いますが、山本和彦さんのalpaca.elでし
たら動作すると思います。こちらのURLからダウンロードできます。
http://www.mew.org/~kazu/proj/cipher/ja/

いかがでしょうか。

---
松尾 直志 <ta...@my...>

P.S.
以前、GNU screenを使い始めたころ「screenのススメ」の記事は大変参考に
なりました。ありがとうございます。



twmode-users MLのみなさん
はじめまして 佐々木と申します。

バグ報告するためMLに入会しました。

動作環境: CentOS6.4 (i686) emacs21.3
twmodeのverion: twittering-mode-vHEAD

アプリ連携のオーソライズにおいて
OAuthですと read, write, direct messages の
3つのpermissionがつきますが
xAuthだと read, writeの2つのpermissionしかつきません。

そのため、初回にxAuthで接続すると
DirectMessageのtimelineを表示することができません。

こうなってしまうと、いったんアプリ連携設定で
twmodeの許可を削除した上で、OAuthで接続しなおす必要があります。

コードは読んでないのですが、とりあえず現象だけ報告します。

以上、よろしくお願いします

     でかいの企画  佐々木茂彦
	ss...@de...



松尾です。

遅くなりましたが、twittering-mode 3.0.0をリリースしましたので
お知らせします。最新版は http://twmode.sourceforge.net/ja/ から
ダウンロードできます。

3.0.0はGitHub http://github.com/hayamiz/twittering-mode/ の
master branchの2013-04-23時点での最新版と同等ですので、それ以降の
版をGitHubやMELPA経由でお使いの場合は更新する必要はありません。

2.0.0からの大きな変更点は以下の通りです。
* 暗黙に署名を付加する機能の廃止
  関数`twittering-sign-string-function'と変数
  `twittering-sign-simple-string'の機能は廃止されました。同様の機能は
  `edit skeleton'で設定できますので、こちらを使ってください。
* 変数`twittering-scroll-mode'の廃止
  変数`twittering-scroll-mode'は廃止されました。現在の版は、過去の版で
  scroll-modeが有効であったときのように振舞います。最新のtweetに追従す
  るには、timelineバッファの最新側のヘッダもしくはフッタ上にカーソルを
  置いてください。
* "C-cD"の代替として"C-cC-w"を導入
  これまで、"C-cD"がtweet削除用関数'twittering-delete-status'にbindさ
  れていました。しかしこのキーはEmacsのKey Binding Conventionsに則って
  いません。そこでその代替として"C-cC-w"を同関数にbindしました。"C-cD"
  も有効ですが、"C-cC-w"の使用を推奨します。
* 文字数カウント時にt.coでの短縮を考慮
* t.coで短縮されたリンクを短縮前のURLで表示
* ヘッダとフッタの表示
* merge timelineに対応
* replyの系列の逐次取得
* 特定日時以前のtweetを取得するコマンドを追加
* favorites timelineで過去のtweetの遡って取得する機能を追加
* timelineごとに異なる取得間隔
* Twitter REST API v1.1に対応

他の変更点や、詳しい内容は NEWS.ja ファイルでご確認ください。

次回リリース4.0.0は、"Developer Display Requirements"
https://dev.twitter.com/terms/display-requirements のための
変更を主に行うつもりです。この requirements を満たすため、
一部の動作や表示形式が、現在のデフォルト時のものから変更される
ことになると思います。

4.0.0もなるべく"近いうちに"リリースしたいと思っています。
---
松尾 直志 <ta...@my...>



松尾です。

昨日の版にはいくつかバグがありましたので、その修正を
GitHubのmaster branchにcommitしました。

今回対処したバグは以下の通りです。
- :direct_messages, :direct_messages_sent でtweetが正しく
  表示されない。
- 400 Bad Requestが頻発する。

また、前回のメールに書くのを忘れていたのですがTwitter REST
API v1.1ではいくつかのtimelineが廃止されていますので注意
してください。具体的には :friends, :replies, :public,
:retweeted_by_me, :retweeted_to_me, :retweeted_by_user/USER,
:retweeted_to_user/USER の7タイプが廃止されています。
(NEWS, NEWS.jaに記載の通り)

この内、 :friends と :replies については、警告表示の上、
それぞれ :home と :mentions として読み替える措置を導入して
あります。

---
松尾 直志 <ta...@my...>



松尾です。

すみません。Twitter REST API v1.1でのAPI回数を間違えていたので
修正します。

APIの回数は以前の全API共通で350[回/時]、というものからAPIの種別毎に
「15分当たり15回」か「15分当たり180回」のどちらかの制限がかかるように
変更されています。
( https://dev.twitter.com/docs/api/1.1/get/application/rate_limit_status )
特に :home や :mentions が「15分当たり15回」となっていますので注意して
ください。リストtimelineや他のユーザのtimeline、検索timelineは
「15分当たり180回」なので以前と同じ感覚で使えるかと思います。
但し、他ユーザのtimeilneの場合、ユーザ毎に別々ではありませんので、
他ユーザのtimelineを多数開いている場合には注意が必要です。

---
松尾 直志 <ta...@my...>



松尾です。

GitHubのrepository http://github.com/hayamiz/twittering-mode/ の
master branchにTwitter REST API v1.1対応版をcommitしました。

なるべく近いうちに、これを3.0としてsourceforgeの方にもupload
しようと思っています。

APIのrate limitingが、各API種別毎にカウントされるようになった
( https://dev.twitter.com/docs/rate-limiting/1.1 )のですが、
その部分の対応はまだ完成できていません。
なのでmode-line上のAPI残り回数は正確ではなくなっているので注意
してください。

APIの回数は以前の全API共通で350[回/時]、というものからAPIの種別毎に
「15[回/15分」か「180[回/時]」のどちらかの制限がかかるように変更
されています。
( https://dev.twitter.com/docs/api/1.1/get/application/rate_limit_status )
特に :home や :mentions が「15[回/15分]」となっていますので注意して
ください。リストtimelineや他のユーザのtimeline、検索timelineは
180[回/時]なので以前と同じ感覚で使えるかと思います。

---
松尾 直志 <ta...@my...>



> すみません。遅くなりましたが修正しました。

  ありがとうございます。

> 井汲さんのpatchでは
...
> という形でしたがこれは
...
> や
...
> と同じ結果のようです。
> 分かりやすいように(t nil)の形にして取り込みました。

  その辺りはお任せします。元々、「doc string の
Return non-nil if one or more statuses are rendered.
Return nil if no statuses are rendered.
からすると、このコードを書いた人の意図としてはこっちなのだろう」くらいの
ことしか考えてなかった修正ですので。

						井汲 景太



松尾です。

すみません。遅くなりましたが修正しました。
いただいたpatchのようにcondのclauseにnilを与えると
どうなるかよく分かっていなかったのですが、単に無視される
みたいですね。

井汲さんのpatchでは

(cond
 ((condition1)
  result1)
 ((condition2)
  result2)
 nil)

という形でしたがこれは

(cond
 ((condition1)
  result1)
 ((condition2)
  result2))

や

(cond
 ((condition1)
  result1)
 ((condition2)
  result2)
 (t
  nil))

と同じ結果のようです。
分かりやすいように(t nil)の形にして取り込みました。
ご指摘ありがとうございました。

---
松尾 直志 <ta...@my...>



> 僕のところでは、この修正はうまく効いていまして、
> 有難く使わせていただいています。

> 更に 
>   pkgsrc/wip/twittering-mode
> にも patch を入れて見ました。

> ありがとうございます。

  おそれいります。全然大した変更ではありませんが（笑）。

（cvmat さんからは早い段階で「近々取り込む」と連絡を頂いてますので、放置
されてるというわけではありません。念のため）

						井汲 景太



>                                                    藤原 誠
僕のところでは、この修正はうまく効いていまして、
有難く使わせていただいています。

更に 
  pkgsrc/wip/twittering-mode
にも patch を入れて見ました。

ありがとうございます。
---
(藤原)



  いつも twmode を利用しています。ありがとうございます。

  reply 上で r をタイプしたとき、そこまでに連なるやり取りを見ることがで
きますが、正常にスレッドが表示された場合にも
The status this replies to has not been fetched yet.
と表示されてしまうのが気になったので、ちょっと調べてみました。どうやら、
twittering-render-replied-statuses の最後の所で、カッコの対応をしくじっ
ていて常に nil が返ってしまうようになっているのがまずいようです。以下の
変更で直ると思います。

						井汲 景太

--- twittering-mode.el~	2013-01-29 00:31:15.000000000 +0900
+++ twittering-mode.el	2013-01-29 00:35:19.000000000 +0900
@@ -8479,8 +8479,8 @@
 				     field-properties formatted-status)
 		formatted-status)))
 	   statuses)
-	  t))
-      nil))))
+	  t)))
+     nil)))
 
 (defun twittering-render-a-status-with-delay (beg end id prefix)
   "Render a status with a delay.




>                                                    藤原 誠
| From: Tadashi MATSUO <ta...@my...>
| Date: Thu, 06 Sep 2012 22:14:57 +0900 (JST)

> 時点でその内容をヒストリに追加しているので、改めて開いた
> 編集バッファ上で M-p してもらえば投稿失敗した内容を復元でき
> ます。
> といってもこれはいかにも裏技的動作なので直感的ではないですね。

一度言われれば、納得して覚えられ、多分三か月くらい経って、
同じ状況になった時に、多分何げなく回復出来ると思います。
(なので結構直感的なのではないかな、と思うのです)

 sf.net が URL と認識されていたので(却って)長くなってしまった。
ような例がもしまたあれば、気が付くまでには時間がかかりそうです
が。
(長くなるのはやめて欲しいですね .. 意味がない > twitter)

*Message* に 長かったようだよ、と書くだけでも良い(助かる)と思い
 ます。

本当にありがとうございます。
---
(藤原)



松尾です。

> 問題が起きた時の話ですが、
> ・書いたものが失われる
> ・何が起きたか分らない
> ので、(もし可能で、複雑にならない範囲で)
> ・字数が多かったようですよ
> ・(元のつぶやきの)原稿をどこかのバッファに残す
> と、本当にうれしいです

実はtwittering-mode.elとしては C-cC-c で編集バッファを閉じた
時点でその内容をヒストリに追加しているので、改めて開いた
編集バッファ上で M-p してもらえば投稿失敗した内容を復元でき
ます。
といってもこれはいかにも裏技的動作なので直感的ではないですね。
失敗の状況を知らせる文章内でこの方法についても触れる、くらい
でしょうか。

> エラーではなくてお知らせ (Warning) だとなおさらいいのかなと
> 思います。

ここは迷っています。POSTを発行してから失敗という応答が返って
くるまでにラグがあるので、その時点ではユーザは別の作業に移って
いる可能性があります。
例えば文章を素早く打ち込んでいる状況で一瞬、メッセージが表示
されたとしても気付けないんじゃないでしょうか。
といってエラーにすると鬱陶しそうな気もして、迷っています。

エラーにしないなら、次にtwittering-modeのバッファに戻って
きたときに気付くよう、mode-lineに何か目立つ細工をする、
とかでしょうか…。
別の作業に移っている可能性を考えると勝手にsplit-windowや
pop-to-buffer的な動作をするのは面倒な状況を作りそうです。

---
松尾 直志 <ta...@my...>



>                                                    藤原 誠

松尾さん、ありがとうございます。sf.net の部分は、全く意識して
いませんでした。

  Twitter の方でも、反応をいただいたので、自分の元の意図のもの
をもう一度、つぶやいて(ささやいて)見ようと思って、こちら(だけ)
に自分の写しがあったので見に来たら、丁寧なお返事をいただいてい
ることに気が付いていま書いているところです。

問題が起きた時の話ですが、
・書いたものが失われる
・何が起きたか分らない
ので、(もし可能で、複雑にならない範囲で)
・字数が多かったようですよ
・(元のつぶやきの)原稿をどこかのバッファに残す
と、本当にうれしいです
エラーではなくてお知らせ (Warning) だとなおさらいいのかなと
思います。

  それと、説明なしに変な版名を書いて申訳けありませんでした。
NetBSD 的 pkgsrc/wip/twittering-mode を make package-install す
ると、git からもらって来て、その日付を版名にするのです。
(特に変更がなくても日付だけ新しくなります)

OS を新しくすると、(sudo と zsh と emacs と日本語入力の後に)
最初に入れるのがこの twittering-mode
だったりします。本当にありがとうございます。
---
(藤原)



松尾です。

こちらでも再現できました。どうやら sf.net の部分がURLと
認識されて、t.co形式の20文字のURLになるためのようです。

試してみたところ sf.net と入力した部分が
 http://t.co/HVGBDAtz になりました。
( http://twitter.com/cvmat/status/243388450026442753 )

ちなみに http://sourceforge.net/p/ximo16/wiki/Home/ は
 http://t.co/wd48C3qf になりました。
( http://twitter.com/cvmat/status/243386561763373057 )

同様の変換を考えると

Prepairing project pages for ximo16. http://sourceforge.net/p/ximo16/wiki/Home/ Thanks for sf.net for providing such facilities. (a little pain editing wiki ;-)

という160文字のtweetは

Prepairing project pages for ximo16. http://t.co/wd48C3qf Thanks for http://t.co/HVGBDAtz for providing such facilities. (a little pain editing wiki ;-)

という152文字のtweetとして扱われることになります。
140文字を越えているので、投稿できない、ということの
ようですね。

twittering-mode.elの側ではURLを t.co 形式に変換した後の
文字数を考えて140文字を超過していないかチェックしていますが、
対象となるのは「http://やhttps://で始まっている、明らかにURL
と分かるもの」だけです。

Twitterの提供しているrubyライブラリ内に、URL扱いされる文字列の
判断方法が書かれていますが、かなり複雑です。
( https://github.com/twitter/twitter-text-rb/blob/f0458ba4eee710140f04c059d70b0faf368e3b10/lib/twitter-text/regex.rb )

以前、これを取り込もうかと考えたこともあったのですが、その当時の
ライブラリ内の判断アルゴリズムが、実際のTwitterのサービスの
振舞いと違っていたこともあって、面倒な割に安心できないと考えて
諦めました。

サーバ側で文字数超過と判断されて投稿できない可能性としては
https://dev.twitter.com/issues/339 の例もあります。
(これはサーバ側のバグと思いますが…)

twittering-mode.el側で対処するとすれば、POSTが失敗したときに
そのエラーに付いているメッセージを解釈してその旨をユーザに
通知する、というところでしょうか。
通知の方法が (message "通知メッセージ") で良いか、それとも
error を起こすべきかは考える必要がありそうですね。


> ----
> twittering-mode-1.0nb20120816 Emacs client for twitter
> ----
> とあるので、多分かなり最近の気もします。

これは何かのrepository上のバージョンでしょうか?
2012-08-16にgithubのmasterから取得したもの、という
意味なら最新版のはずですね。

---
松尾 直志 <ta...@my...>



>                                                    藤原 誠
いつも知識のないことをさらけ出していて申訳けありません。
twittering-mode の版が少し古いかも知れませんが、
----
twittering-mode-1.0nb20120816 Emacs client for twitter
----
とあるので、多分かなり最近の気もします。

それで、次のような tweet をしようとしたら、出来ませんでした。

---------
Prepairing project pages for ximo16. http://sourceforge.net/p/ximo16/wiki/Home/
Thanks for sf.net for providing such facilities. (a little pain editing wiki ;-)
---------


横長で申訳けありませんが、*Messages* の該当部分をそのまま
付けます。

Response: HTTP/1.1 403 Forbidden for POST https://api.twitter.com/1/statuses/update.xml?status=Prepairing%20project%20pages%20for%20ximo16.%20http%3A%2F%2Fsourceforge.net%2Fp%2Fximo16%2Fwiki%2FHome%2F%20Thanks%20for%20sf.net%20for%20providing%20such%20facilities.%20%28a%20little%20pain%20editing%20wiki%20%3B-%29&in_reply_to_status_id=243356374216605697

ありがとうございます。
---
(藤原)



松尾です。

githubのmaster branchにreply先を取得するコマンドを追加しました。

これまでもreply先が既に取得済みであれば、reply上で r を入力する
ことで展開表示させることができましたが、今回の変更でreply先を個別に
取得する機能が追加されました。
以前のように、reply先のuser timelineを開く必要はありません。

今回の変更では r 自体の機能はそのままに、新しい関数
twittering-toggle-or-retrieve-replied-statuses を追加しています。
この機能はreply、もしくは展開表示されたreply系列上で R を入力する
ことで実行できます。

基本的な機能は以下の通りです。
・reply系列を展開表示していない、もしくはreply系列内の取得済みtweetの
  内、非表示のものがある場合は、取得済みtweetを最大限使ってreply系列を
  表示します。
・カーソルがreply上にあり、そのreply先がまだ取得されていない場合はそれ
  を取得して表示します。
・カーソルがreply、もしくは展開表示されたreply系列上にあり、表示されて
  いるreply系列内で最も古いreplyのreply先がまだ取得されていない場合は、
  それを取得して表示します。
・カーソルがreply、もしくは展開表示されたreply系列上にあり、reply系列の
  全てが展開表示されていてそれ以上辿れない場合は、reply系列を非表示に
  戻します。

NEWS、NEWS.jaもご参照ください。

基本的な使い方は
1. R を繰り返し入力して見たいtweetまで表示させる。
2. r を入力して展開表示を閉じる。
   (reply系列が全て表示されているならRでも閉じられます)
のようになると思います。

---
松尾 直志 <ta...@my...>




2009	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (21)	Dec (58)
2010	Jan (129)	Feb (42)	Mar (9)	Apr (6)	May (25)	Jun (29)	Jul (2)	Aug (5)	Sep	Oct (1)	Nov	Dec
2011	Jan (8)	Feb (1)	Mar (2)	Apr (1)	May	Jun	Jul (5)	Aug (3)	Sep	Oct (3)	Nov	Dec
2012	Jan (1)	Feb (1)	Mar (2)	Apr	May	Jun	Jul	Aug	Sep (5)	Oct	Nov	Dec
2013	Jan (1)	Feb (4)	Mar (3)	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec (3)
2014	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec (3)
2015	Jan	Feb	Mar	Apr	May (1)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

twmode-users Mailing List for twittering-mode

twmode-users — (Japanese) A mailing list for twittering-mode users