Life is very short

2014-08-30

coffee-modeの REPL関連コマンドの改善

| 14:24

REPLに複数行送られない問題を修正しました.

あんまりやることはないかもしれませんが, 対話的に作業しやすく

なったかと思います.


リポジトリ

https://github.com/defunkt/coffee-mode


イメージ

f:id:syohex:20140830142031g:image


おわりに

問題がありましたら, github issuesまでお願いします.

私は職業柄一切 CoffeeScriptを書かないので, 要望とか

問題とかありましたらぜひお願いします.

MELPAに登録前に確認すべきこと

| 13:03

melpaのパッケージのフォーマット(仮) - by shigemk2


以前にも軽く書いたのですが, もう少し丁寧に.


概要

  • パッケージのフォーマット
  • コードの書き方
  • その他

パッケージフォーマットに準拠する


どんなパッケージでも登録できるわけではなく, パッケージの規約に

従わないといけません. 上記の URLは必ず見てください. 英語が大量に

書かれているので読解は困難かもしれないですが, サンプルコードの

ように書くことは忘れないでください. 以下に必須事項を示します.


パッケージの規約についてはいちいち調べるのが面倒なので,

snippetを登録しておくことをおすすめします(私のはこんな感じです)


1行目はファイル名と概要を書く(区切りは --- ハイフン 3つ)

1行目はファイル名と概要です. 必ず書いてください. list-packagesや

package-list-packagesコマンドで表示される部分なのでなるべくわかり

やすく書いてください. あと区切り文字はハイフン 3つで, 2つとか 1つ

ではないので注意してください.


バッファローカル変数 lexical-bidingの設定

バッファローカル変数は下記のように任意の位置書けるのですが,

lexical-bindingの設定だけは特別で必ず一行目に書く必要があります.

;; Local Variables:
;; coding: utf-8
;; indent-tabs-mode: nil
;; End:

具体的には以下のような感じです.

;;; helm-gtags.el --- GNU GLOBAL helm interface  -*- lexical-binding: t; -*-

その他バッファローカル変数の設定はファイルの最後にまとめて書くと

よいでしょう.


必要なメタ情報を書く

とりあえず Author, Version, (依存があれば)Package-Requiresを書いてください.

その他 URL, Keywordsなども必要に応じてつければいいでしょう.


コメントの前は ;;; Commentary:

パッケージ関する具体的なコメントは Commentaryセクションに書きましょう

最近は githubの README.md等あるので, あまり長々とここに書いている

人はいませんが, パッケージインストール時に見ることができるので,

どういうパッケージか, どういうことができるかぐらいあった方がいい

かと思います.


私は書かないことも多いので絶対書けとは言えませんが,

何か書きたいことがあればここに書いてください.


コード部の前は ;;; Code:

コードは Codeセクションに書きます.


ファイルの末尾は ';;; ファイル名 ends here'

具体的には以下のような感じです.

;;; helm-perldoc.el ends here

バッファローカル変数はこの前ぐらいに書いておけばよいでしょう.


コードの書き方

名前空間は一つしかない

Emacs Lispは名前空間が一つしかありません. そのため用意な名前を

つけると簡単に他のパッケージを破壊することができます.


名前空間が一つしかないので, 必然的に長い名前をつけることになるの

ですが, 通常はパッケージ名をプレフィックスとしてつけます.

package-variablenameのような感じで, coffee-end-of-blockのように

なります. パッケージ名がそもそも長すぎる場合は, 単語の先頭の

文字を取ったり, 略語を使ったりするとよいでしょう.


しかし長い名前をつけたから衝突が回避できるわけでもないので,

作成しようとしている同名のパッケージがないかは調べておくと

よいでしょう.


変数, 関数の単語区切り

基本はハイフンがいいです. 一時期 ':'とか '/'が流行って

私もそのようにつけたものがありましたが, 基本的にはハイフンが

よいです. このときハイフンが 2つだと privateという慣習が

あるので, 可能な限り従う方がよいでしょう.


具体的

helm-gtags-find-tag ;; public function
helm-gtags--source-select-tag ;; private function

最低Emacs24.1では動くようにする

Debianとかまだ Emacs23がデフォルトの環境もあるので Emacs23を

切り捨てるというのは場合により良くないと思うのですが, 24.1で

動くぐらいのものをつくっておけば, 現状多くの人は困らないと

思います. 新しい機能がないと動かないというのであれば別ですが,

そうでないなら積極的に最新の機能, 関数を使うのは避けた方が

いいと思います.


よくある例としては setq-localや defvar-localです.

これらは Emacs 24.3で導入されたものですが, これだけのために

最低バージョンを上げるというのはよくないと思います.

fboundpでチェックしてなければ defmacroするという手もあり

ますが, それなら使わない方がよいと思います.


cl-libは積極的に使う

cl.elにはクソみたいな規約があるので, 積極的に cl-libを使って

ください. 正直なんで cl-をつけるだけで今まで問題とされていた

ことが解決されるんかいと思うんですが, 使うだけで許されるので

積極的に使ってください. eval-after-loadでラップする必要も

特に無いです.


必ず一度バイトコンパイルする

バイトコンパイルでは, 未定義変数の使用等の指摘が行われるので

必ず実施してください. あとバイトコンパイルをするときは,

実際有効にするかどうかに関わらず, lexical-bindingを有効に

することをおすすめします. 未使用変数の指摘も行ってくれるように

なりますので, 無駄な変数を知る上で役立ちます.




その他

gitで管理している場合はタグを打つ

melpa-stableというものがあります.

これは安定版パッケージをインストールするための ELPAリポジトリです.

melpa-stableにおける安定版というのはタグのことで, 最新のタグの

バージョンがインストールされます.


なので, 安定してきたと思ったらタグを打ってください.

どの程度の頻度で打つかはまちまちですが, 機能の追加, バグフィックが

行われ, 安定もしているというタイミングで打つのがとりあえずよいかと

思います.


レビューしてもらう

私でも emacs-jpの issuesでもいいので MELPAに登録したいんだけど,

これで大丈夫なのかと心配があるようでしたら遠慮なくお知らせください.

MELPAの管理人の purcellさんや milkypostmanさんはかなり親切なので,

指摘してくれたり, pull requestを送ってくれますが, なるべく

負担をかけない方がいいと思いますので, 何かあれば @までお願いします.

2014-08-29

eew.vimを移植しました

| 14:51

https://github.com/haya14busa/eew.vim


@さんの eew.vimを Emacsに移植してみました.


リポジトリ

https://github.com/syohex/emacs-eew


イメージ

M-x eewの実行例(前回から更新情報があるとミニバッファに表示されます.

C-uプレフィックスをつけると必ず情報を表示します).

https://github.com/syohex/emacs-eew/raw/master/image/eew.png