feat(app): save/load diagrams

[PabloZaiden]

This pull request introduces native .td.json diagram documents to termDRAW, allowing users to save and reopen editable diagrams. It adds support for loading and saving these documents via the CLI and app, updates the user interface and documentation, and includes comprehensive tests for the new diagram input logic. The changes are grouped into new feature support, CLI/app integration, documentation, and testing.

New Feature: Native Diagram Documents

• Added support for native .td.json diagram documents, which can be opened and saved for continued editing. Users can now open diagrams with termdraw --diagram <file> or termdraw --diagram - to read from stdin, and save diagrams with Ctrl+D in the app. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

CLI and App Integration

• Updated CLI (main.tsx) to support loading diagrams from files or stdin, and to save diagrams in native format. Added helpers for reading from stdin, parsing arguments, and handling diagram save paths. The app now passes initialDocument and diagramPath props and handles onSaveDiagram events for saving the editable document. [1] [2] [3] [4] [5] [6]

Documentation Updates

• Improved the README.md and CHANGELOG.md to document native diagram support, new CLI options, and to clarify the distinction between exporting rendered art and saving editable diagrams. [1] [2] [3] [4] [5]

Testing

• Added comprehensive tests for diagram input handling, including argument parsing, file and stdin reading, error handling, and logic for interactive input in non-TTY environments.

These changes make it possible to persist, reopen, and continue editing diagrams, delivering a more robust and user-friendly workflow for termDRAW users.

[benvinegar]

Note: this comment is generated, and comes from reviewing the PR for ~15 minutes with an agent

The stdin loading flow makes sense to me: stdin is used to read the document, and then the app falls back to /dev/tty for interactive input once the editor starts.

That seems like a reasonable Unix approach, but the failure mode needs to be handled more explicitly. In an environment without a controlling TTY, this currently fails with a raw error like:

ENXIO: no such device or address, open '/dev/tty'\n\nSo the overall approach is fine, but I think we should catch this case and surface a clearer message explaining that interactive editing from stdin requires a controlling terminal, and that a file path should be used otherwise.\n\nAlso, small API/UX suggestion: I’d prefer --load <filename> over --diagram <filename>. --diagram feels ambiguous since the app already deals with diagrams generally, while --load makes the behavior clearer: open an existing native document for editing. If stdin support stays, --load - also reads naturally.\n\nThis comment was generated by Pi using openai/gpt-5

[benvinegar]

Note: this comment is generated, and comes from reviewing the PR for ~15 minutes with an agent

A couple thoughts after reviewing this:

loadDocument() currently shifts imported objects during load. We’re not really sure that’s serving a useful purpose here, and it seems like the native .td.json format should preserve coordinates exactly rather than rewriting them on import.

For an editable native document format, I’d expect load/save to round-trip cleanly: open a document, save it again, and keep the same object positions unless the user actually changed them in the editor.

Also, small API/UX suggestion: I’d prefer --load <filename> over --diagram <filename>. --diagram feels ambiguous since the app already deals with diagrams generally, while --load makes the behavior clearer: open an existing native document for editing. If stdin support stays, --load - also reads naturally.

This comment was generated by Pi using openai/gpt-5

[PabloZaiden]

Addressed the comments. Let me know if anything else is needed

[benvinegar]

@PabloZaiden Thanks! Merged.