From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20090715132212.6c3cc544.eekee57@fastmail.fm> References: <87r5wivc8s.fsf@plap.localdomain> <20090715132212.6c3cc544.eekee57@fastmail.fm> Date: Wed, 15 Jul 2009 18:00:49 -0300 Message-ID: <32d987d50907151400w6cc65aa5uf33ed1e539fd7391@mail.gmail.com> From: "Federico G. Benavento" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Why does Acme only show text? Topicbox-Message-UUID: 21dcf664-ead5-11e9-9d60-3106f5b1d025 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 t= hat 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 a= lmost 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 w= rote: > On Wed, 15 Jul 2009 09:25:51 GMT > Paul Donnelly wrote: > >> jason.catena@gmail.com (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. =C2=A0Kee= ping >> > 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 itsel= f 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 beh= aviour. 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, scr= olling isn't actually disabled but is not naturally accessible and looks ve= ry messy when you force it. What is true is that rio ceases to interpret ke= ys 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 thou= ght. 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 facilit= ies than Rio does, but it is also natural to use it as a file manager, shel= l 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 Ac= me 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. > > --=20 Federico G. Benavento