Re: [9fans] Why does Acme only show text?

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

fgb, your ability to hack is mighty indeed :-)

On Wed, Jul 15, 2009 at 2:00 PM, Federico G. Benavento
<benavento@gmail.com>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<eekee57@fastmail.fm>
> wrote:
> > On Wed, 15 Jul 2009 09:25:51 GMT
> > Paul Donnelly <paul-donnelly@sbcglobal.net> 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.  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
>
>

[-- Attachment #2: Type: text/html, Size: 4894 bytes --]