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

[Tom Lord]

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

    > So allow the spec for a text-widget to be a (probably) contiguous
    > range of characters, not a single character, and the codomain of the
    > mapping to be set of GUI features, not a glyph, add some scaffolding
    > to wire Emacs events to GUI redisplay and internal state changes
    > instead of vice-versa, and we're there.  Right?

It sounds pretty close but some ambiguities make me think you haven't
quite got the idea yet.

In an Emacs window that is displayed in widget mode, the text
redisplay engine should not be used at all.  Instead, the screen-space
for the window is entirely given over to the top widget of the widget
tree.

Suppose I'm editting one of these dialogs in text mode, then M-x
split-window-horizontally, and put one of the two windows in widget
mode.  The display might look like:


        +--menus-----------------+
        |                        |
        |  this space managed    |
        |  entirely by a widget  |
        |  tree                  |
        |                        |
        +--modeline--------------+
        |                       s|
        | text mode             c|
        | window here           r|
        | usual redisplay       o|
        |                       l|
        +--modeline--------------+


and then, right -- as the text is editted, or its properties changed,
that is turned into changes to widget states.    As input invents
happen to the widgets, those are translated into ordinary Emacs
events, ultimately causing changes to the text or its properties.

Think of the widget-tree as a "scope" peering at the contents of the
buffer in a funny way.   Other than that, it's an ordinary buffer.


    > Where the disconnect is is that I'm asking for the specification
    > _language_ for the text-widget.  So far, you've said nothing about
    > that ("it's text"), and put some of the important stuff out on text
    > properties.  If you put enough out there, all you'll have left in the
    > buffer is a searchable list of labels.  

For each leaf-widget type, identify three sets of parameters for that
type of leaf-widget:

        1) Parameters that make sense in a text-only interface to
           to the widget

        2) Parameters that only make sense when the widget is shown
           graphically

        3) Parameters that control (as text properties) Emacs' _text_
           display of the text version of the widget, but that also
           have significance for the graphical picture of the
           widget.  E.g., visibility of text.

The parameters in (1) are inserted, as text, in the text buffer --
with a syntax that puns as a text-only substitute for the widget.  The
parameters in (2) and (3) are stored as properties of that text.

Let's suppose that I have an "outline widget" such as might be used
for a directory editor.    It let's me expand or hide sub-trees of the
outline, make selections of items from the outline, and it let's
programs set per-item "attributes" (e.g., file-type).

The text buffer contents might look like:

        /    .
        /    ..
          +  Makefile.in
        />   PLUGIN/
               PLUGIN/options
               PLUGIN/autoconf
          +  hello.c

A typical GUI outline widget let's you insert a list of items in a
particular order, specifying (somehow) nesting level.  In this case,
that list is (as parsed from the text buffer):

        .                       1
        ..                      1
        Makefile.in             1
        PLUGIN                  1
        PLUGIN/options          2
        PLUGIN/autoconf         2
        hello.c                 1


The gui widget might let you indicate which items are selected.  In
this case, that'd be:

        Makefile.in
        hello.c

Note that inserting a + in the right column of the text has the side
effect of changing the selection in the widget.

The gui widget might let you add glyps such as "file-type".  In this
case, these items have the glyph indicating "directory":

        .
        ..
        PLUGIN

I'm sure you can see what the grammar is there.  Something like:

        item_list       =       (item "\n")*
        item            =       glyph "." section spaces item-name
        etc.

If I change the (text) visibility of the sub-tree of PLUGIN, that too
gets translated to changes to the widget.

There's a design choice.   You can either "build-in" the mapping from
text buffer to leaf-gui params, or you can let programs manage it.
In the latter case, we're still talking about a high-level interface,
not just a binding to something like the GTk API.


    > An improvement over tab
    > groups, no doubt, but how does this generalize to "other media"?

Which other media?   The vast majority of widgets map perfectly well
into that design and the text-buffer format of them works just fine as
a text-only interface to them.   Won't it be nice to have many of your 
GUI-in-emacs apps _also_ work, even over low bandwidth connections, as
text-only apps?

_Some_ widget types don't map so nicely into a text-only interface:
huge tables, canvases, and pixmaps to name three.

