Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 15/241: « 11 12 13 14 15 16 17 18 19 »

ツリー型タブがあると遅くなるとかツリー型タブが重いとかその辺の話について - Sep 17, 2012

ツリー型タブが重いという声をたまに見かけるんだけど、そういうのを見かける度に「ほんとかなあ?」とついつい思ってしまう。

もちろん、素のFirefoxに対して余計な処理を加えるわけだから、そりゃあ、元の状態より重くはなると思う。でも、「重い」って言ってる人の言ってる「重い」は、なんというか、そういうレベルのことを言ってるわけではないって気がする。もっと鈍重な、全体的に動作がヤバイくらい緩慢になる、そういうのを指してる気がしてる。

で、そういう現象が起こるとして、本当にそれがツリー型タブのせいなのかどうか。ツリー型タブを使っている時と使っていない時とで、同じ数のタブを開いていて、同じ時間だけブラウジングした状態で、ツリー型タブがある場合だけ顕著に性能が劣化するのかどうか。というのが、この件で自分が一番気になっているポイントなのです。

何故僕はこうまで頑なに「ツリー型タブが原因で遅くなっているのだ」と素直に認めようとしないのかというと、基本的にツリー型タブはブラウザのコンテンツ領域や履歴にはタッチしないように設計しているつもりなので、「コンテンツ領域に起因するメモリリークがある」とか「履歴を消去したら軽くなった」とかの報告があるという事自体が、どうにも不可解なのです。

実際、about:memoryではタブ毎にメモリの使用状況を確認できますが、「about:memoryを見ると、メモリが解放されていないことが分かる」と言われた再現条件をこちらで試行しても問題が再現せず、その後報告者の環境でもツリー型タブだけをインストールした状況では問題が再現しなくて、どうやら他のアドオンがこの問題の原因になっているのではないかという話になったこともありました。

ツリー型タブがあるとタブを開く数が増える&1つ1つのタブの生存期間が長くなる傾向があると思うので、他のアドオンやFirefox自身が潜在的に抱えてはいるものの普段の利用では無視できる程度だったという問題があったとしたら、それらがより顕在化しやすい状態になるとは思います。例えばあるアドオンを入れていると全体の動作が0.1秒遅くなるとして、5つくらいタブを開いている状況ではそれが気にならなかった。でも、ツリー型タブを入れてタブを50とか開きっぱなしにしていると、些細な重さでもそのまま×50されるから、シャレにならない重さになる。こういう事は十分にあり得ます。でもツリー型タブ単体でそういう事が起こるとはどうしても自分には考えにくいのです。

「コンテンツ領域への参照を残しているせいでメモリリークが発生する」というのは自分もアドオン開発初期にはよくやらかしていたミスなので、かなり後の方になって開発したツリー型タブの頃にはそこらへんのことは想定に入れられるようになっていて、多少速度を犠牲にしてでも安全になるように、だいぶ気をつけて設計したという認識があります。「そこまでやらんでもええんちゃうん」って所まで偏執的にやってることすらあります。Firefox本体のコードでもaddEventListenerした物をremoveEventListenerせずに放りっぱなし(多分ガーベジコレクション任せ?)になってるのとか見ると、怖いなーって思ってしまうくらいです。

その一方で、僕は「これこれこのアドオンと衝突してるんだけど」という報告を受ける度にそのアドオンのソースを見るという事がこれまで結構あったのですが、ソース見てげんなりすることが割とありました。これメモリリークするやろ、とか。で、そういう問題を解決しようと思ったら、根本的なアーキテクチャの変更が必要だったりして。そういうとこまで見だすときりが無いし、大体それは僕の領分でもないので、ツリー型タブとの衝突の原因になってるとこだけ見てあとは見て見ぬふりしてるんですけども。

そういう惨状を見てるから、僕の心情としてはついつい、まず最初に他の原因の方を疑ってしまいます。それらの可能性がなくてちゃんと明らかに「ツリー型タブが原因だ」と断言できる、という所にまで絞り込まれてないと(はい。ほんとにツリー型タブが原因で問題が起こってる可能性も、もちろんあるとは思ってます。そこまで完全否定はできないです。)、調べようという気になかなかなれないです。これって、思い上がりすぎですかね?

