<a href="https://x410.dev/">X410</a>というX Window Serverがかなり便利。X WindowをVNCみたいにまるっと表示するのではなくて、アプリケーション毎にWindowを分けて表示してくれるモードがあり<a class="footref" href="#fn1" id="r1">[1]</a>、LinuxのGUIアプリを普通のWindowsアプリと同じように扱える。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50302921416/in/datetaken-public/" title="Run Linux GUI app as normal windows application"><img src="https://live.staticflickr.com/65535/50302921416_07462c0010_c.jpg" width="800" height="450" alt="Run Linux GUI app as normal windows application"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">ReactNative開発の図。左のDebuggerはLinux版</div>
 </div>
</div>

ただあくまでLinux上で動いているものなので、フォントとか日本語入力とか、キーボード周りの設定とかはもちろんLinux側で設定する必要がある。
日本語入力に関しては、それが必要なアプリは自分の使うアプリではいまのところEmacsしかないが、Emacsはそれ自体で日本語入力が可能なので特に設定する必要がない。
自分がEmacsのためにインストールしたのは以下:
<pre><code class="sh"># Emacs&#12391;&#20351;&#12387;&#12390;&#12427;&#12513;&#12452;&#12531;&#12501;&#12457;&#12531;&#12488;
yay -S otf-source-han-code-jp

# &#33521;&#25968;&#26085;&#26412;&#35486;&#20197;&#22806;&amp;&#32117;&#25991;&#23383;&#29992;
yay -S noto-fonts noto-fonts-cjk noto-fonts-emoji

# skkserv
yay -S yaskkserv

# for SandS
yay -S xcape</code></pre>

skkservは使わずでローカルの辞書だけでもskkはうごくのだが、
yaskkservは<a href="https://twitter.com/typester/status/1299885480058601472?s=20">ここ</a>にも書いたけど、入力した単語がローカル辞書に見つからなかった場合にGoogle検索を利用してくれるので、新語や人名の入力に便利なので使っている。
一度入力したものは個人辞書のほうに追加されるので、毎回Googleにアクセスがいくわけではないので安心して良い。
またyaskkservはArchLinuxパッケージ付属のsystemd unitファイルはbindアドレスが指定されていなくフルオープンになってしまうので、
<pre><code class="systemd"># ~/.config/systemd/user/yaskkserv.service
[Unit]
Description=Yet another SKK Japanese input method dictionary server

[Service]
ExecStart=/usr/bin/yaskkserv_hairy --no-daemonize --address 127.0.0.1 --google-japanese-input=notfound /usr/share/skk/SKK-JISYO.L.yaskkserv

[Install]
WantedBy=default.target</code></pre>

みたいな127.0.0.1にバインドするuser unitを自分で作って起動してる(WSL2の場合)。WSL1では使う時に毎回手動で起動しているw
あと個人的に必須といえるのがSandSおよびキーリピート加速だが、これは<a href="https://unknownplace.org/blog/2020/06/05/sands/">Linuxの時に使っていたもの</a>がそのまま使える。
<pre><code class="sh"># SandS
xmodmap -e 'keycode 255=space'
xmodmap -e 'keycode 65=Shift_L'
xcape -e '#65=space'

# &#12461;&#12540;&#12522;&#12500;&#12540;&#12488;
xset r rate 200 100</code></pre>

みたいな感じ。
あと、Windows側のSKKFEPとかでSandSの設定をしていると、そのままだとX Windowアプリのほうのスペースの挙動がおかしくなるので、入力ソースを別のもの(Englishとか)にしてあげる必要がある。
その時に全体の入力ソースが変わってしまうとアプリ切り替えるたびにソースを変更しなおす必要があってかなり面倒なので、Windows側の設定でアプリ毎に別の入力ソースを使える設定にしておくと良い。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50302162071/in/datetaken-public/" title="Input source setting"><img src="https://live.staticflickr.com/65535/50302162071_e2d19dd440_o.png" width="735" height="637" alt="Input source setting"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

