[Gnu-arch-users] [OT] fixing emacs (was Re: Architectural renovation)

[Tom Lord]

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

In addition to your notes I had a look at these:

  http://www.cs.indiana.edu/elisp/gui-xemacs/arch.html
  http://www.xemacs.org/Architecting-XEmacs/dialog-boxes.html

Here's what I recommend instead.  This is actually somewhat different
from my plans for what a whole new emacs would look like.

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

Why not provide that via text buffers that are specially rendered?
Create a special, buffer-local variable:

  (defvar buffer-display-style nil
    "If the value of this variable is:

nil    -- display the buffer in the usual way
dialog -- display the buffer as a form

Other values may be given special interpretation in the future
but values not otherwise defined are treated as nil.")

  (make-variable-buffer-local 'display-buffer-as-gui)

The contents of a 'dialog buffer should be a textual form (similar to
widget.el), using text properties to store hook functions, display
hints, and so forth.  The form should look and act like a form if
displayed as ordinary text.

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

Note that this has a very unusual yet pretty easy programming
interface.  For example, to add an item to a list-widget, my program
moves the point to the list as it occurs in the buffer and inserts the
text of the new list item.  Another example: I get to use buffer local
variables and the content of the buffer to keep track of the state of
my dialog.

A nice property of this arrangement is that it works equally well on
text terminals and graphical displays.

A like-Glade-but-using-sexps interface to dialogs is easy to envision
on top of 'dialog buffers.

I realize that idea might sound like a "cheap hack" and far less sexy
than a complete GTk binding.  Nevertheless, I think it's a simple way
to enable a lot of cool programs _without_ radically altering the
programming model, limiting future development, completely abandoning
ttys, etc.

What about "beyond dialog boxes"?  I think there are three directions
to go: more user-friendly window and frame management; better
mini-buffer management for users who like dialogs; GUI components that
are more complicated than dialog boxes.

1) Windows and frames: I think it would be awefully nice to sqeeze into
window-separators and modelines some tiny controls for splitting
windows and deleting windows.  I think it would be nice to add to the
menu-bar some (button-like, not menu) controls for creating new frames
and destroying frames.  The keybindings for these operations are
obscure and this is functionality that I think new users should be
agressively led to learn.

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

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

While I can imagine easy ways to map small and simple tables onto
text, large tables fail.  Both large tables and structured drawings
require a spatially-accessed data type, which a text buffer is not.

Large tables might be displayable on ttys, but let's assume for now
that that isn't the goal.

Suitable spatial types (say, rtrees and sparse arrays) can be added as
new, primitive lisp data types.  In a 'dialog buffer, they can be
stored as a text property rather than as text.


There are still the big insolubles -- stack-oriented interact loops;
slow language; slow text handling; anemic subprocess mgt; etc -- all
the things I previously mentioned.  Nevertheless, my bet would be that
'dialog buffers alone would find a lot of use -- and it seems to me
like an elegant generalization of the existing environment.   At least
it's the kind of solution I can imagine wanting to use myself.

-t