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

[Stephen J. Turnbull]

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

    Tom> Divide the text buffer into distinct "screens" -- each of
    Tom> which defines a single, window-filling widget tree.  Each
    Tom> screen will contain a number of leaf widgets.

    Tom> Each leaf widget should have a text property set that spans
    Tom> exactly the text region of that leaf widget.  Each
    Tom> screen-region should have a text property that spans the
    Tom> entire screen, and whose value is the layout specification.
    Tom> The layout specification can be whatever you currently use: a
    Tom> cons-pair tree of HBOX and VBOX lists is fine.

    Tom> The leaf nodes of the layout specification tree should be
    Tom> markers -- each marker pointing to the textual location of
    Tom> the appropriate leaf widget.

["Markers" and "overlays" and "text properties", oh my!  Just wrap
each leaf widget in an extent and be done with it, for heaven's sake!]

This is basically a widget.el display buffer, except that widget.el as
currently implemented handles only a vertical list of leaf widgets,
displaying tree structure by indentation.  And of course it knows
nothing about constructing composite native widgets.  Your notion that
the textual position of the widgets in the "source" buffer need not
correspond to their position in the "display" window would really
improve widget.el, I think.  But given the similarities between what
you're saying and what Per did, I have to wonder whether the
differences justify your optimism.

    Tom> Why does that work out nicely?

I suspect that in practice it doesn't, since you've separated layout,
grouping semantics, and display text from each other.  I think you end
up either restricting UI appearance to something like a Customize
buffer with nicely beveled and shadowed borders for the fields, or
creating multiple places where changes in a single UI element must be
coordinated.

For example, note that your hbox could be

(foreign-marker in-state-marker us-out-of-state-marker)

with leaf text

v--------------------+ v------------------+ v----------------+
[] California Resident [] Other US Resident [] Non-US Resident

In this example it's a no-brainer, but I see no reason to suppose it
will always be this easy.  For example, I can imagine that in the case
of a long list of radio buttons, the UI designer would want different
sort orders for the two interfaces.  In the text buffer I suspect a
Custom-like layout with one vertical list, and layout nesting
represented by indentation is the way to go.  You probably want
alphabetical sorting in many cases.  But in the widget representation,
this would be officiously ugly.  Instead, you probably want (1) to lay
out the list horizontally, breaking it into lines if it's too long,
and (2) for efficient use of space, labels in each column should be of
approximately the same width.

In fact, in many cases there will be no benefit to imposing an
internal layout in the text case, but the designer will have distinct
ideas about laying out the GUI.

    Tom> One immediate benefit is that since events are routed through
    Tom> the text buffer interpretation, I have the full range of
    Tom> Emacs commands available for editting the text entry widget,
    Tom> regardless of the capabilities of the underlying toolkit.
    Tom> (E.g., I might C-x r g A (aka M-x insert-register A RET) --
    Tom> or type "l o r TAB" to invoke M-x arch-archive-name-complete).

You do anyway, since the native widget can dispatch to a Lisp callback.
(This is not automatic currently because of the Windows/C orientation
of the original contributor, but it wouldn't be hard to do.)

    Tom> And then slickness like this:

    Tom> Using the widget display, I decide that I want to push the
    Tom> preview button.  Sure, I could reach for the mouse -- but I
    Tom> could also:

    Tom>        C-s p r e RET RET

We already have this in text-based customize buffers.  But with a
straightforward implementation, this is going to result in surprising
behavior in widget-trees.  See above for sort order.

    Tom> 2) Edit the leaf widgets directly in the text buffer, with
    Tom>    instant feedback in the widget tree

This is possibly _very_ hard to get right because of the disconnect
between text display, leaf grouping semantics, and layout semantics.
What I mean is that you have a choice of guessing what the user meant
by a change in the text buffer, and then updating the widget tree when
you find out what he meant, or going modal on him, and forcing him to
tell you what he meant before you update the tree.  Or you can go the
libglade route and provide an interface which is shaped by the non-
text aspects which are only artificially visible in the text buffer.

It's worth trying, but I suspect that not very far into the project
you will face a "unified UIAPI vs. esthetic design" choice.

    Tom> c) How far are you, really, from being able to mutually merge
    Tom> with GNU emacs.  Two forks is cool -- one-way forks is lame.

    >> There will be no merger.

    Tom> If the functionality sketched above can be implemented, I'd
    Tom> ideally like to see it available for both Emacs (whether or
    Tom> not or regardless of when it became part of GNU).

I would too, but it's highly unlikely.

For example, you have important parts of the implementation spread
across text properties, markers, and maybe overlays.  XEmacs
developers would of course use extents, and the more abstract concept
clearly has advantages in this context, as it maps directly to the
idea of "widget as active, bounded region of text", which none of the
more specialized concepts in GNU Emacs do.  (Overlays probably come
closest, except that you have to jump through hoops to "attach them to
the widget", which is surely why you chose text properties instead.)

XEmacs already has Lisp implementations of layouts and native widgets.
These will be unacceptable to GNU because of irreducible doubt about
legal issues (maybe even assignment refuseniks), and coding style.

XEmacs already allows callbacks to Lisp from redisplay; I doubt GNU
Emacs does, though I would be pleased to hear otherwise.  This is
certainly something one would not want to do without!

But GNU (on past form) will demand that the contributors do the work
to reimplement any wheels and for any cosmetic surgery, while
insisting on final approval for all design.

    Tom> I'd ideally like to see it implemented in a way that doesn't
    Tom> create _new_ legal problems for merging into GNU.

How much duplicative effort are you willing to pay for this?  The
straightforward way to avoid legal problems is to do the GNU
implementation first, but it's probably technically more difficult,
and the temptation to submit it and try to get it merged would be very
strong, resulting in "compliance" costs with no guarantee of eventual
acceptance.  I don't think XEmacs will supply any manpower for such a
plan.

    Tom> I'd ideally like to see it implemented in a way that programs
    Tom> using the feature are portable between the Emacsen.  That's
    Tom> all.

How can it be portable if GNU doesn't implement?

I agree it's desirable in the abstract, but I think it will double the
cost and halve the available manpower, for very dubious benefit.

Think carefully about it.

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