食べたりないのでカフェへ
MFMみたいな再利用性のない&&CSSの表現力に依存したものをSpannableStringに変換するコードを書かされる(古いのは書いたけど)のと比べると、閉じるタグが合ってるHTMLからSpannableStringへの変換は遥かにマシ
サーバからMarkdownが出てくるならMarkwonでよいけど、HTML or MFMだからな(消耗した顔)
@shibafu528 そりゃglitch edition のmarkdown 由来のHTMLとかにもそれなりに対応してるもの。
このアカウントは、notestockで公開設定になっていません。
@osapon 多分クール最後の時点でも世界最強にはなってないので、その見方はやめた方がいいと思う。練成士という職業が最初に作った銃だけで既に最強だったら、むしろつまらんよね。それなりの過程があるべき
Qだと日本のお菓子の出番はないなあ。 海外予想はいくつかある https://android-geek.net/what-is-code-name-of-android-q-10/
https://github.com/tootsuite/mastodon/pull/11427 まだマージされてないけど、ハッシュタグ入力候補のソート順は直るらしい
tootleの通知サーバって処理系は何なんだろう。C10k考えたらnodeがベストな案件だけど、それでも捌ききれないんだろうか。まあマストドンから再試行いっぱい来るだろうし捌けるまではつらいだろうなあ
会話ミュートの表記を変えとくか…「この会話の次回以降の通知をミュート 」「Mute more notification for this conversation」 くらいがいいかな
v1.1.0
- 通知カラムのトゥートの「…」メニューに「この通知を削除」を追加
- 通知カラムの返信トゥートの「…」メニューに「この会話の通知をミュート」を追加
マストドンのAPIドキュメントが更新されたのでそれを使う機能を追加したよ
/api/v1/notifications/dismiss のAPIはドキュメントに間違いがある。URL中にIDを書くのではなく、POSTパラメータにid=(通知ID)って書くのが正しいっぽい
通知を個別に削除するAPIってマストドンのどこで使われてるの?通知タブで削除おしたら DELETE /api/v1/statuses/:status_id が呼び出されてるんだけど…
https://github.com/tootsuite/documentation/commit/4487f6017eb5b0709e55eaa5b5da96d30b7632a9 に追加された「It is **not** possible to use the `id` of the returned objects to construct your own URLs, because the results are sorted by an internal key.」がキツい。内部キーって何だよ…