2021/01/27
takker.icon
複雑で長いリンクにカーソルが乗るとCPU使用率がずっと100%になる
検索結果を打ち切っていないせい
時々文字列置換に失敗して、前後の行を巻き込む
なるべく早めに直します……m(_ _)m
前回とは違って10個のfetchを非同期に走らせているのに、前回よりも遅い
多分Gyazoのserverがネックになってる
タダで使っているのにこんなに重い処理をさせてしまってごめんなさい
サンプル
既定
https://gyazo.com/897faba30db19f958f3abf2a32aa1479
PDFjsの解像度をいじって600dpiに上げたやつ 解像度の差がエグい
https://gyazo.com/a0e9ac0bbd09f682798266c2fc2f75e4
300dpiくらいで十分だったかな？
kuuote.icon
性懲りもなくReact.js使ってテキストエディタの実装を試みていた
文字幅を等幅にしようが結局マルチバイト混ざると文字列全部舐める必要があった
マルチバイトだと文字幅が2倍になって、行幅から文字数を計算できなくなるからでしょうか？
そういうことです
当然ながらwidthからもlengthからも出せない
余談だけどVimのwrapが重いのもこのせい
Vimのset wrapって重かったのか
1行辺りの文字数を増やしまくるとよくわかると思う
/icons/なるほど.icon
もう一文字づつ<span>で区切ればいいのでは(暴論)
翻訳が死ぬけど
Scrapboxがこの方式採用したのは頭いいなと思う、前にちまちま貼ってたのも同じ方式を採用している
/icons2/へえ〜.icon
マルチバイトつらい
JS的には区別ないのでdouble width characterとでも言ったほうがいいか
描画幅から計算するのはどのみち避けられないと思います
<span>を使ったとしても、offsetWidthで幅を取得することになりますし
contenteditableいやじゃー
つらみポイントがあるんですか？
DOMが直接いじられる、そしてそのいじられた成果が妙
ﾋｪｯtakker.icon
多分React.jsとは相当相性が悪い
古いデータが唐突に欲しくなったので昔のマシンのHDDバックアップをマウントして探索していた
昨日の話の書き忘れなので昨日の日記に書けばよかった気もする
日記は今日の物に書くという固定観念がある
このprojectに限ると、過去や未来の日記に平気で書き込む雰囲気がある気がするtakker.icon
未来日記に予定を書いたり、その日の行事について話したり 肝心の欲しかった物は見付からずに精神にダメージばかり負ってしまった
わかるerniogi.icon
そんな感じでScrapboxに過去の記録を移植するのが進んでいないerniogi.icon
sta.icon
UserScript勉強中
今日の定期タスクを貼り付けるUserScript……の予定
コードをどう管理するか整理するか考える楽しいかもしんない
dnin.icon
PCをクリーンインストールした!