あと、それとは全然別の話として、ツリー構造が何らかの理由で壊れてしまうせいで、無限ループが発生してフリーズしてしまう……という事は時々起こるみたいなので、そういうのはもう完全にツリー型タブの責任なので今後も粛々と直していきたいとは思ってます。

いずれの場合にしても、メンテナンスに十分に時間を割けない現状では「ツリー型タブのせいで問題が起こってる、かもしれない」という段階では動けなくて、「間違いなくツリー型タブのせいで問題が起こってて、この手順で100%再現できる」という所まで絞り込んでもらってることが、こっちで対処できるためには絶対に欠かせない条件という感じです。できれば「この部分が問題になっている」という所まで明らかにしてもらえてると嬉しいし、もっと言えば修正パッチをpull requestでもらえるのがベストなんですが。

それから、何と言おうとツリー型タブを入れてFirefoxの動作がおかしくなり、ツリー型タブを削除したことでこれらが解決されたことは事実なのです。 という風な話はもう何度あったか覚えてられないくらいにあって、GitHubのIssue Trackerを探してもゴロゴロでてくるんだけど、詳しく聞いてみると大概は他のアドオンとの衝突です(全部がそうだというわけではないですが、感覚的には、そうである場合の方が多かったという印象です)。こういうのも、じゃあどのアドオンと衝突してるのかという所まで明らかにさえしてもらえれば、何か手の打ちようが出てきくる可能性がありますので、より快適な生活を望む場合には、衝突の解消に協力してもらえたらなーって思います。

日経Linux 2012年10月号には「シス管系女子」第14話は載ってません、が…… - Sep 14, 2012

告知が遅くなったのですが、日経Linuxの10月号が発売されています。Amazonでも買えます。

こちらの雑誌で「シス管系女子」というコマンドライン豆知識漫画を連載していたのですが、実は前回で終わってしまいました。なんと、今号には「シス管系女子」は載っていません。

というのは釣りで、代わりに「#!シス管系女子」第1話が載っています。タイトルがちょっとだけ変わって、新シリーズです。なので、話数カウントもまた第1話からです。これって一応新連載なんでしょうか?

(扉絵?の一部) で、どこら辺が違うのかというと、新しいタイトルでぴんと来る人もいるかも知れませんが、シェルスクリプトを主軸に置いた内容にしていく予定です。コマンドライン豆知識漫画から、シェルスクリプト入門+コマンドライン豆知識漫画にクラスチェンジです。みんとちゃんがどんどん濃い方向に突っ走っていく様を、どうか生暖かい目で見守って下さい。

ところで、前号からシェルスクリプト関係の連載がいくつか始まって、そのビッグウェーブに乗り遅れてなんでシス管系女子だけ1ヶ月遅れでシェルスクリプトなのかっていうアレなんですが、前号の作業を終えた後でリニューアルを打診されて「じゃあ手を出しやすい所でシェルスクリプトでも扱いますかねえ」とポヤーンと考えていたら届いた見本誌がシェルスクリプト一色で「ちょwwwwwwwwwきwwwwwいwwwwwてwwwwwなwwwwwいwwwww」ってなったんですけど、今更別のシリーズ(構想だけなら一応、Sambaでドメイン構築編とかアイデアがあるにはあったのです)にするのも厳しかったのでそのままシェルスクリプト編にしちゃいました。いやあ、みんな考える事は同じなんですね……

あと、「シス管系女子」第1話から第12話までのまとめ冊子が付いてさらに第13話も掲載の9月号なんですが、今見たらAmazonでは売り切れてました。マーケットプレイスでなら中古を買えるみたいなんですが、通常なら定価より値下がりする所、この号だけ高くなっちゃってました。バックナンバーのページから辿れるBP書店だと定価みたいなので、買おうと思ってたけど買いそびれたという方はこちらからトライしてみるといいかもしれません。

「プロメテウス」3Dで見てきた - Sep 03, 2012

とりあえず見とくか……的な。「エイリアン」好きだったし。

