Noratetsu Lab

　ここのところデジタルのメモの整理を大規模に進めている。

　　

これまでの様子

　なかなかアプリケーションに納得できずあっちこっちを渡り歩いてきたので、色々なところに色々な形式で散らばっていた。少し前にエクスポートデータの整頓は済ませていたので一応おおよそ一箇所に集まってはいたが、ほとんどがそれぞれの形式でエクスポートしたままになっているのでひとまとめに扱える状態ではなかった。
　大体はテキストエディタで開けば見れなくはないものだが、やはり専用のビューがないと見づらいし、結局は死蔵になってしまっていた。見づらいというだけで見なくなってそれで大して不都合を感じないのだから、その程度のものと言えばそれまでだが、やはりその時その時は一生懸命考えたようなことがたくさんあるし、日記の類を確認できなくなるとその期間が空白だったかのような気持ちにもなってしまうので、いつでも確認できる状態にして安心したいと前から思っていた。
　一応ある程度のコーディング能力は獲得しているのでデータの加工はもう少し前から可能だったわけだが、問題は「どこに集めるか」だ。これだと思うものがなかなかなく、それまでの放浪の経験から「このアプリケーションも結局途中で嫌になっちゃうんじゃないか」という予感があってどこにも集められずにいた。

Dynalistへの認識の変化

　これまでに何度も書いているけれど、最近はデジタルノートツールについてはCapacities＋Dynalistという形で安定している。自分が混乱しない枠組み作りもできて、どの情報についても「これはここだな」とあるべき場所を迷いなく判定できるようになった。
　特にDynalistの位置づけが定まったのが大きいが、実のところ最も重要なのはCapacitiesとの棲み分け方やアウトライナーというものの理解の進み方ではない。やや大きいテーマなので別途記事を書くけれども、Dynalistが私にとってこれほど必要不可欠になったのは以下の理由がある。

• APIがあること
• ノート欄があること
• WebアプリなのでChrome拡張機能で干渉できること

　これらは「アウトライナーの特徴」ではない。Dynalistがたまたま備えている仕組み・特徴であって、私がDynalistを使ってやっていることをアウトライナーの良さとして語ることはできない。
　Dynalistを使い始めたのはそれなりに昔のことだが、その当時はプログラミングのプの字もわからずAPIだの拡張機能開発だのはすごいプログラマのためのものと思っていて、ノート欄については存在意義がわからなかった。ノート欄にごてごてと書いたらそのノードを操作しづらくなるからだ。なので今感じているような自由というのは昔は想像もできなかったし、そのために一時はDynalistから離れることにもなった。
　かつては「紙に書いたら動かせないが、デジタルなら動かせる」程度にしかDynalistの良さをわかっていなかったのが、今は「各ノードのデータは自由自在に利用できる」という認識を強く持ち、その変化によって、Dynalistを情報の置き場として捉えることに納得できるようになった。

実行

　そのような前提のもと、これまでに発生した文字情報を全てまとめてしまう場としてDynalistを使ってもいいんじゃないかと思えるようになり、ここ半月ばかりでそれを実行に移した。
　各ツールのエクスポートデータの形式に合わせてそれぞれOPMLファイルを生成するコードを書き、そのOPMLをDynalist上でインポートして取り込んでいった。XMLの知識がまだあまりないために謎のエラーに苦しめられたが、どのデータについてもどうにかOPMLに変換できた。
　インポートしたツール類は以下のものたちだ。

• Diaro
• UniversalDiary
• POPdiary
• Clipto
• ミミノート
• XTMemo
• CatMemoNote
• ハルナアウトライン 18ファイル
• Transno
• Logseq
• Obsidian 4Vault
• Cosense（Scrapbox）9プロジェクト
• 階層付きテキストファイル 2ファイル
• 自作ツール 4種

　一部は既に自作ツールに取り込んであったものなので、これら全種類のコードを書いたわけではない。データの出自を辿るとこれらのものが集約されたことになる（厳密にはもっと多い気がする）。
　これだけの散らかり具合ではデータの活用も何もあったもんじゃないが、ようやくひとつの規格で統一することができ、探し出すのも極めて容易になった。JSONなどに対してただテキスト検索しても結果は見づらいが、Dynalistのノード検索ならとても視認性が良い。
　一番スッキリしたのは日記類の集約だ。ツールを乗り換える度に日記の場が移ってしまい、データの加工技術もなかった時は引っ越しは容易でなく（そもそも不可能なこともある）、散らばるだけ散らばった状態になっていた。今回の整理で2014年頃から2024年8月までのほとんどがひとつのアウトラインに集まった。（2024年8月以降はCapacitiesにある。）

