[Gnu-arch-users] Re: [OT] fixing emacs

[Stephen J. Turnbull]

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

    Tom> For starters, I'd start just with "dialog-box" style
    Tom> functionality.  Is there a mechanism by which I can put up a
    Tom> form with buttons, and check-boxes, and lists, and so forth,
    Tom> rendered with native widgets?

Yes, in 21.4.  Publicly released in April 2001.  The feature was
available in devo since about 1997.

    Tom> Why not provide that via text buffers that are specially
    Tom> rendered?

That's basically the way they're done, in 21.4.

    Tom> Create a special, buffer-local variable:

The way it's currently done is to treat native widgets (including
layouts) as glyphs, and attach the glyphs to an annotation either in a
buffer or in a string placed in the frame's gutter.

A more text-like API was considered, but you end up with too much
cruft in the buffer.  Better to use code.

    Tom> The redisplay engine, to display a window on a 'dialog
    Tom> buffer, should build a widget tree.  Widget-callbacks and so
    Tom> forth should be hidden from Emacs lisp -- just translated
    Tom> into (perhaps new types of) events which the major-mode of
    Tom> the 'dialog buffer can decide how to handle.  I doubt that
    Tom> that would require major changes to the redisplay engine.

Not any more.  I don't know how much was required when it was done 4
years ago.

    Tom> Note that this has a very unusual yet pretty easy programming
    Tom> interface.

It hasn't been unusual to XEmacs hackers for several years.

    Tom> 1) Windows and frames: I think it would be awefully nice to
    Tom> sqeeze into window-separators and modelines some tiny
    Tom> controls for splitting windows and deleting windows.

Ancient history.  I don't think we have that by default but I know
there are hacks for it.

    Tom> I think it would be nice to add to the menu-bar some
    Tom> (button-like, not menu) controls for creating new frames and
    Tom> destroying frames.

I'll keep that in mind, although I'll probably be conservative and put
them in the toolbar.

    Tom> 2) Minibuffer management: Let's suppose that you do, in fact,
    Tom> have 'diaglog buffers.  Many (perhaps all?) interactive
    Tom> declarations can be translated automatically into forms -- so
    Tom> the minibuffer can be displayed as a 'dialog buffer if that's
    Tom> what the user prefers.

Ancient history, but imperfectly and incompletely implemented except
on Windows.

    Tom> 3) Fancier widgets: I'll pick two that don't map very nicely
    Tom> onto text -- structured drawings (e.g., a musical score or a
    Tom> call-graph) and tables (e.g., a large, possibly
    Tom> multi-dimensional spreadsheet).

XEmacs 21.4 has a tree widget for some platforms.  Music and
spreadsheets, not that I know of yet.  We'd need a new layout for
spreadsheets, music (and true sub/superscripts) are harder.

    Tom> stack-oriented interact loops;

That may be insoluble.  I'm not sure how much it matters.

    Tom> slow language;

Maybe, Moore's law helps

    Tom> slow text handling;

I don't see it, except in Mule.

    Tom> anemic subprocess mgt; etc

    Tom> my bet would be that 'dialog buffers alone would find a lot
    Tom> of use

You're wrong.  They've been available for years, and nobody uses them,
or even requests them.  They'd be great in Custom, but Custom is so
fragile and unstable that nobody is willing to rewrite in a way that
makes the quarterly GNU synch harder.  GNU Emacs doesn't support them,
so it's too much pain for too little gain.


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