[email protected] (Ethan Grammatikidis) writes: > On Wed, 15 Jul 2009 09:25:51 GMT > Paul Donnelly <[email protected]> wrote: > >> [email protected] (Jason Catena) writes: >> >> > 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. >> >> Hi, I don't know anything about anything, but it seems to me that it's >> more productive to look at the question the other way around: why not >> modify Rio to tile windows like Acme does? Acme is a text editor, so >> it's no surprise that it handles text only. > > You may be thinking too monolithically. The draw device multiplexes itself so > it shouldn't take much coding for acme to provide draw in addition to the > other files it provides in /mnt/wsys. > > Mouse is just as important as draw and will need a little more code. Not only > would acme need to multiplex it but it would need to emulate rio's behaviour. > To quote Rio's man page: "Opening it turns off scrolling, editing, and > rio-supplied menus in the associated window." That isn't 100% true, scrolling > isn't actually disabled but is not naturally accessible and looks very messy > when you force it. What is true is that rio ceases to interpret keys > specially other than backspace and return (curiously), and mouse events on > the window are blindly sent to the application. > > It still doesn't sound like a lot of code, but may take some careful thought. > Maybe that's a summary of Plan 9 methodology. :)
That's why Rio seems like a more apropos starting point to me. :) It seems to me that the primary task of this hypothetical program would be providing /dev/draw to the programs running under it. Changing Rio's window layout code and adding a command protocol strikes me as less monolithic than combining window system duties with everything Acme already does. > I also take issue with the statement "Acme is a text editor," that never > sounds right, no more than describing Emacs as a text editor. It's natural to > use Acme as a text editor and it provides many more text-editing facilities > than Rio does, but it is also natural to use it as a file manager, shell > window provider, email client, etc, etc. It provides more than Rio and it > does it all with tiling windows and without menus, but that's just style. Rio > windows could seriously use a search function and one or two other > text-editor facilities wouldn't go amiss. It doesn't seem natural to me that > Acme does not allow graphical programs in it's windows. Fair enough. I just meant to say that Acme has a fairly focused design, which is oriented around the notion of windows containing text. If I wanted windows to potentially contain something other that text I'd reevaluate the design based on that criterion. And what I think I'd do would be as I described above, with the addition of a program that behaved like a single Acme window. FWIW, I don't think Emacs's design is perfect for a general application host either, although it's certainly a great program despite that. It's not like I'm some master software architect (and I see Rob Pike, who certainly has a more informed perspective on this than me, was thinking along the lines of Acme with graphics). I'm just saying my instinct is to decompose further and take as much out of the graphics/command host as possible. There are trade-offs either way, and maybe it would be more productive after all to mod Acme.