With the exception of huge tables, none of those can conceivably have
a text-only interface.  Without exception, the "model" for those kinds
of widgets doesn't map well onto an emacs-style text buffer.

So, for those widget types, you need some additional data types.   For
a huge table, you might want a new primitive lisp type which
represents a sparse array, for example.

Those widget types fit into this design as well (store the data
structures in properties) but do fit your description of "If you put
enough [in properties], all you'll have left in the buffer is a
searchable list of labels."  So what?  You'll still have a situation
where Emacs lisp programs are editting an abstract model, and that
model is automatically driving the display (possibly in multiple
windows, etc.).  And applications that don't use those hard widgets,
but stick to the subset that puns as text, will work on text-only
displays.




    > So, here I am hanging in mid-air, clinging to an undifferentiated
    > string, and you've kicked my nice stable widget-pyramid out from
    > under me and I've got no visible means of support except for this
    > string....  Do you blame me for my weak faith?  :-)

You still have a tree structure, stored as a text property of each
screen, controlling the layout of the leaf widgets.   You _also_ have
the as-text pun so that things like isearch, hippie-expand, and
ispell-word "just work".

You can still make an as-object-oriented, hierarchical-as-you-please
programming interface to these widgets -- but with this design, you'll
be building those abstractions out of the existing attributed-text
data structure rather than building them off-to-the-side on top of
something like the GTk API.  As I recall, cleaning up and porting
widget.el is somewhere on one of the XEmacs TODO lists :-)


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

    > No, _you_ have the extensible architecture.  I have an otherwise
    > unstructured string.  :-)

It's perfectly well structured -- it just puns as both ordinary text
buffer and as a parsable set of widget parameters.

We're not arguing over "structured vs. not structured" -- we're
arguing about how to _represent_ the structure.  The representation
I'm advocating "puns" as a text-only interface and so it's transparent
to many Emacs lisp programs and works well on text-only displays.



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

    > At that level, you're right, we don't do this.  All I'm saying is that
    > we have enough primitives that we could maybe hack it in XEmacs Lisp
    > as it is now.

If you have, say, a GTk binding, and if the redisplay engine can be
hacked to give an Emacs-window over to a widget tree, then yes -- you
have enough mechanism to implement what I've described.   I'm not sure
that's the best implementation tactic but it might work.



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

    >     Tom> Why?

    > Because one would like to layer this Lisp on Lisp, and not have to
    > write new C code in order to create new combination widgets.

I think there's a middle way.  You can write a little bit of C code
for each toolkit that you support to build up the standard leaf
widgets (e.g., a scalar-value slider that has a toolkit-independent
set of parameters).  Thereafter, you'll be building composite widgets
much as you do now -- describing a layout, describing parameters to
the leafs -- only your descriptions will pun as text-only interfaces
to the same composite widgets -- they'll happen to be represented as
such.

    > >From the XEmacs point of view, though, it would involve sacrificing
    > _our_ aesthetic and convenience.  The main payoff to us would be the
    > benefits that all Emacs users and maintainers would get from having a
    > stable, common platform.  If GNU doesn't adopt, we're just hurting
    > ourselves for nobody's gain.

The idea that you would be "hurting yourself" is premised on the idea
that adopting this design involves some kind of sacrifice.   I don't
see that.   I don't see any indication anywhere of what your aesthetic
is in this area.

The impression I have of existing plans is that you want to add a GTk
binding, then see what can be done with it.  If lisp programs are just
popping up GTk windows, isn't that going to lead to questions like:


        * why doesn't hippie-expand/isearch/ispell-word work in a
          text-entry?   why doesn't isearch work in a list-selection
          widget?

        * why is it necessary to implement every change to
          customize.el twice, once in customize.el and once
          again in customize-gtk.el?

        * when do you plan to upgrade to GTk 3.0?  How much
          of my old GUI-Emacs code will I have to change?

        * why is my GTk-emacs program so much slower than the
          equivalent program in Python?        


Pick a design that leverages the skills of existing Emacs users and
Emacs lisp programmers -- at a deeper level than "happens to use Emacs
lisp".


-t