↑のチェックボックスのところ。
こんなかんじでいろいろやると、Windows上でも違和感なくLinuxアプリが使える。いろいろやっていることが(当たり前だが)完全にLinuxでやってたことと同じなので、Linuxデスクトップを使っている人は自然に使えるはず。
あとやっぱウィンドウマネージャさえなんとかなればな〜〜という感じがいなめない。bug.nにはだいぶなれてサクサクつかえるようになってきたものの、やはりawesomeとちがって、
<ul>
<li>Emacs + Chrome</li>
<li>Emacs + Terminal</li>
<li>Terminal + Chrome</li>
<li>Terminal + Emacs</li>
</ul>

みたいな組み合せを瞬時に変えられないのがめんどくさい。いや、できることはできるのだが、そのためにはそのように設定したwindow(tag)を作っておく必要がある。
awesomeの場合はTerminalをtag0で、Emacsをtag1で、Chromeをtag2で出すようにしておいて、side-by-side表示したいときにはtag0&amp;1を表示する、みたいにtagをくみあわせて画面をつくれるのが良いのだ。
ここさえなんとかなればWindows上でもかなり快適にすごせそうなので、がんばって自作してみるのも手かもなぁと考えはじめている。
あとは、ArchWSL/ArchWSL2の作者には足を向けて寝られない。どちらもとてもよくカスタマイズされていて、Archをこういう環境<a class="footref" href="#fn2" id="r2">[2]</a>にいれて使うときにハマるポイントがほぼつぶされていて、とても快適に使える。ありがたい。
<aside class="footdef">
<a href="#r1">[1]</a> それがデフォルトっぽい 
<a href="#r2">[2]</a> たとえばTermuxArchとか使うとよくわかる。(TermuxはandroidでWSL1みたいなことをする環境) 
</aside>

WSL上のGUIアプリケーションの設定いろいろ、SandSとかキーリピート加速とか

WSLで動くLinuxとクリップボードを共有する方法は僕が知るかぎりでも、
<ol>
<li>clip.exeを使う</li>
<li>X Window Serverを経由する</li>
</ol>

などがある。自分はGUIアプリを使うこともあるので、もともとX Serverを立てているということもあり、汎用性が高い2のほうを使っている。
実際、
<pre><code class="sh"># copy
cat foo.txt | xsel -bi

# paste
xsel -bo &gt; foo.txt</code></pre>

というような操作はLinuxを使う時と一緒なので覚えやすい。自分はtmuxでcopyすると自動でXのクリップボードにもcopyされるという設定をもともと使っているので、それがそのまま使えるというのもありがたい。
ただ、このXのクリップボードをWindows側と共有してくれるには、それに対応したX Window Serverを使う必要がある。
自分は X410 というのを使っている。<a class="footref" href="#fn1" id="r1">[1]</a>
WSL上のLinuxとWindowsクリップボードの共有に関してはこのXを使う方法でほぼ問題ない。やることは、
<ul>
<li>Windows側でX Serverをあげておく</li>
<li>Linux側でDISPLAY環境変数にその情報を入れておく<a class="footref" href="#fn2" id="r2">[2]</a></li>
</ul>

