ajc-auto-java-complete.el
基本的にはEmacsを使っているけど、ことJavaを扱っているときはEclipse。
でも、Eclipseなんかちょっともっさりだしー、ここまで機能いらないしー
とか考えて過ごして幾星霜。
基本的にはタグジャンプと補完が出来るだけで良いんだけどなぁ。と考えてました。
んで、まぁ、タグジャンプは、globalさん使えば良いのですよ。しかし、問題は補完。
これはなかなか決め手が無かった。。。
JDEEはなんか結構残念なことになるし、malabar-modeはまだ補完対応してない（よね？）みたいだし。
emacs-eclimは、eclipse立ち上げないと行けないから本末転倒だし・・・；；
と、ここで出会ったのが、EmacsWiki: java-complete.elさん。
「お！」と思って、早速導入・・・するもなんか意に沿う形で補完できず。
別バッファに候補出して、マウスで選択してエンターとかちょっとアレゲだったわけですよ。*1
しかし、調べてみると結構引っかかるので、もちょいがんばろうと調べた結果、
GitHub - emacs-java/auto-java-complete: Auto Java Complete ,a plugin for editing Java on emacsに出会えました！
アプローチ、、、というか仕組みは、前述のjava-complete.elの後継（？）っぽいのですが、
現在も更新されてて、なかなか良い感じ。
ただ一点、バッファを自動で消す系（lcomp.el とか tempbuf.el）と相性がわるいっぽいので、
機能をオフにして利用してます。
これでソース編集レベルならEclipse離れ出来そうです。。。
*1:ちゃんと調べればもっとましな補完方法があったかもですが。
moccur-grep-findの実行結果のバッファを
popwin.elの管理対象にさせようとおもって、
(push '("*Moccur*" :height 20 :width 80 :position right) popwin:special-display-config)
なんて設定を描いてみたところ、実行結果をたどる度にウィンドウ分割が実行しまくってなかなかカオスな状況に・・・
（popwin.el管理化に置く以前に）moccur-grep-findは、
(setq split-width-threshold nil)
なんてしてあげないと同じような現象に陥るので、popwin.elさんが悪さしているというわけでは無い（と思う）のが悩ましい・・・
popwin.elの設定
で、まぁ、popwin:special-display-configのwidthを、フレームの半分のサイズにしたいなぁ・・・とか思ったわけですよ。
そんなわけで、安易に
(defun half-frame-size () "(/ frame-width 2)" (/ (frame-width nil) 2))
なんて、半分のサイズを取得する関数を定義して、
(push '("*Occur*" :width (funcall 'half-frame-size) :position right) popwin:special-display-config)
なんて描いてあげるとうまくいくのかなぁ・・・とかおもったけどそうは問屋がおろさなかったわけですよ。
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (funcall (quote half-frame-size))) popwin:create-popup-window((funcall (quote half-frame-size)) right t) popwin:popup-buffer(#<buffer *Occur*> :width (funcall (quote half-frame-size)) :height 20 :position right :noselect nil :stick nil) popwin:display-buffer-1(#<buffer *Occur*> :if-config-not-found #[(buffer) "\302^H \"\207" [buffer not-this-window popwin:original-display-buffer] 3]) popwin:display-buffer(#<buffer *Occur*> nil) display-buffer(#<buffer *Occur*>) occur-1("10" nil (#<buffer *scratch*>)) ad-Orig-occur("10" nil) occur("10" nil) call-interactively(occur) anything-execute-extended-command() call-interactively(anything-execute-extended-command nil nil)
なんてでる・・・
emacs-lispレベルがアリアハンから出れてない認識はあったけど、この程度の問題も解決出来ない自分に凹みつつ、日記に書いてみる。
malabar-modeを利用開始したのはいいけど、なんか不可解なエラーがでた。
(set debug-on-error t)
で
M-x malabar-groovy-start
すると、以下のエラーがでる
Debugger entered--Lisp error: (wrong-type-argument overlayp nil)
overlay-put(nil face ((foreground-color . "green")))
ansi-color-set-extent-face(nil ((foreground-color . "green")))
ansi-color-apply-on-region(#<marker at 52 in *Malabar Groovy*> #<marker at 215 in *Malabar Groovy*>)
ansi-color-process-output("e[32mGroovy Shelle[m (1.7.4, JVM: 1.6.0_22)\nType 'e[1mhelpe[m' or 'e[1m\\he[m' for help.\n-------------------------------------------------------------------------------\n")
run-hook-with-args(ansi-color-process-output "e[32mGroovy Shelle[m (1.7.4, JVM: 1.6.0_22)\nType 'e[1mhelpe[m' or 'e[1m\\he[m' for help.\n-------------------------------------------------------------------------------\n")
comint-output-filter(#<process Malabar Groovy> "e[32mGroovy Shelle[m (1.7.4, JVM: 1.6.0_22)\nType 'e[1mhelpe[m' or 'e[1m\\he[m' for help.\n-------------------------------------------------------------------------------\n")
accept-process-output(#<process Malabar Groovy> 10)
malabar-groovy--match-buffer("*Malabar Groovy*" "^groovy:[^>]*> " 0 (("*Malabar Groovy*" . 1) ("*Malabar Compile Server*" . 1) ("*Malabar Eval Server*" . 1)) "Error starting groovy: time-out waiting for prompt")
malabar-groovy--wait-for-prompt("*Malabar Groovy*" (("*Malabar Groovy*" . 1) ("*Malabar Compile Server*" . 1) ("*Malabar Eval Server*" . 1)))
malabar-groovy-start()
call-interactively(malabar-groovy-start)
anything-execute-extended-command()
call-interactively(anything-execute-extended-command nil nil)とりあえず、Groovyシェルさんを立ち上げる時の配色設定がまずいのだろうといろいろ調べていると、
malabar-groovy.elで
(require 'ansi-color)
をしてるぽい。
というわけで、malabar-groovy-mode の
;(ansi-color-for-comint-mode-on)
となっているところを
(ansi-color-for-comint-mode-off)
に修正したらとりあえずエラーは出なくなった。
けど、これが正しいのかは謎
AIRTEGO11 Alligator Black かった。
※追記※
下記溝の言及に関しまして、私のミスで天地を逆にしたまま検証をしておりました。
ちゃんと天地をあわせて収納すると意図通りのリッドクローズドナイズされたジャストなケースになります！
大変失礼いたしました。
MacBook Air専用ケースAIRTEGO（エアテゴ）
AIRTEGO11 Alligator Black（ZRG-MACS0111AB）を購入しました。
MacBookAir用に、よさげなバッグがないかなぁ？
と、ふらふら情報の海をさまよっているところに、Twitter上で、上記ケースの情報をみて、その収容のスマートさに惚れてしまったのですよ。
まぁ、そんなこんなでいろいろ調べてみると、
・どうやら収納中でも電源に接続らしい。
・立てかけて置くとかスマートに収納できるらしい。
とかかんとか。
ここでMacBookをモジュールとして使っている人には、ティン！と、
「すわ、リッドクローズドモード専用じゃね？」
とか発想されるものというものだと思いませんか？（だれにともなく
しかーし、そこはそれ、さすがにそんなにニッチな層は狙っていないのか、切れ込みは電源接続部のみとのこと・・・
おしい！実に惜しいよお父さん！（誰？
そんな私がつい、Twitterでこうつぶやくのも仕方ないとおもいませんか？
そしたらなんと公式アカウントさん、ちゃんと補足してくれてレスポンスを返してくれました。
公式のアカウントがあることは把握していた（そしてFollowしていた）ので、
ある種、確信的にレスポンスを期待したところもあったのですが、
しかしてしっかり補足するあたり、ここ最近の情報戦略がしっかりしている感じで好感が持てます。（偉そう
そんなわけで、購入に至るみりのり
「特注！」とか「最後の一個！」は私には最高の殺し文句です（ぉ
まぁ、そんなこんなで長い前振りではありましたが、買ったわけですよ。
そして今日来たわけですよ。
それがこれ！
切れ込み
こっちがデフォの方。
収納するとこんな感じ
USBポート埋まるとおもったけど、空いてるね（あれもしかして、こっちも特別に空いたのかしら？？？）（※文頭訂正参照）
んで、もう一個の特注溝
収納するとこんな感じ
なんか、びみょーにUSBポート出きってないけど気にしない！
気にしちゃだめだ！お兄さんとの約束！（※文頭訂正参照）
全体てきにはこんな感じになります。
実際リッドクローズドで運用するのは会社でなので、未体験ゾーンですが、
収納ケースとしてすでに良い感じです。
鞄も選べるしねぇ。
心配された強度も、もともとの製品を知らないけれど、
収納している限りはよれたりしないのではないですかね？
さすがに未収納時は溝があろうが無かろうがつぶしたらダメだしねｗ
そんなわけで、明日からの出勤がわくわくな今日このごろです！
（家族全員インフルで倒れてて、出社しなさそうだけどね！）
何はともあれ、個別対応をしてくださった、[twitter:@ZRG_ratio]さんありがとうございました！
anything-books.elさんがとっても便利
昨今の情勢で、PDFに触れる機会がぐんと増えた昨今、
「EmacsさんからもPDF見やすくなると良いなぁdoc-viewだってあるし。。。」
とおもっていたら、『anythingでPDFファイルをプレビューしながら高速に選びたい - 技術日記＠kiwanami』なんてものが有ったので、
早速導入させて頂いた。
しかし、「PDFファイルを１ディレクトリにまとめるのがなぁ・・・」とかおもっていたら、シンボリックリンクでも大丈夫だったので、
#/usr/local/bin/zsh find ~ -type f -name "*pdf" -print0 | xargs -0 -i ln -fs {} ~/Documents/pdfs/
なんてものを作成して、幸せ環境。
