緩怠 Log

fuzzy note次郎

RDP 接続でパイプが打てない問題を zsh のグローバルエイリアスで解決する

zsh RDP jots

リモートデスクトップ（RDP）経由で Linux 環境を操作していると、キーボードレイアウトの都合でパイプ (|; vertical bar) を入力したつもりが、破断線 (¦; broken bar) として入力されてしまう問題に遭遇した。

根本的には OS 側の設定やクライアントの設定によって解決すべき問題だが、今回は zsh のグローバルエイリアスを利用した．以下で紹介する：

zsh のグローバルエイリアスとは

zsh やその他シェルにおける通常のエイリアスがコマンド部分の置換しかできないのに対し、zsh のグローバルエイリアスはコマンドライン上の任意のトークンをエイリアスとして展開する。

つまり、パイプ記号のようなトークンであっても任意の文字列から展開できる。

zsh.sourceforge.io

方法

通常のエイリアスと同様に定義するが、 -g オプションを付与することでグローバルエイリアスとなる。

# 破断縦線 (¦) を通常のパイプ (|) で置換する
alias -g ¦='|'

設定後は次のようになる：

# 入力（RDP 経由で ¦ が入力されてしまう）
$ echo 'test' ¦ wc -c

# 実際に展開・実行されるコマンド
$ echo 'test' | wc -c

リスク

通常のエイリアス同様、この機能を利用したコマンドは環境依存のコマンドになる。

（当たり前だが）自分の環境以外では動作しないコマンドを仕込むリスクはあるので、シェルスクリプトを書く際や、実行したコマンドを外部にコピペして共有する可能性がある環境ではあまり多用すべきではないと言える。

あとがき（背景）

現在、Proxmox 上に構築した Ubuntu VM をコーディングエージェント用の作業環境として運用している。この環境への接続には SSH のほか、Windows App（旧リモートデスクトップ接続）を利用している。

リモートデスクトップ接続中にパイプ (|) を打つと、すべて破断線 (¦) として入力されてしまう問題に遭遇したのが問題の発端。

解決にあたっては、まず以下の方法を試行した：

  1. RDP クライアント側の設定変更: Windows App の Keyboard Mode を Scancode から Unicode に変更することでパイプ自体は入力可能になった。しかし、今度は IME の変換キー入力が正しく認識されなくなる別の問題が発生した。
  2. Ubuntu VM 上でのリマッピング: いくつかのキーボードリマッピングツールを試した。（keyd, input-remapper など）しかし、仮想化環境のハードウェア設定が噛み合っていないのか、入力イベントを正しく捕捉できず解決には至らなかった。

キーボード自体や仮想化の設定を突き詰めれば根本解決は可能だろうが、パイプ以外の入力では特に困っていない。深追いを避けるべく、今回は zsh の機能を利用して入力を吸収することにした。

本文での記載の通り環境依存のリスクはあるが、そもそもこの環境はコーディングエージェントがメインで動作する場所であり、自分自身の入力さえ通れば問題ない。このような経緯から今回の解決策に落ち着いた。

Codex IDE の表示言語を設定する

jots

背景

いつものように Codex IDE を利用しようとしたら、 UI の表示言語が日本語になっていた。 おそらく i18n 対応が追加された結果日本語環境と判断されたものと思われる。

個人的には英語 UI の方が慣れていて好ましいので UI の言語を設定する方法を調べた。

方法

Codex の設定ファイル（config.toml）ではなく、拡張機能の設定（settings.json）を編集することで UI として表示される言語のロケールを設定できる。

デフォルトでは自動検出となるらしい。

chatgpt.localeOverride: Preferred language for the Codex UI. Leave empty to detect automatically.

developers.openai.com

どんな値が使えるのかドキュメントに記載がなくてよくわからないが、 とりあえず"en" を設定したら英語になった。解決。

{
    "chatgpt.localeOverride": "en"
}

あとがき

Codex IDE の設定キーの prefix が chatgpt なの知らなかった。 拡張機能の Identifier も openai.chatgptらしい。

Prettier の設定読み込みの変遷（2025年12月）

Prettier 考古学

背景

  • LLM や一部の記事で、 Prettier の config 解決は cosmiconfig というライブラリを利用しているという情報が出てくることがある
  • かつてのドキュメントにはそう書かれていたらしいが、現在のドキュメントでは見当たらない
  • 実際に現在（v3.7.3）のコードを読んでみると自前で頑張ってそうな感じがする
  • ということで、いつから何がどうなったのか調べてみる

タイムライン

まとめ

  • Prettier リリースから実に6年ほどの期間、 cosmiconfig が利用されていた
  • その間もだんだんと独自処理が増えており、 2023年11月（v3.1.0）には cosmiconfig からより軽量な lilconfig へ移行した
  • lilconfig 移行から実に1か月で lilconfig も消え、自前の実装になった（v3.1.1）
  • 現在では cosmiconfig への依存は無く、挙動としては cosmiconfig 時代のものが残っているという理解で良さそう

