Right; there seem to be cross-cutting benefits and drawbacks for declarative text-based specification of diagrams vs direct manipulation. One research project e

Right; there seem to be cross-cutting benefits and drawbacks for declarative text-based specification of diagrams vs direct manipulation. One research project exploring this tension is Sketch-n-Sketch https://ravichugh.github.io/sketch-n-sketch/ https://ravichugh.github.io/sketch-n-sketch/ which tries to combine both together in a single system via bidirectional programming. We've been wanting to explore similar ideas more in Penrose, but it's definitely challenging. Barring bidirectionality, another possibility could just be to make it easier to integrate Penrose into existing workflows; for instance, if you're writing a LaTeX document then it'd be nice to have a package for Penrose diagrams rather than having to switch back and forth between your LaTeX editing environment and the Penrose editor. But then, let's say you make a Penrose diagram and you want to tweak it in Illustrator to make it look better, because as you mentioned, the text-based input modality of Penrose is limited. So we could try to make it smoother to export Penrose diagrams to put in Illustrator. You edit the diagram and add it to your LaTeX document. But now, you decide you want to make a tweak to the original diagram by modifying the Penrose source code. This obliterates any changes you made in Illustrator, so now you have to manually repeat the tweaks you already made. I'm not really sure what the best solution is... it seems hard to have a good workflow story without either being entirely text-based, supporting bidirectionality, or forcing a lot of repetitive manual rework when edits are made.