feat(nuldoc): Djot to Markdown

7 files changed, 50 insertions, 91 deletions

diff --git a/services/nuldoc/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.dj b/services/nuldoc/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.md
index 953b936..5766ce7 100644
--- a/services/nuldoc/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.dj
+++ b/services/nuldoc/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.md
@@ -12,7 +12,7 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/94090937bcf860cfa93b
 :::
diff --git a/services/nuldoc/content/posts/2021-10-02/python-unbound-local-error.dj b/services/nuldoc/content/posts/2021-10-02/python-unbound-local-error.md
index 88d0315..1699b45 100644
--- a/services/nuldoc/content/posts/2021-10-02/python-unbound-local-error.dj
+++ b/services/nuldoc/content/posts/2021-10-02/python-unbound-local-error.md
@@ -12,7 +12,7 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/5d733703afcb35bbf399
 :::
diff --git a/services/nuldoc/content/posts/2021-10-02/ruby-detect-running-implementation.dj b/services/nuldoc/content/posts/2021-10-02/ruby-detect-running-implementation.md
index 653b7dc..fd72102 100644
--- a/services/nuldoc/content/posts/2021-10-02/ruby-detect-running-implementation.dj
+++ b/services/nuldoc/content/posts/2021-10-02/ruby-detect-running-implementation.md
@@ -11,7 +11,7 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791
 :::
