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

[Tom Lord]

    Andrew> That one's easy. You need a problem that hasn't already
    Andrew> been solved, and that people actually care about. Making
    Andrew> improvements to a program which is already "adequete",
    Andrew> isn't one, especially with a barrier to entry that high.

    > You're missing the point, I think.  Tom is talking platform, I'm
    > talking platform.  XEmacs has the features Tom specified.  I'm
    > not saying people should hack XEmacs.  I wish they would, but I
    > understand why they don't.  I'm saying people should hack their
    > other hacks in Emacs Lisp, and file bug reports when the docs
    > don't tell them how to implement their hacks or the API makes
    > them jump through hoops.  We see far too little of that, and I
    > don't know why.

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

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

If somebody hacks up a mail reader in Gnome, it right away looks and
feels like the kind of program that MSFT sells a lot of.  If somebody
does that with XEmacs, it looks and feels kinda-sorta like that -- but
not very convincingly.  There's a lot of groundwork to do on core
functionality before it's easy to crank out little demos.  And for
apps which are not very text-centric, you'll have trouble doing it
all.  (I'm not saying that the goal should be to make Emacs apps which
_do_ look like MSFT apps -- I think it should be rather different.
But the MSFTish direction is where Emacsen seem to be gesturing.)

Also, I'm starting to sense that there's an emerging push to give
Emacsen "toolkit bindings" so that you can build a widget tree from
Emacs lisp.    I can strap a clock-radio on my toaster, too, but that
doesn't prove much.

A widget-tree binding for Emacs lisp is an abandonment of the
data-drives-display nature of the Emacs programming environment, and
is likely to be an abandonment of the interact loop, the
self-documenting nature of interactively invocable functions, the
data-driven distinction between interactive and normal functions, the
programs-have-user-like-perspective, and so forth.  There's a lot more
to extending the Emacs architecture for modern applications than being
able to instantiate a window that looks like such and such.  There's a
lot more to what makes Emacs an expressive programming environment
than "it's lisp!"

-t