「エイリアン」で見覚えのある形をしたものがちょいちょい出てきてニヤリとさせられたんだけど、総じて「なんかよくわかんない映画だった……」って印象でした。「エイリアン」の前日譚っていう触れ込みだったから、アクションなりホラーなりの分かりやすい特徴に期待しちゃったんだけど、そういう分かりやすい(ユーザーフレンドリーな)映画では残念ながらなかった。

敵を2種類出すのは詰め込みすぎだったんじゃないかなあ。「俺は先に帰らせてもらうぜ!」ポジションな2人の扱いも適当っていうか投げやりっていうか……なんかわちゃわちゃ起こってた中の1つの出来事でしかなくって、あんまりオイシイ使われ方ではなかった気がするし。パンフレットを後で見たら「人類の起源に迫る」みたいな所が前面に押し出されてたけど、本編中ではそれすらもなんかわちゃわちゃ語られてた中の1つだった印象を受けました。そういう壮大なテーマよりはむしろ、デヴィッドとホロウェイ博士、社長さんとその子のやり取りから、子が親を超えるとか子が親を殺すとかそういう所の方が話の根底にある物なのかなーという気がしました。

Mozilla勉強会@東京 7th 発表資料を公開しました - Aug 19, 2012

Mozilla勉強会@東京 7thでの発表資料やサンプル実装を公開しました

発表時は準備不足のため時間の配分に失敗し、満足な説明を行えませんでした。すみません。発表時に喋ろうと思っていた内容のメモも併せて公開していますので、そちらもご覧頂ければと思います。

続きを表示する ...

同居と食生活 - Aug 19, 2012

家事とか料理とか普通にしてますよって言ったら「意外だ」って言われた、という事が過去にあった。

「料理してる」という言葉の響きがなんか大仰だけど、実際僕の方がやってる事って、スパゲッティを茹でるか、ご飯の上に鰹節載せてレタスと水菜を刻んで載せてアボカドとネギトロ載せてマヨネーズと醤油かけて「アボカドネギトロ丼や-!!」って言い張って出すか、Cook Doするか、そんな感じですよ。特に料理が趣味というわけでも無い人間が、朝出勤して夜帰ってきた後に残った気力でできる事なんて、たかが知れてますよ。

なんとなくだけど、自分以外の人がいると、カップラーメン出して「晩ご飯これで」とか、スーパーで見切り品の弁当買ってきて「はい」とか、そういうのは、何か、こう……ちょっと、ないよね、って思っちゃって。結果的に取れる栄養の内容は大差なくても、スパゲッティ茹でて出来合いのソースかけて出す方を選んでしまう。

そこにどれだけの意味があるんだろう。見栄なんだろうか。薄いプラスチックのペコペコの容器で出す、っていう事に一番抵抗があるのかも。家でまでそういう器で食事を取るって、なんか、みじめな思いをさせてしまう気がして。そういうのが動機のかなりの部分を占めている気はする。栄養バランスをちゃんと考えていたら、こんなもんじゃ全然駄目なんだろうし。体裁だけ整えようとしてるんじゃんって言われたら、返す言葉も無いですね。

という風な事を、中村うさぎ×伏見憲明 トークライブの記事私にしてもパートナーがいるとか、一緒に暮らしてる人がいるってことは、ちょっと重荷なのよ。だけど、その重荷がずっしりと重くて、背負って歩けないというほどではなく、ちょうどいい重しみたいな感じ。あたりの件を読んで自分を省みて思ったのでした。

「シス管系女子」1話から13話までまとめて読める日経Linux 2012年9月号発売中です - Aug 09, 2012

既にご覧になった方もいらっしゃるかとは思いますが、コマンドライン豆知識漫画の「シス管系女子」が連載されている日経Linuxの9月号が8日付けで発売となりました。Amazonでもお買い求め頂けます。

(付録の表紙の写真) 今回、別冊付録としてシス管系女子の1話から12話までを再録した「シス管系女子まとめ読み」が付いています(代わりにDVD-ROMは無し)。元々の掲載ページ数が少ないので全部で70ページにも満たないいわゆる「薄い本」なのですが、本誌掲載分も合わせると13話を一気読みできます。過去の回を見逃された方・「シス管系女子」ってなんやねん?と気にはなっていたけれども……という方は、是非ご覧下さい!


