Emacs

blogsyncはpushした時のファイル名と違うファイル名が返ってくることがある1 blogsync-mode.elはこの場合を対処してないので、ファイルが増殖してしまう。blogsync-pushを実行した結果、返ってきたファイル名がpushしたバッファのものと違っていたら、バッファとファイルを削除して開きなおすという対応を入れてみたが、本当にこんな手しかないのだろうか……。 Draft: trueの場合やDate:がない場合かな ↩︎

blogsync-mode、記事の一覧を見て検索できるといいなと思ったけど、よく考えなくてもそんなのはhelm-agで容易に実現できるわけで。 (defun helm-blogsync () (interactive) (helm-ag (expand-file-name blogsync-hatenablog-host blogsync-rootdir)))) こんな感じのを.emacsに書いてキーにバインドすればよい。こんな事でhelmとhelm-agに依存するのも何なので本体には入れないでおこう。

blogsyncを使うとしても、記事はEmacsで書くわけで、何かfrontendが欲しいところだ。 どこかにblog用リボジトリを作ってhookでblogsyncを実行するのが正道だとは思いつつも、そこまで重要なコンテンツでもないし、自分らしく手元のEmacsで実行できるEmacs-lispのフロントエンドを作りかけてみた。blogsync-mode.el。 blogsync-pull : blogsync pullを実行する。出力先はblogsync-rootdir blogsync-push : カレントバッファのファイルをblogsync pushする blogsync-post : 新規のdraftを作成して、それを開く 現状はいろいろ適当すぎるので、もうちょっとなんとかしよう……。

手元バージョン管理を全部gitにしてからはや数ヶ月。最初はいろいろとまどったが、案外慣れてしまうものだ。 まず仕事方面。いろいろな都合から会社の中央レポジトリはSubversionなので、gitはgit-svnと共に使っている。最近の仕事はどっぷりLinuxで、gitでさくさくfeature branchを切りかえて作業ができるのは実によい。 仕事で相手をしているSubversionのレポジトリはtrunk/branches/tagsの標準的なスタイルなので、git svn clone時には-sをつけて、リモートのsvnブランチもローカルのgitのブランチとしてcloneしている。 git svn clone -s (subversionのURL) hoge このcloneはかなり遅いが、まあ、一度作ってしまえば、あとは適当に[cci_bash]git svn rebase[/cci_bash]してゆけば更新されるのでさほど困りはしないはず。 さて、そうやってcloneしたレポジトリの上で、何か機能を作りこむ必要があるときは、 git checkout -b hogehoge と作業ブランチhogehogeを作って作業し、確認が終わったら git checkout master して、git svn rebaseして、おもむろに、 git merge --squash hogehoge あるいは git merge ーno-ff hogehoge としてhogehogeブランチの作業内容をマージしてから最後に git svn dcommit して、またgit svn rebaseしつづける定常状態に戻る。dcommit直前まではsvnのことを忘れていられるのがよい。 自宅環境(Windows&FreeBSD)にはsvnはからまないので普通にgitを使っている。自宅サーバにbareレポジトリを作って、そこにssh経由でpush/pullすることで出先からの取得・更新も可能にしているが、運用練習も兼ねてbitbucketに移動したほうが幸せかもしれないと最近は考えている。 LinuxでもFreeBSDでもWindowsでも、シェルにbashかzshを使っている限りは補完が充実しているので、シェルで使うのが一番だ。ただ、作業はEmacs上で行うので、履歴や差分の確認はEmacs上のEggに頼ることも多い。慣れ親しんだEmacsのvc.elライクなキーバインドなので悩まずに済むのがよい。 さて、コマンドラインでgitを使っていてもコミットメッセージはEmacsを使いたいので、core.editorにはemacsclientを指定している。FreeBSDとLinux上のEmacsは(prefer-coding-system 'utf-8-unix)にしているので何もせずに新規バッファを作ればutf-8になるが、Windows環境は諸処の事情でutf-8を最優先にしていないので何もしないとコミットメッセージが化ける。んで、下記のhookを入れている。 (add-hook 'server-visit-hook (function (lambda () (if (string-match "COMMIT_EDITMSG" buffer-file-name) (set-buffer-file-coding-system 'utf-8))))) 職場でもっとgitとgit svnの啓蒙活動をしたいところだなぁ。

大学4年の頃の話である。当時の研究室の計算機環境はSunのSS10, SS20やSONY NEWSが転がっていて、OSはSunOS 4.1.4やNEWS-OS 4.2.1Rあたりで、みんなは高岳のX端末からそれらを使うという環境だった。 エディタはNemacsからMuleに移りかわるあたりだったと記憶している。 当時日本語入力エンジンとしてはWnnとsj3とCannaが選べた。が、まあ、どれもバカだった。それでグチってたら先輩が「SKKいいよ！」と布教しにきたのでつい乗ったのが始まり。SKK 6.32あたりだったと記憶している。 それ以来、日本語入力方式としてはずっとSKK系ばかり使っている。 当時自宅のメインPCはX68000・X68030だったが、FEPはrjjを利用した。 Windowsに移行したらSKK95を使おうと思ったが、イマイチ安定しなかったので、BOW 1.0/1.5でMule 1.1PL4を動かして本物のSKKも使っていた。 SKKIMEが安定するようになってからはずっとSKKIMEを使っている。 BOWを止めて、Mule for Win32→Meadowと移っても やっぱ日本語入力はddssk。 FreeBSD 9.0R上のEmacsももちろんddssk。 Mac miniを買ったときも当然のようにAquaSKKを使っていた。 で、iTunesとSKKIMEの食い合わせの悪さを感じていたので、ひさびさにWindowsのSKK環境を変えてみた。 それはSKK日本語FEP。lと^Jで日本語英語を切りかえていれば、IMEを無効にせずとも普通に使えというのが実によい。カスタマイズはむしろテキストファイルベースでイケるのはむしろ俺好み。辞書サーバが使えないけど、まあ、もともとそんなに活用していないし問題なし。今のところほぼ問題も文句もなし。 キーボードで文章を打ち込む時代が続く限りは、SKKを使っていきたいものだ。