あとがき

Antigravity 経由の Gemini 3 Pro (high) に投げたら調べてくれました。基本的には git コマンドを駆使しつつ特定していたので見ていて面白かったです。

Language Server における設定値周りのライフサイクルについて検討する

biome Language Server LSP

Language Server を提供する場合、その動作を左右する設定値は一般的に2種類存在する

  1. VS Code が管理する設定
  2. ツール固有の設定ファイルに記された設定

Language Server はこれらの設定値をそれぞれ a. サーバ起動時 および b. 設定値変更時 の2種類のタイミングで知る必要がある。 以下では設定の種類とライフサイクルごとに必要な処理をまとめる。

※なお、ここでは Biome および biome-vscode を参考にした内容を記す

1. VS Code が持つ設定

VS Code 本体の設定あるいは VS Code Extension が持つ設定など、VS Code の settings.json から制御できる設定のこと。 ここでは VS Code を念頭に置いているが、任意のエディタおよびクライアントに読み替えて良いはずである。

a. 起動時

workspace/configuration を利用する

  • サーバは起動後に workspace/configuration をリクエストし、設定値を受け取る
    • scope_uri と section を params として送ることで、 現在のワークスペースに適用されている、目的の拡張機能の設定値を知ることができる
    • initializeRequest 受け取り時に rootUri を受け取っていれば scope_uri として利用できる
  • 参考
  • （VS Code Extension の）クライアントがやること
    • 起動時に URI を渡す
    • 設定値は vscode-languageclient が自動返却する

b. 設定値変更時

workspace/didChangeConfiguration にて変更された設定値を受け取り、サーバ側で保持している設定に反映する または、 workspace/didChangeConfiguration を変更通知としてのみ扱い、 workspace/configuration で設定値を取得する

  • エディタ側で設定変更がなされた場合、 workspace/didChangeConfiguration がエディタから送信される
    • ペイロードには変更された設定が入っているため、これを元に設定を組み立て直してもよい
  • 一方 workspace/didChangeConfiguration自体はLSP標準の通知なので、目的外の設定が混ざる可能性もある
    • Biome ではこの通知を受け取ったらペイロードは解釈せず捨てて、workspace/configuration をリクエストすることで変更された設定値を取得している
    • 変更通知の用途のみに利用
  • 参考
  • （VS Code Extension の）クライアントがやること
    • なし（vscode-languageclient が対応）
    • 当該 Extension に属する設定変更を検知したらサーバを強制的に再起動する手もある（Biome がそう）
      • もちろんサーバ側はこの動作に依存するべきではなく、設定変更処理を実装しているべき（クライアントは一つとは限らないため）

2. ツール固有の設定ファイルに記された設定

エディタが特別視しない、ツール固有のファイルに記された設定のこと。 CLI が読み込む設定値と捉えても良い。 Biome なら biome.json などが該当。

a. 起動時

すべきことは2つ

  1. サーバが設定ファイルをファイルシステムから探索して保持する
  2. 設定ファイルのパスを登録する

具体的には：

  • 規定のパスを持つファイルと、それ以外で明示的に設定されたファイル（カスタムパス）を監視対象にして、変更時の通知を受け取れるようにする
    • 具体的には registerCapability で workspace/didChangeWatchedFiles を登録する
    • Biome は Extension 側で設定されたカスタムパスは監視対象にしない。クライアント側が VS Code の設定変更時にサーバを強制的に再起動するという挙動に依存している
  • 参考
  • （VS Code Extension の）クライアントがやること
    • なし（vscode-languageclient が対応）

b. 設定値変更時

workspace/didChangeWatchedFiles によってクライアントから変更通知を受け取る

  • クライアントが監視対象のファイルが変更されたことを通知する
    • ファイルのURIと、そのファイルがどうなったか（created, changed, deleted）が params として送られる
  • VS Code 側の設定取得とファイル再探索をして、サーバ側で保持している設定を更新する
  • ファイル監視はサーバ側でやっても良いが推奨されていない
    • エディタに任せるのが実装コスト的にも複雑さの面でも好ましい
  • 参考
  • （VS Code Extension の）クライアントがやること
    • なし（vscode-languageclient が対応）

あとがき

めちゃくちゃ雑にまとめた。　エディタの設定・ツール固有の設定ともに、設定値の変更監視はエディタ側に委譲できることがわかったのは良い収穫でした。

Rust 製 Language Server 実装におけるライブラリ選定（2025年10月）

rust Language Server

Rust で Language Server を実装する際の選択肢について調査した。

TL;DR

  • 基本的には tower-lsp-server でよい
  • 自分でサーバ周りを実装する場合は lsp-types だけ使っても便利

候補の洗い出し

まずはそれなりに使われていそうなライブラリを列挙する