再録にあたって原稿を見返していると、「描き直したい……!」と思う所ばかりで、古い原稿はほんと見返すもんじゃないなと思いました。1話と2話はみんとちゃんの髪型が3話以降と少しだけ違ってた(3話から変えた)ので、カラー化のついでにそこだけ直しましたけど。

カラー化で思わぬ落とし穴だったのが、スクリーンショットでした。うっかりモノクロに変換した状態の物しか残していなかったので、同じような状況をまた作ってスクリーンショットを撮り直す羽目になってしまい、これがいろんな意味で辛かったです。元ファイルはなるべく残す、というのを怠ってしまった代償は大きかった……


ところで、付録の表紙と本誌掲載の13話(さらに言うとカラー化した1話・2話も)から、制作環境をComicStudio 4にアップグレードしました。コミティアの会場で買ってから半年ほど本棚の肥やしにしてしまってましたが、原稿のカラー化にあたってちょうどいい機会だと思って、頑張って移行してみました。ComicStudio 3から変わっている箇所が結構あって戸惑うことも多いのですが、13話を書き終える頃にはだいぶ慣れてきたような気もします。

あと、アップグレードついでに描画ツールを「鉛筆(ラスター)」から「ペン(ベクター)」に変えました。最初のもえじら組の同人誌で使った時に結構戸惑ったのと、やっぱり線編集に頼るのって邪道かな……という思いと、あと柔らかい線があって、それ以後ベクターのペンツールはずっと避けてしまっていたのですが、表紙に載せるならやっぱり綺麗な線じゃないとガッカリだよねとか、変な所にこだわって無駄に時間かかって汚い絵になるのと、ツールの助けを借りてサクッと綺麗な絵にするのとどっちがいいのかとか、そのへんの事を考えて、昼の仕事と無理なく両立させるためにも読者の皆さんにより良い物をお届けするためにもツールの機能を活かせる所は最大限活かした方がいいだろう……と考えを改めた次第です。

で、実際切り替えてみた感想ですが、いやー、いいですねこれ(手の平返し)。今までは「この線、なんか気に入らない……!」と思ったら消して描き直してという事を何度も何度も繰り返してたのですが、大体こんなもんやろってところで引けたら後は線修正で微調整するという感じで、ずいぶん時間が短縮された気がします。交点削除で髪の毛などの重なりを描きやすくなったのも大きい。あと、グレースケールのラスターレイヤに鉛筆を組み合わせた描き方だとどうしても線に半透明の部分ができてしまって、トーン処理する時に単純な閉領域選択の塗りつぶしだと線の所が逆に色が薄く見えてしまうというようなことが起こってしまっていたのですが、ベクターのペンツールだとパキッと線の色が着くので、単純な塗りつぶしのままでも結構見れる物になるんですね。これも時間短縮につながった気がします。

まとめると、ツールの機能をちゃんと使うと漫画制作は確実に楽になるのだなあとしみじみ実感したという話なのでした。

セッションの復元とツリー構造の維持 - Aug 07, 2012

ツリー型タブを3ヶ月ぶりに更新した。

地味な修正が多い中で特に地味な修正だけど、セッション復元でツリー構造が壊れるという問題について一定の改善を見られたのではないかと思ってる。実際に効果があったのかどうかは、今後同様のバグ報告が減るかどうかで見るしかない。

何故ツリーが壊れるか、という事の前にそもそもツリーが壊れるってどういう事やねん、という話なんだけど、ツリー型タブを使っててごく希に、「リンクから新しい子タブを開いても子タブにならない」とか「親にあたるタブには折り畳みのためのつまみが表示されているのに、子になったはずのタブはインデントされておらず、つまみをクリックしても子になったはずのタブが折り畳まれない」とかそういう怪しい挙動になる事があった。

何故そういう事が起こるのか。これはタブの管理方法に理由がある。