　デジタルツールに書き留めた日記やメモの類がこのように一箇所に集まったことは未だ嘗てない。なので私の中では人生史上で割とすごい出来事である。

　前から作ろうと思っていた個人サイトができました。

• Noratetsu House

　　
　いやあ頑張った。
　見た目はどシンプルでしょぼい感じがすると思いますがかなり頑張っています。この先に進む前にちょっとでいいので触ってみてください。^[1]

ブログ、用語集、茶の間の統合

　これまで以下の場所にアウトプットしていました。

• 記事：このブログ（Noratetsu Lab）
• 用語集（フレーズや概念などの切り出し）：Noratetsu Lab Dict.
• ちょっとした短文：茶の間（のらてつの茶の間）→のらてつの雑記帳

　ブログを書いていてすごく気になるのが、続きとして書いた記事に前の記事へのリンクを貼っても前の記事からはそれが分からないこと、そして単語やフレーズを対象とした記述（つまり事典風の記述）を書きにくいことです。元々日記に適した形態なので仕方ないことでしょう。
　一応そのやりにくさを補うために、用語集と称した場をScrapboxに作ってちょこちょこ更新していました。Scrapboxの更新は簡単で楽しいのですが、ブログ記事とリンクするには手動で頑張る必要があります。ブログに書いたものを後から概念として名付けたりした時、元のブログ記事にリンクを貼りに行くのはなんだか非常に面倒で、結局いまいち一体感はないままになってしまいました。用語集を作る前と比べたら気分的にものすごくスッキリしてはいるのですが、実用的にはもう一歩というところです。
　そういうわけで、記事と記事あるいは用語集とのリンクを大した手間なく実現できる仕組みを作ろう、と思ってこのサイトができました。

　また、ブログに書くほどじゃないけどSNSに投稿するのもなんか違う、みたいな短めの記述を置く場所として「のらてつの茶の間」と名付けたサイトを以前作りました[^2]。
　本当にめちゃくちゃ頑張って作って、ページ間リンクの仕組みは個人的には会心の出来だったのですが、如何せん更新作業が面倒で、とても「ブログに書くほどじゃない」程度の軽さの記述をほいほい公開できる感じではありませんでした。そもそも、そういう軽い記述と「縦横無尽のネットワーク」みたいな仕組みの相性が良くなくて、自分で作ったものを自分が活かせないという状態に陥ってしまいました。
　その後、反省を踏まえて簡易版を作ってもみたのですが、自作サイトという形態である以上更新作業の面倒臭さの低減には限度があり、手間が「ブログに書くほどじゃない」程度のものを書けるレベルより下回らなかったので、結局いくらもしないうちにやめてしまいました。
　最終的に掲示板サービスをひとりで使うというところに至りました[^3]。これは全然不満はなく面倒でもないのですが、なんとなく書くタイミングを掴めないというか存在を忘れがちというかで、そんなに活発には使っていません。Podcastや記事の感想を書くのには重宝しています。
　で、後述しますが、今回のサイトは投稿内容のメンテナンスが非常に簡単になる仕組みを作ったので、今度こそと思って「茶の間」の欄を設けています。超単純なブログ風のビューになっています。記事更新のタイミングで一緒にまとめて更新できるので、茶の間の記述のためにわざわざ更新作業をするということをしなくてよくなりました。

Dynalistをエディタにする

