From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200107102257.XAA00499@localhost.localdomain>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] sam vs acme
In-Reply-To: Message from rog@vitanuova.com
   of "Tue, 10 Jul 2001 11:32:39 BST." <20010710102311.AA4B61998A@mail.cse.psu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: Steve Kilbane <steve@whitecrow.demon.co.uk>
Date: Tue, 10 Jul 2001 23:57:44 +0100
Topicbox-Message-UUID: c4df4918-eac9-11e9-9e20-41e7f4b1d025

rog wrote:
> i've not used wily, but IMHO there are some places where a unix-based
> acme clone could never approach the real acme, namely those places
> where acme leverages the power of plan 9.

All true; the RPC interface library is a nightmare to use, compared
with the ease of just echoing into appropriate files. However, that's
a given anyway.

> much of the power of acme comes from living in happy symbiosis with
> plan 9 - acme under unix is kind of like a hacked off limb; it looks
> similar to the original, but won't work so well...

Is this just from a programmer's point of view, or does it apply purely
to someone who sees both through their interface? For example, if the
mail reader manages to present mail messages as files which are opened
in windows, is one better than the other, to the user?

> > [eg. we had edit interfaces three or was it four years ago :)]
>
> presumably by this you mean the named-pipe RPC interface, not the sam
> command Edit command?  (which doesn't seem to be in wily)

There were two. There was an attempt to emulate acme's e pipelines
(a miserable failure), and a much cleaner, better and simpler | > <.
The former used the RPC library, the latter was a builtin.

There were differences. In particular, the window layout heuristics
stopped trying to be like acme, and tried to be nice, instead. By that,
I don't mean that acme's heuristics weren't nice, but that wily's
attempts to match acme weren't producing something that was pleasant
to use. A major revision produced something that wouldn't rearrange
windows unless it had to, which was a nicer user experience than wily
had previously offered. However, by this time, it didn't have cursor
warping that worked in the same manner as acme, and didn't have the
convenient warping-back that acme had.

Wily only had two fonts. iirc, the B3-on-<stdio.h> stuff didn't work as well
(or in the same manner). win, as an application, was greatly reduced under
wily, but that's more a fault of UNIX's ttys and the immense cruft they
demand, rather than wily's faults.

Wily treated tags differently from acme. afaik, the filename in acme is
just the string at the start of the tag [been a long time since i looked],
while wily maintained filenames internally, truncated them to shorter
strings with environment variables, and mused over mounted directories.

Wily was never that hot on working out whether it should save a modified
window on closing, if the window had been created by a client.

Wily didn't have the save/restore layout features, although it may do now.

In day-to-day usage, wily was very nice. The window management worked smoothly,
cursor keys worked, and it looked great. It crashed on me occasionally, but
generally less than the OS did. Where it fell down was that it was just too
much damn work to write clients for it.

steve