ツリー型タブでは、個々のタブに一意なIDをあらかじめふっておいて、tab.setAttribute(TreeStyleTabService.KPARENT, parentTab.getAttribute(TreeStyleTabService.kID)) とか tab.setAttribute(TreeStyleTabService.kCHILDREN, childTabs.map(function(aChild) { return aChild.getAttribute(TreeStyleTabService.kID); }).join('|')) とかいう感じにIDの文字列をキーにして互いの関係を保持している。親のタブや子のタブを取得する時は、TreeStyleTabService.getParentTab(tab) とした時にその中で tab.getAttribute(TreeStyleTabService.KPARENT) して取得したIDを使って(DOM3 XPathなどで)実際の要素を改めて取得するという風になってる。何故こうしたかというと、

  • タブの要素ノードに直接 tab.parentTab = parentTab のようにしてしまうと、うっかり参照を消し忘れたらいつまで経ってもメモリが解放されないんじゃないか、という心配があった。(意図しない事態の発生を防ぐため)
  • 実際には setAttribute() するのと同じタイミングで SessionStore.setTabValue(tab, TreeStyleTabService.kPARENT, parentTabId) のようにしてセッションに情報を複製しており、クラッシュ時のツリーの復元などに役立てている。(ツリー構造の永続的な保存のため)

といった理由があってのことだった。

これはそれなりに堅牢なやり方なはずだと思ってたんだけど、実際にできあがってからJavaScriptデバッガでプロファイリングしてみたら、IDの文字列からタブの要素ノードを探すという処理が呼ばれる回数が突出して多くて、それが結構無駄な待ち時間を増やす元になっているらしかった。それで、もう少し高速に動作するような仕組みを後から加える事にした。setAttribute(TreeStyleTabService.kID, id) するのと同じタイミングで、gBrowser.treeStyleTab.tabsHash[id] = tab; としてハッシュテーブルを作っておき、それ以後はそちらだけを参照するという、ごくシンプルな物だ。

上記のおかしな挙動は、このハッシュテーブルが原因だっていた。このハッシュテーブルの仕組みが上手く働くためには、「ハッシュテーブルに入っていないタブはない(すべてのタブがハッシュテーブルで管理されている)」という前提が必要になる。もし万が一何らかの理由でハッシュテーブルの管理から漏れてしまうと、そのタブはAPI経由では永久に見つけられないことになってしまう。そのタブを親として子タブを登録する、という風な事はできるのに、その子タブに保存された情報から親のタブを探そうとしても、ハッシュテーブルに無いタブだから見つけられない。こういう不整合の発生は考慮に入っていなかったので、親子関係に基づくインデント幅の調整などの処理が中途半端な所で止まってしまって、上記のような色々と不可思議な現象が発生していた。

色々調べた結果、大量のタブが一気にセッション復元された時に「現在のタブ」になっていたタブが、このハッシュテーブルの管理から漏れてしまうことがあるようだという事が分かった。なので、そのような場合もちゃんとハッシュテーブルに入るようにした。これによって、手元で再現性100%だったケースについては問題が起こらないようになった。これまでに報告があった全ての問題がこれと同一の原因かどうかは不明だけれども、今までよりは問題が起こりにくくなったという事は言えると思う。

あと似たような問題で、タブの復元のタイミングによっては「ツリー構造だけの高速な復元」ができなくなるという現象も起こっていた。ツリー型タブが完全に初期化されるよりも前にFirefoxのセッション復元の仕組みによってタブが復元されていた、という想定外の状況が発生していて、それで色々な前提が崩れてしまっていた。理屈から言ってなんでそうなるのかがてんで分からなくて、どうにかしてタブが復元されるよりも前のタイミングに割り込みたかったんだけど、どうも無理っぽかったので、既にタブが復元されてしまっていた場合でもちゃんとそれらのタブを「後から初期化」するようにした。

そういう地味な修正ばかりが入っている版です。

Unityのランチャーに沢山Firefoxの項目を追加する代わりにサブコマンド?にした - Jul 29, 2012

