2020年ももう残り少ないことを意識すると、身近なものを見返したりして、成し遂げた数を自分の中で増やしたり、マシに新年を迎える準備をする気になってくる。
そういうことで記事の執筆環境を見返してみる。
端末エミュレータ/ターミナル
コマンドを実行したり、Vim を操作したり、各種操作を行ない、長い間見つめ続けることになる
端末エミュレータにはそれ程拘りが無く、lxterminal を使っている。
最低限の機能 (ウィンドウサイズ、フォントの設定) は備えているし、タブ機能もある。
端末エミュレータでは、GPU (OpenGL API) による高速な描画を特徴とする Alacritty が人気だ。
確かに Alacritty は高速で、設定面も充実してる素晴らしいソフトウェアだが、タブ機能に対応していない。
これは、そうした機能は Alacritty に実装するよりもウィンドウマネージャーに任せた方が良いという判断で、目的あってのものである。
ただ FullHDモニタ 1枚で作業してる身としては、端末エミュレータの他にウェブブラウザを開けばもう画面に余白は無く、そのためタブ機能はあった方が嬉しい。
Vim にマルチウィンドウ機能があるため、それを活用することもできるが、実質分割機能であるため、元のウィンドウに大きめのサイズが必要となる。
フォント
最強のフォント。
英語と日本語の両方を最も綺麗に表示できるフォントだと思っている。
HackGenフォントが無かったらエディタを Vim に一本化することを諦め、日本語文書と Markdown用のエディタをわざわざ別に用意していたかもしれない。
Vim のカラースキームには morhetz/gruvbox を、background=dark 設定で使っている。
Vim
上でも少し触れたが、エディタは Vim で統一している。
理由としては好きだからというのが大きいが、実用的な理由を挙げると、多様なテーマ (カラースキーム) が開発されている、強力な置換コマンド、インサートモードに入りつつ改行を挿入をする o コマンド、new コマンドと複数ウィンドウにより他のテキストファイルから容易にコピーできること等がある。そして、それら操作をする上で、手をマウスにいちいち移す必要が無いというのは素晴らしいことだと思う。
高度なカスタマイズ性も備えており、キーマップやシンタックスを自分好みにいくらでも設定できる。
~/vimrc
記事を書く中で、気付けば Vim も普段遣いするようになってから 1年近く経っているが、いざ見直してみると .vimrc はあまりカスタマイズしていなかった。
少ないが、その内の一部設定を見直すついでに紹介したい。
inoremap <Enter> <Space><Space>
highlight markdownTrailingSpaces ctermbg=023
autocmd BufNewFile,BufRead *.md match markdownTrailingSpaces "\s\s$"
改行に関して役立ってくれるはずの設定。IMEの切り替え操作を減らす働きが期待できる。
Markdown記法では、改行を行末の半角スペース 2個で表現する。空白行を入れても改行はされると言えばされるが、その場合段落が分けられる。
通常であれば、日本語文書を書いていて改行を入れたい時、IME を切り替え、スペースバーを 2回、そしてエンターキーを打つことになる。
改行を使う機会は少なくない。紙ではなくウェブページに掲載する上では、行に詰め込む文字数は抑えた方がいいため、改行はより多くなる。
なのに上記操作を何度も行なうのはかなりの手間だ。
それを多少楽にしてくれるのが一番上の inoremap から始まる行の設定。
この設定により、改行を入れたい時は IME 有効のまま、全角スペース+エンターで半角スペース 2個を入力できる。
実際には、全角スペースと組み合わせたのと改行のためのとで、エンターキーを連続で 2回打つことが多い。
スペースバーを 2回打つより楽なことと、使える場所を増やすためにそうした設定としているが、改良の余地があるようには思う。
下 2行はシンタックスの設定で、Markdownファイルを読み込んだ時、行末にある半角スペース 2個の背景に色を付ける。
inoremap １ 1
inoremap ２ 2
inoremap ３ 3
inoremap ４ 4
inoremap ５ 5
inoremap ６ 6
inoremap ７ 7
inoremap ８ 8
inoremap ９ 9
意外に使える設定。インサートモード時、全角数字を半角数字にマッピングする。
最近追加した設定で、よくよく考えたら日本語文書であっても全角数字を使うことはほとんど、いや全く無かった。
au BufNewFile,BufRead *.md syn match markdownIgnore "_" containedin=markdownLineStart,markdownLink,markdownLinkText,markdownH2,markdownH3,markdownH4,markdownH5
au BufNewFile,BufRead *.md syntax region markdownCode start=/>\ / end=/$/
上は、エラーを抑制するための設定。Markdown記法では _ (アンダースコア) で囲んでも斜体 (<em>~</em>)、太字 (<strong>~</strong>)を表現できるが、基本 * (アスタリスク) が使われる。
それでも Vim 内の Markdown シンタックスは _ にも対応しているため、文章中にそれが現れると他のシンタックスが崩れてしまう。
それを対策したのがこの設定で、多少強引にシンタックス設定を上書きしている。
下も同様に対策目的の設定。引用部分に Markdown記法に使われる記号があると、それもまた他が崩れる原因となるため、コード部同様のハイライトを適用している。
この記事も元となるMarkdownファイルを Vim で書いているのだが、書きながら新たなキーマップを追加、テストするもんだから、記事が遅々として進まなかった。
更新作業
Github Page サービスを利用して公開しているため、更新作業もターミナル上でコマンドを入力して行なわれる。
更新までは、Vim で記事を Markdown形式で書き、Hugo でビルドし、Githubレポジトリをクローンしたディレクトリに移動し、git add --all、git commit、コミットメッセージを入力、そして git push で Github側にアップロードする、という流れだが、当然ここも手間は少ない方が良い。
自分は簡単なシェルスクリプトで更新するようにしている。自作の Hugoテーマと記事部も git で管理しているため、単純といっても更新に掛かる作業量は多く、スクリプトが無ければ気力を大きく削ぐ障害となる。
また、一連の作業をスクリプトにしてしまえば、作業時間の短縮だけでなくミスも減らせる。
引数によって、単純な更新作業以外も行なえるようスクリプトを書くと、さらに使い勝手が良くなる。
.bashrc に以下のような行を記述し、スクリプトをコマンドのように実行できるようエイリアスを作成すれば、より短い手間で更新できる。
alias _page_update="sh <スクリプトのパス>/update.sh"
記事を書き始める時だが、自分の管理方法だと元ファイルへのパスが <Hugoディレクトリ>/content/posts/<年>/<月>/<日>/<ファイル名> とかなり長くなる。
Hugo でファイルを生成した後、また長いパスを打って Vim で編集を開始するのは面倒なため、以下のような関数を .bashrc に記述している。
_new_article () {
export NEW="${PWD}/${1}"
hugo new ${1#content/}
if [ "${2}" = "--vim" ] || [ "${2}" = "-V" ]; then
vim ${NEW}
fi
}
これにより、ファイルへのパスはシェル変数 ${NEW} にあるため、長いパスを打たずに vim ${NEW} だけで済む。引数 --vim か -V を追加すればそのまま開始することもできる。
2021年の執筆環境
今後どう環境を改良していくかだが、まあモニタをもう 1枚買ってマルチモニタ環境にするのが一番効果的な気がする。ソフトウェア環境に不満がないとなると、後はハードウェア側を強化する他ない。
後はノートPCだろうか。個人用のノートPCがあれば、執筆やテンプレートの開発、改良に費やす時間をかなり増やせる。
ただ、ファイルの共有方法が少し面倒に思う。Github 経由でやり取りするとかあるが、手間が増えることに変わりはない。
ノートPCの具体的な検討すらしてないため、杞憂なのだが。