だけ。
GUIでEmacsを使っていればこれだけで良いのだが、今はbug.nの操作に慣れていないということもあり、CLI上でEmacsを使っていて、そちらでも自動でXのクリップボードが同期されてくれるとうれしい。
ググると<a href="https://stackoverflow.com/a/21833639">stackoverflowにxselを使った良い設定を書いている人がいた</a>ので、それをそのまま拝借して以下の設定を追加:
<pre><code class="lisp-interaction">;; sync with x clipboard
(unless window-system
 (when (getenv "DISPLAY")
 ;; Callback for when user cuts
 (defun xsel-cut-function (text &amp;optional push)
 ;; Insert text to temp-buffer, and "send" content to xsel stdin
 (with-temp-buffer
 (insert text)
 ;; I prefer using the "clipboard" selection (the one the
 ;; typically is used by c-c/c-v) before the primary selection
 ;; (that uses mouse-select/middle-button-click)
 (call-process-region (point-min) (point-max) "xsel" nil 0 nil "--clipboard" "--input")))
 ;; Call back for when user pastes
 (defun xsel-paste-function()
 ;; Find out what is current selection by xsel. If it is different
 ;; from the top of the kill-ring (car kill-ring), then return
 ;; it. Else, nil is returned, so whatever is in the top of the
 ;; kill-ring will be used.
 (let ((xsel-output (shell-command-to-string "xsel --clipboard --output")))
 (unless (string= (car kill-ring) xsel-output)
 xsel-output )))
 ;; Attach callbacks to hooks
 (setq interprogram-cut-function 'xsel-cut-function)
 (setq interprogram-paste-function 'xsel-paste-function)
 ;; Idea from
 ;; http://shreevatsa.wordpress.com/2006/10/22/emacs-copypaste-and-x/
 ;; http://www.mail-archive.com/help-gnu-emacs@gnu.org/msg03577.html
 ))</code></pre>

これでかなり便利に。bug.nに慣れたらGUI版に戻そうとおもっていたが、このままでもいいかもなぁと思いはじめている。
<aside class="footdef">
<a href="#r1">[1]</a> よくセールしてるから定価で買うと損らしいので注意w ref: <a href="https://twitter.com/typester/status/1273708353202446336">https://twitter.com/typester/status/1273708353202446336</a>のコメント
<a href="#r2">[2]</a> WSL1では <code>127.0.0.1:0</code> 、WSL2では <code>$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0</code> を入れている
</aside>

WSL上のEmacs(nw)とWindowsとでクリップボードを共有する方法

最近(といっても半年くらいたってる気がするが)、<a href="https://www.notion.so/">Notion</a>から<a href="https://orgmode.org/">org-mode</a>へドキュメント管理を戻している。
NotionはUS移住前から使っているので、2年以上使っていたことになる。もともとorg-modeを完全に置き換える形で、
<ul>
<li>タスク・習慣管理</li>
<li>メモ</li>
<li>ブックマーク</li>
<li>ゲーム・読書・映画記録</li>
<li>家族とのドキュメント共有</li>
</ul>

などかなりガチで使うようになっていたのだが、根本的な文章の書き味がEmacs上でやるのと比べ致命的に悪いという問題があった。
また、<a href="https://roamresearch.com/">Roam Research</a>とか<a href="https://obsidian.md/">Obsidian</a>のようなブレインマップを構築するようなノートアプリがいろいろ出てきているのも気になっていた。Notionでそういうことをするのはなかなか難しそうに思う。
そんな中で、org-modeでRoam Researchみたいなことをする<a href="https://www.orgroam.com/">org-roam</a>というものを知って、しばらく試していたのだが、なかなか良さそうなので本格的にorgに戻ってきている。
いまのところ、
<ul>
<li>タスク・習慣管理</li>
<li>メモ</li>
<li>ブックマーク</li>
</ul>

はEmacs上でおこなうように戻した。Notion上にあるものはまだ特にimportしたりはしていない。こういうのは最初から完璧を求めないで、徐々に気がむいたときにアップグレードするくらいじゃないと疲れてしまうし、完璧を目指すと破綻しやすいということが長年の経験で分かっているのである。(大人になったものだ)
ただ、orgの弱点はやはりモバイル環境だ。いまのところ、スマホしかないところでのメモやブックマークは現状いったんスマホ上に貯めておいて、適当なタイミングでorgのほうで手動で移している。これはそのうちもうちょい改善したいが、Notionのようにはなかなかいかないだろう。
そういうこともあって家族との共有は今後もNotionでいいかなと感じている。
ただ、やはり個人用のタスク管理+情報集約ツールとして、orgはやっぱりいいなぁと思う。org-roamはいまのところはまだ情報が少ないのであまりうれしさを感じないが、Zettelkasten Method的な情報管理には興味があるし、ゆっくり学んでいきたい。
それで、ブックマークに関してがこのエントリの本題なのだが、ブラウザとかからダイレクトにorgに記事を差し込めるorg-protocolという仕組みがあるけど、setupがかなり面倒なのでいままでは<a href="https://github.com/rexim/org-cliplink">org-cliplink</a>を使用して半手動で行なっていた。で、今回その重い腰をあげてorg-protocolをsetupしましたよ、という話。
ただでさえめんどそうなorg-protocolの設定が、WSL上でEmacsを使っているとよりめんどうになる。さらに自分の場合は<a href="https://github.com/sorah/subsystemctl">subsystemd</a>を使ってsystemdを動かしているので、さらにちょっとした修正が必要になった。
この環境でorg-protocolを使うには以下のようなregistryファイルを作って、取り込んでやればOK。すると、 <code>org://</code> をWSL上(&amp; subsystemd上)のemacsでリンクを受け取ることができるようになる。
<pre><code class="text">REGEDIT4

[HKEY_CLASSES_ROOT\org-protocol]
@="URL:Org Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\org-protocol\shell]
[HKEY_CLASSES_ROOT\org-protocol\shell\open]
[HKEY_CLASSES_ROOT\org-protocol\shell\open\command]
@="\"C:\\Windows\\System32\\wsl.exe\" -u typester -d ArchLinux subsystemctl exec emacsclient -- -s /run/user/1000/emacs/server \"%1\""</code></pre>

まぁ全く同じ環境の人はほとんどいないとおもうので、個人的な備忘録として残しておく。
あとは適当にbookmarkletをブラウザにセットすれば完了。ほんとはホットキーでブックマークしたいので、そのうち調べる。

Notionからorg-modeへの出戻りと、WSL上でのorg-protocol

Windows上でAndroidアプリを開発するとき、普通の人、というかWindowsに慣れている人は、普通にWindows上で開発すればいい案件なのだが、自分にとってはLinuxの世界で開発できたほうがいろいろ都合がよいので、WSL2上で開発をしている。
Android Studioや、<a href="https://github.com/jhen0409/react-native-debugger">react-native-debugger</a>といったツールたちは、WSL2+X Server (X410) という環境でも問題なく動く。
しかし問題はAndroidエミュレータを、WSL2上でうごかすことが現状ではできないのだ。<a class="footref" href="#fn1" id="r1">[1]</a>
それで、いままでうまい方法がよくわからなかったので、WSL2上でつくったapkを、Windowsのほうのadbで <code>adb install</code> して実機なりエミュレータにいれる、というかなりめんどくさいことをしていた。
ただ、通常ほとんどの開発がReact Nativeでのものだったため、ネイティブのほうの実装を変更することはあまりなく、一度apkを実機orエミュレータにインストールさえしてしまえばapkを入れなおす必要はないので、あまり問題にはなっていなかった。
ただ最近はReact Nativeばかり書いていて、何年もネイティブ開発をしていないという状況がつづいてしまっているので、ネイティブのほうのキャッチアップもしておかないとな〜という気持ちがたかまってきていて、Holiday projectとしていま仕事で書いてるわりとでかめのアプリをネイティブで再実装する、というのをはじめていて、そうなるってくるとこのいびつな開発環境だとつらすぎるので、ようやく重い腰をあげて、なにか良い方法はないかしらべはじめた。

<h3>TL;DR:</h3>
Windowsの <code>5037</code> ポートをWSL2へreverse port forward。(WLS2上で 127.0.0.1:5037 がWindowsの5037につながるように、という意味)

<h3>前準備</h3>
Windowsのほうにもadbが必要なのでAndroid Studioをいれておく。どのみちエミュレータをそっちで動かすので入れるとは思うが。

<h3>ポートフォワード</h3>
adbのhelpコマンドを良くみてみると
<pre><code class="text">-H name of adb server host [default=localhost]
-P port of adb server [default=5037]</code></pre>

という部分があって、他のホストのadb serverを使えそうな記述がある。しかし、adbは <code>127.0.0.1:5037</code> にbindしてしまうので、実質そのままでは他のホストにつなぐことはできない。<a class="footref" href="#fn2" id="r2">[2]</a>
なのでポートフォワードしてみることにした。方法はいろいろあるが、自分の場合はWSL1の環境もあるので、WSL1から
<pre><code class="sh">ssh -R 5037:127.0.0.1:5037 127.0.0.1</code></pre>

としている。127.0.0.1に接続していてなんのこっちゃという感じだが、Windowsホストの22番ポートはWSL2ホストにforwardされるようにしているのでこれでWSL2につながるのである。そうしてない人は接続先をWSL2のアドレスにする必要あり。
あと、これをする前にWSL2上でadb serverがうごいている場合はあらかじめ <code>adb kill-server</code> しておく、またWindowsのほうでは <code>adb start-server</code> しておく必要がある。<a class="footref" href="#fn3" id="r3">[3]</a>
この状態で、WSL2上で <code>adb devices</code> とかしてみると、Windowsのほうに繋っているエミュレータや実機が普通に見えるようになっているはず。adb shellや、adb installなどもWindowsから操作するのとおなじことがWSL2からおこなえるようになる。便利!
いままでこの環境だとうまく使えなかった<a href="https://fbflipper.com/">Flipper</a>もちゃんと(WSL2サイドで)動くようになってうれしいかぎり。

<h3>余談</h3>
とまぁ、最終的には実際5037を転送するだけでよかったのだが、最初はリモートのAndroidエミュレータに繋ぐ方法、みたいな検索ワードで調べていたのでまったく答えにたどりつけず、ハマりにハマってかなりの時間をとかしてしまった。あと、Flipperを起動するとadb serverが自動で起動されてしまうことに気付かず、 <code>kill-server</code> してるのになぜか終了できない!(pidがかわってうまれかわってくる)、みたいになってWSL2上のadb serverがとめられなくなったりもした。pstreeでみてみてもsystemdが親にみえるため、Flipperが原因だとはなかなか気が付けなかった。
とはいえ最終的につかえるようになったので、時間をかけたうえに「なんの成果も!! 得られませんでした!!」となる最悪の自体はさけられたのでよしとしよう。
<aside class="footdef">
<a href="#r1">[1]</a> intel CPUの人はできるかもしれない。AMDのCPUではまだ<a href="https://techcommunity.microsoft.com/t5/virtualization/amd-nested-virtualization-support/ba-p/1434841">nested virtualizationが一般向けには降りてきていない</a>ので使えないっぽい 
<a href="#r2">[2]</a> <code>-a</code> というオプションが <code>listen on all network interfaces, not just localhost</code> と書いてあるけどこれつけて <code>start-server</code> しても127.0.0.1にbindされていた😅
<a href="#r3">[3]</a> たぶんデフォルトの状態だとAndroidエミュレータを起動するだけでadb serverもたちあがるようになってるので実際はwindowsのほうで明示的にadb serverを上げることはあまりないかもしれない 
</aside>

WSL2のadbからWindowsのAndroid Emulatorを使う

WSL1/2環境として<a href="https://github.com/yuk7/ArchWSL">ArchWSL</a>を愛用してきたけど、そろそろ自分でWSLイメージを作ってみたいな。という思いがあり、<a href="https://docs.microsoft.com/en-us/windows/wsl/build-custom-distro">公式ページのドキュメント</a>に従って自分のイメージを作ってみようとしたのだが、いかんせん、Visual Studioの知識がなさすぎて、Distro Launcherのビルドすらままならない😭
Visual Studio 2019、installできるcomponentの選択肢が多過ぎてなにが必要なのか、とかが全然わからない。まじで難しいなぁ。ビルドしようとするときに足りてなかったら教えてくれる、とかそういう心づかいが欲しい…。
それでしばらく調べてみたら、Distro Launcherを使わずにイメージを作ってる人を発見:
<blockquote>
<a href="https://www.spatacoli.com/blog/2020/03/custom-wsl-image/">Custom WSL Image - Spatacoli</a>
</blockquote>

なんだ、 <code>wsl --import</code> なんていう方法もあるんだ。しかも、dockerイメージからファイルをとってきていて賢い。
ArchLinuxのdockerイメージはArchLinux公式がメンテしてるから安心だし。
そんなわけで作ってみた。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50889660557/in/datetaken-public/" title="ArchLinux on WSL2"><img src="https://live.staticflickr.com/65535/50889660557_53c71f182b_b.jpg" width="1024" height="590" alt="ArchLinux on WSL2"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

イメージ作成手順はリンク先の通りだから割愛。
Distro Launcherを使っていないイメージの場合、デフォルトユーザーをregistryに保存したりということができないので、 <code>wsl -u typester</code> のように毎回ユーザーを指定する必要があるが、Windows Terminalの設定にそれを書いてしまえば意識しないですむのでまったく問題ない。
あと、この記事でWindows Terminalの設定でタブバーのiconを自由に変更できるのを知ったので、真似してArchLinuxのアイコンにしてみたところなかなか満足度がたかくなった。おすすめ。
以下追加で作業したこと。

<h3>systemd (WSL2)</h3>
systemdはArchWSLのドキュメントからもリンクされているが、 <a href="https://github.com/sorah/subsystemctl">https://github.com/sorah/subsystemctl</a> を使うと簡単。
Windows Terminalを起動後、
<pre><code class="shell-script">sudo -E subsystemctl start
subsystemctl shell</code></pre>

というおまじないをしてる。Distro Launcher方式なら起動時に自動で実行されるようにできるかもだが、いまのままでも基本一度立ち上げたらずっと立ち上げっぱなしなのであまり問題ではない。

<h3>fakeroot-tcp (WSL1)</h3>
ArchLinuxはpackageの作成にfakerootという仕組みをつかうのだが、これがWSL1だと動かないので、代わりに<a href="https://aur.archlinux.org/packages/fakeroot-tcp/">fakeroot-tcp</a>というのを使う必要がある。
これは必須というわけではないが、なにかAURのパッケージを使う予定があるなら必要になる。
しかし、普通にAURでfakeroot-tcpパッケージを作ろうとするとそれにfakerootが必要で詰む。ので、一旦 <code>makepkg</code> でfakeroot-tcpのパッケージをつくるのはやめて、
<ol>
<li>一時的にどこかあとで消せるところに普通に自前でmakeして入れる<a class="footref" href="#fn1" id="r1">[1]</a></li>
<li>そこにパスを通すか <code>/usr/sbin/fakeroot</code> をそこへのsymlinkに置き換える</li>
<li>これでfakerootできるようになるので、あらためて <code>makepkg -si</code> して入れ直す</li>
<li>一時的にいれてたのを消す</li>
</ol>

みたいな感じでやる必要があってめんどくさい。このらへんの作業は<a href="https://github.com/TermuxArch/TermuxArch">TermuxArch</a>と同じなので自分的には慣れてしまっているが、最初はかなり苦労した覚えがある😅
あとはほんとに普通に使える。先人の知恵に感謝。
<aside class="footdef">
<a href="#r1">[1]</a> ビルド方法はPKGBUILDみれば分かる。prefixだけ変える感じで。 
</aside>

2021

2020