papaeye

[papaeye]

ChangeLog を書く必要性がわからない

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

2014-10-20 Glenn Morris <rgm@gnu.org> * 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 だけでもいいはず。

tarball では git log が使えないから ChangeLog を同梱する理由はあるかもしれない。そういう場合は tarball 生成時にコミットメッセージから ChangeLog を自動生成すればいいんじゃないかなと思う。そのときにコミットのハッシュ値も含むようにすれけば実際の変更が参照できてさらにいい。

[papaeye]

自動フォーマット駆動の JavaScript 開発環境

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 プラグインが対応してない。

Emacs の JavaScript 開発環境

実現したいことをまとめると

JSHint/ESLint と JSCS で自動チェック

JSCS の設定を JavaScript のメジャーモードに反映

JSCS で自動フォーマット

JSHint/ESLint と JSCS で自動チェック

これは Flycheck でできる。すべての linter をインストールしている場合は、JSHint > ESLint > Closure Linter の順で優先される。たとえば JSHint をインストールした状態で常に ESLint を使うようにするには .emacs に

(setq-default flycheck-disabled-checkers '(javascript-jshint))

と書く。あるいはファイルローカル変数として設定する。

JSCS をインストールしている場合は、linter のチェックの後で結果が warning 以下なら JSCS でコードスタイルもチェックされる。

JSCS の設定を JavaScript のメジャーモードに反映

これは以前やっていた。このうち global ディレクティブを反映させる機能は今では js2-mode が実現する。以前のときより JSHint の環境オプションも増えているし、ESLint に対応しながら、JSHint の vars.js をパースしたり、ESLint の globals.json を読んだり、ESLint の設定ファイルの継承をサポートしたりした。

でこれを書きながら以前のポストを見直したら

これって、JSHint を Flymake で走らせている場合は

(setq js2-mode-show-parse-errors nil) (setq js2-mode-show-strict-warnings nil)

のように js2-mode の lint （の警告とエラーの表示）をオフにすれば、「js2-additional-externs に追加」の処理をしないでいい気がしてきた。つまり単に js2-basic-offset を適用するだけっていう。

って書いてあって馬鹿すぎた。これでだいたい合ってる。Flycheck から呼び出す JSHint や ESLint が /*global ... */ や /*jshint ... */ や /*eslint-env ... */ を見てくれるから Emacs Lisp でこれらを見て js2-additional-externs に追加したりする必要はない。

JSCS のインデントルールを js2-basic-offset などに適用する elisp は emacs-jscs に書いた。

以下は js2-mode のオプションを見直してみた結果で、JSHint を使う場合は

(setq js2-include-browser-externs nil) (setq js2-mode-show-parse-errors nil) (setq js2-mode-show-strict-warnings t) (setq js2-strict-trailing-comma-warning t) (setq js2-strict-missing-semi-warning nil) (setq js2-strict-inconsistent-return-warning t) (setq js2-strict-cond-assign-warning nil) (setq js2-strict-var-redeclaration-warning nil) (setq js2-strict-var-hides-function-arg-warning nil) (setq js2-highlight-external-variables nil) (setq js2-include-jslint-globals nil)

で値が t の変数は初期値のままだけどオプションを一覧表示するために書いておく。nil に変更した部分は対応する JSHint のオプションで警告させる。ESLint を使う場合は

(setq js2-strict-trailing-comma-warning nil) (setq js2-strict-missing-semi-warning t) (setq js2-missing-semi-one-line-override t) (setq js2-strict-inconsistent-return-warning nil)

を追加・変更する。ただしこれらの設定はセミコロンで終わらない文は警告するが、function(x) {return x} のようなワンライン関数内のセミコロンで終わらない文は警告しないようにするためのものになっている。もし常に警告するか警告しないようにするなら JSHint や ESLint で設定できるから、ESLint の設定は js2-mode-show-strict-warnings を含めて上記の変数はすべて nil にする。JSHint の設定は変わらない。

詳しくは以下の通り。

js2-include-browser-externs

初期値は t で、window や document などの識別子が定義済みとなる。JSHint で browser オプションを、ESLint では browser 環境を true にすればいい。ただしこれらで定義される識別子はそれぞれ微妙に異なる。

js2-mode-show-parse-errors

初期値は t で、JavaScript のパースエラーがハイライトされる。パースエラーは JSHint と ESLint で検出されるから js2-mode でハイライトする必要はない。

js2-mode-show-strict-warnings

初期値は t で、js2-strict-* 変数の設定を有効にする。nil の場合は js2-strict-* 変数の設定が一括で nil になる。

js2-strict-trailing-comma-warning

初期値は t で、{foo: 2,} や [3,] のカンマを警告する。JSHint でこれを警告するには es3 オプションを true にする必要がある。この変数を t のままにしておくと es3 オプションが false の場合でも js2-mode で警告させることができる。ESLint では comma-dangle ルールで制御できるから ESLint を使う場合は nil にすればいい。ESLint はデフォルトで警告する。

js2-strict-missing-semi-warning

初期値は t で、セミコロンで終わらない文を警告する。JSHint では asi オプションが、ESLint では semi ルールが提供されていてどちらもデフォルトで警告する。

js2-missing-semi-one-line-override

初期値は nil で、function(x) {return x} のようなワンライン関数内のセミコロンで終わらない文を警告する。t にすれば警告しない。ただし js2-strict-missing-semi-warning が nil の場合は、この変数の値に関係なくセミコロンで終わらない文を常に警告しない。JSHint は lastsemic オプションによってデフォルトで警告する。ESLint には対応するルールがないっぽい。

js2-strict-inconsistent-return-warning

初期値は t で、同じ関数内の return と return value の混在を警告する。JSHint では警告できないようだから js2-mode で警告するようにしておく。ESLint は consistent-return ルールによってデフォルトで警告する。

js2-strict-cond-assign-warning

初期値は t で、if (a = b) ... のような条件式としての代入を警告する。JSHint では expr オプションが、ESLint では no-cond-assign ルールが提供されていてどちらもデフォルトで警告する。

js2-strict-var-redeclaration-warning

初期値は t で、変数の再宣言を警告する。よくわからないけど JSHint はデフォルトで警告する。ESLint は no-redeclare ルールによってデフォルトで警告する。

js2-strict-var-hides-function-arg-warning

初期値は t で、関数引数と同じ名前の変数定義を警告する。JSHint はデフォルトで警告しないが、shadow オプションで警告するようにできる。ESLint は no-shadow ルールによってデフォルトで警告する。

js2-highlight-external-variables

初期値は t で、未定義の変数をハイライトする。JSHint はデフォルトで警告しないが、undef オプションで警告するようにできる。ESLint は no-undef ルールによってデフォルトで警告する。

js2-include-jslint-globals

初期値は t で、/*global .. */ ディレクティブで指定した識別子を定義済みとする。JSHint と ESLint がディレクティブを見るから js2-mode で見る必要はない。

JSCS で自動フォーマット

JSCS で自動フォーマットするための関数 jscs-fix を emacs-jscs に書いた。go-mode.el の gofmt 関数の大部分を再利用するため langfmt パッケージを抽出してそれに依存するようにした。

[papaeye]

インポートはコンポ��ション

たとえば 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 つのインポート方式がある。

インポート時の意図した名前空間の汚染を名前解決の観点から言い換えれば、コンポジションによるインポートは名前解決に明確さをもたらす。さらに Python と Go は名前解決をシンプルにしているのがいい。インスタンスで修飾せずにインスタンスの属性を参照することはできない。Python では代わりに、メソッドの第 1 引数にインスタンスを self として受け取って self.foo としてインスタンスの属性を参照する。Go のメソッド定義も構文は少し違うけど同じ方式になっている。名前解決の明確さとシンプルさがコードを読みやすくする。

[papaeye]

Python の __file__

問題です。

あるディレクトリに 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)

誤答例 1

with open(__file__, 'r') as f: source = f.read()

誤答例 2

import os.path with open(os.path.abspath(__file__), 'r') as f: source = f.read()

[papaeye]

navbar.el

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

24.3 から利用可能な display-buffer-in-side-window 関数を使っているため。

[papaeye]

[M-mouse-1] へのキーバインド

たとえば

(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)

で動くっていうのなら納得がいくんだけど。これでもいける。でも ignore でもいける。

[papaeye]

Display プロパティの space が効かないケース

(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 ">")))

1 行目は 2 つの space1 が合成（？）されて :width 0.5 分のスペースしか表示されない。どういう仕様かわからない。

[papaeye]

Travis-CI で Cask と undercover.el を動かす

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 されなかった。

undercover.el を動作させるためには sviridov/undercover.el にある通り、undercover.el をロードした後で (undercover "my-package.el") してから (require 'my-package) すればいい。ただし my-package をバイトコンパイルしていると undercover.el は動作しない。というのを順番に書いた。

[papaeye]

case-insensitive な OS X で git で名前を変更

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

$ git --version git version 2.2.1

[papaeye]

ElScreen のタブバーをフレーム幅いっぱいに

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) でいけるようにした。

3 はテキストプロパティで nowrap を指定するようなパラメータが見つからない。syntax table をいじって visual-line-mode にするというのもやってみたけど、word-wrap は synta table は見ずに空白かタブで折り返すっぽいのでできない。手動で折り返すしかわからなかった。4 は実害がないからとりあえず放置。

[papaeye]

https://github.com/papaeye/elscreen

[papaeye]

migemo.el の行をまたぐ検索

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 を変更するのが欠点。

どっちも決め手に欠けるというか…

[papaeye]

Bron–Kerbosch

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\) を拡張できる可能性があるから探索を続けられる。

というのを 9 月の終わり頃に考えていたらしい。