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

[Tom Lord]

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

Reference for Per's work, please?  If you mean his
Scheme-on-Java-emacs .... well, there's plenty o' practical reasons
why it didn't (or has yet to) work out.  But more to the immediate
point, I haven't heard of him doing anything like the
text-buffer-to-widget-tree mapping I'm describing, so, please, provide
a pointer......


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

Huh?  Are we really this far away from communication?


    > 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

I would expect that exclusive choice to be a single "widget", not
three.   The HBOX would contain a reference to `residency-choice'.
C.f. my comments about the leaf widgets in my proposal quite possibly
corresponding to a composite widget from the toolkit perspective.


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

Don't worry about that for now.   We can add hair for such matters as
necessary and, meanwhile, the simplicity is worth many times more than
the perfect control.


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


Go for the 80% solution.  You have an extensible architecture when
it's needed.



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

No, you don't "do this anyway".  I'm talking about bypassing most of
the input processing that the toolkits offer, and retrofitting them
with an actual Model and Controller for their Views.


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

Right.   So there's a tiny bit of art in designing these buffers so
that things like ordering "works" both when viewed as text and when
viewed as a widget-tree.   So?   


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

I have no idea what you mean.   

Look, start from the widget.el conception.   That's got a perfectly
clear meaning and integration into emacs, right?

Ok, now, in a window displaying that buffer, you can render the
contents of the buffer in an exotic way -- in particular, using a
toolkit.

It's still a text buffer.  It's still the usual interact loop.   It
just happens that the rendering is a bit more indirect than you're
used to.



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

Why?

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


Nothing I requested as considerations about compatability requires any
involvement at all from GNU.   JWZ gets humor value of these stupid
old fights -- I'm not sure what you get.   Is there some political
point here that I'm missing?


    >     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 don't mind it being a fork of GNU.   Actaully, I'm arrogant enough
to think that if this design were nailed, GNU would likely adopt it.


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


Well, the fact that we're "discussing" this kind of stupidity makes me
want to whisper in your ear one more time:  "Hmm... about that
start-from-scratch release-early-release-often emacs.....".   That
would leapfrog all this bullshit.


(rant mode, yes),
-t