build error

コミットメッセージをきちんと書けば ChangeLog を書く必要なんてない、と思う。ここでいう ChangeLog というのは Emacs などの

2014-10-20 Glenn Morris <[email protected]> * Version 24.4 released.

こういうフォーマットのもののこと。コミットメッセージにも "Version 24.4 released." のようなことを書いてるはずだから、同じことをなぜもう一度書かないといけないのかわからない。

それに ChangeLog には今では明らかな欠点がある。ひとつはマージが面倒くさくなること。ChangeLog のコンフリクトの解消とかしたくない。もうひとつは実際の変更を参照する術がないこと。その点においてはコミットのハッシュ値を含む git log の方が勝っている。

emacs の info の 28.2 Change Logs には

Many software projects keep a "change log". This is a file, normally named `ChangeLog', containing a chronological record of when and how the program was changed.

とあり、28.2.1 Change Log Commands には

Version control systems are another way to keep track of changes in your program and keep a change log.

と書かれている。another way なんだから変更の記録をつけるのに VCS だけでもいいはず。

Python や Go では、コードの編集時には標準のコードスタイルで自動チェックし、保存時にもその同じコードスタイルで自動フォーマットするといったことができる。言語で決められた標準のコードスタイルのない言語では、自動チェックと自動フォーマットで同じコードスタイルが適用されるようにしないと意味がない。

Closure Linter はまさにそのためのツールだけど Google JavaScript Style Guide に限られる。

jsfmt は esformatter を自動フォーマットエンジンとして利用する。esformatter では diff を出力することはできるけどコードスタイルエラーの詳細を出力できない。

Linter である JSHint や ESLint にはコードスタイルに関するオプションもある。それらを esformatter における同等の設定に変換して jsfmt で自動フォーマットすればいいように思ったけど、自動変換してくれるようなツールは見つからなかった。手動で変換するにはオプションが多すぎる。

また JSHint ではコードスタイルに関するオプションは deprecated になっていて、次のメジャーリリースで削除されるらしい。JSHint のドキュメントではコードスタイルのチェックとして代わりに JSCS が参照されている。JSCS には自動フォーマット機能が最近実装された。

以上の状況をふまえると、自動チェックと自動フォーマットを一致させるには今のところ Closure Linter か JSCS しかないけど Closure Linter は使わない。なぜなら自分のコードだけならそれでもいいけど、いろいろなスタイルの既存のコードを触るなら最初から JSCS で設定しておけばいいと思うから。でも JSCS の自動フォーマット機能は、設定が緩いせいかもしれないけど、気が利かないと感じることが多い。

コードスタイルの自動チェックとともに、もちろん Linter による自動チェックも行う。

ESLint 2.0.0 Wish List で ESLint に autofix オプションを提供するか話されていて将来的には ESLint だけで済むかもしれない。でも同時に ESLint からコードスタイルに関するオプションを削除して JSCS に任せるという意見も出ている。

コードスタイルの設定のうちインデントの設定については、自動チェックと自動フォーマットに対応していれば EditorConfig に任せて、JSCS では指定しないのもいいかと思ったけど、Emacs の EditorConfig プラグインが対応してない。

たとえば Python で main.py ファイルに import sys と書けば、main モジュールは sys モジュールをコンポジションすることになる。

import sys class MyClass(object): pass

と書いたとき、sys モジュールも MyClass クラスも main モジュールがコンポジションするという意味においては変わらない。

Java と Go のインポートもコンポジションだけど少し異なる。

Java だと java.util.List を使う Main クラスは、Main.java に

import java.util.List; class Main { // Use java.util.List... }

と書く。import java.util.List; は Main.java ファイル内全体で java.util.List を利用可能にする。class Main {} ではなくて Main.java が Main クラスに相当する。Java ではクラスがコンポジションの単位となっている。

Go では、main.go ファイルに

package main import "encoding/json"

と書けば main.go ファイルは encoding/json パッケージをコンポジションし、main.go ファイル内で json という名前で参照できるようになる。Go では複数の .go ファイルで同じパッケージを宣言できインポートはファイル内でローカルだから、パッケージがパッケージをコンポジションするという言い方はできない。

この点に関しては、Python ではモジュールがモジュールをインポートして、Java ではクラスがクラスをインポートして、というふうにうまく抽象化されている。

いずれにしてもこれらの言語はインポートによって、クラスや関数やモジュールやパッケージなどをコンポジションすることができる。コンポジションでは名前空間が勝手に汚染されないのがいい。foo.py に import bar と書いたとき汚染されるのは bar という名前だけで、それは import bar と書いた／書かれたときに宣言したことだから「勝手に」ではなく「意図して」なのがいい。そしてその意図はインポート文が明確に表す。

ところで PEP 8 では、名前空間に存在する名前が不明瞭になり読者や多くの自動化ツールを混乱させるからワイルドカードインポート（from <module> import *）は避けるべきといっている。

Wildcard imports ( from import * ) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools.

コンポジションと対比して、ワイルドカードインポートはモジュールの継承といえる。from sys import * や from os.path import * と書けば それらのモジュールで定義されているものをモジュール名で修飾しないで使える。けれどそれは sys モジュールや os.path モジュールを継承していることになる。そのような設計はおかしい。

Python についてまとめると 3 つのインポート方式がある。1 つは import <module> 文でモジュールをコンポジションして、モジュール名で修飾しながらそのモジュール内のクラスや関数を利用する方法。もう 1 つは from <module> import <something> 文で利用したいクラスや関数を直接コンポジションする方法。最後に from <module> import * 文でモジュールを継承する非推奨の方法。

Java と Go にも同様の 3 つのインポート方式がある。

問題です。

あるディレクトリに main.py と sub.py があります。任意のディレクトリから python <path to>/main.py を実行したとき、常に sub.py のソースコードがプリントされるようにするには sub.py はどう書けばいいでしょうか。ただし Python のバージョンは 2.7.9 で、main.py のソースコードは以下の通りとします。

import sub if __name__ == '__main__': print(sub.source)

https://github.com/papaeye/emacs-navbar

What is navbar.el

ElScreen のタブバーをフレーム幅いっぱいにを一般化させたもの。

名前は Bootstrap の navbar コンポーネントから。役目も同様で様々なコンポーネントを含めることができる。navbar.el で含めるコンポーネントは navbar item と呼んでいる。

Why navbar.el

以下の動作はおかしい。

display-time-mode を有効にするとすべてのモードラインに時刻が表示される

Mew の biff もすべてのモードラインに表示される

ElScreen のタブがフレームの第一ウィンドウのヘッダラインにのみ表示される

モードラインやヘッダラインはこれらの情報を表示する場所として適していない。navbar.el はこれらに適した表示場所を提供する。

Screenshots

Requirements

Emacs 24.3 or later

たとえば

(global-set-key [M-mouse-1] (lambda () (interactive) (message "foo")))

を評価した後 meta キーを押しながらクリックしてもメッセージは表示されない。

(global-set-key [A-mouse-1] (lambda () (interactive) (message "bar"))) (global-set-key [header-line M-mouse-1] (lambda () (interactive) (message "baz")))

などは動作する。普通に info に書いてあった。20.7.6 Button-Down Events

(lookup-key global-map [M-down-mouse-1]);\C-j mouse-drag-secondary

で [M-down-mouse-1] が定義されているから [M-mouse-1] を定義しても実行されないってことのようだから

(global-set-key [M-down-mouse-1] 'ignore)

こうすれば動いてるっぽいけど納得がいかない。ignore の場合は後で [M-mouse-1] のキーバインドが有効になって、mouse-drag-secondary の場合はそうではないってところが。

(global-set-key [M-down-mouse-1] nil)

(with-current-buffer (get-buffer-create "*my-test*") (erase-buffer) (let ((space1 (propertize " " 'display '(space :width 0.5))) (space2 (propertize " " 'display '(space :width 0.5)))) (insert "<" space1 space1 ">" "\n" "<" space1 space2 ">")))

Travis-CI でテストしたいことは

パッケージを作成できること

作成したパッケージを package.el でインストールできること

インストールしたパッケージがテストをパスすること

の 3 つ。

テスト対象のパッケージは papaeye/emacs-navbar で、Emacs 24.3 以上サポートだから EVM を使って Emacs 24.3 と 24.4 でテストする。ert-runner とかは使わない。

完成したのは

before_install: - sudo mkdir /usr/local/evm - sudo chown travis:travis /usr/local/evm - git clone https://github.com/rejeep/evm.git $HOME/.evm - export PATH=$HOME/.evm/bin:$PATH - git clone https://github.com/cask/cask.git $HOME/.cask - export PATH=$HOME/.cask/bin:$PATH env: - EVM_EMACS=emacs-24.3-bin - EVM_EMACS=emacs-24.4-bin install: - evm install $EVM_EMACS - evm use $EVM_EMACS - cask install - cask package script: - cask exec emacs --version - cask exec emacs --batch -f package-initialize --eval "(package-install-file (car (file-expand-wildcards \"$PWD/dist/navbar-*.tar\")))" - cask exec emacs --batch -f package-initialize -l test/navbar-test.el -f ert-run-tests-batch-and-exit - if [ "$EVM_EMACS" = "emacs-24.4-bin" ]; then cask exec emacs --batch -f package-initialize -l undercover --eval "(undercover \"navbar.el\")" -l navbar.el -l test/navbar-test.el -f ert-run-tests-batch-and-exit; fi

$PWD なしで (file-expand-wildcards "dist/navbar-*.tar") とすると Emacs 24.3 で dist ディレクトリが見つけられなくて失敗した。

emacs-navbar では undercover.el を実行するのは 1 回だけでいいから↑の if 文はあっていい。if 文なしにすると Emacs 24.3 で (undercover "navbar.el") が失敗した。file-expand-wildcards と同じ理由かと思って同じような修正をすると正常終了するけど Coveralls に push されなかった。

普通に git mv Readme.md README.md でいけた。

https://github.com/papaeye/elscreen

delete-other-windows しても消えないウィンドウをフレームの上部にずっと表示させてそこにタブを表示すればいいんじゃないかと思って、info を読んでいたところ 27.25 Window Parameters に window-side というパラメータを見つけたのがはじまり。side window というのがそれで、info にはほとんどドキュメントがなくて不安だったけど Re: Tabs are ready? に

If we want per-window tabs, atomic windows should be used. If we want per-frame tabs, side windows could be used.

というのを見つけたので間違った使い方はしていないはず。ただ side window をサポートしていなくて変な挙動になるプログラムは割とよくあると思う。既知の問題は

popwin-mode が有効だと表示がくずれる

popwin HEAD で修正済み

howm 1.4.2 で検索したとき *howmS* を開いたウィンドウが前面にこない

狭いフレームでタブをいっぱい開くとタブの途中で折り返される

elscreen-start 後に elscreen-display-tab の値を変更すると、スクリーンごとに異なるタブウィンドウを保持することになる

で、2 はまだ調べていない。3 はたぶん何かパラメータがあると思っている。4 は難しい。

2 は (elscreen-workaround-one-window-p riffle-summary) でいけるようにした。

migemo.el の行をまたぐ検索をすべてのモードで可能にするという試み。

現在の仕様

現状は http://0xcc.net/migemo/ にあるように

Emacs の "\s " の意味はモードによって変わります。モードによっては行をまたぐ検索ができないことがあります。

となっていて、たとえば text モードだと行をまたぐ検索ができるけど emacs-lisp モードではできない。これはそのバッファで (string (char-syntax ?\n)) を評価することでわかる。

emacs lisp モード: ">" => デリミタクラス

text モード: " " => 空白クラス

\s = \s- は空白クラスを意味するから emacs-lisp モードでは改行とマッチしなくて行をまたぐ検索ができないという仕様。

"Regular expression too big" エラー

ASCII の printable な 1 文字だけで検索した場合、Homebrew の C/Migemo は stable と HEAD ともに

c: "Regular expression too big" エラーになる

]: 検索に失敗する

という結果になった。gist

後者は C/Migemo のバグで PR を出したけど全然間違ってた。info を見た限り ] を [ ... ] の先頭にくるようにすればいいような気がするけど実装力不足。

修正案 1: Ruby/Migemo に倣う

https://github.com/papaeye/migemo/tree/fix-multiline-search

行またぎ検索のために正規表現に \s-* を挿入しているのを Ruby/Migemo と同じように migemo-white-space-regexp = [ 　\t\r\n]* を挿入するようにすると、C と s で検索した場合にも "Regular expression too big" エラーになるようになった。

Ruby/Migemo と同じ挙動だと思うのでこれでいい気もする。いや "cmigemo" で string-match はない気がする。

修正案 2: syntax table にパッチを当てる

https://github.com/papaeye/migemo/tree/multiline-search-all-modes

一時的に syntax table を変更して改行等を空白クラスに設定するというもの。"Regular expression too big" エラーになるケースを増やさないという意味でいいと思う。syntax table の変更が副作用を及ぼさないかわかってない。

行またぎ検索をしない場合でも syntax table を変更するのが欠点。

Bron–Kerboschがなかなか理解できなかった。

BronKerbosch1(R, P, X): if P and X are both empty: report R as a maximal clique for each vertex v in P: BronKerbosch1(R ⋃ {v}, P ⋂ N(v), X ⋂ N(v)) P := P \ {v} X := X ⋃ {v}

こんなにシンプルなアルゴリズムなのに。

いくつか検索したサイトにあった \(X\) とは禁止リストであるみたいな説明がわからなかった。禁止リストなのに if v in X: break # 探索終了 みたいな疑似コードではないし、\(X \cap N(v)\) によってどんどん \(\emptyset\) に近づく禁止リストというのがよくわかなかった。DFS とかの visited リストみたいに、探索が進むにつれて禁止するものが増えていくのが禁止リストのイメージだったから。

確かに最終的には禁止リストだけど、そういう見方をせずに考えることで理解できたつもりでいる。

まず \(R\) を拡張してできる極大クリークは、\(P\) の部分集合によって \(R\) を拡張したものでありそれ以外にはない。なぜなら \(R\) をクリークとして拡張できる頂点集合は、その各要素が互いに隣接し、かつ \(R\) のすべての要素とも隣接しなければならず、それは \(P\) の（各要素が互いに隣接するような）部分集合だから。\(P\) の各要素が \(R\) のすべての要素と隣接するのは、\(R = \{v_1, \dots, v_k\}\) とするとき \(P = V \cap N(v_1) \cap \dots \cap N(v_k)\) となっていることからいえる。

またバックトラック時の操作により \(v \in P\) は \(P\) から \(X\) に移動する。つまり \(X\) の要素はすべてもともとは \(P\) の要素だから、\(P\) と同様に \(X\) の（各要素が互いに隣接するような）部分集合で \(R\) をクリークとして拡張することができる。しかし \(X\) の要素は既に調べた頂点だから、\(u \in X\) とするとたとえば \(R \cup \{u\}\) は既に出力した極大クリークの部分集合となる。

ここで \(X\) の部分集合によって \(R\) を拡張して新しい極大クリークができるとする。クリークができるのであれば、その部分集合の各要素は互いに隣接していなければならない。互いに隣接しているのであれば、それらは既に調べた頂点からなるのだから、それまでに極大クリークとして出力しているはずだから矛盾。つまり \(X\) の部分集合によって \(R\) を拡張して新しい極大クリークを作成することはできない。

よって \(P = \emptyset\) かつ \(X \neq \emptyset\) の場合は、\(R\) は極大クリークではないし \(R\) と \(X\) で新しい極大クリークを出力することもできない。

\(P \neq \emptyset\) かつ \(X \neq \emptyset\) の場合は、\(P\) で \(R\) を拡張できる可能性があるから探索を続けられる。