　訪問者には特に関わりのないことですが、このサイトの肝心なところは、Dynalistをエディタにしていることです。
　記事も用語集も茶の間もAboutも全てDynalist上に書いています。それをサーバーサイドでDynalist APIを使って取得して諸々加工し、データとして取り扱える形にしてからHTMLに読み込んでいます。
　この仕組みは、先月突如としてDynalistに目覚めて（？）活用法を怒涛のように思いついたことにより実現しました。ノート機能、タグ機能、ノードリンク機能をフル活用しています。
　Dynalistでやることの利点は、過去の記述に手を入れることが非常に楽になることです。一般的なブログではおそらく過去記事の編集は面倒極まりないものではないかと思いますが、アウトライナーならとても簡単です。後からリンクを追加したいという時も作業は一瞬で終わります。
　また、Dynalist APIで取得したデータはその後好きなように加工できます。正規表現を駆使してHTMLにしているわけですが、例えばNoratetsu Labの記事へのリンクをこのサイト内のリンクに変換するとか、#で始まるタグを用語集へのリンクとして解釈するとか、さまざまなことをやっています。つまり、Dynalist内ではDynalist上で扱うものとして自然な書き方で書いて、それをサイト仕様にコンバートすれば、投稿先の仕様に合わせて無理をする必要がなくなるのです。
　具体的にはDeno^[2]のスクリプトで取得・加工してjsonファイルを作っておき、　GitHubの専用リポジトリにプッシュして、それをサイトのロード時に読み込む流れです。データの加工（サーバーサイド）とサイトでの実行（クライアントサイド）は完全に切り離されているので、加工にはどれだけ時間がかかっても構いません。やろうと思えばいくらでも複雑な処理ができます。

Drummerを思い出した

　Dave Winer氏が開発したアウトライナーに、Drummerというものがあります。UIが独特過ぎて本人以外がこれに慣れるのはちょっと容易でないでしょうが、搭載している機能は非常に画期的だと思います。最大の特徴は、直接ブログとして公開できることと、JavaScriptを拡張したスクリプトを使えることです。
　Drummerを知った当初は「スクリプトを使える」と言われても何をすればいいのかよくわからなかったのですが、その後二年弱が経った今、結局私はDynalistに対してブックマークレットやらChrome拡張機能やらDenoやらでスクリプトを使いまくって自分専用の機能を拡張しています。やっと意味がわかった、という心境です。
　そしてDrummerと同様に、Dynalistに書いた内容をそのままブログやサイトのコンテンツとして公開するに至りました。この形式を思いついてコードを大方書いてから、ふとDrummerのことを思い出して、そういえばあれはつまりこういうことだったのではと思いました。
　Drummerはずっと「わかりたいけどわからない」ものだったので、自分にとって良い形を追い求めた先に答えが待っていたことには感慨深いものがあります。

今後の予定

　さて、作って公開に至ったことで若干燃え尽き気味な感がありますが、やらなきゃいけないこと、やりたいことは色々あります。
　まず過去記事の引っ越し（というかDynalistへの追加）です。どう頑張っても全自動にはならないので、それなりの手間をかけて作業する必要があります。時間がかかるのを覚悟してちまちまやっていきます。
　あとはスタイルの改良です。最低限は整えましたが、細かい部分の調整や、複数のビューモードの用意を考えています。
　このサイトを自分の拠点として自分的に面白いことができたらいいなと思っています。

---

1. 表示されない、挙動がおかしい、という場合はTwitter（X）（@Foam_Crab）かBluesky（@noratetsu.bsky.social）かお問い合わせからご連絡ください。ブラウザ毎に異なる仕様に対応できていないということなので、使用しているブラウザを教えていただければ対処できるかもしれません。
   のらてつの茶の間とは
   ひとり掲示板で自由に呟く ↩︎

2. 私はDenoを大変気に入っているのでDenoを使っていますが、もちろんその前身のNode.jsでも、あるいはPythonでもいいはずです。他のサーバーサイド言語のことはわかりませんが、おそらく多様な手段があるでしょう。 ↩︎

　ここ最近、Denoを使い始めた。

（※プログラミングについて色々書いていますが非プログラマーの素人が頑張って喋っているだけなので表現の正確さは全く保証しません。）

　Denoとはなんぞやというのはお調べいただければと思うが、簡単に言うとNode.jsの製作者であるRyan Dahl氏がNode.jsの設計ミスを解決すべく開発したJavaScript実行環境ということになろうかと思う。「Node.jsを洗練させたもの」という感じである。
　要はサーバーサイド（素人的に言うとWebブラウザ上ではなくパソコン上ということ）でJavaScriptを使うためのもので、例えばローカルファイルを読み込んで操作したりサーバーを立てたりできる。できることは無限にあると思うが、今のところ私の中で理解と実践が可能なのはローカルファイルの操作である。私が作っている自作ツールというのは、WebブラウザをGUIとして利用しているが、Node.jsでローカルサーバーを立ててローカルファイルの読み書きを可能にしている。