複数のプロファイル、複数のバージョンを検証用に用意しないといけなくて、簡単に使い分けられるような環境を作る必要があるのです。

  1. Unityのランチャー上にある「Firefox ウェブ・ブラウザ」を右クリックして、「ランチャーに常に表示」のチェックを外す。
  2. /usr/share/applications/firefox-custom.desktopとして以下の内容でファイルを作成する。

    [Desktop Entry]
    Version=1.0
    Name=Firefox Web Browser (custom)
    Name[ja]=Firefox ウェブ・ブラウザ (custom)
    Comment[ja]=ウェブを閲覧します
    GenericName=Web Browser
    GenericName[ja]=ウェブ・ブラウザ
    Exec=firefox %u
    Terminal=false
    X-MultipleArgs=false
    Type=Application
    Icon=firefox
    Categories=GNOME;GTK;Network;WebBrowser;
    MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;x-scheme-handler/chrome;video/webm;application/x-xpinstall;
    StartupWMClass=Firefox
    StartupNotify=true
    X-Ayatana-Desktop-Shortcuts=NewWindow;Sub;ESR;Stable;Beta;Nightly;
    
    
    [NewWindow Shortcut Group]
    Name=Open a New Window
    Name[ja]=新しいウィンドウを開く
    Exec=firefox -new-window
    TargetEnvironment=Unity
    
    
    [Sub Shortcut Group]
    Name=Sub
    Exec=firefox -no-remote -p sub
    TargetEnvironment=Unity
    
    
    [ESR Shortcut Group]
    Name=ESR
    Exec=/home/piro/opt/firefox-esr/firefox -no-remote -p esr
    TargetEnvironment=Unity
    
    
    [Stable Shortcut Group]
    Name=Stable
    Exec=/home/piro/opt/firefox-stable/firefox -no-remote -p stable
    TargetEnvironment=Unity
    
    
    [Beta Shortcut Group]
    Name=Beta
    Exec=/home/piro/opt/firefox-beta/firefox -no-remote -p beta
    TargetEnvironment=Unity
    
    
    [Nightly Shortcut Group]
    Name=Nightly
    Exec=/home/piro/opt/firefox-trunk/firefox -no-remote -p trunk
    TargetEnvironment=Unity
    
  3. ファイルに実行権限を設定する。
  4. Dashホームから「Firefox ウェブ・ブラウザ(custom)」を探して、実行する。
  5. ランチャーに表示されたアイコンを右クリックして「ランチャーに常に表示」にチェックを入れる。

これで、アイコンを右クリックして各プロファイルで起動できるようになった。

ユーザのホーム以下にファイルを作成して複数のアイコンを登録してみたりとか色々試みてたんだけど、自分で付けた名前と表示名が一致しないとか色々動作が怪しくて、結局このような所(グローバルな設定ファイルとして作成)に落ち着いた。

2014年8月21日追記。Ubuntu 14.04LTSで、Thunderbird用の物も作った。

[Desktop Entry]
Encoding=UTF-8
Name=Thunderbird Mail (custom)
Name[ja]=Thunderbird電子メールクライアント (custom)
Comment=Send and receive mail with Thunderbird
Comment[ja]=メールの読み書き
GenericName=Mail Client
GenericName[ja]=電子メールクライアント
Keywords=Email;E-mail;Newsgroup;Feed;RSS
Keywords[ja]=Eメール;イーメール;mail;e-mail;email;メール;電子メール;ニュースグループ;ネットニュース;RSS;フ>ィードリーダー;書く;読む;Mozilla
Exec=thunderbird %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=thunderbird
Categories=Application;Network;Email;
MimeType=x-scheme-handler/mailto;application/x-xpinstall;
StartupNotify=true
Actions=Compose;Contacts;AnotherProfile

[Desktop Action Compose]
Name=Compose New Message
Name[ja]=新しいメッセージの作成
Exec=thunderbird -compose
OnlyShowIn=Messaging Menu;Unity;

[Desktop Action Contacts]
Name=Contacts
Name[ja]=連絡先
Exec=thunderbird -addressbook
OnlyShowIn=Messaging Menu;Unity;

[Desktop Action AnotherProfile]
Name=Start with Another Profile
Exec=thunderbird -no-remote -p sub
OnlyShowIn=Messaging Menu;Unity;

Firefoxの物を作った時と微妙に様式が変わっているようだ。

Ubuntuでのgeditとvimの初期設定 - Jul 23, 2012

自分がGNOME3ベースの環境でgeditを使う時に最低限これだけはやっとくという設定。

  • タブ幅4、自動バックアップなし。
  • フォントはシステムフォントではなくIPAゴシックあたりをダイレクトに指定(これは必要ないか?)
  • シンタックスハイライトで太字にならないようにする。 /usr/share/gtksourceview-3.0/styles/classic.xmlをclassic-nobold.xmlとかなんとかいう名前でコピーして、vimで開いて:%s/ bold="true"//して、スタイルの名前を書き換えて上書き保存して、geditの設定で色のスキームの欄からファイルを選択して一覧に追加して選択する。 ( Gedit の色設定。 - 研究日誌。のやり方に従った)
  • エンコーディング自動判別用の設定を日本語環境向けに変更する。 gsettings set org.gnome.gedit.preferences.encodings auto-detected "['UTF-8','CURRENT','SHIFT_JIS','EUC-JP','ISO-2022-JP','UTF-16']"で、自動判別がまともに動くようになる。 (geditの文字化けを解消する (GNOME3) - 憩いの場のやり方に従った)
  • プラグインを入れる。設置場所は ~/.local/share/gedit/plugins/ 以下(GNOME2の頃に書かれたような古いドキュメントでは ~/.gnome2/gedit/plugins/ 以下に置くように書いてあるけど、GNOME3では .local 以下に置くようになってる)。
    • Regex Search and Replace(正規表現での検索と置換を可能にする): Gedit/Plugins - GNOME Live!の「Regular Expression Plugin」の所からダウンロードできる。

あと、vimの設定も。というか、Ubuntuの方の設定なんだけど。

  • sudo apt-get install vimでインストール。
  • sudo update-alternatives --config editorで設定のリストが出るので「vim.basic」を選択する。

vimを使っているのは、nanoはGNOME標準のキーバインドとも何とも異なるワケ分からない操作体系のようなので、それよりはまだlessとかと操作が共通している部分が多いvimの方がマシ……という判断による。

ページ内の見出し一覧をMarkdownのリスト形式で出力するbookmarklet - Jul 05, 2012

前に似たような事をやった気がするけど。

javascript:

var tab  = '   ',
    min = prompt('Input minimum level of the headings (default=1)');

function tabs(n) {
  var ret = [];
  for (var i = 0; i < n; i++) ret.push(tab);
  return ret.join('');
};

function collectHeadings(minLevel) {
  var rawHeadings = document.querySelectorAll('h1, h2, h3, h4, h5, h6');
  var headings = [];
  var heading, node;
  for (var i = 0, maxi = rawHeadings.length; i < maxi; i++)
  {
    node = rawHeadings[i];
    heading = {
      node: node,
      id: node.id,
      label: node.textContent,
      level: parseInt(node.localName.charAt(1))
    };
    if (heading.level >= min)
      headings.push(heading);
  }
  return headings;
}

function generateList(headings) {
  var list = [],
      h,
      id,
      item,
      nest = 0;
  for (var i = 0; i < headings.length; i++)
  {
    h = headings[i];
    id = h.id || h.node.parentNode.id || h.node.parentNode.parentNode.id;
    item = (id) ? '['+h.label+'](#'+id+')' : h.label ;
    if (i > 0) {
      if (h.level > headings[i-1].level) {
        nest += 1;
      } else if (h.level < headings[i-1].level) {
        nest -= 1;
      }
    }
    if (nest == 0) {
      list.push(' * '+item+'\n');
    } else {
      list.push(tabs(nest)+'* ' + item + '\n');
    }
  }
  return list.join('');
}

var headings = collectHeadings(Math.max(1, min));
var list = generateList(headings);
if (list) window.open('data:text/plain,'+encodeURIComponent(list));

見出しレベルの関係がちゃんとしてないとうまく動かない。あとsection/headingのネストには対応してない。

Page 15/241: « 11 12 13 14 15 16 17 18 19 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき