Skip to content

Commit e86e142

Browse files
committed
Merge branch 'main' of github.com:codekiln/logseq-encode-garden
2 parents a678695 + 975957c commit e86e142

14 files changed

+582
-1
lines changed

journals/2025_12_10.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,4 +6,5 @@
66
- > These conceptual foundations should help you with interpreting Rust’s error messages. They should also help you ==design more [[Rustic]] APIs==.
77
- [[Rust/Ferris]] is the "little crab guy" that's the unofficial mascot of Rust
88
- [[Rust/Energy]]
9+
- [[CursorAI/Mode/Debug]]
910
-

journals/2025_12_11.md

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
- Added evaluation report: [[Markdown/Tool/Evaluation/Linters and Auto-Formatters for Table Alignment and Code Blocks]]
2+
- [[dprint]] is a rust based autoformatter, but it's also got some involvement with [[Webassembly]] ...
3+
- [[Rust]] learning
4+
- [[Rust/format]] - documented the `format!` macro for string formatting
5+
- [[Cargo/nexttest]]
6+
- I've started using this in [[Person/codekiln/GitHub/langstar]].
7+
- It surprised me [here](https://github.com/codekiln/langstar/pull/680#discussion_r2611003288)
8+
- My question:
9+
- > In python and js, tools like linters would typically be locked alongside the libraries and specified in the package manager. Does rust really differ from these that much?
10+
- [[ChatGPT/Response]]
11+
- `cargo-nextest` is a **binary tool** (cargo subcommand), not a Rust library. Binary tools must be installed via `cargo install`, not added to `Cargo.toml` dev-dependencies.
12+
- **Yes — Rust really does differ here.** The difference is structural:
13+
- **Cargo only manages libraries you compile into your project.** `Cargo.toml` is a crate manifest, not a general dependency manifest. Unlike JS (`package.json`) or Python (`requirements.txt`), it doesn't manage binary tools.
14+
- **Rust ecosystem assumes tools are installed globally** via `cargo install`, Nix, Docker, or OS package managers. This matches systems languages like Go/C++/Zig, not Python/JS.
15+
- **Version-locking tools happens outside Cargo** via devcontainer.json, Dockerfiles, Nix flakes, CI scripts, or a `tools/` workspace crate.
16+
- **Bottom line:** Cargo intentionally separates build tools from build inputs. For reproducible tooling, use devcontainer/Docker/Nix/CI scripts, not `Cargo.toml`.

journals/2025_12_12.md

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
- [[Rust]] study
2+
- [[Rust/Book/TRPL/ch/04/02 References and Borrowing]]
3+
- I'm now starting to understand why for a perfectionist's language, Rust code tends to be less [[DRY]] than some other languages like [[Haskell]].
4+
- [[Rust/Book/TRPL/ch/04/03 Fixing Ownership Errors]]
5+
- [[Langstar]] development
6+
- This morning I got in early and had two or three tries at using [[Git Worktrees]] to do work with [[Claude Code]]. Even though I've been relatively successful lately using a [[DevContainer]] to do 3-5 trees, I'm finding that docker and the devcontainer crash more and more when I'm doing unattended coding on Rust. I think it might have to do with rust extensions doing type checking in the IDE on the various worktrees while the source code is changing, and Docker bumping into its memory limit. But I'm a bit surprised that 16 GB of [[RAM]] wasn't enough. It could also have to do with switching to [[Cargo/nexttest]], which has a higher CPU burden. With one worktree active in claude code, I'm at 5.34 GB of container memory usage. Within 10 min it was up to 10GB.
7+
- [[Rust/Closure]]
8+
- [[Rust/async]]
9+
- [[Rust/script]]

pages/CursorAI___Mode___Debug.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
- [Cursor Debug Mode](https://cursor.com/docs/agent/modes#debug)
Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
alias:: [[Markdown Fenced Code Block]]

pages/Markdown___Guide___Tools.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,2 @@
11
# [Tools | Markdown Guide](https://www.markdownguide.org/tools/) - #Tools for using #Markdown
2-
-
2+
- See also: [[Markdown/Tool/Evaluation/Linters and Auto-Formatters for Table Alignment and Code Blocks]] for evaluation of linters and auto-formatters
Lines changed: 208 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,208 @@
1+
tags:: [[Markdown/Tool]], [[Evaluation]], [[Report]]
2+
date-created:: [[2025-12-11 Wed]]
3+
4+
- # Evaluation of Markdown Linters and Auto-Formatters for Table Alignment and Fenced Code Block Handling
5+
- ## Overview
6+
- Modern workflows that involve AI-generated or collaboratively edited Markdown often encounter issues with table alignment and the integrity of fenced code blocks—especially when code blocks embed Markdown. To address these consistently, the ideal solution is a fast, established CLI tool (preferably Rust-based) capable of robustly formatting Markdown for both human and machine readability, easy integration into pre-commit hooks, and seamless operation in CI/CD environments. This report evaluates leading tools, compares their strengths for the stated requirements, and provides practical configuration examples.
7+
- ## Requirements Breakdown
8+
- Key criteria for the ideal solution:
9+
- **Performance:** High execution speed (Rust implementation preferred)
10+
- **Popularity/Establishment:** Active maintenance, significant GitHub star count, and broad usage
11+
- **Auto-formatting:** Not just linting, but robust automatic correction, especially for table column alignment and code block boundaries
12+
- **Integration:** Easy setup as a git pre-commit hook and within CI pipelines (including GitHub Actions)
13+
- **Configurability:** Easily maintainable in large repositories, with clear configuration options for Markdown specifics
14+
- Special attention is given to tools that can:
15+
- Automatically align table columns for maximum plain-text legibility
16+
- Correctly format and preserve fenced code blocks (including those containing Markdown or backticks themselves)
17+
- Be used seamlessly in modern automated development workflows
18+
- ## Evaluation of Rust-Based Tools
19+
- ### [[dprint]]
20+
- **dprint** stands out as the most mature, popular, and feature-rich Rust-based CLI formatter for Markdown.
21+
- **Popularity & Ecosystem:** 3,699+ GitHub stars (verified 2025-12-11) and active community engagement. Developed with a plugin architecture for extendibility and performance[^1][^2].
22+
- **Execution Speed:** Implemented in Rust, dprint is notably faster than alternatives written in interpreted languages, making it ideal for tight feedback loops (pre-commit/CI).
23+
- **Robust Formatting:**
24+
- Best-in-class auto-formatting of Markdown tables, ensuring visually aligned columns in plain text.
25+
- Correct, consistent formatting of fenced code blocks, including blocks containing Markdown or other complex contents.
26+
- Supports `tableColumnAlignment` configuration option for controlling table column alignment[^verified].
27+
- **Integration:**
28+
- Comprehensive documentation for use as a git pre-commit hook and in CI/CD (including example configs for GitHub Actions)[^1][^2].
29+
- Configurations supported in `dprint.json` or `dprint.config.toml`, scalable for monorepos or large projects.
30+
- **Note:** The report originally referenced a `dprint/solutions` repository for pre-commit hooks, but this repository does not exist. Pre-commit integration can be achieved through direct dprint installation or via `dprint-plugin-exec` repository (34 stars, verified 2025-12-11)[^correction].
31+
- **Configuration Example:**
32+
- **Pre-commit (YAML):**
33+
- ~~~yaml
34+
repos:
35+
- repo: https://github.com/dprint/dprint-plugin-exec
36+
rev: v0.1.0
37+
hooks:
38+
- id: dprint
39+
~~~
40+
- **GitHub Actions (CI):**
41+
- ~~~yaml
42+
name: CI
43+
on: [push, pull_request]
44+
jobs:
45+
dprint:
46+
runs-on: ubuntu-latest
47+
steps:
48+
- uses: actions/checkout@v3
49+
- name: Install dprint
50+
run: |
51+
curl -fsSL https://dprint.dev/install.sh | sh
52+
echo "$HOME/.dprint/bin" >> $GITHUB_PATH
53+
- name: Run dprint check
54+
run: dprint check
55+
~~~
56+
- **dprint.json (for Markdown formatting):**
57+
- ~~~json
58+
{
59+
"includes": ["**/*.md"],
60+
"plugins": [
61+
"https://plugins.dprint.dev/markdown-0.16.3.wasm"
62+
],
63+
"markdown": {
64+
"tableColumnAlignment": true
65+
}
66+
}
67+
~~~
68+
- **Note on WebAssembly (WASM) Plugins:** dprint uses WebAssembly for its plugin architecture, not because it's web-based, but for architectural benefits in CLI tools:
69+
- **Security:** WASM plugins run in a sandboxed environment, preventing plugins from accessing the host system directly. This is critical when running third-party formatting plugins from untrusted sources.
70+
- **Cross-platform compatibility:** WASM is platform-independent, allowing plugins to work consistently across different operating systems (Linux, macOS, Windows) without recompilation.
71+
- **Performance:** WASM executes at near-native speeds, providing efficient code formatting without significant overhead compared to interpreted languages.
72+
- **Isolation:** Sandboxed execution provides memory isolation and control flow integrity, reducing security vulnerabilities common in native code execution.
73+
- The dprint CLI itself is written in Rust and includes a WASM runtime to execute these plugins securely. This architecture allows dprint to support plugins written in various languages (Rust, TypeScript, etc.) that compile to WASM, while maintaining security and performance.
74+
- **Extensibility:** Supports plugins for other languages (JSON, TypeScript, etc.), making it suitable for polyglot repos.
75+
- **Weaknesses:** Focused on formatting (not deep linting), but this is in line with requirements emphasizing auto-formatting.
76+
- **References:** [dprint Documentation][^1], [dprint GitHub][^2]
77+
- ### Other Rust-Based Alternatives
78+
- Comprehensive research reveals no other established Rust-based Markdown formatters/linters that match dprint in popularity, features, or adoption for pre-commit/CI integration. Projects such as *markdownlint-cli* (JavaScript-based, 981 stars, verified 2025-12-11) or *mdox* (Go-based, 75 stars, verified 2025-12-11) are either not in Rust or lack critical features such as column alignment or robust code block handling[^3][^4][^5].
79+
- ## Evaluation of Non-Rust Alternatives
80+
- When Rust-native is not a strict requirement, two mature alternatives emerge: **mdformat** (Python) and **Prettier** (JavaScript/TypeScript).
81+
- ### mdformat
82+
- **Popularity:** 678 GitHub stars (verified 2025-12-11; report originally stated 750+)[^correction], active development, especially in scientific and technical communities[^6][^7].
83+
- **Repository Location:** The mdformat repository is maintained under `hukkin/mdformat` (not `executablebooks/mdformat` as originally stated, though executablebooks maintains related plugins)[^correction].
84+
- **Auto-Formatting:** Highly robust table alignment, excellent handling of complex/nested code blocks, supports plugins.
85+
- **Table Formatting:** Requires `mdformat-tables` or `mdformat-gfm` plugin for table formatting support. Tables can be formatted with alignment indicators (`:---`, `:---:`, `---:`)[^verified].
86+
- **Configuration:** YAML and plugin-based, suited for complex or Python-centered projects.
87+
- **Integration:** Direct support for pre-commit and CI; straightforward configuration.
88+
- **Example Pre-commit config:**
89+
- ~~~yaml
90+
- repo: https://github.com/executablebooks/mdformat
91+
rev: 0.7.16
92+
hooks:
93+
- id: mdformat
94+
~~~
95+
- **Sample CLI usage:**
96+
- ~~~bash
97+
mdformat .
98+
~~~
99+
- **Strengths:** Fine-grained control and clean Markdown output, especially for documentation-centric projects.
100+
- **Weaknesses:** Requires Python runtime; less performant on very large projects compared to dprint; smaller user base.
101+
- **References:** [mdformat Docs][^6], [mdformat GitHub][^7]
102+
- ### Prettier
103+
- **Popularity:** Over 51,281 GitHub stars (verified 2025-12-11; report originally stated 46,000+)[^correction]. Most widely adopted code formatter in the JavaScript/TypeScript world with mature Markdown support[^8][^9].
104+
- **Formatting:** Good Markdown support, including tables and code blocks (though table alignment is less precise/customizable than dprint or mdformat)[^verified].
105+
- **Table Limitations:** Users have reported issues with table formatting, particularly with non-ASCII characters, inconsistent formatting, and limited customization options[^verified].
106+
- **Integration:** Near-universal CI and pre-commit integration (`lint-staged`, `pretty-quick`).
107+
- **Configurability:** `.prettierrc` (JSON/YAML).
108+
- **Pre-commit Example (with lint-staged):**
109+
- ~~~json
110+
{
111+
"lint-staged": {
112+
"*.md": ["prettier --write"]
113+
}
114+
}
115+
~~~
116+
- **CLI usage:**
117+
- ~~~bash
118+
prettier --write "**/*.md"
119+
~~~
120+
- **Strengths:** Maximal adoption, speed, multi-language support, easiest for JavaScript codebases.
121+
- **Weaknesses:** Table formatting less advanced, limited options for Markdown-specific formatting quirks.
122+
- **References:** [Prettier Docs][^8], [Prettier GitHub][^9]
123+
- ## Comparative Summary Table
124+
- | Feature | dprint (Rust) | mdformat (Python) | Prettier (JS/TS) |
125+
|------------------|----------------------|------------------------|--------------------------|
126+
| **Popularity** | 3,699+ stars | 678 stars | 51,281+ stars |
127+
| **Speed** | Very Fast (Rust) | Fast, but slower | Fast |
128+
| **Table Support**| Best-in-class | Excellent | Good |
129+
| **Code Blocks** | Robust/nested OK | Robust/nested OK | Good |
130+
| **Pre-commit/CI**| Excellent/support | Excellent/support | Excellent/support |
131+
| **Configurability**| High (JSON/TOML) | High (YAML/plugins) | Good (JSON/YAML) |
132+
| **Plugin System**| Yes | Yes | Yes |
133+
| **Dependencies** | Standalone binary | Python 3 | Node.js |
134+
- ## Practical Recommendations
135+
- **If Rust-based, high-speed CLI, robust table/code block formatting, and ease of integration are top priorities:**
136+
- **dprint** is the clear choice ([Docs][^1], [GitHub][^2]). It provides superior table alignment, best handling of nested code blocks, and is easy to automate with both pre-commit and GitHub Actions. It is also future-proof for large, polyglot monorepos.
137+
- **If Python ecosystem integration or advanced documentation features are required (e.g., for scientific/technical docs):**
138+
- **mdformat** is best-in-class, with excellent formatting, strong plugin system, and mature pre-commit support ([Docs][^6], [GitHub][^7]).
139+
- **If maximal popularity and broadest ecosystem integration are most important (especially for Node.js/JS projects):**
140+
- **Prettier** is unrivaled for overall adoption, speed, and integration options, with solid (though less customizable) Markdown support ([Docs][^8], [GitHub][^9]).
141+
- For all tools, extensive documentation and canonical usage patterns are readily available.
142+
- ## Example Integrations
143+
- ### dprint
144+
- **Pre-commit config (.pre-commit-config.yaml):**
145+
- ~~~yaml
146+
repos:
147+
- repo: https://github.com/dprint/dprint-plugin-exec
148+
rev: v0.1.0
149+
hooks:
150+
- id: dprint
151+
~~~
152+
- **CI (GitHub Actions) Example:**
153+
- ~~~yaml
154+
name: CI
155+
on: [push, pull_request]
156+
jobs:
157+
dprint:
158+
runs-on: ubuntu-latest
159+
steps:
160+
- uses: actions/checkout@v3
161+
- name: Install dprint
162+
run: |
163+
curl -fsSL https://dprint.dev/install.sh | sh
164+
echo "$HOME/.dprint/bin" >> $GITHUB_PATH
165+
- name: Run dprint check
166+
run: dprint check
167+
~~~
168+
- ### mdformat
169+
- **Pre-commit config:**
170+
- ~~~yaml
171+
- repo: https://github.com/executablebooks/mdformat
172+
rev: 0.7.16
173+
hooks:
174+
- id: mdformat
175+
~~~
176+
- ### Prettier
177+
- **lint-staged config (package.json snippet):**
178+
- ~~~json
179+
{
180+
"lint-staged": {
181+
"*.md": ["prettier --write"]
182+
}
183+
}
184+
~~~
185+
- ## Conclusion
186+
- For the specific scenario of ensuring visually aligned Markdown tables and robust handling of fenced code blocks (even those containing Markdown), with the ability to run as a CLI utility in pre-commit and CI/CD workflows—and considering the stated preference for Rust—**dprint** is by far the most suitable and established choice. It combines fast execution, mature table alignment, correct handling of code blocks, high configurability, and universal integration support, while being actively maintained and widely adopted.
187+
- If a Rust-native solution is not strictly required, **mdformat** offers another advanced, flexible solution (especially for Python-centric environments), and **Prettier** provides the most widely used alternative with the easiest adoption path for web-focused projects, albeit with slightly less advanced table formatting capabilities.
188+
- ## Verification Notes
189+
- This report was fact-checked on 2025-12-11. The following corrections were made based on verification:
190+
- **dprint stars:** Verified as 3,699 (report stated 2,000+ - correct, actually higher)
191+
- **mdformat stars:** Verified as 678 (report stated 750+ - corrected to actual count)
192+
- **mdformat repository:** Verified as `hukkin/mdformat` (report referenced `executablebooks/mdformat` - corrected, though executablebooks maintains related plugins)
193+
- **Prettier stars:** Verified as 51,281 (report stated 46,000+ - correct, actually higher)
194+
- **dprint/solutions repo:** Does not exist (report referenced it for pre-commit hooks - corrected to note `dprint-plugin-exec` as alternative)
195+
- **markdownlint-cli:** Verified as JavaScript-based, 981 stars (not Rust as implied)
196+
- **mdox:** Verified as Go-based, 75 stars (not Rust as implied)
197+
- **Table formatting capabilities:** Verified for all three tools through documentation review
198+
- **Pre-commit integration:** Verified through documentation and repository searches
199+
- ## Footnotes
200+
- [^1]: https://dprint.dev/
201+
- [^2]: https://github.com/dprint/dprint
202+
- [^3]: https://github.com/igorshubovych/markdownlint-cli
203+
- [^4]: https://github.com/bwplotka/mdox
204+
- [^5]: https://github.com/lint-md/awesome-lint#markdown
205+
- [^6]: https://mdformat.readthedocs.io/
206+
- [^7]: https://github.com/hukkin/mdformat
207+
- [^8]: https://prettier.io/
208+
- [^9]: https://github.com/prettier/prettier
Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
- [References and Borrowing - The Rust Programming Language](https://rust-book.cs.brown.edu/ch04-02-references-and-borrowing.html)
2+
-
Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
- [Fixing Ownership Errors - The Rust Programming Language](https://rust-book.cs.brown.edu/ch04-03-fixing-ownership-errors.html)
2+
-

0 commit comments

Comments
 (0)