Skip to content

docs: fix Atomic Memory comparison table - #181

Closed
kuanih wants to merge 1 commit into
atomicstrata:mainfrom
kuanih:fix/atomic-memory-table-separator
Closed

kuanih wants to merge 1 commit into
atomicstrata:mainfrom
kuanih:fix/atomic-memory-table-separator

Conversation

@kuanih

@kuanih kuanih commented Aug 15, 2026

Copy link
Copy Markdown

Summary

  • fix the Markdown delimiter row in the llmwiki/Atomic Memory comparison table
  • use valid GFM delimiter cells so the table renders consistently

Why

The first delimiter cell used only two hyphens. GFM table delimiter cells require at least three.

Validation

  • git diff --check
  • npx tsc --noEmit
  • npm run build
  • npm test (4,860 passed, 3 skipped)
  • npm run fallow:ci

@kuanih
kuanih marked this pull request as ready for review August 15, 2026 10:31
@ethanj

ethanj commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Thanks for sending this, and welcome. It's a good instinct to fix a table delimiter that looks off.

I went to verify it before merging and it turns out the original row was already valid. GFM requires one or more hyphens per delimiter cell, not three, so |--| parses fine, and even |-| would. I checked it against two parsers, including remark-gfm, which is what our docs site actually uses:

const before = "| | llmwiki | Atomic Memory |\n|--|---------|---------------|\n| **A** | b | c |\n";
const after  = "| | llmwiki | Atomic Memory |\n| --- | --- | --- |\n| **A** | b | c |\n";
// both render a <table>, and the output HTML is byte-identical

So the table renders correctly on main today and this change is a no-op. It's a completely reasonable thing to have assumed. Most style guides do use three hyphens, so "three is required" is an easy conclusion to reach.

I'm going to close this one, but two things:

  • If you actually saw this table rendering wrong somewhere, please do open an issue. That would be a real bug and it wasn't caused by this line.
  • We don't have a documented table style, which is the other reason I'd rather not merge a purely cosmetic normalization: it would set a convention by accident. If you'd like to propose one as an issue, that's a genuinely useful contribution and I'd be happy to look.

Thanks again for taking the time. Hope to see another PR from you.

@ethanj ethanj closed this Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants