fgb, your ability to hack is mighty indeed :-) On Wed, Jul 15, 2009 at 2:00 PM, Federico G. Benavento <[email protected]>wrote:
> acme is more than a buffer with text to edit, it also has the > filesystem interface > that allows programs to be written specifically for it (Mail, Wiki, etc). > I never thought that doing graphics in acme was a need, as most of the time > I'm just editing text and having some graphical up there would take space > that > I can really use to list a directory, another source file, or whatever. > > I also don't think that you'll have to emulate rio's behavior as you > can run most > of the graphical programs without rio, that's the beauty of rio, it gives > almost > the same interface as it gets from the kernel. > > in any case, years ago I gave it a try, but I after a day of hacking I lost > my > interest, I know some people still want this functionality, so if you are > up to the challenge go for it. I have a tgz on mordor which can run > draw apps on acme, but it's not functional at all, so if you're > interested let me know > > http://www.tip9ug.jp/who/fgb/acme.png > > > On Wed, Jul 15, 2009 at 9:22 AM, Ethan Grammatikidis<[email protected]> > wrote: > > 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. :) > > > > 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. > > > > -- > > Ethan Grammatikidis > > > > Those who are slower at parsing information must > > necessarily be faster at problem-solving. > > > > > > > > -- > Federico G. Benavento > >
