<feed xmlns='http://www.w3.org/2005/Atom'>
<title>org-drill/tests/test-org-drill-map-entry-resilient.el, branch main</title>
<subtitle>Spaced-repetition flashcards for Org Mode
</subtitle>
<id>https://git.cjennings.net/org-drill/atom?h=main</id>
<link rel='self' href='https://git.cjennings.net/org-drill/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/org-drill/'/>
<updated>2026-05-05T10:32:32+00:00</updated>
<entry>
<title>fix: keep collection scan alive when one entry errors (upstream #53)</title>
<updated>2026-05-05T10:32:32+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-05-05T10:32:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/org-drill/commit/?id=53d4b9654627c206d14b1345a4efe0a3e70d38d2'/>
<id>urn:sha1:53d4b9654627c206d14b1345a4efe0a3e70d38d2</id>
<content type='text'>
User reported that running org-drill on a buffer with a new (no-ID)
entry threw 'Wrong Type Argument: hash-table-p, nil' and stopped the
scan — every subsequent entry was silently skipped, so the user had
to re-run org-drill once per item (10 items meant 10 invocations).

The exact source of the hash-table error is environment-dependent
(Emacs version, Org version, lazy org-id-locations init, Doom
overrides), so this fix targets the user-visible failure mode
instead of the underlying triggering condition.

Wrapped the per-entry body of org-drill-map-entry-function in
condition-case.  An error on one entry now logs a 'skipping' message
and the scan continues to the next entry.  The session collects all
the well-formed items, and the user can re-run drill once total to
process them — no more once-per-item.

Two regression tests: one verifies the resilience behavior directly
(fail entry 1, scan continues to entry 2), the other documents the
ID-creation-with-uninitialized-locations scenario as a smoke check.
</content>
</entry>
</feed>
