fcopy.el を MELPA に登録した

Emacs 用のコピー・パッケージ fcopy を MELPA に登録した。

fcopy とは?

奇妙なコピーという意味で Funny Copy と名付けた。略して fcopy。

普通のコピーは「コピーする対象」を「コピー」してから「貼り付け場所」に移動して「ペースト」を行なう。

fcopy は手順が逆になる。今、カーソルのある場所が「貼り付け場所」。先に「貼り付け場所」が決まってる。この前提で fcopy コマンドを実行 (M-x fcopy) すると、「コピーする対象」を探す・選択するモード (fcopy-mode) に移行する。「コピーする対象」を選んで RET を押すと、「貼り付け場所」(fcopy を始めた場所) に自動的に戻って「ペースト」が実行される。

対話的に「挿入」を行なう、とも言える。interactive-insert とかに名前を変えようかと思ったけど、ぼくの意識は「挿入」よりも「コピー」なので、fcopy という名前を使い続けてる。

fcopy-mode では、いくつかワンストロークのコマンドも用意している:

• バッファーへの書き込みは禁止され、誤編集ができなくなる
• 代わりに SPACE キーでスクロール、f キーでワード単位の移動、. (ピリオド) でマーク
• ( で括弧単位のコピー (括弧含む)、) で括弧の中身のコピー
• C-g で元の場所に戻って fcopy の終了、q でその場で fcopy の終了

詳しくは、過去記事 clmemo@aka: Fcopy.el ver.6.0 リリース や ataka/fcopy の README をどうぞ。

インストール

Emacs 24 系なら MELPA からインストールできる。

MELPA の準備:

(require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.milkbox.net/packages/") t)
(package-initialize)

M-x package-list-packages でパッケージ一覧を取得して、fcopy を探して RET。Install ボタンの上で RET。これでインストール終了。

適当なキーに割り当てる:

(global-set-key "\C-ck" 'fcopy)

もし古い fcopy.el があるようなら、消除を忘れずに。

過去からの変更点

MELPA に登録したことで、バージョン番号を 7.0 へ上げた。主な変更点は 2 つ。

• fcopy というコマンドを用意した (もう fcopy-mode は直接呼ばない)
• fmodify というペースト直前に編集を行なうコードをなくした

あとがき

fcopy は、今やぼくが Emacs を使う時になくてはならないパッケージになった。今まで、新しい環境に移るたびに fcopy.el をダウンロードしてインストールしていたけれど、Emacs のパッケージ・システムを使えばそんな手間をかける必要もなくなる。

修正も github に push すれば、他の環境にパッケージ・システム経由でアップデートできる。便利になった。自分が一番喜んでいる。

これからは、古い Emacs でも動くようにコードをレガシー対応させるつもり。というのも、以前、リモートでログインした環境に Mule 2 (Emacs 19 相当) しか入ってなくて泣きそうな目にあったから。他のパッケージは最新 Emacs で動けばいいと割り切ってるけど、fcopy だけはどの環境でも動いてくれないとぼくがツラい。緊急性は低いので、ゆっくりやってくつもり。

もちろん、他の機能強化項目があれば手を付ける。

Funny Copy。どうぞ、よろしく。

iOS オールスターズ勉強会、参加メモ #dotsios

2015-02-14 (土) に開かれた iOS オールスターズ勉強会に参加したので、発表内容の簡単なメモを残しておく。

既にまとめもあがっているのでリンク。

• 2015/2/14 #dotsios iOSオールスターズ勉強会 - Togetterまとめ
• [イベントレポート] iOS オールスターズ勉強会 #dotsios ｜ Developers.IO

Adaptive Collection View (LINE, 石川)

Adaptive = いろんな端末に対応。

UITableView と UICollectionView が似ているので、使い分けるより UICollectionView だけで UI を設計してしまえば iPad, iPhone 対応が手軽にできる。iPhone は UITableView, iPad は UICollectionView で作成することが多いけど、同じコードを二回書かなきゃいけないことが多い。UICollectionView を上手く使えば、画面サイズに応じて小さな分岐を入れるだけでコードを一つにまとめることができる。

Swift で使いやすい API を考える (ユピレジ, 岸川)

KeychainAccess という自作ライブラリーを例に Swift から加わった機能の説明など。

struct 型は不変な class という促え方をしてて目から鱗が落ちた。Swift は型が非常に厳密なので、Optinal 型を使わない設計が良いかも。デフォルト引数は良い機能だけど、補完がいまいち (XCode の要改善点?) なのと、フレームワークを作る時にデフォールト値がユーザーに伝えられないので困る。戻り値のオーバーロードは、キャストが必要になるのでリズムが悪い。エラー処理の戻り値は Either 型で success or error を返す。Playgroud を付けてライブラリーを提供すると、ユーザーに優しい。Functional style API は書けなくはない程度なので、普通の API と並録する方がよさそう。等々。

let UIWebView as WiKiWebView (ヤフー, 佐野)

• let UIWebView as WKWebView - Yahoo! JAPAN Tech Blog

let UIWebView as WKWebView from Taketo Sano

iOS 8 以降から使える WKWebView と iOS 7 以前でも使える UIWebView を同居させなきゃいけなくなった時に、最小の修正で切り抜けるノウハウの紹介。

通信のパフォーマンス改善 (Wantedly, 杉上)

iOS 通信のパフォーマンス改善 ・ iOSオールスターズ登壇資料 from Youhei Sugigami

Wantedly は海外進出する! (らしい) ので、低速回線での使用を考慮に入れた開発を行なった。その技術分析と対処のノウハウ集。

New Relic Mobile の分析は大雑把すぎたので、square/PonyDebugger を利用。使ってない通信があること、画像の通信量が多いことなどが分かった。ボトルネックを見つけて潰すと、また別のボトルネックが見つかるので、それを潰す。

rs/SDWebImage が素晴らしいが、まだまだ便利な機能があることを皆知らない。WebP に対応している。SDWebImagePrefetcher で画像の先読みができる。SDWebImageOptions で画像取得の優先度を 3 段階で付けられる。画像取得のキャンセルができる (遷移前のビューの画像を取っているケースなどに有効)。等々。

WebP は pod で SDWebImage/WebP で取得できる。サーバーが大変。嬉しいことに、docker を用意して公開している。

• wantedly/nginx-image-server

AsyncDisplayKit と仮想 View について (Glee, 矢口)

効率的なアプリ開発のベストプラクティス from yayugu

大原則は「やることを減らす」。通信コストの削減。サーバーに処理を任せるのも手。API 共通化・REST にこだわらないのも良い。

WatchKit を実際にさわってみてわかったこと (フリーランス, 堤)

• WatchKitを実際にさわってみてわかったこと＠iOSオールスターズ勉強会 #dotsios - Over&Out その後

WatchKitを実際にさわってみてわかったこと from Shuichi Tsutsumi

WatchKit 初見は意外と出来ない子。よく見てみると、それほど悪くもない。

animatedImage は、アニメーション用画像を配列で渡すとパラパラ漫画風アニメーションを実現。

話変わるけど、来月「iOS x BLE プログラミング 〜Core Bluetooth 徹底解説〜」という上を発売予定。Amazon では、まだヒットせず。

長生きするために心臓に悪いリリースはもうやめよう (Cookpad, 所)

Internal Testers はリリース・ビルドのアプリを審査前に小人数でテストできるので使おう。25 人、iOS 8 でしか使えないという弱点あり。

エンジニア戦記 〜 小さなチーム 大きな未来 〜 (クラスメソッド, 平井)

エンジニア戦記 〜小さなチーム、大きな未来〜 from Yuki Hirai

WebAPI の作成が難しい。iOS エンジニアも WebAPI の知識が必要。サーバー・エンジニアも分かってくれる。「1 Screen, 1 API call」。WebAPI を iOS エンジニアが分かってないと、炎上すよ。

まだ iOS でリッチな演出に消耗しているの? (カヤック, 布田)

アニメーションには iOS 7 から使えるようになった 2D ゲーム・フレームワーク SpriteKit が便利。あまり知られてないけど、UIView との親和性も高い。(0,0) の位置が UIView は左上なのに対して SKView は左下なので注意。軽いとはいわないが、描画領域を小さくして部品化すれば、十分実用点。アニメーションの作成 (Particle) はコードじゃないので、デザイナーに作ってもらうことも出来る。

あとがき

メモで書きなぐったことをのせただけ。一部、質疑応答でのやりとりも入れてある。

何人かの発表者はスライドを、講演前に公開していた。スライドを自分のペースで見ながら (自分が読み終わらない内に先に進まれても、手元にスライドがあれば安心して話が聞ける)、必要なポイントだけメモが取れて良かった。自分が発表する時の参考にしよう。

EmacsLisp でマクロを使う (初級編)

EmacsLisp のマクロは byte-compile することで、ソースコードに埋めこまれる。マクロは defun の代わりに defmacro を使って書く。シンプルなマクロは、関数を書くのと変わらない。一点注意するとしたら、マクロは使われる前に定義しておくこと。

マクロの特徴の一つに、byte-compile 時に式を評価できることが挙げられる。一例として deprecated (廃止された) 関数の呼び出しを書いてみる。

関数を使う

Emacs は進化とともに廃止される関数がある。ここでは interactive-p という関数を取り上げてみよう。この関数は、関数がコマンドとして呼ばれた時は t を返し、関数の中から呼ばれた時は nil を返す。しかし、Emacs 23.2 で called-interactively-p という関数に置き換わった。

古い Emacs でも動作を保証するために、関数 called-interactively-p が存在する時はこれを使い、存在しないなら古くからある interactive-p を使う関数 foo-called-interactively-p を作る。自作の EmacsLisp では called-interactively-p や interactive-p を直接呼ばず、 foo-called-interactively-p を使う。

(defun foo-called-interactively-p ()
  (cond
   ((fboundp 'called-interactively-p) (called-interactively-p 'any))
   (t (interactive-p))))

この関数には気に入らない点が二つある。

1. Emacs 23.2 以降でソースコードを byte-compile すると、 interactive-p は deprecated だと警告が出る
2. foo-called-interactively-p を呼び出す度に、関数 called-interactively-p が存在するかチェックする

マクロを使う

foo-called-interactively-p をマクロで書き直してみる。マクロを使うと、byte-compile 時に評価が出来るので、 called-interactively-p が存在するか否かのチェックは byte-compile 時に行なえる。

また、マクロによって展開されたコードに (Emacs が 23.2 以降なら) interactive-p は含まれていないので、警告も出ない。Emacs の byte-compiler が出す「本当の警告」に集中することができる。

マクロを使って書き直したコードは次のようになる:

(defmacro foo-called-interactively-p ()
  (cond
   ((fboundp 'called-interactively-p) '(called-interactively-p 'any))
   (t '(interactive-p))))

byte-compile 時に評価するコードはそのまま書いて、残すコードを quote している。

試しに macroexpand を使って、このマクロを展開してみる (Emacs 24.4 にて評価)。結果は次の通り:

(macroexpand '(foo-called-interactively-p))
-> (called-interactively-p (quote any))

called-interactively-p を使うコードだけが残った。

あとがき

EmacsLisp では、C 言語より高度なマクロを書くことができる。使いすぎは毒だけど、適度に使えばとても便利。バッククォートと組み合わせると、更に便利になる。何か良い例題があったら中級編も書いてみたい。

ちなみに、今回紹介したコードは fcopy.el で使っている。

• ataka/fcopy

Github で fork したリポジトリーをオリジナル・リポジトリーに同期させる

Github で milkypostman/melpa を fork して ataka/melpa を作った。

Pull Request を作って、本家にマージしてもらった。それから数か月経った。また Pull Request を作ろうと思った。ところが、ローカル・リポジトリーは最新じゃない。リモート・リポジトリーを pull しても意味がない。何故なら、リモート先はオリジナルのリポジトリーじゃなくて、ぼくが Fork したリポジトリーだから。Fork したリポジトリーをオリジナルに同期させなきゃいけない。

サイトを探したら、英語の説明があった。自分用メモとして訳しておく。

• How to update GitHub forked repository? - Stack Overflow

$ git remote add upstream git@github.com:milkypostman/melpa.git
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
$ git push origin master

upstream リモートを作って fetch。master ブランチで upstream/master を rebase。最後に push で Github に反映させる。以上。

Mac の Emacs で aspell

Mac 環境にて Emacs からスペルチェックする。

スペルチェックには ispell コマンドが有名だけど、最近、ispell の後継とされる GNU Aspell が気になったので、こちらを試してみた。

• MacのEmacsでスペルチェック(ispell)できない aspell - 黒川仁の文具堂ブログ三昧

上記サイトを参考にした。上記サイトでは Mac Ports を使っているらしく、Homebrew の内容と混在していたので、Homebrew の設定だけを抜きだしてメモしておく。

インストール

$ brew install aspell --lang=en

設定

.emacs に aspell を使う設定を追加。

(setq ispell-program-name "/usr/local/bin/aspell")

~/.aspell.conf というファイルを作って、次の一行を書く:

lang en

以上で設定はお終い。

使ってみる

適当な英単語の上で M-$ (M-x ispell-word) してみる。間違ってたら、正解の候補が現れる。あとは、M-x ispell-buffer を知ってればいいかな。これはバッファ全体に対して ispell (この場合 aspell コマンド) を実行する。

これでスペルチェックができるようになった。よかった、よかった。

GitHub Flavored Markdown でリストの中に code block を入れる

Github では Markdown (SM: Standard Markdown) を拡張した GFM (GitHub Flavored Markdown) が使われる。

リストの中でソースコードを書くのに手こずったので、メモしておく。

HTML で書くとこんなコードを書いて:

<ul>
  <li>This is test C code:
  <pre><code>int main(void) {
    printf("Hello World!\n");
    return 0;
}</code></pre></li>
  <li>secod item</li>
</ul>

次のような出力を得ることを期待している。

• This is test C code:

  int main(void) {
      printf("Hello World!\n");
      return 0;
  }

• secod item

GFM の code block

GFM には二種類の code block 書式がある。

一つはコードの前に 4 つのスペースを置く方式。GFM では non-fenced code blocks と呼んでいる。

    int main(void) {
        printf("Hello World!\n");
        return 0;
    }

もう一つはコードを ``` で囲む方式。GFM では fenced code blocks と呼んでいる。この方式はインデントしなくて済むのがメリット。

```
int main(void) {
    printf("Hello World!\n");
    return 0;
}
```

更に fenced code blocks では ```言語 という書式を使って言語のコードハイライトができる。

```c
int main(void) {
    printf("Hello World!\n");
    return 0;
}
```

リストの中にコード・ブロック

GFM ではリストの中にコード・ブロックを入れるのに 2 つの制限がある

1. non-fenced code blocks しか使えない
2. インデントは 4 ではなく 8

よって、本ページ冒頭に示した HTML コードを GFM で書くなら、こうなる。

- This is test C Code:

        int main(void) {
            printf("Hello World!\n");
            return 0;
        }

- second item

リストの入れ子とコード・ブロック

応用編。リストの入れ子にコード・ブロックを入れる場合、non-fenced code blocks のインデントは 16 になる!!

- This is test C Code:

        int main(void) {
            printf("Hello World!\n");
            return 0;
        }

  - C Header is required

                #include <stdio.h>

- second item

あとがき

当然のことだけど、non-fenced code blocks はコード・ハイライトに対応していない。口惜しいけど仕方ない。

Github のマニュアルはサラリとしか、この事を説明していないので、読み逃してしまう。おかげで README.md を 17 回も書き直してしまった。次回、同じコードを書くことになったら、また困りそうなのでメモとして残しておく。

• ref. GitHub Flavored Markdown - User Documentation