　Node.jsはnode_modulesフォルダにライブラリがガンガン追加されていくわけだが、この形式のせいでコードを置く場所が縛られている感じがするし、自分で直接触ることのないファイルが作業ディレクトリ内に大量に発生するのにも違和感があった。Denoはnode_modulesを生成しないのでとても身軽である。別にどこに書いてもいいし、どこで実行してもいい。触りもしないよくわからないファイルが視界の中に溜まっていくこともない。
　また、DenoはTypeScriptで書いたコードをそのまま実行できる。jsファイルを生成しなくて良いのである。そうするとソースマップのmapファイルも生まれないし、フォルダの中はスッキリサッパリ。
　require形式からimport形式に変更されているのも良い。私は新参者なのでES2015の仕様が自分にとって普通で、CommonJSは混乱の元になっている。書き方を機械的に覚えてはいるが、同じ意味のものに別の書き方があるみたいなのはもやもやと気になってしまう（歴史的にやむを得なかった分岐なのはわかっているのだが）。なので全部importで済むのは非常にありがたい。
　Node.jsにあった問題点が如何なるものでそれが実際にどう解消されているのかというのは話が高度過ぎて私にはよくわからないのだが、普通に使おうとしてすぐ出くわすような部分のデザインの変更だけでも快適さが段違いである。

　こんな感じでなんだか気分がたいへん軽やかになったので、ローカルファイルの操作に関して色々と思いつき、あれこれコードを書いた。
　具体的には、或るディレクトリ内に存在するプレーンテキストとdocxファイルを全部まとめてTextManager用のjsonに変換するとか、階層付きテキストをjsonに変換するとかである。パソコンの中に散らばっているテキスト情報を掃除機のようにガーッと吸い取って良い感じに整えるということができるようになった。
　CLIコマンドにも急に親しみ（？）を感じ始め、コマンドへの苦手意識がすっと消えた。Denoの仕様を知ることで、そもそもコマンドとは何なのかというのがちょっとわかったような気がする。

　Denoにすることで自分に可能なことが増えた、というわけではない。Denoでできること、少なくとも今の私がやれることはNode.jsでもやろうと思いさえすればできることである。しかし、潜在的に可能なことについて「できそう」と思うに至れるかどうか、という点で私の中ではNode.jsとDenoの間に大きな違いがあるのだと思う。
　理解しなくても支障がないものだとしても、それがあると「理解できそう」という希望が生まれない、みたいなことというのがある。Node.jsのデザインは私にとって希望を生まれにくくする暗幕のようなものだったので、Denoの採用は大変に高い効果があった。
　もっと早くから使っていれば……という思いはなくもないが、Node.jsとTypeScriptとCLIにある程度以上慣れていないと多分全然理解できないことだったので、このタイミングでの導入はまあ妥当なところなのだろうと思う。Deno自体、何年か前の時点では新しすぎて不安定な部分が多かっただろうし、仕様変更にすいすいついていけるスキルも私にはないわけなので、2023年の今というのは挑戦にはちょうどよかったのかもしれない。

参考リンク

• Node.js における設計ミス By Ryan Dahl - from scratch
• Deno ってなんだっけ? - Qiita
• Denoとはなにか - 実際につかってみる - Qiita

　

　ここのところ、記事に小見出しを多くつけるようになった。

　ここのところ、未だかつてなくScrapboxを盛んに使っている。といっても非公開の個人プロジェクトの話だが、きっかけがあって劇的に使いやすくなった。

　これまでずっとページのタイトルの付け方に納得がいっていなかった。全然Scrapboxが悪いとかではなく（そりゃそう）、自分がうまくやれないでいただけの話である。
　特にうまくできなかったのが、Web記事などの中の文章をScrapboxに保管しようと思った時のページタイトルである。記事のタイトルにすべきか、引用した文章そのものにするか、内容の要旨にするか。記事タイトルは必ずしも保存したい内容に沿っているとは限らないし、文章そのものというのもその文章が名言的なものでなければあまり有効でない。一時期は「～～は……である（要旨）」みたいな書き方をしたりしていたが、なんだか全然しっくりこない。
　単に「～～は……である」だけでいいのでは、というのはもちろんあり得ることなのだが、自分が思いついた発想と誰かの言葉から得たものとを区別したいという気持ちがある。なので何かしらのルールでタイトルを書き分けたかったのだが、その目的に於いては記号や絵文字を付けると見た目に煩わしく感じてしまう。どうしたものか。

　なかなか答えが出ないままでいたのだが、先日、ふとあることを閃いた。ページタイトルをスレタイみたいにすればいいのではないか？
　スレタイと言っても色々あるが、イメージしているのはニコニコ動画でもよく見る隅付き括弧で挟むタイプのものだ。匿名掲示板はそんなに見に行ったことはないのだが、本題に対してサブタイトルが二つに分かれて左右についている形式を最初に見た時にはなんだかとても面白く感じたのを覚えている。以下スレタイと言ったらこの形のことを指しているということにする（この形式に何か名称があるのかわからなかったため）。

　Scrapboxのページタイトルとしては、例えばこんな感じのページを作るようになった。いずれも実際に作ってあるページである。

• 【名文】真にカルチベートされた人間になれ【太宰治】
• 【なるほど】覚えたい英単語でショートストーリーを作らせる【ChatGPT】（→出典）
• 【💡Scrapbox】ページタイトルはスレタイ方式にする【実践】
• 【感想】RemNoteを使ってみた【惜しい】
• 【悩】ローカルサーバー方式でデータを保存すると一部文字化けする問題【解決🎉🎉🎉】
• 【2023/03/12】漠然と体調不良【翌日解消】

　パターンはいくつかある。整理すれば「【感想】～【出典・対象等】」「【分類】～【状態】」の形が多いだろう。如何にもスレタイっぽくなる場合もあるが、別に如何にもなスレタイっぽくしたいわけではないので、ただ日付を入れたり絵文字や顔文字を入れたりすることもある。例に挙げたのはいずれも両端に隅付き括弧をつけているパターンだが、頭の方だけつけているページもある。
　で、この場合、【名文】とか【なるほど】というような言葉を頭につけたものは明らかに自分以外の誰かの発信が元だとわかる。逆に【💡Scrapbox】は「💡」で閃きを示しており、自分が思いついたことだとわかる。自分発のものと他人発のものの区別がしたいということはこれでクリアである。
　前々から、頭の方に隅付き括弧で種別を添えることはあった。例えば「【JavaScript】指定した要素の位置までスクロールする方法」という感じ。しかしスレタイのイメージは浮かんでいなかったので、感想をそこに書いてしまうという発想はなかった。

　この形式の良いところは、なんといっても情報量が増えることだ。一文に領域が三つでき、それぞれメインとサブ①、サブ②であることが明らかである。且つ、隅付き括弧同士は繋がっている可能性があるが、真ん中の内容部分とは少し断絶があるという独特のニュアンスを持っている。そしてメインが何であるかは明確でありながら、両脇も強調している感があるのが面白い。
　例えば「【名文】真にカルチベートされた人間になれ【太宰治】」というタイトルについて考えてみる。この一文が示しているのは「『真にカルチベートされた人間になれ』というメッセージを含む太宰治の名文」であることがほぼ明らかである。「太宰治の名文」という要素が、【名文】【太宰治】に分割されている（【太宰治】～【名文】の順でもいい）。ちなみに、「太宰治のこと」ではなく「太宰治が書いたもの」であることを明示したいという理由で【名文】を敢えてつけている。
　これが「【太宰治の名文】真にカルチベートされた人間になれ」とか「真にカルチベートされた人間になれ【太宰治の名文】」とかいう形だと、サブの部分が重たくなり、なんだかバランスが悪い。一方、むしろ情報を足して「【太宰治の名文】真にカルチベートされた人間になれ【正義と微笑】」とするとまた見やすさを取り戻す。天秤のように左右に重さが乗っていればサブ部分がある程度長くても違和感がない。
　とはいえ短く済むならその方がスッキリする。作品名を入れたら必然的に「書いたもの」の話なので「の名文」はカットしてもいいだろう。比較しやすいように列挙してみよう。

