auto-complete に日本語を補完させるプラグインをつくってみた

emacs

はじめに

これはEmacs Advent Calendar 2017の 25 日目の記事です。

記事を書くのは実に 3 年ぶりのようですね……

発端

ある日*1、嫁さんが言いました。

「講演会のメモとりでメモ帳とかワードパッド使ってるけど、emacs を試してみようかな」

それを聞いた私は考えました。

「せっかく使うって言うんだし、便利機能があると嬉しかろう。そういえば、昨今はスマホもタブレットも入力時は補完候補を出してくるし、日本語補完とかあったら良さそう。よーし、おじさん一肌ぬいじゃおかな？」

できたもの

というわけで、ac-jawords という拡張機能を書きました。auto-complete が導入されている環境ならすぐに使えますので、よろしければお試しください。

https://raw.githubusercontent.com/lurdan/ac-jawords/master/screenshot.png

次のような特徴があります。

  • 文脈 (現在作業中のバッファ) に即して補完候補を表示
  • 補完候補は単語+αくらいでほどほどの長さ
  • 議事録やブログエントリ程度の長さの文章なら、まぁ軽快に動作 (論文とか書籍原稿なんかは重すぎて厳しいかも……)

補完候補の元データは現在のバッファなので、既に入力している言葉以外は出現しません。逆に、特殊な用語などで「あー、単語登録するほどでもないけど何度も同じ入力するの面倒くせー」とか、自分がよく使う言い回しなどは、それなりに候補として出してくれるのではないかと思います。

tinysegmenter という形態素解析ライブラリを使うことで、候補文字列をわりといい感じに区切って出すということをしていますが、一方で頻度計算や重みづけといったスマートな仕組みは何もないため、候補の妥当性は完全に tinysegmenter 頼みになっています。

オチ

それっぽく動くようになった時点で「こんなん作ってみたけど、どうかなー？」と動作デモをしてみた結果、

「専門用語は自分で略記するからねー (だから補完はなくても別に……)」
「一呼吸あるというか、ちょっと動作が重いよね」

など、ありがたいお言葉をいただき、利用されるには至りませんでした。泣いてなんかないやい。*2

実装まわりのよしなしごと

さて、日本語を補完するような emacs 拡張は実はすでに存在しています*3。

auto-complete 用のプラグインとして、情報源が 2 つ利用可能です。ただ、困ったことにどちらも情報源の名前で ac-source-skk を使っているので、併用したい場合は注意が必要です。

ac-source-dabbrev-ja は、同じような入力ではじまる文字列を、バッファ内から探してくれるものです。標準の ac-source-dabbrev でも日本語を拾ってくれなくはないのですが、半角スペースや行末をみつけるまで全部つなげてきたりと色々な問題があって実用できません。それを日本語だけ拾うように調整した、という感じの挙動をします。

ac-source-skk (ac-ja 版) は、入力しかけた頭文字と一致する単語を SKK 辞書から拾ってくれるものです。動作イメージとしては、ローカルで動く server completion、でしょうか。先頭一致の候補がどさっと表示されるので、ちょっと絞るのが大変かも。

ac-source-skk (ac-skk 版) は、skk-dcomp のように動きます。つまり、漢字を変換しようとしている時に、その候補を出してくれます。skk-dcomp との違いは、候補がひらがなではなく漢字で表示されることでしょうか。「探す→選ぶ→変換」という操作が「探す→選ぶ」になって若干短縮されるのかもしれません。

ac-source-skk-hiracomp は、ひらがなを入力していくと、変換モード扱いの候補を出してくれます。区切り文字がうるさかったり、動きにはクセがありますが、SKK でモードレス入力をしたい、とかはできる、のかもしれません……。

私のイメージに一番近いのは ac-source-dabbrev-ja だったのですが、「出てほしい候補が出ないな……」「候補がちょっと長すぎるかも」と、どうにも挙動がしっくり来ません。他の情報源も、出てくる候補が多すぎたり、挙動が鈍重だったりして、どうもうまく使えるようにできませんでした。

仕方ない、自分でなんとかするしかなさそう。というわけで、あれこれ模索してみることにしました。

(失敗) company-dabbrev-ja / ac-dabbrev-ja-2

