(setq projectile-switch-project-action 'neotree-projectile-action)

とすることで、 Projectile でプロジェクトを切り替えた時に neotree を起動するというオプションがある。

設定当時、結構この挙動が気に行ってたんだけど 気付いたらそういう挙動をしなくなっていて その代わりに find-file 的な挙動をするようになっていた。

で、その挙動をされると、絞り込みが結構だるい。 何しろプロジェクト以下のファイル全部が候補になるので。

というわけで、自分としてはプロジェクトの切り替えの後は Rails のプロジェクトなら projectile-rails の機能で絞り込みをするとか org-mode のリポジトリなら find-file するとか 自分に選択権がある状態にしたかった。

で、原因を調べてみると projectile-switch-project ではなく counsel-projectile-switch-project を使うようになってるから 記事冒頭に書いた設定が活かされない、というのに気付いた。

もはや ivy に飼い馴らされて来ている体を持つ者としては counsel-projectile-switch-project は手放せないので そっちで動かしても基本的には neotree が動くようにしたらいいよねってことで対応した

まず counsel-projectile-switch-project は

(defun counsel-projectile-switch-project (&optional default-action)

https://github.com/ericdanan/counsel-projectile/blob/06b03c1080d3ccc3fa9b9c41b1ccbcf13f058e4b/counsel-projectile.el#L1455

という感じで default-action を指定できるので、

(counsel-projectile-switch-project 'neotree-dir)

とかすれば良いだろうと考えて実行すると

(error "Action not found: neotree-dir")

とか怒られた。

原因を調べると

https://github.com/ericdanan/counsel-projectile/blob/06b03c1080d3ccc3fa9b9c41b1ccbcf13f058e4b/counsel-projectile.el#L99-L125 に書いてるように どうも、action-list に登録されてない action は実行されないようになってるらしい。

じゃあ追加したらいいよね〜っってことで counsel-projectile-remove-current-project という変数を調べると defcustom で定義されている

https://github.com/ericdanan/counsel-projectile/blob/06b03c1080d3ccc3fa9b9c41b1ccbcf13f058e4b/counsel-projectile.el#L1214-L1269

個人的には Customize で設定した情報は普段設定を書き込んでるファイルから遠い位置に書き込まれるので あんまり好きじゃないんだけど 今回に関しては Customize じゃない方法で変更しているとだるそうだったので Customize 画面から neotree-dir を counsel-projectile-remove-current-project に登録。

すると無事 counsel-projectilw-switch-project が動くようになってハッピー。 ってのが以下の Pull Request

https://github.com/mugijiru/.emacs.d/pull/183

あと、まだ ivy リキが足らなくて default じゃないアクションを動かす方法を気にしてなかったんだけど M-o でコマンドリストが出るのね。便利そう。

ただ確実にその操作忘れるので posframe のどこかにその情報残したいなって気持ちになったので 宿題としておく。

日報に org-ql を使うことにした経緯

(defun my/nippou-query ()
  (interactive)
  (org-ql-search
    (my/org-nippou-targets)
    "todo:TODO,DOING,WAIT,DONE ts:on=today"
    :title "日報"
    :super-groups '((:auto-group))))

やったこと

途中でちょっと力尽きているので、 何をやったか情報を残すことにした。

力尽き始めてから記録を残すことにしたので 結構記憶頼りである……。

https://github.com/mugijiru/.emacs.d/pull/84 あとでこれを見ながら lock 対応を進めていく。

最初はこのブログ記事に残そうと思ってたけど、 後から個人的に見返る分には GitHub の PR の方が楽な気もしたので 情報の本体はあっちに譲ることにした。

結果、ここの情報量がほぼゼロである。うける〜。

というのもアレなので、 実際にどういう作業をしたかを書くか。

#!/bin/sh

cd ~/.emacs.d/el-get
dirs=$(ls -d *)

for dir in $dirs
do
    checksum=$(cd $dir && git rev-parse HEAD)
    echo "($dir :checksum \"$checksum\")"
done

目次

前提

(pretty-hydra-define window-control-hydra (:separator "-" :title "Window Control" :exit nil :quit-key "q")
  ("Move"
   (("h" move-frame-left  "Left")
    ("j" move-frame-down  "Down")
    ("k" move-frame-up    "Up")
    ("l" move-frame-right "Right"))))

まあ Hydra のススメ とか Emacs Pinkyをhydraで解決する とか読んだら大体わかる。 ビジュアル的なメニューを出せて便利なやつ。 自分も、使いこなしてるとは言わないけども、愛用しているパッケージ。

なんだけど、そこそこいい感じな見た目にするには GitHub の README の The impressive-looking one に書かれてるように docstring でどういう表示にしたいのかを自分で書いてあげないといけない。 これが地味にだるい。

だってそのメニューに書いてるやつの一部は heads とかいう引数でも設定しているから DRY じゃないのよね。 俺ズボラだからそんな丁寧に書きたくないんですよ。

まあ実は hydra だけでも docstring まともに書かなくても 一応なんか表示してくれるのですが、これがちょっと微妙。

そこで pretty-hydra ですよ

(pretty-hydra-define
  global-org-hydra
  (:separator "="
   :title "Global Org commands")
  ("Main"
   (("a" org-agenda "Agenda")
    ("c" org-capture "Capture")
    ("l" org-store-link "Store link")
    ("t" my/org-tags-view-only-todo "Tagged Todo")
    ("F" org-gcal-fetch "Fetch Calendar")
    ("C" my/open-user-calendar "Calendar"))
   "Clock"
   (("i" org-clock-in  "In")
    ("o" org-clock-out "Out")
    ("r" org-clock-in-last "Restart")
    ("x" org-clock-cancel "Cancel")
    ("j" org-clock-goto "Goto")
    ("r" org-clock-report "Report"))))

Global Org commands

 Main^^                Clock^^
===================================
 _a_: Agenda           _i_: In
 _c_: Capture          _o_: Out
 _l_: Store link       _r_: Restart
 _t_: Tagged Todo      _x_: Cancel
 _F_: Fetch Calendar   _j_: Goto
 _C_: Calendar         _r_: Report

Global Org commands

 Main                Clock
===================================
 a: Agenda           i: In
 c: Capture          o: Out
 l: Store link       r: Restart
 t: Tagged Todo      x: Cancel
 F: Fetch Calendar   j: Goto
 C: Calendar         r: Report

(major-mode-hydra-define org-mode (:separator "-" :quit-key "q" :title (concat (all-the-icons-fileicon "org") " Org commands"))
  ("Insert"
   (("l" org-insert-link "Link")
    ("t" org-insert-todo-heading "Todo")
    ("h" org-insert-heading-respect-content "Heading")
    ("S" org-insert-structure-template "Snippet"))

   "Edit"
   (("a" org-archive-subtree "Archive"))

   "View"
   (("N" org-toggle-narrow-to-subtree "Toggle Subtree")
    ("D" my/org-clock-toggle-display "Toggle Display"))

   "Task"
   (("s" org-schedule "Schedule")
    ("d" org-deadline "Deadline")
    ("T" org-todo "Change state"))

   "Clock"
   (("i" org-clock-in "In")
    ("o" org-clock-out "Out"))

   "Babel"
   (("e" org-babel-confirm-evaluate "Eval"))

   "Trello"
   (("K" org-trello-mode "On/Off" :toggle org-trello-mode)
    ("k" (if org-trello-mode
             (org-trello-hydra/body)
           (message "org-trello-mode is not enabled")) "Menu"))

   "Agenda"
   (("," org-cycle-agenda-files "Cycle"))))

(major-mode-hydra-define emacs-lisp-mode (:quit-key "q" :title (concat (all-the-icons-fileicon "elisp") " Emacs Lisp"))
  ("Describe"
   (("F" counsel-describe-function "Function")
    ("V" counsel-describe-variable "Variable"))))

とりあえず、脱 Mac を目指している。 基本ちょっと高い気がするし、最近の macOS 微妙だしついでに iPhone も微妙になりつつあるので、ぐらいの理由。

ということで1週間以上調べながらこの記事を書いた。 そして結論は、来週ぐらいに出そうかなぐらいになってる(優柔不断)。

あと、表とかに書いてる内容間違えてたらごめんな。

ただデフォルト状態で xlsx ファイルを開こうとすると Emacs の中で zip を展開したような感じになって無念。

というわけで

;; org-mode のリンク先が xlsx の時に numbers を開くようにした
;; default は内部的には open コマンドが使われる
(add-to-list 'org-file-apps '("\\.xlsx?\\'" . default))

とかして、xlsx ファイルは OS で紐付けられたアプリで開くようにした。 今の自分の環境的には Numbers で開かれる。 ちょっと便利になった。

https://github.com/mugijiru/.emacs.d/pull/49

1年以上 org-gcal を使ってる。

けど実際にやってることは、 org-gcal-fetch で Google Calendar の情報を時々取得してきて org-calfw や org-agenda で確認できるようにしているぐらい。

が、そろそろなんとなく、 Emacs から予定の登録を試したくなった。 org-gcal の仕組み上、できるはずだし。

というわけで導入時に読んだ https://qiita.com/clothoid/items/73a937a22eeeb82c3ee7 の記事を改めて読んだけど まあよくわかってない

M-x org-gcal-post-at-point でカーソル位置の内容をカレンダーに登録

を見ると、これを使って登録はできそうだが……? という感じ

GitHub の方を見ても

org-gcal-post-at-point

Post/edit org block at point to Google calendar.

という感じなので、書いてることはほぼ一緒……。

じゃあやってみるしかないか、ってことで Google Calendar を同期しているファイルの中で

* test from emacs
  <2020-05-03 日 17:00-17:15>

this is test

とか書いて そこから `M-x org-gcal-post-at-point` としてみた。

で、何故か Got error: (error http 404) [3 times] というように 3回ほど 404 を拾って来たものの Google Calendar への登録は成功してたし、 PROPERTIES として LINK と ID が設定されたのでよしとする

そのあたりの情報があるので、恐らくそのまま編集もできるのだろう。 コマンドの説明には編集できるって書いてるし。

で、登録されたテストの予定は邪魔なので、今度は試しに消してみるとする org-gcal-delete-at-point を使えばいけるはず……

というわけでやってみたら、 「マジで消す?」的な英語のメッセージが出て、「yes」と答えたら Google Calendar からも org ファイルからも消えた。これは便利げ。

今回同期しているファイルの上で試しているけども、 多分、そのファイルじゃなくても別の org ファイルから登録することもできるはず。

ということは GTD 的に使うとすると Inbox に溜め込んでおいて Inbox から振り分ける時に `org-gcal-post-at-point` とかしておいて その後に org-gcal-fetch でもすれば同期用ファイルに入ってくるはずかな。 今度試してみよっと(今日は満足したのでそこまでやる気がしない)

元々ケチなので、キーボードを含めた周辺機器についてはあまり金をかけてなく、 基本的にこだわりもないけど、 このキーボードは分離型なのが気に入って購入した。

分離型の何がいいかは、ノートPCを使ってるので 普通のキーボードだとノートPCを奥に追いやる必要が出て来て 奥側スペースが余分に必要になるのと、ディスプレイが遠くなるのが問題なのだけど、 分離型だとノートPCの左右にバラして配置できるので ディスプレイが遠くならなくて便利。

あとは、一目見て、変わったキーボードだと分かるところ。 使ってるとまるでデキるプログラマっぽく見えそうだからだ。イメージ戦略である。

また、この製品は分離型キーボードとしてそこそこコンパクトでありつつ、 以前の型? である MD600 とは違い、カーソルキーがあったので、 キー数的に十分かなと。 カーソルキー、地味に使うから、ないと困るのよね……。 自作キーボード勢はその手のキーは削る傾向にある気がするけど、僕は軟弱者なので。

あと、このシリーズのいいところは、 自作キーボードキットの ErgoDox などとは違い、 キーの縦配列がキレイに並んでるのではなく、 普通のキーボードみたいにジグザグになってるところ。

多分 ErgoDox みたいな配列だと慣れるのに時間がかかってしまい、 嫌気が差しそうだなと思ってる。

というわけで今のところ概ね満足しているのだが、 いくつかは不満点がある。

その中の1つが、左右のキーボードを接続する付属のケーブル。 13インチの MacBook Pro を間に置いて 付属のケーブルで左右を接続すると、結構ギリギリな感じになる。 ギリギリなので USB-C のポートに大分近くなって、 結構色々なケーブルの接続に苦労する。なんとかできるんだけどね。

なんとかなるので、半年以上そのままにしていたんだけど、 最近とうとう面倒になって別のケーブルを購入した。こんなやつ。

見ての通り、ケーブルがコイル状になってるので、引き伸ばすことができる。 つまり、これがあると、 分割された左右のキーボードを結構離して配置することができる。

ということで、ギリギリの幅でなんとか配置していた状態を解消できて便利になった。

ちなみに同シリーズで今年発売された MD770 の方は LED で光るし F1-F12 もあるしバッククォートもあるし 今回問題に上げてた付属されてくる左右の接続ケーブルがコイル状になってるのでとっても良さそう。 正直買いたい……。

setq-local 内部的に make-local-variable をした上で setq をしてくれる便利なマクロらしい。 便利なので今後はこれを使うことにしよう。

あと手元の設定ファイルを見てたらまだ3行 make-local-variable がいるので 近々修正しておこう

このところは org-mode によるタスク管理もうまくいってないというか 管理がだるくなって放置している……。

今のところ業務の種類でファイルを分けつつ さらに日別でファイルを作ってるので、 ファイルの移動がだるいのと毎日ファイルを作って定期的に整理するのだるいことが分かってきた

というわけで、今度は思い切って1ファイルで管理しようと思う。 既存の区分けはタグでも使えば代用できるだろうし。

今のところは大体以下のような構成になってる

• tasks

  develop.org

  開発系タスク

  interupted.org

  割り込みタスク

  management.org

  管理系タスク。といいつつ雑用を突っ込んでる

  research.org

  調査タスク

  reviews.org

  レビューしないといけないやつ

  各日のファイル

  2020-04-01.org みたいな感じ

• old_day_files
  • 各日のファイルを適当なタイミングで移動してきている

各日の中身はこんな感じになってる

* 休憩
** 昼休み
** その他
* 会議
** 朝会
** 夕会
* その他
* Report

って感じ。 Report 部は org-clock での計測結果を入れてる。

ほんで、これをやってると タスクを積むのがどのファイルだったっけみたいになってる。 org-mode を使ってるから org-agenda でアクセスはできるはずなんだけどね。 積む時も org-capture で積めるし。

まあやっぱりこれまでの人生でタスク管理をまともにやったことがなく 基本的に脳内メモリで処理していたし、今のところ割とそれでまだ回ってるので ま、ある意味使わなくてもそれほど問題ない気がする……。

あと TODO リストの優先順位が低いタスクが増えていく問題、 みんなどう解決しているんですかね。 大体 TODO リスト管理をしなくなって来るのって それが溜まってしまってげんなりするところにある気もすんですけどどうでしょう。

ま、それはともかくとして、 一旦自分が知ってるタスク管理方法である GTD に近い感じにしてみる。

ファイル構成は

• tasks

  gtd.org

  基本はこっちに放り込む

  interupted.org

  割り込みタスク

ぐらいにしておいて、gtd.org の中身は

* Next Actions
* Projects
  いつかやるやつも含めたタスク
  ステータス等はタグで管理
* Daily log
  定例会議などの定期タスクや
  org-clock の計測結果を突っ込むところ。
** YEAR
*** MONTH
**** DAY
***** 会議
***** Reports
* Pointers
  整理の結果資料として保管することになったもの
* Inbox
  ひとまずタスクを溜めるところ

ぐらいにする。 Inbox に色々溜め込み、 ちょっと先の TODO は Projects に移動し、 資料は Pointer に移動する。 要らない作業はさくっと消すか archive SOMEDAY はステータス管理にしておく。 Next Actions はその日でやるタスクを入れると。

Daily log という概念は GTD にはないけど org-clock の計測結果を入れたいし、 あと会議などの定期イベントはそっち側で管理して時間計測する

ここに入れる際にはそれなりに分割するのが良さそう。

というのも GTD とスクラムのバックログの考え方が似てるなと思ってて Projects はプロダクトバックログ、 Next Actions はスプリントバックログ、 そして1スプリントが1日と考えると、大体似た感じかなという気がしている。

というわけでスクラムのプラクティスで考えると スプリント開始前、即ち始業時にでも計画を立てて スプリント終了時、つまり終業前にふりかえりをしたら良さそう。 終業前に両方やることも考えられるけど。

さて、そうすると、プロダクトバックログリファインメントにあたる行為をいつするかが悩ましい……。 毎日やるとしたら、ふりかえり前後か。

終業直前にこの手の定期イベントを入れると 業務上のイベントと重なりがちなのが困るな……。まいっか、ひとまず。

ステータスは

• TODO
• DOING
• Waiting
• DONE
• SOMEDAY

ぐらいで考えてる。

あとは元々ファイルとして分類してたやつをタグで分類する感じで

• Management
• Develop
• Review
• Research

とする。

基本的には1日の中で

• 実作業
• リファインメント(Projects の見直し、分割)
• ふりかえり
• 計画(Inbox の整理、Next Actions へ移動、分割)

をやっていく感じで進めるか。

あとは GTD の考えに則り、週1ぐらいで別途見直しをする工程を入れてもいいかもしれない。

という大体の方針が決まったので、しばらくそういう運用をしていこうと思う。 さて、なんか結構色々詰め込んでしまった気がするが果たしてうまくいくか……。

Issue 上で書いてる内容