補足： tower-lsp と tower-lsp-server について

tower-lsp は現在アクティブな開発が行われていない。現時点の最終コミットも2年近く前（2024年1月）になっている。そのため tower-lsp-server という名称の community fork が作成されており、Biome や Oxc を含むほとんどのアクティブなツールはそちらに移行している。

GitHub から追えた経緯を簡単に書いておく：

観測範囲のツールにおける利用例

tower-lsp または tower-lsp-server の利用例が多い。それ以外では lsp-types のみ利用してサーバは自分で書く例がちらほらある

結論

以上の内容から、選定するなら以下の感じになりそう

  1. tower-lsp-community/tower-lsp-server
  2. gluon-lang/lsp-types
    • 十分な使用実績がある（さまざまなライブラリや LS 実装に使われている）
    • サーバ部分を自分で実装する場合でも、In/Out 部分だけはこのライブラリを使うケースが多い
    • 参考になりそうな実装

lsp-server は （rust-analyzer 以外の）有名どころではあまり使われていなさそうだったので一旦見送った。あまり調べていないというのが正直なところ。

async-lsp については現時点だと利用例が少なそうということでこちらも今回は見送った。

参考

この記事は以下の私の Cosense への投稿をまとめたものです：

VS Code の Markdown Preview で Mermaid コードブロックを図としてレンダリングする

Mermaid VS Code Extension VS Code

2026-06-20 追記： VS Code 1.121 （2026-05-20）から、VS Code 本体に ビルトインの Mermaid サポート が追加されました。

Markdown Preview で Mermaid Diagram をレンダリングしたいだけであれば、この記事で紹介している拡張機能をインストールする必要はなくなりました。

追記終わり

GitHub では mermaid という Language tag のコードブロックを書くと、それが Mermaid の図としてレンダリングされる機能がある。

一方で VS Code の Markdown Preview についてはその限りではなく、 コードブロックに mermaid タグをつけようが、それは単なるコードブロックとして表示される。エディタでドキュメントを読むとき、 Markdown Preview でも GitHub と同じように勝手にレンダリングされるようにしたかったので方法を調べた。

方法

拡張機能をインストールする。選択肢に挙げられそうなものは次に示す2つ。

インストールさえすれば Markdown Preview にて自動で Mermaid コードブロックが図としてレンダリングされる点はどちらも同じである。

  1. Mermaid Chart
  2. Markdown Preview Mermaid Support

1. Mermaid Chart

marketplace.visualstudio.com

Mermaid 公式が出している拡張機能。 ここでの目的である Mermaid レンダリング以外にもさまざまな機能があり、編集などもVS Code 上で完結できるようになっている。

便利そうなのは何よりだが、Mermaid を書きたいわけではない場合は豊富な機能がノイズに感じるかもしれない。

また 2023 年リリースと比較的新しめなのもあり、次に述べる Markdown Preview Mermaid Support (2017 リリース) にダウンロード数で大きく差をつけられている。Marketplace や 拡張機能タブで mermaid と検索してもトップには表示されない。

2. Markdown Preview Mermaid Support

marketplace.visualstudio.com

Markdown Preview に Mermaid をレンダリングするだけというシンプルな拡張機能。 Marketplace や 拡張機能タブで mermaid と検索するとトップに表示され、ダウンロード数も圧倒的である。 Mermaid Chart が出る前はみんなこれを使っていたんだろうなという感じがする。

特に公式が絡んでいるわけでもなく個人が作ったプロジェクトと思われる。

あとがき

今回は Mermaid 本家のコミュニティが出しているやつ入れた方がいいやろという判断で Mermaid Chart を入れたが、Mermaid を編集するわけではなかったのでいらない機能が多いなと思ってしまった。正直、コードブロックの自動レンダリングくらいの機能は VS Code 本体に入ってほしい。 （追記： v1.121 から VS Code 本体に追加されました🎉）

Google Slides 内の画像を保存する裏技

Google Slides

Google Slides 上の画像は、右クリック・ダウンロードみたいな正攻法っぽい方法では保存ができない（2025-10-10 時点）。

どうやら画像もスライド上のオブジェクトとして扱われている都合上、ブラウザ視点でもクリップボード上でも画像扱いではないらしい。よってダウンロードもできないし、画像としてコピーすることもできない。

方法

これを回避する方法はいくつかあるが、自分が多用しているものを書いておく。Google Keep を使う方法である：

  1. 画像を右クリックする
  2. 選択肢の一番下あたりに「keep で保存」が出てくるのでこれを選択
  3. Google Keep にアクセスする

すると、Google Keep に作成されたメモから画像をダウンロードできる

あとがき

Google Slides は気に入って使っているので、こういう細かいところで時間を奪われたくないなと思って記しておくことにした。 このブログはこういう不毛な裏技の行き場として用意したブログだったので活躍の場があって嬉しい。