Mac OSX 上の Google Chrome は、何故か system.log にデバックか実装上の何かしらの情報を沢山吐く。
システムの他の問題を調査するときジャマ臭い。。。なんとかならんのかなぁ。
syslogd には高度なフィルタ機能が実装されていないので、system.log に書き出される行に関しては何ともしがたい。
但し、MacOSXでは syslogd とは別に asl という仕組みが並行して導入されている。「コンソール.app」 のデータベース検索以下の情報は asl の仕組みから取得している。
asl には、結構便利なフィルタ機能が実装されている。なので、件のログを収集しないようにするには、/etc/asl.conf の最後に次の設定を付け加えれば良さそうである。
# /etc/asl.conf に追加
# ommit com.google.Chrome
? [S= Sender com.google.Chrome] ignore
良く考えれば、Chromeからのログを除外した「新規データベース検索」を登録しとけば良かったのかぁ。。。
MacBook Pro 15(Late 2008)は公式では最大メモリ容量は4Gまでサポートなのだが、ファームウェアを最新のアップデート(MacBook Pro EFI ファームウェア・アップデート 1.8)を適用すれば、最大 8G まで普通に認識し速度低下せずに使えるそうである。
2009年末位には結構高価だったのだが、最近値下がりして手ごろになってきたので、交換した。 次いで HDD も交換して SSD (TOSHIBA THNS256GG8BBAA)に入れ替えた。
まぁ、SSD に入れ替えたお陰でOSの起動もアプリの起動も機敏で、いい感じ。
空きメモリが増えてたので、ちょっと1Gくらいブラウザのキャッシュに割り当ててみた。
MacOSX では「hdid」コマンドを使えば簡単にRAMディスクを作成できる。
ramlabel="RamDisk"
ramdev=$(hdid -nomount ram://10240)
diskutil eraseDisk HFS+ ${ramlabel} ${ramdev}
rc.localに仕込んでやれば、起動時にRAMディスクを作成できる。
なぜか上手く行かない。起動後に手打ちで入力すれば、出来るのだが、、、
はて、なんでだろうかぁ？
まぁ、ググっても明快な正解がわからない。。。
当てずっぽに答えれば、『「hdiejectd」デーモンが起動して、正常に定常状態に無いときには「hdid」は機能しない』っぽいのかなぁ。。。多分 SSD で起動が拙速になったからだと思うが、、、
上記の憶測のもとに rc.local を次のようにすれば、起動直後にユーザ用にRAMディスクに載ってる作業領域が作れるようになる。
#!/bin/sh
RAMSIZE=1024 # MBtyes
MP=/tmp/ramdisk
MYNAME=username
# Start hdiXXX
launchctl start com.apple.hdiejectd
sleep 5
# Make RamDIsk
RAMNUMSECTORS=$((${RAMSIZE}*2048))
ramdev=$(hdid -verbose -kernel -nomount ram://${RAMNUMSECTORS})
newfs_hfs -v ramdisk $ramdev
[ -d ${MP} ] || mkdir ${MP}
mount -t hfs -o nobrowse $ramdev ${MP}
# Finder.appで /Volume 以下で参照したいときは nobrowse を外す
# for ${MYNAME}
mkdir ${MP}/${MYNAME}
chown -R ${MYNAME}:${MYNAME} ${MP}/${MYNAME}
あとは、ログイン項目に、次のような キャッシュを調節するシェルスクリプトを埋め込んだ Automator アプリを登録すれば良い。
| MP=/tmp/ramdisk | |
| WP=${MP}/${USER} | |
| if [ $(stat -f %d /tmp) -ne $(stat -f %d ${MP}) ]; then | |
| MNTRD=yes | |
| else | |
| MNTRD=no | |
| fi | |
| ramdirlink() { | |
| name=$1; dir=$2 | |
| if [ $MNTRD = yes ]; then | |
| mkdir -p ${WP}/$name | |
| rm -rf $dir | |
| ln -sf ${WP}/$name $dir | |
| else | |
| [ -h $dir ] && rm -rf $dir | |
| fi | |
| } | |
| ramfilelink() { | |
| name=$1; base=$2; file=$3 | |
| if [ $MNTRD = yes ]; then | |
| mkdir -p ${WP}/$name | |
| cp $base ${WP}/$name/$(basename $file) | |
| ln -sf ${WP}/$name/$(basename $file) $file | |
| else | |
| [ -h $file ] && rm -f $file | |
| fi | |
| } | |
| # for WebBrowser | |
| ramdirlink Caches/Chrome ${HOME}/Library/Caches/Google/Chrome | |
| ramdirlink Caches/Firefox ${HOME}/Library/Caches/Firefox | |
| # 予め Safari でキャッシュを空にした Cache.db を CacheBase.db として保存しておく。 | |
| ramfilelink Caches/Safari \ | |
| ${HOME}/Library/Caches/com.apple.Safari/CacheBase.db \ | |
| ${HOME}/Library/Caches/com.apple.Safari/Cache.db | |
| # for Xcode | |
| ramdirlink XcodeCaches ${HOME}/Work/XcodeCaches |
まぁ、サクサクになったのかなぁ？
コードをちょっとだけ整理して、Xcode と TMPDIR もRAMDISKにのせてみた。
TMPDIR もRAMDISKに載せると、どうも ramdisk のアクセス出来ない現象が時々発生し、キャッシュを載せている Chromeなどのブラウザが固まって、まともに使えない結果になる。。。どうも TMPDIR は ramdisk に載せて運用するのは難しそうである。仕方がないので、設定を削除してみた。。。ここ１ヶ月は、安定してるっぽいので正解かな。。。
dotfiles を公開レポジトリに上げるのが最近の流行らしい。なので、僕も github に上げてみた。
結構古くから VCS に入れて適当に履歴を記録したんだが、 「git rebase -i 」を使うと commit を修正できるので、 CVS ～ Subversion ～ git に変更する過程の履歴を 適当に整理してみた。
うん、なんとも紆余曲折がある、、、未だにちょっと壊れ気味の設定だなぁ。。。
squeeze がフリーズされて、暫く経つので安定の良い頃合いかなと、 自宅のメインのサーバを lenny から squeeze に移行してみた。
何とも、安定してる。。。
lenny ベースだと、古く使いたい機能が無いので、
適当に野良バックポートしてた netatalk と kvm/libvirt-bin とか幾つかあったのが、
標準のパッケージで済むのが良い。
ただ、１点だけ手作業が必要だった。 どうも autofs のマップファイルが LDAP を参照しているとき、 マスタでは slapd が立ち上がらないタイミング(autofs より slapd が後)なので、 うまく機能しない。。。
まだ sysvinit ベースなので、次のようにした。
update-rc.d -f slapd remove
update-rc.d slapd defaults 18 82
upstartに移行した暁には、Debian もいい感じになるのかなぁ
Debian squeeze から upstart の時代だといった奴は、、、 sysvinit と insserv の合わせ技が標準じゃないかぁ！！
なので、/etc/init.d/autofs の先頭に書かれた insserv 設定行の該当部分を下記のように書き換えると、対処ができる。
...
# Should-Start: ypbind nslcd slapd
# Should-Stop: ypbind nslcd slapd
...Debian/Ubuntu の iSCSI Target のお話が出てくると、iSCSI Enterprise Target (IET)が必ず出てくる。
まぁ、良いんだけど kernel ソースに取り込まれていないモジュールを使うので、 時々、他の複合的な要因かもしれないが、あさっての場面で oops は吐いくれたりする。
Fedora/RHEL/CentOS とかだと、既にLinux SCSI Target Framework(tgt)に移行している。コイツは 2.6.20 頃 kernel ソースに取り込まれているので、 結構安定してるんじゃないかなと思う。
tgt の性能に関しては、2006 年頃の論文「Linuxにおけるストレージシステムフレームワークの実現(オペレーティングシステム)」を見る限り、IET と若干落ちるぐらいなので、気にしなくても良いかも。
そろそろ Debian/Ubuntu でも Linux SCSI Target Framework(tgt)に移行する時期だ。
ユーザベースのツール群 tgt パッケージは、squeeze/lucid で用意されているみたいなので、やってみた。
ハマりポイントが２点ある。
なので Fedoraのinitスクリプトを参考に、upstart 用のイベント設定ファイル？ /etc/init/tgtd.confを書き下し、tgt-admin の修正パッチtgt-admin.diffを作ってみた。
例として、単一ディスクをiSCSIで公開する事を考える
以下の設定ファイルを書き下し、「tgt-admin -e」とタイプすれば良い。
/etc/tgt/targets.conf
default-driver iscsi <target iqn.2010-07.com.example:stroage.fserver.data> driver iscsi backing-store /dev/sdb </target>
実際にiSCSIターゲット設定が上手く行ったかは、次のようにする。
# tgt-admin -s
Target 1: iqn.2010-07.com.example:stroage.fserver.data
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00010000
SCSI SN: beaf10
Size: 0 MB
Online: Yes
Removable media: No
Backing store type: rdwr
Backing store path: None
LUN: 1
Type: disk
SCSI ID: IET 00010001
SCSI SN: beaf11
Size: 34360 MB
Online: Yes
Removable media: No
Backing store type: rdwr
Backing store path: /dev/sdb
Account information:
ACL information:
ALL
あとは、巷に溢れている tgt の設定方法が使える。 上手く設定すると、CDドライブやリムーバルディスクとかも、ネット越しで使えるようになるらしい。
気づいてみると、二番目のハマり点も修正済み(#589716)になったようである。
debian squeeze がリリースしたら、tgt をサクッと使うようになれる訳ですね。
GNU のドキュメントシステムに texi 形式のファイルがある。 この形式のファイルから適当なコマンドを使って、info / dvi / pdf / html 等の 文書に変換できる。
最近では PDF 形式に変換するのに pdfetex を使う事で dvi 経由せずに直接 pdf に変換できる。 ただ、pdfetex は日本語化されていないので、日本語で書かれた texi は pTeX と dvipdfmx を組み合わせて変換する必要がある。
% TEX=ptex texi2dvi filename.tex % dvipdfmx filename.dvi
このやり方でも pdfetex を使った変換と同様な PDF が作れるが、一つだけ違いがある。
栞/ブックマークが付かない。
実用上は問題は無いが、栞が付いた方が使い易い。。。はてどうしたもんだかぁ
変換用のマクロ texinfo.tex の日本語化は本家 texinfoには含まれていない。 現在良くメインテナンスされているものとして、角藤版pTeXの texinfotools-w32.tar.bz2 がある。
ただ、僕も昔に texinfo.tex や makeinfo のナンチャって日本語化対応したことがある。 HDD の隅にある断片を探して調べてみたら、どうも elisp-manual-19-2.4-jp2.0.tar.gz を起点にして 作業したもので、検索をかけるとホンの僅かだが OSS の文書変換用に取り込まれている。。。
まぁ、自分の成果から起点とするのが、やり易いからコイツから作業するのがいいやぁ
dvipdfmx が PDF 生成用の special は 「Dvipdfm User’s Manual」/「DVI specials for PDF generation」 にキッチリ記載があり、栞の生成は難しくはなさそうである。
で、texinfo.tex の履歴だけgithub fukusaka/texinfo-ja に上げて、texinfo.tex の最新版と組み合わせて使えるように修正、同時に栞生成コマンド@usedvipdfmxを追加してみた。
texi のヘッダ部を次のように修正する。
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename filename.info
@settitle TITLE
@documentlanguage ja
@documentencoding utf-8
@iftex
@usedvipdfmx
@end iftex
@c %**end of header
で、pTeX / dvipdfmx を使って、栞付きのPDFが生成できる。
iOS4のPDFリーダーは栞付きが上手く扱えるのだろうかぁ。。。
個人的な使い方の問題だろうが、emacs に凝っていた頃は仮想ディスクトップ毎にフレームを置いた使い方をしていた。
この使い方の要は、elisp からフレームを任意の位置、任意のワークスペースに移動できる事であった。既に MacOSX では仮想ディスクトップが Spaces としてサポートされている。 位置移動はできるようだが、ワークスペースの移動はどうもわからない。。。
マウスでチマチマ動かすのは、ちょっといただけない。。。
どうしたもんだろう？
MacOSX の仮想ディスクトップは Leopard で初めてお目見えしたが、 結構前から Window Server (Quartz Compositor/Core Graphics Services/Quartz Window Services...一体いくつの名称があるんだか。。。)には実装されていたそうである。 Tiger の時代から仮想ディスクトップがサードパーティのものがあったのはそういう訳らしい。
で、コイツのAPIのほとんどが今でも非公開になっている。。。断片的には、スクリーンキャプチャ用途レベルのものが公開されている。。。なんとも厄介。
先人が調べ尽くした結果として、最後のリンクの先の内容が、 特定のウィンドウを任意のワークスペースに移動する方法らしい。
模式コードは次のようになる。(CGSPrivate.hは一番目のリンク先にあるもの)
#import <CGSPrivate.h>
...
NSWindow *win = ...;
CGSConnection cid = _CGSDefaultConnection();
CGSWindow wid = [win windowNumber]; // ?
CGSMoveWorkspaceWindowList(cid, &wid, 1, workspace);
CGSを解析した作られた CGSPrivate.h でのCGSWindow と Appleから出ているドキュメントに出てくる CGWindowID とは window server 内で割り振られた番号で同じ実体と思われるが、 NSWindow の windowNumber のドキュメントには、それとは違うと書かれている。 混ぜても動いたから多分良いかと思われるが、、、ここいらはぼかしたい内容なのかなぁ。。。分からんなぁ林檎は。
まぁ、ここまで分かれば、出来たも同然〜。
で、適当にコマンドを作ってみた。
cgsutil.m(frame-parameters)には window-id があるから、Cocoa Emacs では多分コイツがフレームウィンドウの CGWindowID のはずで、コイツと飛ばしたい workspace 番号を適当に作ったコマンドに渡して、お仕舞いかなぁ。
わぁーい。らくちん。
はぅ。。。
Cocoa Emacs では window-id の値は、1から単調増になるように割り振った全く意味の無い番号でした。
仕様が無いので、次の追加機能を付けるパッチ(emacs-23-cgs-workspace.diff)
を作ってみた。
ns-window-idに、CGWindowIDと思われる値ns-workspace-idに、フレームのworkspace番号(set-frame-ns-workspace FRAME WORKSPACE)まぁ、最初の一つだけで十分だが、後二つは組込まなくてもいいかも。
上のパッチを適用した Emacs.app に適当な elispを書くと、１コマンドで複数のフレームを特定のワークスペース／特定の位置に開く事が出来るようになった。
うん〜〜。快適じゃ。
はぅ。。。
Cocoa Emacs で８フレームも開くと、キー入力が引っ掛かるようになり、Emacsプロセス自体のCPU利用率もイマイチ高い。イベント処理方法にまだ難があるのかなぁ。
４フレームくらいで抑えないとスムーズに使えないかなぁ。。。
複数のフレームを開いたときCPU利用率が高くなるのは、本パッチ内のframe-paramaters にワークスペース番号を追加するのが原因だった。。。frame-parameters の取得は不随に起きるらしくのでどうも軽くなくては行けない。
なので、workspace番号は取得関数から得るように変更し、workspace 絡みの部分を分けたパッチにしてみた。
ns-window-idに、CGWindowIDと思われる値(frame-ns-workspace FRAME)(set-frame-ns-workspace FRAME WORKSPACE)ふむ。
８フレームを開いても、キー入力が引っ掛かる症状は無くなった！！
すごく快適〜ん。
パッチを切ったり張ったり入れ替えたりする(1)のに、git rebase -i は極めて便利。git 優秀だなぁ
Emacs でプログラムを書く人々は、リアルタイムに文法チェックをするために flymake を使うらしい。
以前聞き覚えがあるが、何をする物か分からないのでスルーした奴だが、結構使えるものだったのかぁ。
なので flymake の設定をしてみた。
詳細は info マニュアルに書かれているが、 使い始めの設定は次の通りになる。この状態で、何もせずに Perl/PHP の文法チェックは行なえる(perl/php コマンドがあればの話だが)。
(require 'flymake)
;; GUIの警告は表示しない
(setq flymake-gui-warnings-enabled nil)
;; 全てのファイルで flymakeを有効化
(add-hook 'find-file-hook 'flymake-find-file-hook)
;; M-p/M-n で警告/エラー行の移動
(global-set-key "\M-p" 'flymake-goto-prev-error)
(global-set-key "\M-n" 'flymake-goto-next-error)
;; 警告エラー行の表示
(global-set-key "\C-cd" 'flymake-display-err-menu-for-current-line)
次に C/C++ で文法チェックを可能にするには、 Makefile を使い、次の様な check-syntax ルールを追加すればよい。
PHONY: check-syntax
check-syntax:
$(CC) -Wall -Wextra -pedantic -fsyntax-only $(CHK_SOURCES)
ここまですると、編集途中にリアルタイムに文法エラー/警告の部分に色が付き、分かり易い。
なるほど、、、これは素晴らしい。
以下の設定は、好きずきだと思う
警告エラー行の表示は、 プラットホーム毎のポップアップメニュー実装が使われるが、 色々検索すれば出てくるが、２通りのカスタマイズが良く知られている。
;; Minibuf に出力
(defun my-flymake-display-err-minibuf-for-current-line ()
"Displays the error/warning for the current line in the minibuffer"
(interactive)
(let* ((line-no (flymake-current-line-no))
(line-err-info-list (nth 0 (flymake-find-err-info flymake-err-info line-no)))
(count (length line-err-info-list)))
(while (> count 0)
(when line-err-info-list
(let* ((text (flymake-ler-text (nth (1- count) line-err-info-list)))
(line (flymake-ler-line (nth (1- count) line-err-info-list))))
(message "[%s] %s" line text)))
(setq count (1- count)))))
;; popup.el を使って tip として表示
(defun my-flymake-display-err-popup.el-for-current-line ()
"Display a menu with errors/warnings for current line if it has errors and/or warnings."
(interactive)
(let* ((line-no (flymake-current-line-no))
(line-err-info-list (nth 0 (flymake-find-err-info flymake-err-info line-no)))
(menu-data (flymake-make-err-menu-data line-no line-err-info-list)))
(if menu-data
(popup-tip (mapconcat '(lambda (e) (nth 0 e))
(nth 1 menu-data)
"\n")))
))
僕としては popup.el を使うのが結構好み
先に述べて Makefile の check-syntaxターゲットルールでは一種類の文法チェックプログラムしか使えない。。。 gcc でチェックできるものは全てチェック出来るから、気を回す必要は無いかもしれない。
GNU make を使えば、拡張子毎に文法チェックプログラムを選べるルールの書き方がある。
CHECKSYNTAX.c = $(CC) $(CFLAGS) $(CPPFLAGS) -Wall -Wextra -pedantic -fsyntax-only
CHECKSYNTAX.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) -Wall -Wextra -pedantic -fsyntax-only
check-syntax: $(addsuffix -check-syntax,$(CHK_SOURCES))
%.c-check-syntax:
$(CHECKSYNTAX.c) $*.c
%.cc-check-syntax:
$(CHECKSYNTAX.cc) $*.cc
まぁ、ここまで書く奴はいないかぁ。。。
Makefileが無ければ、直接 gcc で文法チェックをし、 Makefileがあればcheck-syntaxターゲットルールを使いたい場合は、 次の設定をすれば良い。
(defun flymake-simple-generic-init (cmd &optional opts)
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list cmd (append opts (list local-file)))))
;; Makefile が無くてもC/C++のチェック
(defun flymake-simple-make-or-generic-init (cmd &optional opts)
(if (file-exists-p "Makefile")
(flymake-simple-make-init)
(flymake-simple-generic-init cmd opts)))
(defun flymake-c-init ()
(flymake-simple-make-or-generic-init
"gcc" '("-Wall" "-Wextra" "-pedantic" "-fsyntax-only")))
(defun flymake-cc-init ()
(flymake-simple-make-or-generic-init
"g++" '("-Wall" "-Wextra" "-pedantic" "-fsyntax-only")))
(push '("\\.[cC]\\'" flymake-c-init) flymake-allowed-file-name-masks)
(push '("\\.\\(?:cc\|cpp\|CC\|CPP\\)\\'" flymake-cc-init) flymake-allowed-file-name-masks)
取り敢えず、次いでに ruby/bash の文法チェックを追加したのが、 今現在の設定になっている。
45flymake.elあとは Python/Java/HTML/CSS をチェックするのがあれば良いが、、、 これくらい素のflymakeに含まれていればいいのになぁ。。。
あとSemanticかぁ。。。
暫く使ってみたが、基本動作で２点だけイマイチな挙動を修正しないと、ストレスが溜まりまくる。
;; flymake を使えない場合をチェック
(defadvice flymake-can-syntax-check-file
(after my-flymake-can-syntax-check-file activate)
(cond
((not ad-return-value))
;; tramp 経由であれば、無効
((and (fboundp 'tramp-list-remote-buffers)
(memq (current-buffer) (tramp-list-remote-buffers)))
(setq ad-return-value nil))
;; 書き込み不可ならば、flymakeは無効
((not (file-writable-p buffer-file-name))
(setq ad-return-value nil))
;; flymake で使われるコマンドが無ければ無効
((let ((cmd (nth 0 (prog1
(funcall (flymake-get-init-function buffer-file-name))
(funcall (flymake-get-cleanup-function buffer-file-name))))))
(and cmd (not (executable-find cmd))))
(setq ad-return-value nil))
))
上の修正は、ちょっと上手く行かない場合があったので修正っと。
tramp経由の場合も、イマイチ上手く動かないので、除外に加えてみた。
Emacs のチートシートは、Emacs と一緒に配布されている。 refcard.tex から pdfを作って印刷すれば良い。 少し古いバージョンだが、日本語に翻訳されたものは「Emacs-20/21 Reference Card 」にある。
キー操作として、手に染み付いているものは半分くらいしか無い。。。 大抵 M-x コマンドで済まして場合が多いなぁ。
いかんなぁ。。。
再度覚え直す為に、先の日本語RefcardとEmacs23に入ってるrefcardと若干漏れている部分を補い、 一部語句を修正し、フォント関係を微調節してものを作ってみた。
refcardja.tex次いでに ptex/dvipdfmx を使って PDF を作って、Google Docs に上げてみた。
refcardja.pdfうん、久しぶりに素のTeXを弄ったが本当にややこしい奴だな。
Cocoa Emacs は安定していると思ったが、 どうもポップアップダイアログが出ると暫くして落ちてしまう。
flymake をチマチマ使えるように設定を弄ったら、時々でるポップアップに刺さる。。。
しようがないので、gdbで追っかけてみた。
調べてみたら、次のような簡単な処理でも、 ポップアップが出て暫くしてEmacsが落ちるようである。
| (x-popup-dialog | |
| t | |
| '("Sample Popup" | |
| ("OK" . t)) | |
| t) |
どうも inline patch 側での処理抜けらしい。。。 こんな感じに修正すると落ちなくなった
| diff --git a/src/nsterm.m b/src/nsterm.m | |
| index 635f737..4aade4a 100644 | |
| --- a/src/nsterm.m | |
| +++ b/src/nsterm.m | |
| @@ -3920,6 +3920,8 @@ ns_term_shutdown (int sig) | |
| if (mac_store_change_input_method_event()) | |
| { | |
| + if (!emacs_event) | |
| + return; | |
| emacs_event->kind = NS_NONKEY_EVENT; | |
| emacs_event->code = KEY_MAC_CHANGE_INPUT_METHOD; | |
| EV_TRAILER ((id)nil); |
うん、すこぶる快適
新し目の Emacs ではフォントエンジンの改良が進んでおり、 antialiasing が効いた奇麗な表示が出来る。また、沢山の種類のフォントを扱えるようになっている。
プログラムの編集等をしてると等幅フォントが必要である。 特に、日本人としてはASCII文字と日本語文字の幅が 1:2 である事が強く望ましい
まぁ、いくつか設定方法が流れてるので、コピペして使えば良いのだが。。。 みんなどうやって見やすい設定を探してるのだろうか？
疑問に思ったので、次のような機能のelispを書いてみた
my-sample-ascii.el適当にdefaultフェースを設定した後だが、CocoaEmacs/NTEmacs/Emacs(onUbuntu)での、 my-sample-face-sizeの結果は次のようになる
いくつか設定してみたが、全ての pt で、1:2 に揃うフォントの組み合わせはほんとに稀で、日常的に使うサイズに合わせて、サイズの微調節が必要のようである。 やはり、IPAフォントの恩恵は結構でかいなぁ。
今現在、いい感じに設定できたのは次の通り。
| ;; | |
| ;; フォントの設定 | |
| ;; | |
| ;; VMware 上の X Server であるか？ | |
| (defvar my-x-on-vmware nil) | |
| (if (string-match "^HOSTNAME-ON-VMWARE" (system-name)) | |
| (setq my-x-on-vmware t)) | |
| (when window-system | |
| (cond | |
| ;; Ver.21 以前 | |
| ((<= emacs-major-version 21) | |
| (set-default-font "fontset-standard")) | |
| ;; X / emacs22 | |
| ((and (eq window-system 'x) | |
| (= emacs-major-version 22)) | |
| (dolist (fspec '("-*-fixed-medium-r-normal--12-*-*-*-*-*-fontset-12" | |
| "-*-fixed-medium-r-normal--14-*-*-*-*-*-fontset-14" | |
| "-*-fixed-medium-r-normal--16-*-*-*-*-*-fontset-16" | |
| "-*-fixed-medium-r-normal--18-*-*-*-*-*-fontset-18")) | |
| (if (not (assoc fspec fontset-alias-alist)) | |
| (create-fontset-from-fontset-spec fspec))) | |
| (add-to-list 'default-frame-alist '(font . "fontset-14") t)) | |
| ;; CarbonEmacs | |
| ((eq window-system 'mac) | |
| (require 'carbon-font) | |
| (setq mac-allow-anti-aliasing t) | |
| (fixed-width-set-fontset "hirakaku_w3" 12)) | |
| ;; Emacs 23 以上 | |
| ((>= emacs-major-version 23) | |
| (let (my-font-height my-font my-font-ja my-font-size my-fontset) | |
| (cond | |
| ;; for X (debian/ubuntu/fedora) | |
| ((eq window-system 'x) | |
| ;;(setq my-font-height 90) | |
| (setq my-font-height 105) | |
| ;;(setq my-font-height 120) | |
| ;;(setq my-font "Monospace") | |
| (setq my-font "Inconsolata") | |
| ;;(setq my-font "Takaoゴシック") | |
| ;;(setq my-font-ja "VL ゴシック") | |
| ;;(setq my-font-ja "Takaoゴシック") | |
| (setq my-font-ja "IPAゴシック") | |
| (setq face-font-rescale-alist | |
| '(("-cdac$" . 1.3))) | |
| ;; VMware 上のX11では、800x600 のとき 96 dpi になるように調節されている。 | |
| ;; なので、別のサイズやフルスクリーンにすると、dpi の値が変化する。 | |
| ;; 結果、Emacs Xft では同じ pt に対するpixel値が大きくなってしまう。 | |
| ;; 対処不明。。。取り敢えず直接 pixel サイズで指定して対処？ | |
| (when my-x-on-vmware | |
| (setq my-font-size 14)) | |
| ) | |
| ;; Cocoa Emacs | |
| ((eq window-system 'ns) | |
| (setq mac-allow-anti-aliasing t) | |
| (setq my-font-height 120) | |
| ;;(setq my-font "Courier") | |
| ;;(setq my-font "Courier New") | |
| ;;(setq my-font "Osaka-Mono") | |
| ;;(setq my-font "Monaco") ;; XCode 3.1 で使っているフォント | |
| (setq my-font "Menlo") ;; XCode 3.2 で使ってるフォント | |
| ;;(setq my-font "Consolas") | |
| (setq my-font-ja "Hiragino Kaku Gothic Pro") | |
| ;;(setq my-font-ja "Hiragino Maru Gothic Pro") | |
| ;;(setq my-font-ja "IPAゴシック") | |
| ;; フォントサイズの微調節 (12ptで合うように) | |
| (setq face-font-rescale-alist | |
| '(("^-apple-hiragino.*" . 1.2) | |
| (".*osaka-bold.*" . 1.2) | |
| (".*osaka-medium.*" . 1.2) | |
| (".*courier-bold-.*-mac-roman" . 1.0) | |
| (".*monaco cy-bold-.*-mac-cyrillic" . 0.9) | |
| (".*monaco-bold-.*-mac-roman" . 0.9) | |
| ("-cdac$" . 1.3))) | |
| ) | |
| ;; NTEmacs | |
| ((eq window-system 'w32) | |
| (setq scalable-fonts-allowed t) | |
| (setq w32-enable-synthesized-fonts t) | |
| (setq my-font-height 100) | |
| ;;(setq my-font "ＭＳ ゴシック") | |
| ;;(setq my-font "VL ゴシック") | |
| ;;(setq my-font "IPAゴシック") | |
| ;;(setq my-font "Takaoゴシック") | |
| ;;(setq my-font "Inconsolata") | |
| (setq my-font "Consolas") | |
| ;;(setq my-font "DejaVu Sans Mono") | |
| ;;(setq my-font-ja "ＭＳ ゴシック") | |
| ;;(setq my-font-ja "VL ゴシック") | |
| (setq my-font-ja "IPAゴシック") | |
| ;;(setq my-font-ja "Takaoゴシック") | |
| ;;(setq my-font-ja "メイリオ") | |
| ;; ime-font の設定がわからん | |
| ;; フォントサイズの微調節 (10ptで合うように) | |
| (setq face-font-rescale-alist | |
| '((".*ＭＳ.*bold.*iso8859.*" . 0.9) | |
| (".*ＭＳ.*bold.*jisx02.*" . 0.95) | |
| (".*DejaVu Sans.*" . 0.9) | |
| (".*メイリオ.*" . 1.1) | |
| ("-cdac$" . 1.3))) | |
| ;;(dolist (e face-font-rescale-alist) | |
| ;; (setcar e (encode-coding-string (car e) 'emacs-mule))) | |
| ) | |
| ) | |
| ;; デフォルトフォント設定 | |
| (cond | |
| ;; pixel 単位で指定 | |
| ((and my-font-size my-font) | |
| (setq my-fontset | |
| (create-fontset-from-ascii-font (format "%s:size=%d" my-font my-font-size)))) | |
| ;; 高さを pt 単位で指定 | |
| (my-font | |
| (set-face-attribute 'default nil :family my-font :height my-font-height) | |
| ;;(set-frame-font (format "%s-%d" my-font (/ my-font-height 10))) | |
| ) | |
| ) | |
| (when my-fontset | |
| (add-to-list 'default-frame-alist `(font . ,my-fontset) t)) | |
| ;; 日本語文字に別のフォントを指定 | |
| (when my-font-ja | |
| (let ((fn (or my-fontset (frame-parameter nil 'font))) | |
| (rg "iso10646-1")) | |
| (set-fontset-font fn 'katakana-jisx0201 `(,my-font-ja . ,rg)) | |
| (set-fontset-font fn 'japanese-jisx0208 `(,my-font-ja . ,rg)) | |
| (set-fontset-font fn 'japanese-jisx0212 `(,my-font-ja . ,rg))) | |
| ) | |
| )) | |
| )) |
なんか Emacs をガンガン使い倒したくなってきた！！
VMware 上の X で画面サイズの変化で dpi が変化し pt 単位でフォント指定すると、実際のフォントの大きさがまちまちになるので、 明示的にpixel単位？で指定する方法に切り替えてみた。
Windowsの定番は Meadowであり、今でも十分安定している。 ただ、ベースにしてるのが Emacs 22系なので、ちょっと新しくないかなぁ。。。
今日では本家EmacsでもWindows版のバイナリを配布している。Windows特有のInstallerが使いたければ、EmacsW32から入手できる。
結構、安定して使える。かつ、アイコンが奇麗だ。。。
本家バイナリはネイティブのIMEのサポートが弱い気がする。。。と思ったら、有志によってIMEのinlineパッチも作成されいる。また、 VCSの新し目のタグに有用なパッチを当てたバイナリも「NTEmacs Build History 」から入手できる。
なので有り難く使わせてもらいます。
らくちんだ。
NTEmacs内部ではWin32のA系の呼び出し(ファイルI/Oやプロセス生成など)が使われるっぽいので、 現在の言語環境でのコードページに合わせなければ、奇妙な文字化けが発生する。 つまり、ファイル名とコマンド引数(processのdecoding)のcodingは shift_jis/cp932 じゃないとまずい。
と思うのだが、誰か大層語ってくれる人が見当たらないので、本当のところはさっぱり分かりません。。。
なので、「Cygwin 1.7でUTF-8サポートされたぜ！いぇーい！今時は UTF-8 ですが何か？」とは、口が裂けても言えない。。。僕は恨めしくshift_jis/cp932で使いますよ。。。へたれですから。。。
上のサイトや他多数をちょっと参考にして、今現在の次のようにしている。今でもチマチマ書き換えているのでそのうちgithubで晒しとくかなぁ。。。
ホームディレクトリ指定を環境変数HOMEで与える必要があり、Cygwinでのホームディレクトリと同じにすると混乱せずに済む。
| ;; 日本語入力を賢くしたい | |
| ;; GNU/Linux で egg-anthy を使う設定 | |
| (if (eq system-type 'gnu/linux) | |
| (set-language-info "Japanese" 'input-method "japanese-anthy")) | |
| ;; Cocoa inline_path 対応 | |
| (if (featurep 'ns) | |
| (set-language-info "Japanese" 'input-method "MacOSX")) | |
| ;; NTEmacs IME 対応 | |
| (when (featurep 'w32-ime) | |
| ;; W32-IME の初期化 | |
| (setq-default w32-ime-mode-line-state-indicator "[--]") | |
| (setq w32-ime-mode-line-state-indicator-list '("[--]" "[あ]" "[--]")) | |
| (dolist (args '((y-or-n-p nil nil) (yes-or-no-p nil nil) | |
| (universal-argument t nil) (read-string nil nil) | |
| (read-from-minibuffer nil nil) (read-key-sequence nil nil) | |
| (map-y-or-n-p nil nil) (read-passwd t t))) | |
| (apply 'wrap-function-to-control-ime args)) | |
| (setq w32-ime-on-cursor-color "blue") | |
| (setq w32-ime-off-cursor-color "black") | |
| (add-hook 'w32-ime-on-hook | |
| '(lambda () (set-cursor-color w32-ime-on-cursor-color))) | |
| (add-hook 'w32-ime-off-hook | |
| '(lambda () (set-cursor-color w32-ime-off-cursor-color))) | |
| (add-hook 'minibuffer-setup-hook | |
| '(lambda () | |
| (if (ime-get-mode) | |
| (set-cursor-color w32-ime-on-cursor-color) | |
| (set-cursor-color w32-ime-off-cursor-color)))) | |
| (w32-ime-initialize) | |
| (set-language-info "Japanese" 'input-method "W32-IME")) |
| ;; | |
| ;; 日本語環境で UTF-8 をメインにする設定 | |
| ;; | |
| ;; 日本語環境 | |
| (set-language-environment 'Japanese) | |
| (cond | |
| ;; Windows系で対応 | |
| ((memq system-type '(cygwin windows-nt)) | |
| (prefer-coding-system 'shift_jis-dos) | |
| ;;(prefer-coding-system 'cp932-dos) | |
| ;;(prefer-coding-system 'utf-8-unix) | |
| ;; NTEmacs内部ではWin32のA系の呼び出しが使われるっぽいので、 | |
| ;; 現在の言語環境でのコードページが固定で使われるのかぁ？ | |
| ;; locale-coding-system 以外では文字化けは避けられないと思う。 | |
| (when locale-coding-system | |
| ;; ファイル名はロケール依存 | |
| (setq default-file-name-coding-system locale-coding-system) | |
| ;; IMEパッチで必要らしい。 | |
| (set-keyboard-coding-system locale-coding-system)) | |
| ) | |
| ;; UTF8サポートありならば、優先してUTF-8を使う | |
| ((memq 'utf-8 coding-system-list) | |
| (prefer-coding-system 'utf-8-unix) | |
| (setenv "LANG" "ja_JP.UTF-8") | |
| ) | |
| ) | |
| ;; 常に新規ファイルは utf-8-unix を使いたい | |
| (if (memq 'utf-8 coding-system-list) | |
| (setq-default buffer-file-coding-system 'utf-8-unix)) | |
| ;; |
cygwinのsubversionやgitを使う場合、ログメッセージが文字化けするので、ちょっと設定が必要。。。
| ;; | |
| ;; VCS (PCL-CVS/PSVN/etc) の設定 | |
| ;; | |
| ;; VCは自動的にリンクを辿って、かわりに本当のファイルを訪問 | |
| (setq vc-follow-symlinks t) | |
| ;; VC-DIR を PCL-CVS -status に近づける | |
| (when (>= emacs-major-version 23) | |
| (add-hook 'vc-dir-mode-hook | |
| '(lambda () | |
| (define-key vc-dir-mode-map "a" 'vc-register) | |
| (define-key vc-dir-mode-map "c" 'vc-next-action) | |
| ))) | |
| ;; for CVS | |
| (setq cvs-diff-flags '("-u")) | |
| ;; for Subversion | |
| (when (locate-library "psvn") | |
| (autoload 'svn-status "psvn" nil t)) | |
| (setq svn-status-hide-unmodified t) | |
| ;; for Git / git-coreのcontribにある | |
| (when (locate-library "git") | |
| (autoload 'git-status "git" nil t) | |
| (autoload 'git-blame-mode "git-blame" nil t)) | |
| ;; for MaGit | |
| (when (locate-library "magit") | |
| (autoload 'magit-status "magit" nil t)) | |
| ;; for Subversion | |
| ;; サーバ内部ではログメッセージの文字コードはUTF-8になってる。 | |
| ;; なので、Windowsでクライアント等のASCII/UTF-8の文字コード以外の場合、 | |
| ;; Subversionに文字コードを教える必要(コマンドスイッチ)がある。 | |
| ;; なぜかコマンド引数のエンコードは、coding-system-for-write | |
| ;; または default-process-coding-system の decoding で変換される。 | |
| (when (eq system-type 'windows-nt) | |
| (cond | |
| ;; SJISロケール | |
| ((not my-prefer-utf8-for-cygwin) | |
| ;; vc-svn.el用 | |
| (setq vc-svn-checkin-switches '("--encoding" "Shift_JIS")) | |
| ;; psvn.el 用 | |
| (setq svn-status-default-commit-arguments '("--encoding" "SJIS")) | |
| (setq svn-status-svn-process-coding-system 'shift_jis) | |
| (setq svn-status-svn-file-coding-system 'shift_jis) | |
| ) | |
| ;; UTF8 | |
| (t | |
| ;; vc-svn.el 用 | |
| (defadvice process-file | |
| (around my-process-file) | |
| (let ((coding-system-for-write 'shift_jis)) ;; ここが一番分からん | |
| ad-do-it)) | |
| (defadvice vc-svn-checkin | |
| (around my-vc-svn-checkin activate) | |
| (ad-activate-regexp "my-process-file") | |
| ad-do-it | |
| (ad-deactivate-regexp "my-process-file")) | |
| ;; 今現在の環境(Cygwn1.7.4/LANG=ja_JP.UTF-8)では、 | |
| ;; なぜかこれだけが上手くいくなぜ？ | |
| ;; だれが SJIS->UTF8への変換を行っているのか？ | |
| ;; | |
| ;; psvn.el 用 | |
| (setq svn-status-svn-process-coding-system 'utf-8) | |
| (setq svn-status-svn-file-coding-system 'utf-8) | |
| ) | |
| ) | |
| ;; vc-git.el 用 (vc-git-checkin自体が小さいので置き換えた、、、) | |
| (defadvice vc-git-checkin | |
| (around my-vc-git-checkin activate) | |
| (let ((files (ad-get-arg 0)) | |
| (comment (ad-get-arg 2)) | |
| (fname (make-temp-file "vc-git-"))) | |
| (let ((buffer-file-coding-system 'utf-8-unix)) | |
| (with-temp-file fname (insert comment))) | |
| (vc-git-command nil 0 files "commit" "-F" fname "--only" "--") | |
| (delete-file fname) | |
| )) | |
| ) | |
| ;; もう少し整理できそうなんだが、、、 |
、、、VC-xx.elの実装では、ログメッセージはコマンド引数で受け渡されるようになっている。 一時ファイル経由で無いとWindowsではバケバケになるのだが。。。そのうち直るのかなぁ
あと大事な Font 設定ですね。。。次回で。
最近、また Emacs にはまっている。
ここ数年は vi やら eclipse やら JeditX やら xcode やらを広く浅く使っていて、 いまいちスッキリしない感じで、まぁ年なのか諦めていた。 Snow Leopardにアップグレードを期に、 ちょっと設定等を手入れしてMacOSX/Windowsで使い出したらすこぶる手になじむ。。。
はて、なんでEmacsを使うのを忘れていたのかんなぁ。。。
そう、当時 Emacs 20か 21 (mule-2.3だったかもしれん、、、)だったかなぁ。 UTF8/Unicodeを使う為にはMule-UCSとかいうパッケージが必要で、 そいつを組み合わせると普通に使えるのだが、起動も動作ももっさりしていまいちだった。。。
今日のEmacsはサクッとUnicode系の一群のcoding-systemが使えて、それなりに軽快に動作する。
良い時代になったなぁ。。。
MacOSX 上の定番は CarbonEmacsで、 かなりしっかりメンテナンスされており、実に安定している。ただ、ベースにしてるのがEmacs22だったり、Carbonベースだったり、32bitバージョンだったり、本当に細かく気になる人が気になる程度。
ふと気づくと 本家 Emacs では既に 64bit Cocoa版が構築でき、かつ日常作業で問題ならないくらいは安定してるらしい(1,2)。また、フォントの等幅調節設定や日本語入力等のinline patchなどが入手が可能で、 ほぼ CarbonEmacs を置き換えて使えるレベルになっている(と思う)。
なので、Cocoa Emacs 64bit を構築してみる。
うん、一番の難関は Bazaar という分散VCSを使う事かもしれない。。。準オフィシャルなGitレポジトリがあるので、Gitに慣れてる場合はこっちを使うのが吉。僕は、へたれなので git の方を使った。
取り敢えず、 ローカルネットに emacs.git のミラーレポジトリを立てて、そのマシン上でフォークして個人用の共用レポジトリを作る。 その個人用レポジトリから作業マシンに複製を展開する。 また、継続的にupstreamを追っかけるため、ミラーレポジトリもリモートとして登録する。
% ssh server # ローカルネットの server にログイン % cd /git % git clone --mirror git://repo.or.cz/emacs.git % git clone --bare --reference emacs.git emacs.git emacs-my.git ... % ssh client # 作業マシンにログイン % cd ~/work % git clone git+ssh://server/git/emacs-my.git emacs % cd emacs % git remote add upstream git+ssh://server/git/emacs.git % git fetch upstream
個人用レポジトリを挟んだのは、バックアップを意図してなんだが、、、git使いはそんな事はしないのかなぁ。。。分からんなぁ。。。
続いてMacEmacs JP から inline_patch を取って当てる。
% ssh client # 作業マシンにログイン % cd ~/work/emacs % git checkout -b topic EMACS_PRETEST_23_1_96 # 次いでに topic ブランチも作っとく % pathc -p0 < emacs-inline.patch
あとは、configure/make で問題が無ければ nextstep/Emacs.app の場所で 64bit Cocoa Emacs が構築される。
% ssh client # 作業マシンにログイン % cd ~/work/emacs % eval "$(PATH= /usr/libexec/path_helper -s)" # PATHをクリーンにする % ./configure --with-ns % make install % open nextstep/Emacs.app # Emacsの実行確認
なんともあっけなく構築できた。 ただ、僕は masterブランチの方にパッチを丁寧に当てた物(24.0.50とか)を使っている。すこぶる快適。
まぁ、忘れそうなので次いでに書いとく。
ミラーレポジトリは次のコマンドで更新する。
% ssh server # server にログイン % cd /git/emacs.git % git fetch
そして、作業レポジトリで upstream を追っかけるには
% ssh client # 作業マシンにログイン % cd ~/work/emacs % git fetch upstream % git rebase upstream/master topic # upstream 先端に rebase % git push origin :topic # topicブランチを削除し、 % git push origin topic:topic # 新しくtopicブランチをプッシュ
いまいち Git の使い方に慣れない/分からないので、間違ってるかもしれん。。。
そういえば、github にも Emacsのミラーレポジトリが上がってるので、そのうち生えてくるかもしれん。。。
それにしても覚える事が次から次と現れて、知恵熱が出っぱなしだなぁ。。。
初期設定のemacs.elはまた次回。
フォント以外の設定は、殆ど定型文っぽいので以下の用に設定した。
| ;; CocoaEmacs 対応 | |
| (when (eq window-system 'ns) | |
| (require 'ns-win) | |
| ;; JISキーボード円記号/バックスラッシュ対応 | |
| (mac-translate-from-yen-to-backslash) | |
| ;; Option/Command キー を Super/Meta に割当 | |
| (setq ns-command-modifier 'meta) | |
| (setq ns-alternate-modifier 'super) | |
| ;; システムへ修飾キーを渡さない設定 | |
| (setq mac-pass-control-to-system nil) | |
| (setq mac-pass-command-to-system nil) | |
| (setq mac-pass-option-to-system nil) | |
| (define-key global-map [ns-drag-file] 'ns-find-file) | |
| ) | |
| ;; Cocoa inline_path 対応 | |
| (if (featurep 'ns) | |
| (set-language-info "Japanese" 'input-method "MacOSX")) | |
| ;; 日本語環境 | |
| (set-language-environment 'Japanese) | |
| (cond | |
| ;; UTF8サポートありならば、優先してUTF-8を使う | |
| ((memq 'utf-8 coding-system-list) | |
| (prefer-coding-system 'utf-8-unix) | |
| (setenv "LANG" "ja_JP.UTF-8") | |
| ) | |
| ) | |
| ;; 常に新規ファイルは utf-8-unix を使いたい | |
| (if (memq 'utf-8 coding-system-list) | |
| (setq-default buffer-file-coding-system 'utf-8-unix)) | |
| ;; |
フォントの設定は「Emacs23 の フォント設定」を参照
どうもポップアップダイアログが出たとき落ちる問題にはパッチが必要。
libvirt+QEMU/KVM を使った仮想化の運用を続けていると、どうしても気になる事がある。
libvirtd の設定には、自動起動するGuestVMは登録できるのだが、 終了時には有無を言わさず GuestVM を強制終了してしまう事である。
自前で libvirt (0.7.2)を入れているので今のバージョンでは何らかのサポートが入ってかもしれない。 ただ「libvirt: Releases」を見る限り入って無さそうである。
それにQEMU/KVMドライバだけの挙動かもしれない。他とドライバ(Xen等々)だと状況は違うかもしれない。
まぁ。。。そのうち何らかの対応が入るんだろうなぁ。。。
そうは言っても、ホストマシンを終了するときイチイチ確認するのは難儀である(とくにACPIサポートが悪く電源断しないGuestOSタイプとかねぇ)。
さて、QEMUにはVMの状態を保存復帰(save/restore)がサポートされている。コイツとストレージ共有を組み合わせると、ライブマイグレーションが一丁上がりになるので、つい何年か前に小躍りしてる人がたくさんいた気がする。
まぁ普通にサスペンド/レジュームの仕組みなので、コイツをなんとか上手く使うスクリプトを組んでみた。
指定する項目は３つで、それぞれスクリプト冒頭に書かれている。
...
SAVEVMDIR="/var/lib/libvirt/save" # 保存するVMの置き場所
LISTVM_SHUTDOWN="linux_sid linux_fedora" # 終了時 shutdown するもの
LISTVM_SAVE="freebsd_cur netbsd_cur solaris" # 終了時 save するもの
...
やってる事は単純で virsh コマンドを叩いてるだけである。 ただ、LISTVM_なんたらで指定し無かったり、15分以内に正常に電源断しない奴は、 最後に念のためsaveしてある。
コイツを、/etc/init.d/libvirt-binのスクリプトの必要な部分に入れ込むだけ。
うん〜、これでマシンを立ち上げると前回マシンを落とした時の状態のままのSolaris10/FreeBSDが立ち上がるようになった。。。しかし、時刻が合わん。なんか、GuestOSが共通に取れるイベントの仕組みがあるのかなぁ。。。SNMPとかで叩くんかなぁ。。。SSHとかで叩くんかいなぁ。。。順当に cron でntp引っ張ってくるが原始的でいいのかぁ。。。でも、時刻合わせの精度は低いし、常時CPUをちょっとだけ使うのはなぁ。。。ぶつぶつ
あんまり、すっきりしないが個人で使う分には用は足りそうである。