I've been wondering for years now why Acme (and Wily, which I used first) only display text files.
It seems to me that the content of an Acme window could be anything: a picture, a postscript or PDF file, a star chart, a web page. Keeping with the spirit of small parts brought together, Acme could outsource the displaying of the content to another program, place its output in the Acme window, and operate on it by sending commands from the tag to the rendering program. Browsers do this (except the tag-command part) with PDF for example, displaying a PDF file within an embedded viewer (usually Acrobat). Looking through the Oberon document, I see that its Acme-like interface uses exactly this kind of embedded-viewer architecture, and commands in the tag suitable to the object viewed. I know Oberon came first, so my question is, is there an architectural or design reason the plumber invokes programs completely outside Acme to view and control files other than text? Is the embedded capture and control a planned feature or enhancement that was just never added to Acme yet? Is it considered too much work or too complicated to implement for the benefit of a more integrated interface? Or is any format other than text considered a red-headed stepchild to be delegated to other programs in the few cases where it must be used? Jason Catena