• 【名文】真にカルチベートされた人間になれ【太宰治】
• 【太宰治の名文】真にカルチベートされた人間になれ
• 真にカルチベートされた人間になれ【太宰治の名文】
• 【太宰治の名文】真にカルチベートされた人間になれ【正義と微笑】
• 【太宰治】真にカルチベートされた人間になれ【正義と微笑】

　ブログで紹介するみたいなことなら一番目より五番目の方が相応しく思える。ただ、自分の個人的なメモとしては、どの作品で書かれたものかより「太宰治がこんな名文を残している」という感慨の方が重要なので、一番目の方が適当なのである。
　また、「真にカルチベートされた人間になれ」というのは実際に『正義と微笑』の中にある表現そのままだが、この部分が多少要約的になっていてもよい。例えば「【名文】学問は人格をカルチベートする【太宰治】」でもいい。これは私の中にある「スレタイには要旨が書かれているものだ」という前提の助けを借りている。そのまま引用しているかもしれないし、適宜縮めて要約しているかもしれないが、ともかくそのような内容で太宰治が残した名文がある、という意味合いのタイトルになっている。わざわざ「（要旨）」と断らなくても気にならなくなった。

　個人的な感覚の話だが（それは全面そうではあるが）、絵文字が単体で文にくっついた状態というのが私は好きでないようだ。例えば、「【💡Scrapbox】ページタイトルはスレタイ方式にする【実践】」というタイトルを例に挙げたが、前は「💡Scrapboxのページタイトルはスレタイ方式にする」と書いていた。これがなんだかとても気に入らない。しかし絵文字が持つニュアンス自体は好きなので、絵文字を使えたらいいという気持ちはある。絵文字の情報量を優先して、ずっと気に入らなさを我慢していた。
　ところが、「【💡】Scrapboxのページタイトルはスレタイ方式にする」と書いたところ、不思議と気に入らなさがなくなった。多分、絵文字部分が本体の一部のようであったのが、隅付き括弧で本体から明確に分離されたというのがその理由だろう。
　最終的に、左の隅付き括弧に分類を示す言葉と合わせて入れることにした。【Scrapbox】だけなら「Scrapboxに関する一般的な知見や仕様」のニュアンスがあり、【💡Scrapbox】なら「Scrapboxを利用するにあたっての自分のアイデア」という意味になり、他には【💭Scrapbox】なら「Scrapboxの使い方として今考えていること」という意味がある。なお【💡】だけなら生活に関わる閃きなどになる。

　このスレタイ風タイトルは、名詞・フレーズのページとそうでないページを区別する役割も担っている（後者のみをスレタイ風にしている）。このページはWiki的に使いたいページで、こっちはスレッド的な使い方のページだ、というのがひと目でわかる。私にとってこれは結構重要なことだ。
　両端に隅付き括弧を配置する形式を好ましく感じるかどうかは多分人それぞれだろうし、そもそもページタイトルにそんなに細かくニュアンスを込めたいかというのも個々人でバラバラだろうと思うが、私の場合は自分の微妙な要求に答えてくれる形式をこれに見出して怒涛のようにページを作るようになった。スレタイのあの形を前から面白いと思っていたので、やっていて楽しい。Scrapboxライフは劇的に豊かになった。
　

　Twitterのコミュニティ（知的好奇心向上委員会）でキーバインド（ホットキー、ショートカットキー）が話題になっていたので、そういえばショートカットキーを足すことはあっても「大本のキー配列を変えてしまう」ということは考えたことなかったな、と思い早速チャレンジすることにした。

　Windowsを使っているのでAutoHotkeyというものを導入した。
　公式ドキュメントとWikiは難解すぎて何言ってるのかわからないレベルだが、世の中には親切に知見を書いてくれている人がたくさんいるので、そういう人々の導きによって必要な設定は特に苦労なくできた。
　参考にした記事・サイトやひとまずの設定はScrapboxにまとめている。

• AutoHotkeyでキー配置をリマップする - Noratetsu's Room（のらてつ研究所）

