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