You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create from…: entry points on documents, including a highlighted selection #14
Part of #10 — "Create from…" (materialize) — turn messages, lists, rows and documents into new lists/documents/posts
Web behaviour: Create-from works on a whole document and on a highlighted passage inside
the editor — highlight some markdown (headings, bullets) and use the Selection menu to turn
just that part into a list or a new document.
+ Create on the document browser row and in the editor.
A selection action in DocumentEditorScreen for the highlighted range.
Document → list: each heading and bullet point becomes its own row.
Document → message: markdown converted to plain text with paragraphs preserved; code blocks
are dropped.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Implemented in the PR above (branch issue/14-materialize-docs-entry). Closing here — review and any follow-up happens on the PR.
This also answers the open question #15 left for the entry-point issues. The default column sourceKeys are not published in the help centre or the OpenAPI spec, but the live web client's JS bundle contains the real Create-from window: for a document/docElements source the columns are Section / Text / Type with sourceKeysection / text / type, rows are elements filtered to heading|list-item (falling back to all elements), and the title/file-name defaults are Copy of X / slug-<id8>.md / X (selection). #12 and #13 can use the same source for the messages and lists spellings.
The element-identity concern turned out to be a non-issue: docElements carries documentId + markdown, so a selection's markdown is its identity — which is how #11 already modelled it. Nothing was invented.
One bug in :core:materialize was found and fixed while wiring this: without a reset(), dismissing and reopening the same launch resurrected the previous success pane, because start() deliberately preserves edits across recomposition.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/14-materialize-docs-entry). Closing here — review and any follow-up happens on the PR.This also answers the open question #15 left for the entry-point issues. The default column
sourceKeys are not published in the help centre or the OpenAPI spec, but the live web client's JS bundle contains the real Create-from window: for adocument/docElementssource the columns are Section / Text / Type withsourceKeysection/text/type, rows are elements filtered toheading|list-item(falling back to all elements), and the title/file-name defaults areCopy of X/slug-<id8>.md/X (selection). #12 and #13 can use the same source for the messages and lists spellings.The element-identity concern turned out to be a non-issue:
docElementscarriesdocumentId+markdown, so a selection's markdown is its identity — which is how #11 already modelled it. Nothing was invented.One bug in
:core:materializewas found and fixed while wiring this: without areset(), dismissing and reopening the same launch resurrected the previous success pane, becausestart()deliberately preserves edits across recomposition.merge: #14 Create-from entry points on documents (PR)