最初は「まぁ auto-complete 用はもうあるんだし、ac-source-dabbrev-ja を company 用に移植する感じでいってみよう」と思ってました。

実際に作りかけていたんですが、company にはコンソールモードでは fullwidth 文字が崩れるという問題がある (うえで放置されている) *4 ことがわかったので、company じゃダメだわ、となってしまいました。イマドキ ASCII 専用とかマジ勘弁。
余談ですが、自分 の emacs 設定では auto-complete から company へとのんびり切り替えを進めていたんですが、上記を受けてキャンセルし、auto-complete の設定をやり直すハメになったりしています。

ともあれ、先達の実績もあるので、素直に auto-complete を使うことにします。これなら ac-dabbrev-ja をちょっと自分好みに調整するだけでいいだろうし？

……というのは浅はかだったようで、次は dabbrev の挙動を追いきれないという壁にあたってしまいました。
どうやら、現在カーソルがある場所から、前方と後方にそれぞれ複数回の検索をしているような気配なんですが、細かい部分でどういう意図で何をやっているのかどうも見えてきません。
だいたい、一つの関数がやたら長くてわかりにくいし、これはコードを読んで挙動を追うのは無理っぽい……ということで諦めました。プログラマじゃないからね。しかたないね。

(断念) prime.el / pobox.el もどき

prime も pobox も、知る人は知っているイニシエの Emacs 拡張で、日本語入力の補完機能をもっていたものです。
打ち捨てられて久しいこれらの機能を、auto-complete の情報源として使えないかしら？