　あれこれ設定して使ってみたところ、確かに便利である。
　何よりありがたいのが、「うっかり押すと面倒くさいキー」を封じられることだ。例えばCapsLockとかCapsLockとかCapsLockとか。他にはNumLockとInsertも反応しないようにした。
　注意が必要なこととして、CapsLockなどのLock系キーは他のキーとそもそもの挙動が違っているらしく、例えばCapsLockをCtrlに置き換える、ということはレジストリを弄らないとうまくいかないらしいということがある。慣れない領域の話なのでよく解っていないのだが、多分「同時押し」が必要な修飾キーとして使うのが無理ということなので、他の役割なら持たせられる。最初はCapsLockを単に封印していたが、途中でBackspaceを割り当てることにした。まあまあ便利である。
　修飾キー（Shift、Ctrl、Altの類）を独自に増やせるというのも大きい。既存の修飾キーはWindowsや各種ソフトによってショートカットが割り当てられていて、自分で設定するとそれらと干渉する可能性が高い。しかし、他のキーを修飾キー化してしまえば、それがショートカットキーとして登録されている可能性はほぼゼロなので、何も気にせずに自由に設定できる。私はとりあえず無変換キーとAppキー（コンテキストメニューを出すキー）を修飾キー化してみた。変換キーも修飾キーの候補だったが、そちらは今のところCtrlを割り当てている。
　更に、AutoHotkeyは任意のキーに他のキーの役割を持たせるというだけに留まらず、スクリプトで相当複雑なことができるらしい。言語としてはそんなに難しくはなさそうだが、自分が慣れているJavaScriptとは違う部分もあちこちにあるので、馴染むにはちょっと時間がかかりそうだ。
　そもそも「こうできたらいいのに」という願望が特になかったので、実現すべきものを思いついていない。でもこれから何か思いついた時に、それを叶わぬ願いなどではなく「スクリプトを書けば実現できるもの」と思えるのは、気持ちの面で随分違ってくるように思う。

　そんな感じで便利なのだが、これまでの長い歳月で両手にはデフォルトのキー配列に適応した動きが染み付いている。変更した配列に従えば小指や手首に負担がかからないとわかってはいても、反射的に従来どおりの無理な動きをしてしまう。自分の手がリマップされるのにはそれなりの時間が必要そうである…。
　あと、やはり後から被せた形であるがゆえにAutoHotkeyがちゃんと効かない時が偶にある。ほとんどは大丈夫だが、メモリに余裕がなくなった瞬間に変になったりする気がするので、そういう状況ではちょっと注意が必要かもしれない。まあPCのスペックが高ければ問題ないのかも。

　先程スクリプトの話をちらとしたが、文字列をそのまま貼り付けたいということから関数を使う必要が生じ、その延長で簡単なコードを書けるように色々試行錯誤してみた。そしてどうせならと、文章化してnoteにいくつか記事を投稿した。

• 「from:@noratetsu AutoHotkey」の新着の記事一覧｜note

　noteへの投稿は実に一年半ぶりである。noteに投稿していたのはこのブログを始める前のことなので、文章を書いて人の目のあるところに投稿するということに対する考え方が今とは随分違っている。一言で言うと、昔はものすごく構えて書いていた。
　当時の自分とはどういうものであったかというのは何度かこのブログ内に書いたかと思うが、フェードアウトした理由を簡単にまとめるなら「noteに何かを投稿しようとしている時の自分が嫌になった」ということになるだろう。
　どういう頻度で書くべきか、どういう長さで書くべきか、どういう内容を書くべきか、どういう文体で書くべきか、そういったことをぐるぐる考えていた。考えて悩んだだけで何も実行できていないのだが、とにかく「こうではいけない」という自己認識で苦しんでいた。
　そういう悩みはもう捨ててしまった――むしろ捨てて書いたものによって出会いを得た――ので、noteという場に対する考え方も変わってきた。まあどうせ「読まれる」ことは期待できないのだから、テキトーに書いていいだろう、という気分になっている。テキトーというのはぞんざいという意味ではなく、「自分が良いと思えば良いだろう」ということだ。どうするのが"適切"か、ということを考えるのはやめた。

　noteを「ホーム」にしようとしていた時はひたすら辛かった。でももうホームは別にあるので、noteは自分にとって大した意味を持っていない。だから逆にサラッと書けるし、多分その方が読み手にとっても読みやすく有用な記事になるという気がしている。