長い間,ぼくは選択肢の多さに悩まされてきた.いや,惑わされてきた,と言った方が適切かもしれない.そして,最近ではそんな選択肢の多さに憎しみすら抱くようになった.以下は,とりとめもなくつづられた,そうした選択肢に対する呪詛の言葉だ. あまりに多い選択肢はプログラマを悩ませる 良く言われることに「あまりに多い選択肢は消費者を悩ませる」というものがある.イヤホンを新調する時のことを考えてみよう.あなたは電気屋へ車を走らせ,イヤホンコーナーへと向かう.すると,そこにはずらりと並んだイヤホンがあなたを待ち受けているのだ. 「一体全体,どれを選んだら良いのだろう」 あなたは途方にくれることとなる. ぼくの中に,ここ半年ほどもやもやと渦巻いていた考えがある.これをどう表現したものかと思っていたのだが,つい先ほど,冒頭の文での「消費者」という単語を「プログラマ」という単語で置きかえることで,すっきりと表現
find-file Emacs の find-file (C-x C-f) は本当に使いにくいものだと, 常々思っていた. 中でも, 補完候補が複数あった場合の挙動. これが何とも気にくわない. 例えば, 以下のように C-x C-f を入力した直後の状態を考える. この時 TAB キーを押すと, デフォルトの Emacs では [Complete, but not unique] との表示が出るだけで, 候補一覧を表示するにはもう一度 TAB キーを押す必要がある. この「二回 TAB キーを押す」という行為が毎度毎度要求されることとなり, そのストレスたるや凄まじいものがあった. また, TAB を二回押して補完候補が表示された後の挙動は, 輪をかけて苛立たしい. この時 TAB を押すとどうなるかといえば「補完候補が全て見れるようにスクロールが行われる」だけなのだ. 補完候補一覧が画
何となく LDRize に手を出してみる気になったのが二時間ほど前のこと。使ってみるとあまりに便利過ぎて、もう LDRize 抜きでのブラウジングは考えられなくなってしまった。 この LDRize で気に入ったのは、 jk を押すだけで、 Google の各検索結果 Flickr の各写真 p2 とか 2ch での各レス はてなダイアリーの各エントリ といった「アイテム」毎にスクロールしてくれるところ。単なる less 風キーバインドだと jk で一行ずつスクロールさせなければいけないため、 20 行のエントリなら 20 回。 5 行のエントリなら 5 回。といったように各エントリ毎に押すキーの回数が異なっていた (もちろんこれはあたりまえのこと)。 しかし LDRize は(データベースに登録されている)サイトの構造を把握している為 jk 1 回で次のエントリ / 前のエントリに移動する
shell-pop.el + ansi-term 先日 shell-pop.el を導入し, その中で ansi-term を使うようにしてみた. 非常に軽快に動いてくれとても快適なのだけれど, ansi-term はデフォルトのままだとかなり癖があって使い辛い. そんなわけで, 自分好みにカスタマイズしてみることにした. 設定 (defvar my-shell-pop-key (kbd "C-t")) (defvar my-ansi-term-toggle-mode-key (kbd "<f2>")) ;; ============================================================ ;; ansi-term ;; ============================================================ (def
popup.el の popup-menu* は非常に便利なのですが, auto-complete.el のように打ち込んだ文字に応じて絞り込み検索がされてくれればなあ, と思うこともあります. 候補が選択されてから C-s を押すことで incremental-search はできるのですが, この C-s が中々手間です. こんなことを Twitter でつぶやいていたら, 作者の id:m2ym さんからコメントを頂くことが出来ました. コメントを参考に書いてみたのが次の関数です. (defun popup-menu-ac-like (&rest arguments) (interactive) (push (car (rassoc 'popup-isearch popup-menu-keymap)) unread-command-events) (apply 'popup-menu
emacs の shell-mode はどうにも好かなかった。使う度にストレスを感じ、結局端末を別に起動してしまう、の繰り返し。 しかし、実行結果を文書中に張り付けたいときなどは、やはり shell-mode でないと手間がかかる。そこで、この際と思ってちょっくら改善を図ってみることにした。 まず、最低限あってくれないと困るのは、 シェルのヒストリが使える zsh や tcsh での history-beginning-search 色表示 といったところ。 一つ目のヒストリに関しては comint-input-ring-file-name という変数に読み込ませたいヒストリファイル名を指定するとのことだったので、 ;; zsh のヒストリファイル名を設定 (setq comint-input-ring-file-name "~/.histfile") ;; ヒストリの最大数 (setq
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く