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

[Stephen J. Turnbull]

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

    Tom> I gave a whole list of ways in which XEmacs is functionally
    Tom> anemic but let me also say this from a higher-level perspective:

On the one side, you're right.  On the other, who knows?  Why don't
you _try_ using XEmacs (or GNU Emacs) to do what you want, and then
request features that would enable those applications?  Isn't it
possible that you're asking for perfection when an approximation,
admittedly gross and partial, is available?  One that could grow into
something reasonable?

(These are rhetorical questions, I know you're busy.)

    Tom> You don't have (and will have trouble making) any really
    Tom> suggestive demos.

What would you consider a suggestive demo?  Have you tried
preview-latex yet?

    Tom> If somebody hacks up a mail reader in Gnome, it right away
    Tom> looks and feels like the kind of program that MSFT sells a
    Tom> lot of.

This is precisely because it's based on a widget tree.  We can already
do that in XEmacs with libglade.  But you are quite right, that's
wrong, and _nobody_ is interested in doing that (although I get the
feeling that Jonathan Walther would love to use it).

    Tom> And for apps which are not very text-centric, you'll have
    Tom> trouble doing it all.

Conceded.  But have you tried xpm-mode in XEmacs?  Pretty slick for a
halfway-house (XPM files are textual representations of an image).

    Tom> A widget-tree binding for Emacs lisp is an abandonment of the
    Tom> data-drives-display nature of the Emacs programming environment,

I don't see it.  Historical Emacs Lisps, possibly.  Once you get into
redisplay, you have to shut down the Lisp engine, or all hell breaks
loose.  This is not true any more (in CVS XEmacs).  You do not have
full access to Lisp (because the stuff that used to be prohibitively
dangerous now raises exceptions rather than doing what you would
expect it to do), and you have to be careful about trapping errors (we
don't have a good sense of how to catch them automagically yet).

But it makes it much easier to write widgets that accept callbacks in
Lisp.  That means that if you want to use a big composite widget as
though it were monolithic, you can, but you can also create the same
widget in Lisp and have it tell Lisp what it's doing step by step.  Of
course this currently requires the cooperation of the widget programmer,
since a callback that is a Lisp object is implemented very differently
from a traditional X callback.  But conventions and eventually (I hope)
toolkits for getting this right will arise.

And the GTK, wxWindows, etc bindings for Python, Perl, etc already are
approximating such toolkits, although they don't give you the fine
control over the event loop that an Emacsen does.

It's not what you want, yet, but I see lots of steps in the right
direction.  The problem is lack of architects and hackers who know how
to and want to use these features, to stress them and force improvement.
:-(

    Tom> and is likely to be an abandonment of the interact loop,

True, but it's a social problem.  The people who write the widget code
for us are C/Java programmers sentenced to hard time writing MS apps,
they don't grok Lisp, and so put too much into C.  The Schemers are
always scheming, though, and as I say every few weeks something that
never should have been in C in the first place is put where it belongs.

The widgets will be hard, I admit.  But at least we now have the
possibility of callbacks in Lisp.

    Tom> the self-documenting nature of interactively invocable
    Tom> functions,

Oh, come on.  You know about the DEFUN macro for primitives.  On the
UI side, for the GUI elements of XEmacs and AFAIK the GUI elements of
GNU Emacs, C-h k <mouse-click> DTRTs.

    Tom> the data-driven distinction between interactive and normal
    Tom> functions,

What distinction?  As far as I can see the basic issue for the
functions themselves is namespace, and some internals hiding.  Or are
you talking about the distinction between "call-interactively" and
"funcall"?  Why do you expect that to go away?

    Tom> the programs-have-user-like-perspective, and so forth.

Why do you expect that to go away?

    Tom> There's a lot more to extending the Emacs architecture for
    Tom> modern applications than being able to instantiate a window
    Tom> that looks like such and such.

XEmacs has a lot of extensions (extents, specifiers, various kinds of
glyphs) that give fine control to the programmer.  Maybe you should
take a closer look at it.

The problem is that traditional Emacs hackers are text oriented, they
don't use this stuff much.  And the "new men"[1] go "eewwwww, what's
that?  Why isn't this all in C where I don't have to look at it?"
Admittedly the interfaces generally kinda suck, but the thing is that
the people who want to use them basically want to emulate Microsoft
UIs, and for that libglade without an Emacs event loop is perfectly
fine.  They don't want a good interface to Emacs-like facilities, they
want the same-old-same-old.


Footnotes: 
[1]  shinjinrui.  What the Japanese call the generation born since
1970 that have no experience of war, poverty, and the bootstrap phase
of a "startup" that grows into an economic powerhouse.

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