@@ -65,8 +65,7 @@ CRuby) については執筆時現在 (2020/12/8) も `'ruby'`
 
 [mruby 該当部分のソース](https://github.com/mruby/mruby/blob/ed29d74bfd95362eaeb946fcf7e865d80346b62b/include/mruby/version.h#L32-L35) より引用:
 
-{filename="version.h"}
-```c
+```c filename="version.h"
 /*
  * Ruby engine.
  */
diff --git a/services/nuldoc/content/posts/2021-10-02/ruby-then-keyword-and-case-in.dj b/services/nuldoc/content/posts/2021-10-02/ruby-then-keyword-and-case-in.md
index 82d6d9c..ea9526b 100644
--- a/services/nuldoc/content/posts/2021-10-02/ruby-then-keyword-and-case-in.dj
+++ b/services/nuldoc/content/posts/2021-10-02/ruby-then-keyword-and-case-in.md
@@ -12,19 +12,17 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/787a8cf888a304497223
 :::
 
-{#tl-dr}
-# TL; DR
+# TL; DR {#tl-dr}
 
 `case` - `in` によるパターンマッチング構文でも、`case` - `when`
 と同じように `then` が使える (場合によっては使う必要がある)。
 
-{#what-is-then-keyword}
-# `then` とは
+# `then` とは {#what-is-then-keyword}
 
 使われることは稀だが、Ruby では `then`
 がキーワードになっている。次のように使う:
@@ -64,8 +62,7 @@ when p then
 end
 ```
 
-{#why-then-is-usually-unnecessary}
-# なぜ普段は書かなくてもよいのか
+# なぜ普段は書かなくてもよいのか {#why-then-is-usually-unnecessary}
 
 普通 Ruby のコードで `then`
 を書くことはない。なぜか。次のコードを実行してみるとわかる。
@@ -97,8 +94,7 @@ puts 'Hello, World!' end
 
 無事 Hello, World! と出力されるようになった。
 
-{#why-then-or-linebreak-is-needed}
-# なぜ `then` や `;` や改行が必要か
+# なぜ `then` や `;` や改行が必要か {#why-then-or-linebreak-is-needed}
 
 なぜ `then` や `;` や改行 (以下 「`then` 等」)
 が必要なのだろうか。次の例を見てほしい:
@@ -132,8 +128,7 @@ end
 Ruby の場合、プログラマーが書きやすいよう改行でもって `then`
 が代用できるので、ほとんどの場合 `then` は必要ない。
 
-{#then-in-case-in}
-# `case` - `in` における `then`
+# `case` - `in` における `then` {#then-in-case-in}
 
 ようやく本題にたどり着いた。来る Ruby 3.0 では `case` と `in`
 キーワードを使ったパターンマッチングの構文が入る予定である。この構文でもパターン部との区切りとして
@@ -143,8 +138,7 @@ Ruby の場合、プログラマーが書きやすいよう改行でもって `t
 
 https://github.com/ruby/ruby/blob/221ca0f8281d39f0dfdfe13b2448875384bbf735/parse.y#L3961-L3986
 
-{filename="parse.y"}
-```yacc
+```yacc filename="parse.y"
 p_case_body : keyword_in
 {
   SET_LEX_STATE(EXPR_BEG|EXPR_LABEL);
@@ -222,12 +216,9 @@ in n then c
 end
 ```
 
-{#outro}
-# まとめ
+# まとめ {#outro}
 
 * `if` や `case` の条件の後ろには `then`、`;`、改行のいずれかが必要
-
   * 通常は改行しておけばよい
-
 * 3.0 で入る予定の `case` - `in` でも `then` 等が必要になる
 * Ruby の構文を正確に知るには (現状) `parse.y` を直接読めばよい
diff --git a/services/nuldoc/content/posts/2021-10-02/rust-where-are-primitive-types-from.dj b/services/nuldoc/content/posts/2021-10-02/rust-where-are-primitive-types-from.md
index 9fa61d5..ab7345e 100644
--- a/services/nuldoc/content/posts/2021-10-02/rust-where-are-primitive-types-from.dj
+++ b/services/nuldoc/content/posts/2021-10-02/rust-where-are-primitive-types-from.md
@@ -11,13 +11,12 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/9a429432258bbcd6c565
 :::
 
-{#intro}
-# 前置き
+# 前置き {#intro}
 
 Rust
 において、プリミティブ型の名前は予約語でない。したがって、次のコードは合法である。
@@ -48,11 +47,10 @@ struct str;
 では、普段単に `bool` と書いたとき、この `bool`
 は一体どこから来ているのか。rustc のソースを追ってみた。
 
-        前提知識: 一般的なコンパイラの構造、用語。`rustc` そのものの知識は不要
-        (というよりも筆者自身がよく知らない)
+前提知識: 一般的なコンパイラの構造、用語。`rustc` そのものの知識は不要
+(というよりも筆者自身がよく知らない)
 
-{#code-reading}
-# 調査
+# 調査 {#code-reading}
 
 調査に使用したソース (調査時点での最新 master)
 
@@ -96,8 +94,7 @@ rustc_resolve/src/lib.rs:        table.insert(sym::i128, Int(IntTy::I128));
 `rustc_resolve`
 というのはいかにも名前解決を担いそうなクレート名である。該当箇所を見てみる。
 
-{filename="rustc_resolve/src/lib.rs"}
-```rust
+```rust filename="rustc_resolve/src/lib.rs"
 /// Interns the names of the primitive types.
 ///
 /// All other types are defined somewhere and possibly imported, but the primitive ones need
@@ -199,8 +196,7 @@ fn main() {
 として解決される。なぜなら、プリミティブ型の判定をする前に `bool`
 という名前の別の型が見つかるからだ。
 
-{#outro}
-# まとめ
+# まとめ {#outro}
 
 Rust
 のプリミティブ型は予約語ではない。名前解決の最終段階で特別扱いされ、他に同名の型が見つかっていなければ対応するプリミティブ型に解決される。
diff --git a/services/nuldoc/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.dj b/services/nuldoc/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.md
index a97337d..945e270 100644
--- a/services/nuldoc/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.dj
+++ b/services/nuldoc/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.md
@@ -11,18 +11,16 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/79ab4db8564032de0b25
 :::
 
-{#tl-dr}
-# TL; DR
+# TL; DR {#tl-dr}
 
 違いはない。ただのエイリアス。
 
-{#code-reading}
-# 調査記録
+# 調査記録 {#code-reading}
 
 Vim の autocmd events には似通った名前のものがいくつかある。大抵は
 `:help`
@@ -45,24 +43,21 @@ vim と neovim のソースコードを調査した。
 * [vim (調査時点での master branch)](https://github.com/vim/vim/tree/8e6be34338f13a6a625f19bcef82019c9adc65f2)
 * [neovim (上に同じ)](https://github.com/neovim/neovim/tree/71d4f5851f068eeb432af34850dddda8cc1c71e3)
 
-{#vim}
-## vim のソースコード
+## vim のソースコード {#vim}
 
 以下は、autocmd events
 の名前と内部で使われている整数値とのマッピングを定義している箇所である。見ての通り、上でエイリアスではないかと述べた3組には、それぞれ同じ内部値が使われている。
 
 https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L85-L86
 
-{filename="src/autocmd.c"}
-```c
+```c filename="src/autocmd.c"
 {"BufAdd",      EVENT_BUFADD},
 {"BufCreate",   EVENT_BUFADD},
 ```
 
 https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L95-L97
 
-{filename="src/autocmd.c"}
-```c
+```c filename="src/autocmd.c"
 {"BufRead",     EVENT_BUFREADPOST},
 {"BufReadCmd",  EVENT_BUFREADCMD},
 {"BufReadPost", EVENT_BUFREADPOST},
@@ -70,23 +65,20 @@ https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/aut
 
 https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L103-L105
 
-{filename="src/autocmd.c"}
-```c
+```c filename="src/autocmd.c"
 {"BufWrite",    EVENT_BUFWRITEPRE},
 {"BufWritePost",    EVENT_BUFWRITEPOST},
 {"BufWritePre", EVENT_BUFWRITEPRE},
 ```
 
-{#neovim}
-## neovim のソースコード
+## neovim のソースコード {#neovim}
 
 neovim の場合でも同様のマッピングが定義されているが、こちらの場合は Lua
 で書かれている。以下にある通り、はっきり `aliases` と書かれている。
 
 https://github.com/neovim/neovim/blob/71d4f5851f068eeb432af34850dddda8cc1c71e3/src/nvim/auevents.lua#L119-L124
 
-{filename="src/nvim/auevents.lua"}
-```lua
+```lua filename="src/nvim/auevents.lua"
 aliases = {
   BufCreate = 'BufAdd',
   BufRead = 'BufReadPost',
@@ -98,32 +90,23 @@ aliases = {
 ところで、上では取り上げなかった `FileEncoding` だが、これは
 `:help FileEncoding` にしっかりと書いてある。
 
-{filename=":help FileEncoding"}
-```
+```text filename=":help FileEncoding"
                                                               *FileEncoding*
 FileEncoding                    Obsolete.  It still works and is equivalent
                                 to |EncodingChanged|.
 ```
 
-{#outro}
-# まとめ
+# まとめ {#outro}
 
 記事タイトルについて言えば、どちらも変わらないので好きな方を使えばよい。あえて言えば、次のようになるだろう。
 
 * `BufAdd`/`BufCreate`
-
   * → `BufCreate` は歴史的な理由により ("for historic reasons") 存在しているため、新しい方 (`BufAdd`) を使う
-
 * `BufRead`/`BufReadPost`
-
   * → `BufReadPre` との対称性のため、あるいは `BufWritePost` との対称性のため `BufReadPost` を使う
-
 * `BufWrite`/`BufWritePre`
-
   * → `BufWritePost` との対称性のため、あるいは `BufReadPre` との対称性のため `BufWritePre` を使う
-
 * `FileEncoding`/`EncodingChanged`
-
   * → `FileEncoding` は "Obsolete" と明言されているので、`EncodingChanged` を使う
 
 ところでこの調査で知ったのだが、`BufRead` と `BufWrite`
diff --git a/services/nuldoc/content/posts/2021-10-02/vim-swap-order-of-selected-lines.dj b/services/nuldoc/content/posts/2021-10-02/vim-swap-order-of-selected-lines.md
index 1cd070e..6f4ca34 100644
--- a/services/nuldoc/content/posts/2021-10-02/vim-swap-order-of-selected-lines.dj
+++ b/services/nuldoc/content/posts/2021-10-02/vim-swap-order-of-selected-lines.md
@@ -11,13 +11,12 @@ tags = [
 date = "2021-10-02"
 remark = "Qiita から移植"
 ---
-::: note
+:::note
 この記事は Qiita から移植してきたものです。
 元 URL: https://qiita.com/nsfisis/items/4fefb361d9a693803520
 :::
 
-{#tl-dr}
-# TL; DR
+# TL; DR {#tl-dr}
 
 ```vim
 " License: Public Domain
@@ -27,30 +26,26 @@ command! -bar -range=%
     \ keeppatterns <line1>,<line2>g/^/m<line1>-1
 ```
 
-{#version}
-# バージョン情報
+# バージョン情報 {#version}
 
 `:version` の一部
 
 > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 26 2020 11\:30\:30) macOS
 > version Included patches: 1-148 Huge version without GUI.
 
-{#existing-solution}
-# よく紹介されている手法
+# よく紹介されている手法 {#existing-solution}
 
-{#external-commands}
-## `tac` / `tail`
+## `tac` / `tail` {#external-commands}
 
 `tac` や `tail -r` などの外部コマンドを `!`
 を使って呼び出し、置き換える。
 
-> :h v_!
+> \:h v_!
 
 `tac` コマンドや `tail` の `-r`
 オプションは環境によって利用できないことがあり、複数の環境を行き来する場合に採用しづらい
 
-{#global-command}
-## `:g/^/m0`
+## `:g/^/m0` {#global-command}
 
 こちらは外部コマンドに頼らず、Vim の機能のみを使う。`g` は `:global`
 コマンドの、`m` は `:move` コマンドの略
@@ -60,12 +55,12 @@ command! -bar -range=%
 で指定された検索パターンにマッチする行に対して、順番に `[command]`
 で指定された Ex コマンドを呼び出す。
 
-> :h :global
+> \:h \:global
 
 `:move` コマンドは `[range]:move {address}` のように使い、`[range]`
 で指定された範囲の行を `{address}` で指定された位置に移動させる。
 
-> :h :move
+> \:h \:move
 
 `:g/^/m0` のように組み合わせると、「すべての行を1行ずつ
 0行目(1行目の上)に動かす」という動きをする。これは確かに行の入れ替えになっている。
@@ -82,8 +77,7 @@ command! -bar -range=%
 
 これは望みの動作をするが、実際に実行してみると全行がハイライトされてしまう。次節で詳細を述べる。
 
-{#problem-of-global-command}
-# `:g/^/m0` の問題点
+# `:g/^/m0` の問題点 {#problem-of-global-command}
 
 `:global`
 コマンドは各行に対してマッチングを行う際、現在の検索パターンを上書きしてしまう。`^`
@@ -91,13 +85,11 @@ command! -bar -range=%
 オプションを無効にしている場合その限りではないが、その場合でも直前の検索パターンが失われてしまうと
 `n` コマンドなどの際に不便である。
 
-> :h @/
+> \:h @/
 
-{#solution}
-# 解決策
+# 解決策 {#solution}
 
-{editat="2020-09-28" operation="追記"}
-::: edit
+:::edit{editat="2020-09-28" operation="追記"}
 より簡潔な方法を見つけたので次節に追記した。
 :::
 
@@ -120,9 +112,9 @@ command! -bar -range=%
 
 Vim のヘルプから該当箇所を引用する (強調は筆者による)。
 
-> :h autocmd-searchpat
+> \:h autocmd-searchpat
 >
-> *Autocommands do not change the current search patterns.* Vim saves the
+> **Autocommands do not change the current search patterns.** Vim saves the
 > current search patterns before executing autocommands then restores them
 > after the autocommands finish. This means that autocommands do not
 > affect the strings highlighted with the 'hlsearch' option.
@@ -132,20 +124,18 @@ Vim のヘルプから該当箇所を引用する (強調は筆者による)。
 `:nohlsearch` のヘルプにある。同じく該当箇所を引用する
 (強調は筆者による)。
 
-> :h :nohlsearch
+> \:h \:nohlsearch
 >
 > (略) This command doesn’t work in an autocommand, because the
 > highlighting state is saved and restored when executing autocommands
-> |autocmd-searchpat|. *Same thing for when invoking a user function.*
+> |autocmd-searchpat|. **Same thing for when invoking a user function.**
 
 この仕様により、`:g/^/m0`
 の呼び出しをユーザー定義関数に切り出すことで上述の問題を解決できる。
 
-{#solution-revised}
-# 解決策 (改訂版)
+# 解決策 (改訂版) {#solution-revised}
 
-{editat="2020-09-28" operation="追記"}
-::: edit
+:::edit{editat="2020-09-28" operation="追記"}
 より簡潔な方法を見つけたため追記する。
 :::
 
@@ -160,4 +150,4 @@ command! -bar -range=%
 のように使い、読んで字の如く、後ろに続く
 Exコマンドを「現在の検索パターンを保ったまま」実行する。はるかに分かりやすく意図を表現できる。
 
-> :h :keeppatterns
+> \:h \:keeppatterns