gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephen J. Turnbull
Subject: [Gnu-arch-users] Re: [OT] Architectural renovation
Date: Tue, 02 Sep 2003 10:10:26 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    >> 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?

    Tom> Why do you believe that widget trees are the only way to do
    Tom> "other media types"?

I don't.  However, I have little programming experience with
structured media types other than widgets, and you fell into the trap
of using the widget tree as an example yourself.

    Tom> suggestive resources

Thanks for the pointers!

    Tom> Programmatically, the kinds of operations i'm going to do on
    Tom> that thing I'm editting imply different access patterns.

If the access patterns are serializable and continuous, then "(point)"
generalizes.  "Follow the bouncing ball" and all that.  If they are
like performance (or martial) art, it will not, because in such arts
"gestalts" (for want of a more precise word) and "surprise" are
essential to effectiveness.

I suspect that attempts to mirror the "global awareness" of the active
user in the application's state are precisely the root of concepts
like "keyboard focus" on parent widgets, and of course of event-driven
programming.  Attempts to force that back into "(point)" are the root
of such brain-damaged standards as the Motif keyboard traversal model
which doesn't grok that some interfaces involve preparation and then
repeated invocation of an action (search, replace) and others do not
(a file selection widget should not leave focus on "OK" just because
that's the last thing that was done).  Or Windows, where the keyboard
focus is ALWAYS several <TAB>s aways from where I want to type.  Even
the Mac.  :-/

    Tom> Yup.  Part of why I'm participating in this thread is that
    Tom> it's working both ways.

Whew!  I feel better now.  :-)

    Tom> In other words, why don't "we" (for some value of "we") grab
    Tom> a Scheme (because, hey, why _not_ a Scheme) and make a
    Tom> really, really minimal, yet really really clean/portable/
    Tom> tractable text-only emacs.

Right.  XEmacs is a sandbox.  As long as it's a GNU Emacs, it's never
going to be the new Emacs.  Just a nice place to play with the
occasional nifty sand castle that crumbles when the sun shines on it
too long.

The problem is that I haven't really seen anything particularly
exciting in architectural terms that justifies leaving the sandbox,
which is where most of my friends play.

    Tom> Make lots of noise about it -- then go from there?

Uh-oh.  Haven't you learned anything from Arch?

(That's a rhetorical question.  I think this thread has said all it
needs to.)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]