……と思ったのですが、prime も pobox もコードを読もうとしてみたものの、挙動がさっぱり理解できなくて諦めました。プログラマじゃ(ry

ac-jawords

こりゃ無理かな、と思っていた時に、auto-complete には標準で ac-source-words-in-buffer があることに気付きました。これは開いている複数バッファ内の (英) 単語を補完候補として探してくるもので、その場で検索する dabbrev とは違って、事前に単語のインデックスを作っているようです。コードも比較的追いかけやすい気がするし、これをベースに、日本語でそれっぽく動くようにしてみよう、……としてみた結果が、ac-jawords(-in-buffer) というわけです。

実際のところ、調整した内容は比較的単純です。

  • 日本語文字以外は全て無視する
  • 候補は、形態素解析をした後で、先頭の 2,3 ブロックのみを候補として利用する

この時点で、おおむね想定通りの動きはするようになっていたのですが、嫁さんはともかく自分でも使わんわい、というぐらい動作がもっさりで、「うーん、微妙……」という感じでした。
なので、その後は少しでも動きを軽くするための調整をちまちまとやっています。

  • 各種文字数の分岐条件をあれこれいじってみる (何文字以上は無視、とか何文字以上だけ拾う、とか)
  • 候補になりえない文字列をはじくなど、インデックスをできるだけコンパクトに
  • できるだけ tinysegmenter に文字列を渡す回数を減らし、渡す文字列も短く
  • 対象を現在バッファのみに限定 (同一 major-mode のバッファとかそういうのは削除) *5

ネタとして Advent calendar に間にあうように仕上げるのは無理かなー？ と諦めていたのですが、自分では使ってもいいかと思えるくらいにはなった*6ので、えいやっとエントリしてみることにしたのでした。

というわけで、Advent calendar 最終日、お楽しみいただけましたでしょうか。それでは皆様、よいお年を。

*1:この日に至るまでにはそれなりの経緯 (セットアップとか専用設定とか org-mode の説明とか) があったりするけど、それはまた別の話……

*2:なので、その後の調整はほぼ自分専用 (= SKK 前提) になってしまった

*3:ほぼ @myuhe さんの独壇場

*4:https://github.com/company-mode/company-mode/issues/495

*5:実はこれで劇的に軽くなった

*6:コミットログを眺めると、右往左往してあがいているさまがあらわに……（＊ノノ

lookup の検索結果を pos-tip で表示する

emacs

ドーモ、emacs おじさんです。

辞書を引くのに、10 年以上 lookup を使っています。epwing は絶滅危惧規格ではありますが、dessed と LogoVista さんのおかげで現在でも有用な辞書を手元におくことができます。

そんなわけで手放せない lookup なのですが、不満がいくつかあります。

ひとつは、完全に独自に構築されたウィンドウ管理。popwin や helm に噛ませることができればなぁ……と一時あれこれ試してみたのですが、結局挫折しました。

もう一つは、autolookup です。これは lookup の 1.x 系列にしか対応していないので 2.x 系列では使えないうえに、使えたとしても訳語の表示場所がミニバッファで、視線移動が切ないといえるでしょう。

できれば、ウェブブラウザでよくあるように、結果をポップアップして欲しい。

という思いをずーーーっと持っていたのですが、関西 Emacs で気分が盛り上がっているうちに、と無理矢理なんとかしてみました。lookup 2.x 用です。

elisp

もしかして gist 貼れないの……？

https://gist.github.com/lurdan/11146220#file-lookup-at-point-el

モックとして上流の方に見せてみて、同じようなことをより流儀にそったやり方で実現してもらおー、という目論見なので、極めて投げやりかつその場しのぎのコード (というかlookup 本体から関数コピーして出力いじっただけ) になっています。

上記を .emacs に追記して (キーバインドはご自由に)、lookup-at-point を適当な英単語の上で呼んでみてください。

このように、カーソル付近の単語を拾って、検索結果を pos-tip で表示します。

デフォルトでは、何か操作をするまで表示し続けるようになっていますので、好みで

(setq lookup-at-point-pos-tip-timeout 時間)

を指定するといいでしょう。

タイマー的な処理と組み合せて、autolookup の代わりにすることもできると思いますが、個人的にはちょっとうるさかったので、w3m-mode-map で ; にアサインするくらいが丁度いい感じです。

制約とか問題とか

なにぶんやっつけ仕事なもので、あれこれ制約があります。

辞書は決め打ち

自由に選んだりすることができません。

デフォルトでは、辞書リストの最初にあるものを使います。指定したい場合は、事前に lookup でモジュールを作って使いたい辞書を登録し、

(setq lookup-at-point-pos-tip-module "モジュールの名前")

とする必要があります。

エラー処理なし

対象の単語は lookup の機能を使って拾っていますが、結果のチェックをしていないため、単語を拾えない場合は string をよこせ、nil 投げんな、と怒られます。

スペル補正なし

lookup のように賢く見出し語を予測してくれたりしません。

フォーマットなし

外字とかリンクとか修飾とか、おおむね全滅です。

というわけで

誰かかっこよく実装し直してくれないかなぁ……。

Debian/Ubuntu Advent Calendar の紹介

debian

これは、ディストリビューション/パッケージマネージャー Advent Calendarの 23 日目の記事です。


実は Debian/Ubuntu 界隈では、2011 年から単独で Advent Calendar が走っていたりします。
Advent Calendar は毎日楽しみにめくっていくにはいいのですが、後で見返すのはなにげに面倒だったりしますので、紹介も兼ねてこれまでの Advent Calendar エントリを整理してみました。

最初は可能な限り拾おうと思っていたのですが、ちょっと収拾がつかないので、Debian 固有かつ時事ネタでないものに絞りました。

インストールとブート

Live イメージ作成ツールの紹介から、ブートローダ設定、加えて自動インストールでは欠かせない preseed の Tips などです。

各種アーキテクチャとクロス環境

Debian は主流でないアーキテクチャへの移植版も、作業する人がいる限りは公式に含められる可能性があります。そういったアーキテクチャやクロスビルドについての記事あれこれです。

派生ディストリビューション関連

Debian には 派生版がたくさん存在しています。Ubuntu が筆頭ですが、他にもこんなのがあるよ、という紹介です。

Debian システム管理

ユーザとしては、日常での運用管理で役立つこれらの記事が有用かと思います。

APT とパッケージ

Debian の肝である、APT とパッケージについての各種 Tips です。

パッケージ開発

意外なことに、パッケージングそのものについての記事はあまり数がありませんでした。

BTS あれこれ

何かやってみたいけど、とっかかりがないなー、という方はまずこのあたりからどうぞ。

ビルド環境など

ビルドのために入れた依存パッケージをそのままにして環境が汚れるのは避けたいものです。隔離したり記録をとったり、いくつかやり方がありますので、好みの方法を参考にしてみてください。

パッケージの情報収集

開発時に必要なパッケージ情報をあれこれ知りたい場合は、これらの手段を使うことができます。

Debian Maintainer 向け

Debian Developer になるのはとても大変ですが、そうでなくても Debian Maintainer としてパッケージをメンテナンスすることはできます。そんな見習い開発者向けにはこういった記事があります。

複数リリースを渡り歩く

Debian は昨今の状況においては、リリースのペースが比較的ゆっくりです。以前のリリースや、開発版と安定版が併走する期間も長いので、その間の差分が気になることもあると思います。そういう場合はこれらの記事を参考にしてみましょう。

各種資料や情報源など

まずは、この記事のもととなった、これまでの Advent Calendar の一覧です。ここでは紹介していませんが、各種アプリ紹介や利用上の Tips、いろんなハードに入れてみた、などの記事もありますので、眺めてみると面白いのではないかと思います。

インストールしたパッケージについて、可能な限りそのシステム上でドキュメントを参照できるようにする、というのが Debian のポリシーなのですが、Debian 自体の操作についてもちゃんと用意されています。


なお、関東と関西でほぼ毎月行われている Debian 勉強会では、TeX で作成している配布資料をリポジトリが公開しており、誰でもビルドできるようになっています。ビルド方法は、次の記事が参考になるでしょう。


というわけで、これまでに書かれている Advent Calendar 記事を振り返ってみました。ぜひ活用してみてください。

冬休みを前に、最強のフラッシュカードを手にしよう

emacs

これは、.emacs Advent Calendarの 20 日目の記事です。

さて、org-mode の contrib パッケージには、org-drill という暗記支援の拡張機能が収録されています。

これは一般的にはフラッシュカードや単語帳と呼ばれる類のもので、SRS (Spaced Repetition System)*1 をベースに、クイズの反復練習間隔を賢く管理してくれます。

同種のツールは他にも様々なプラットフォーム向けに存在していますが、org-drill には次の利点があります。

  • フラッシュカードの内容にあまり制約がない
  • 最強のフラッシュカード編集環境
  • フラッシュカードと通常のメモが共存できる
  • カスタマイズし放題

org-mode のツリー形式に変換するだけで既存の単語帳データをそのままインポートできる他、メモの中で気になる部分だけクイズ形式で書いておいて後からまとめて復習する、といったことも可能です。

逆に、次のような欠点もあります。

  • ちょっとした待ち時間に携帯端末でクイズを実行、は難しい
  • 結果の自己評価がすこし面倒 (ツールによっては選択肢を提示し、解答結果を元に自動評価してくれるものもあります)

最初の問題は android であれば emacs アプリを使って頑張れるかも知れませんが、あまり現実的ではなさそうです。

ともあれ、普段 org-mode をメモの道具として使っていれば、導入はとても簡単なので、気軽に試してみてください。

インストール

Debian パッケージの org-mode を使っている場合は、ファイル自体は含まれていますので、contrib への load-path を追加で指定してください。
emacs の packages を使っている場合*2は、org-mode.org が配布しているバージョンが必要*3ですので、リポジトリに追加した上で、org-plus-contrib パッケージをインストールします。
他の方法を使っている場合は、どうとでもできるでしょうから、どうとでもしてください。

次回起動時から有効になるように、.emacs への追記もお忘れなく。

; Debian パッケージを使っている場合
;(setq load-path (cons "/usr/share/org-mode/lisp" load-path))

(require 'org-drill)

単語帳の作成

org-drill では、当然ですが org-mode でカードを書きます。サンプルとして単語帳ファイルも付属しているのですが、題材がスペイン語 (spanish.org) なので、日本人的には扱いにくいように思えます。
ですので、まずは簡単に英語の単語帳を作ってみることにしましょう。新しく org ファイルを作成 (e.g. english.org) してみてください。

org-drill には、デフォルトでカードの形式がいくつか用意されています。そのうちいくつかの例を紹介しますので参考にしてください。その他の形式の詳細や、カード形式のユーザ定義などについてはマニュアルをどうぞ。

おおまかな前提として、org-drill は :drill: タグをヘッダにつけたエントリを問題カードとみなします。子ヘッダはカード形式によって使われたり使われなかったりします。

シンプル

問題があって、解答を下敷で隠して考える、というイメージのカード形式です。

適当なヘッダに :drill: タグをつけましょう。
ヘッダの深さは関係なく、:drill: タグのあるエントリが一組のカードと見做されます。また、ヘッダの内容自体は無視されるので、自由に使うことができます。

ヘッダ直下のエリアに、問題となる内容を記述します。ここに書いた内容は、クイズセッション中にそのまま表示されます。

* Quiz                                                                :drill:

tuberculosis

続けて、ヘッダを一段下げて、解答となる内容を記述します。ここに書いた内容は、クイズセッション中、問題が表示されている時に何かキーを押すと表示されます。

* Quiz                                                                :drill:

tuberculosis

* Answer
肺結核
穴埋め問題

マーキングした単語に、半透明の赤いフィルムをかぶせて、問題文の一部をマスクするイメージのカード形式です。

この形式では、子ヘッダは不要です。問題文中でマスクしたい部分をブラケットで囲んでおけば、問題ではその部分がマスクされ、何かキーを押すとその部分が表示されます。

* Quiz                                                                :drill:
He died of [tuberculosis].

彼は肺結核で死んだ。
両面カード

小さいカードの表と裏にそれぞれ対応する内容が書かれているイメージのカード形式です。一方通行ではなく、どちらの内容も問題として使われますが、残念ながらどちらが使われるかはセッション毎にランダムになります。

この形式では、カードの表と裏をそれぞれ子ヘッダとして書きます。正確には、子ヘッダのうち最初の 2 つがカードとして扱われます。カード形式を明示するため、親ヘッダにはプロパティの追記が必要です。

* Quiz                                                                :drill:
:PROPERTIES:
:ORG_DRILL_CARD_TYPE: twosided
:END:

** English
tuberculosis

** 日本語
肺結核

クイズの実行

単語帳ファイルができたら、M-x org-drill を実行してみてください。そのとき開いているバッファを単語帳として、クイズセッションが開始されます。

クイズセッションは、次の順序で進みます。

  1. 問題が表示されるので思い出そうとしてみる
  2. 何かキーを押して解答を見る
  3. 暗記レベルを自己評価してスコアをつける
  4. (オプション) 次回の復習タイミングをスケジュールする
  5. 終了条件を満たすまで繰り返す
  6. セッションのサマリを表示して終了

初めて実行したのであれば、最初のエントリが問題として表示されているはずです。

訳語を思い出したら、あるいは思い出せなくて諦めたら、何かキーを押せば解答が表示されます。
次の問題に進む前に、暗記状況の自己申告が求められますので、1 〜 5 のうち当てはまるものを押してください。場合によっては次回のスケジュールを聞かれたりしますが、こだわりがなければそのまま C-m (RET) すれば問題ありません。ここで思い出せなかったエントリは、思い出せるようになるまで何度も何度も問題として出現します。

これを繰り返していき、一定の条件 (デフォルトでは、30 件の暗記テストに成功するか、20 分が経過) を満たせば、クイズセッションは終了です。結果のサマリが表示されますので、そっと涙を拭くなどしましょう。

おおむね、こういうものは継続的に行うことで効果が増すものですが、常時目の前にある環境だと「いつでもできるわー」とズルズル後回しにしてしまいがちです。個人的には、セッションに入る特定の状況を決めてしまうことをオススメします。例えば、通勤/通学途中で PC を開く余裕があるならそこでとか、警備任務から帰投するまでの 20 分とか、あるいは帰宅後にダラダラ TL を眺めながら、など。日々繰り返していて、20 分程度までの待ちが発生する状況がうまく見つかるといいですね。

ちょっとした小ネタ

org-capture で単語帳を作る

次のような org-capture テンプレートを使って、簡単にカードエントリを追加していくことができます。リージョン選択していた部分を表側に自動で入力してくれるので、若干手間が省けるでしょう。ヘッダの名前やカードの種別は私が使っているそのままなので、適当に修正してください。

("v" "Vocabulary" entry
(file+headline "~/path/to/wordbook.org" "Vocabulary")
"* Quiz :drill:\n:PROPERTIES:\n:DRILL_CARD_TYPE: twosided\n:END:\n** 表\n%?%i\n** 裏\n** Context\n%l\n** 補足\n")

英語の単語帳として使うなら、expand-region や mark-word あたりを適当なキー (C-@ など) にバインドしておくとさらに便利に使えます。
w3m-el や org-mode で英語文書を眺めながら「あーこの単語わからん」と思ったら、C-@ C-M-r *4 でその単語が入力されたカード編集画面になるので、カードの裏に訳語を追記して C-c C-c、で備忘録を残しながらすぐに元作業に復帰することができます。

カードを作った時点で、入力された単語の位置にカーソルがいるので、そのままそこで C-x C-y *5 すれば辞書をひくことができます。


中断と再開

単語帳が育ってくると、あるいは一度に大量のエントリを投入したりすると、クイズセッションにかかる時間がバカにならなくなってきます。そういう場合は、無理せずにできるところまでやって中断しましょう。
クイズ表示中に q (quit) もしくは e (edit) を押せば、クイズセッションはその場で終了します。もう一度 M-x org-drill とやってしまうと、最初からになってしまいますが、かわりに M-x org-drill-resume を実行すれば、前回中断したところからセッションを再開することができます。

一夜漬け(おさらい)モード

問題の出現頻度は SRS によって管理されているのですが、もう覚えたハズのものも含めてランスルーしたくなる場合もあると思います。その時は、M-x org-drill-cram とすると、これまでの解答履歴データを無視して、全てのカードを復習することができます。

マルチメディア

emacs ですし org-mode ですので、普通に画像をはりつけることが可能です。org-player を併用すれば音声や動画へのリンクを集約することもできます。

深みにハマったら

org-drill は、適切なデフォルト設定をもっているので、あまり設定を意識せずにそのまま便利に使うことができます。ですが、当然というかやっぱりというか、やろうと思えばいくらでもカスタマイズすることができます。

  • 表示色
  • 単語帳ファイルの分割
  • SRS アルゴリズム (いくつかの種類から選択)
  • スケジューリング
  • 内部マーキング条件
  • etc.

このあたりに手を出して org-drill 自体をしゃぶりつくすのもいいでしょうし、単語帳を育てに育てて公開する (そのための機能も用意されています) のもまた楽しいかもしれません。

最後に

ざっと駆け足で、org-drill によるフラッシュカードの導入方法を紹介してきました。いかがでしたか？
用途は単語の暗記に限らないので、普段「あーなんか毎回これググってんなー」と思うようなことがあれば放りこんでみるのもいいでしょうし、読書しながら、付箋やマーキングのかわりに使用してもいいでしょう。

折しも冬休みが目前ですね。まとまった時間がとれる(で、あろう)この時期に、気分をかえて自然言語に手を出してみる*6のも面白いかもしれません。

Happy Anking!

*1:SRS の詳細はてきとーにググってください

*2:アップグレードができず、毎回 org を消して再インストールが必要なので要注意

*3:http://orgmode.org/elpa.html

*4:私は org-capture を C-M-r にバインドしています

*5:私が使っている lookup2 の場合

*6:機械の言語ではなく

ラテン語の入力方法

emacs

これは、ラテン語プログラミング Advent Calendarの 5 日目の記事です。
残念ながら私はプログラマではないので、壮絶に流れをぶったぎって基本に立ち返り、手元の環境 (当然 emacs) でラテン語を入力する方法について調べてみました。

ラテン文字は、基本的に英語のアルファベットと同じなので、実は特に工夫をするまでもなくほとんどそのまま入力できます。ただし、次のような場合に特殊文字が必要になります。

  • 母音に長短の区別があるため、表記上で長母音を明示したい場合 (マクロン)
  • アクセントの位置を明示する場合 (アキュート・アクセント)

ちょっと調べてみた範囲では、この他にも稀に短母音を明示する記号 (ブレーヴェ) を使うケースがある他、ギリシャ語由来の言葉をそのまま表記する場合は、ギリシャ文字を使うこともあるようです。
アクセントに関しては音節によって定まる明確なルールがあるため、いちいち明示しなくてもいいと考えれば、初学者的にはとりあえず長母音が入力できればよさそうですね。案外気楽に入力できるような気がしてきました。

さて、肝心の入力方法ですが、emacs に標準で用意されている input method を利用します。M-x list-input-methods すると、言語ごとに利用可能な input method が一覧されますので、ラテン語のところを見てみましょう。

Latin
  latin-prefix (`L>' in mode line)
    Latin characters input method with prefix modifiers.
  latin-alt-postfix (`L<' in mode line)
    Latin character input method with postfix modifiers.
  latin-postfix (`L<' in mode line)
    Latin character input method with postfix modifiers.

それぞれの input method におけるキーの組み合せは、M-x describe-input-method で調べることができます。例えば、私の好みは postfix (アルファベットの後で特殊指定する) なので、こういう感じになります。

Input method: latin-postfix (mode line indicator:L<)

Latin character input method with postfix modifiers.
This is the union of various input methods originally made for input
of characters from a single Latin-N charset.

<<はてダは UTF8 非対応なので snip>>

実際に入力する時は、M-x set-input-method で input method を指定します。上の表を見ながら、実際にいろいろ入力してみましょう。入力がおかしくなったので戻したい、という場合は C-\ で ON/OFF を切り替えることができます。

上にも書きましたが、とりあえず母音のマクロンだけ入力できればいいなら、"a-" "e-" "i-" "o-" "u-" だけで事足りるはずです。まずはこれを武器に、格変化の写経からはじめてみるといいのかなーと思います。

Omnium rerum principia parva sunt.

pdiff を無効にする

debian

これは、Debian/Ubuntu JP Advent Calendar 2013の 2 日目を意図して書かれた記事です。昨日は、岩松さんによるmultiarch アーキテクチャ用に apt-line を設定するでした。

debian のデフォルトでは etch 以降から、apt のパッケージリスト取得を差分単位で行うようになっています。

ところが、通信量の観点では「一度取得したデータを二度とらなくていいよねー」と合理的に思えるのですが、
差分が増えると、細かいファイルを大量にサーバにリクエストするため、ダウンロードの完了まで、余計に時間がかかる傾向があります。

特に､利用状況が下記にあてはまるなら、都度かなり待たされることになっているのではないでしょうか。

  • パッケージリストが頻繁に更新される sid/testing を使っている
  • 毎日 apt-get update するわけではない

「あーそれ自分とこだわー」と思い当たるところがあれば、試しに次回のタイミングで、こんなオプションをつけて実行してみましょう。

apt-get update -o Acquire::Pdiffs=false

さて、違いは体感できましたか？

環境によっては、デフォルトのままの方が早かったり、あまり違いが感じられないケースもあるでしょうから、そういう場合は変にいじらずデフォルトのままにしておくといいでしょう。

実際に差分形式だと遅いわー、という場合は、毎回オプションをつけるのも面倒だと思いますので、設定ファイルに追加して、忘れてしまいしょう。/etc/apt/apt.conf.d/01pdiffs などのファイルを作成して

Acquire::PDiffs "false";

と書いておけば、毎回パッケージリストを丸ごと取得しなおすようになります。

Apt のパッケージリスト取得形式の変更方法でした。明日は誰かな？

twittering-mode を popwin に閉じこめる

emacs

私は普段、PC から twitter へのアクセスでは hootsuite か twittering-mode を使っています。

emacs で何か作業している時に twittering-mode を呼ぶと、その作業を完全に中断されるので、本当は shell-pop ライクな操作でチラ見できればいいんだけどなぁ……、と思っていました。

そこで、最近 emacs 設定の整理をあれこれやっていたこともあって、popwin に閉じ込めてみることにしました。

(defun twittering-pop ()
  (interactive)
  (if (popwin:popup-window-live-p)
      (popwin:close-popup-window)
    (if (twittering-get-buffer-list)
        (display-buffer ":home")
      (let ((cb (buffer-name)))
        (twittering-mode)
        (switch-to-buffer cb)
        (display-buffer ":home"))
      )))
(push '(":home" :height 10 :position bottom) popwin:special-display-config)

(global-set-key (kbd "<f10>") 'twittering-pop)

twittering-mode 自体の設定にも手を入れて、twittering-initial-timeline-spec-string によく見る timeline をセットしたり、h と l で timeline の切り替えができるようにしたりしてみました。

結果、「twitter でも眺めるかなー」と思ったら F10 で :home timeline をポップアップさせ、h/l で各種 timeline をザッピングして、用が済んだら C-g (もしくは F10) で消す、という操作の流れになりました。幸せ。

私は minibuffer を使っているので問題ありませんが、popwin の仕様では編集バッファを出すとポップアップが消えてしまうはずなので、つぶやくのにそっちを使っている場合はイマイチかも知れません。