[Gnu-arch-users] Re: [OT] Architectural renovation

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    >     Tom> 3) Emacs is too text-centric.  The "Emacs architecture" needs
    >     Tom> thoughtful extension for other media types.

    > I'm confused.  Are you coming to praise or to bury widget trees?

Why do you believe that widget trees are the only way to do "other
media types"?  I could write a book answering that question.

You're not alone.... the industry and the free software community have
been stuck there for about two decades now, except for some late night
conversations, research, and prototyping that has been forcibly shut
down more than once.

My most recent "fixing emacs" post, answering your questions, gives
you an indication of how widget trees can at least be thoroughly
hidden (relegated to "internal detail of implementation") for many
common types of interfaces -- many common interfaces considered
isomorhic to a buffer of attributed text.

Beyond that, Joel Bartlett gave one interesting sketch and other
projects have demonstrated the scalability of the general idea that
graphical interfaces are edittable _structured_drawings_, not widget
trees.  (citeseer.nj.nec.com/bartlett91dont.html and
www.cs.umd.edu/hcil/pad++/ may be suggestive resources.)

It's a little bit of a slippery concept.  Sure, a widgetlike
"hierarchy" of drawings is a fine abstraction for drawing some common
types of interface.  The problem is that the view-tree architecture
takes that abstraction far too literally, and then hangs lots of other
crap (like input processing, callbacks, storage of application data,
and confusions about flow of control) (inappropriately) off the same
abstraction.  (For another approach to building abstractions in
drawings: "www.scsh.net/resources/fps.html".)




    >     Tom>    and, _more_importantly_, how do the necessary capabilities
    >     Tom> for such apps fit coherently into the "Emacs architecture" so
    >     Tom> that such applications can be written, extended, and
    >     Tom> documented with an ease comperable to Gnus or c-mode?
    > [...]
    >     Tom> Overall, does the "program and user have isomorphic dynamic
    >     Tom> state" principle generalize?)

    > Yes, I think the various aspects ("(point)", "(current-buffer)",
    > "(interactive ...)", etc) you talk about do generalize.  It's mostly
    > about taking advantage of human eye-hand coordination where that is
    > "serializable".  Eg, an application I simply can't see that
    > architecture working for would be an app that edits scores from a
    > piano keyboard or guitar neck.

If I press a key or make some other input gesture, it's meaning is
context specific.  Part of that context is "on which part of the thing
being editted is your attention focused".  That `thing' (the most
specific part of it) is what the `(point)' represents.

Invariably, the `thing' I'm editting -- the thing with parts upon
which attention may be focused -- has structure.   And, since that
`thing' is a human artifact, mostly likely that structure has an
intuitive topology that partly logical and partly spatial.   So,
that's the basis for navigation of the `(point)'.

Programmatically, the kinds of operations i'm going to do on that
thing I'm editting imply different access patterns.   And
interactively, too.   And that's where "edittable string" falls down
as the central abstraction.    And that's why we ought to (eventually)
think about generalizing `(point)' and all that it relates to.



    > The more implementational technical issues (process support and frame
    > layout) are currently being worked on in XEmacs, with a fair amount of
    > success AFAIK (but that's not my pidgen, I don't know if you would see
    > them as real improvements, and they don't manifest in the UI yet).

    >     Tom> I'm really skeptical that starting with the XEmacs source
    >     Tom> base is the best course -- but I fully acknowledge that it's
    >     Tom> a decision to make rather than a no-brainer.

    > Me too.  I think we see eye-to-eye on that, then.  Different emphasis,
    > I have obvious vested interest, we can deal with that.

    > If you decide to strike out in a different direction (de novo
    > implementation, I mean), let me know.  I might just come along.

Yup.  Part of why I'm participating in this thread is that it's
working both ways.  I'm reconsidering tactics for my de novo
implementation.

I didn't expect the idea for "widget-tree == text buffer" that I sent
earlier today and started talking about yesterday.   That came from
trying to retro-fit emacs.   Yet it seems to me like a good idea on
its own.

One idea it suggested to me, along with

  http://www.gnu.org/gnu/rms-lisp.html

and the memes that got summed up in

  http://www.openresources.com/documents/cathedral-bazaar/node5.html

and the accumulated dead horse crap in

  http://www.jwz.org/doc/lemacs.html

is the idea of (i know this sounds obvious in retrospect
</forhead-slap>) doing a de novo implementation by making an initially
anemic, worthless emacs -- but one that is extremely and forsightfully
well designed in the paucity of features it offers.

In other words, why don't "we" (for some value of "we") grab a Scheme
(because, hey, why _not_ a Scheme) and make a really, really minimal,
yet really really clean/portable/tractable text-only emacs.   Make
lots of noise about it -- then go from there?


-t