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

[Stephen J. Turnbull]

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

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

Details, mere details.  Analogies are like that.

    Tom> In an Emacs window that is displayed in widget mode, the text
    Tom> redisplay engine should not be used at all.

It hasn't been used since 1999.  The redisplay has a general subwindow
facility.  It treats each such subwindow as an opaque rectangle (I'd
like to say "glyph", but that's not correct; changes in one instance
of a subwindow glyph are not reflected in another instance of the same
subwindow glyph---pad++ portals get this right, for instance), and
does nothing with it except to map and unmap.  Tab controls, progress
bars, and other such "native widget glyphs" are subclassed from this.

In particular, that's how the search dialog in dialog-items.el is
implemented.

    Tom> The parameters in (1) are inserted, as text, in the text
    Tom> buffer -- with a syntax that puns as a text-only substitute
    Tom> for the widget.

That's what I was afraid of.  "Show me"; I see a black hole of user
frustration and internal incoherencies here.

You said you don't see an "XEmacs aesthetic".  Well, "parsimonious
encapsulation" is one aspect of it.  ICON notwithstanding, text
strings are not a good way to represent and manipulate hierarchical
data structures.  Lists are, for some purposes.

I think it's a fundamental mistake to make arbitrarily structured
text, where the structure is partially implicit in geometric layout,
the primary representation.  I see the elegance of the idea, but I see
lots of deeply-rooted problems to overcome, too.

I should mention that Jamie Zawinski proposed an architecture based on
a third-party redisplay and a textual redisplay language, in
particular linking to an HTML rendering engine such as Safari or KHTML.
The idea of using "HTML" as an internal API makes me wanna puke, but
something like HTML with a standard DTD might very well work.  This
would give (modulo fixing the search code to ignore tags and translate
entities) similar benefits to those you describe at a cost in
implementing editing functions on plaintext with embedded tags.

Of course, nobody in their right mind would want the HTMLoid text for
normal display.  :-)

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

    Tom> Which other media?

*shrug*  You're the one who says that Emacs has hit a wall because
it's so text-oriented.  That's what attracted me to this thread.

    Tom> With the exception of huge tables, none of those can
    Tom> conceivably have a text-only interface.

Er, what's XPM, then?  And don't forget, Beethoven composed much
wonderful music, during the years he was deaf---he was restricted to a
text-only interface.  I'm sure that some of it was borrowed directly
from music he read with his eyes, and never had aural experience of.

    Tom> Without exception, the "model" for those kinds of widgets
    Tom> doesn't map well onto an emacs-style text buffer.

Amen!  That's precisely why we should force the underlying model to
give them equal status.  It's bad enough if implementing accurate text
representations for any given use case is tedious, and none of the
available text representations covers more than a fraction of the
important use cases.  Let's not put them outside the pale by design!

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

Details, schmeetails.

    Tom> And applications that don't use those hard widgets, but stick
    Tom> to the subset that puns as text, will work on text-only
    Tom> displays.

Just because those widgets are hard for us to implement is no excuse
for making them hard for users to manipulate.

There is also the "recursive medium".  By that I mean the widget
embedding problem.  The basic concept of a widget is that you only
need to know its API to embed it.  But in the text context, the
application programmer is going to need to know the precise _internal_
syntax of every widget.  In your directory example:

------------------------ Tom's version ---------------------------------
        /    .
        /    ..
          +  Makefile.in
        />   PLUGIN/
               PLUGIN/options
               PLUGIN/autoconf
          +  hello.c
------------------------------------------------------------------------

------------------------ new degraded version --------------------------
        /    .
        /    ..
          +  Makefile.in
+----------------------------------------------------------------------+
| # Makefile.in --- root Makefile for BarFu, by BarFustication Inc.    |
+----------------------------------------------------------------------+
          +  hello.c
------------------------------------------------------------------------

Ie, I've just popped up a file viewer (as balloon help, say, giving
head -3 for text files, a thumbnail for images, audio player with a
fast-forward slider if the device supports the medium) over your
directory viewer.  Of course, the file browse window displays an
excerpt from whichever file is "at point" in the buffer.  However,
there's an alternative implementation, which pushes the text down, so
that nothing in the directory listing is hidden by the file viewer:

------------------------ really devo version ---------------------------
        /    .
        /    ..
          +  Makefile.in
+----------------------------------------------------------------------+
| # Makefile.in --- root Makefile for BarFu, by BarFustication Inc.    |
+----------------------------------------------------------------------+
        />   PLUGIN/
               PLUGIN/options
               PLUGIN/autoconf
          +  hello.c
------------------------------------------------------------------------

A text-based parser is not going to like this!

But you really, really want to support it, right?  Isn't this kind of
"just drop in a widget, _any_ widget" application building what you
mean by "expressive power"?  (And even if your opinion of my UI design
skills just rode over Yosemite Falls in a canteen full of Charles
Gallo, shouldn't this kind of idiocy be trivial to _try and see_?)

    Tom> but with this design, you'll be building those abstractions
    Tom> out of the existing attributed-text data structure rather
    Tom> than building them off-to-the-side on top of something like
    Tom> the GTk API.  As I recall, cleaning up and porting widget.el
    Tom> is somewhere on one of the XEmacs TODO lists :-)

Eh, but we will be building paying appropriate respect to the
attributed text data structure anyway, at least if Ben, Mike, or I
review the patch.  The point is not to embed GTK composite widgets in
XEmacs (yes, use complex composites if that's the appropriate level of
abstraction, but that's not the preferred design in most cases), it's
to bind Lisp primitives to GTK APIs.

The point I've taken from your idea is that we _can_ strongly
encourage good, hackable design by our choice of the widget control
language.  We _can_ give naive users "hands on" access to their user
interface.  Your idea of structured buffer text has strong appeal to
me, but I still feel intuitively that it's not powerful enough to warp
us into Emacs TNG.

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

Well, here's an alternative architecture:  Emacs widgets are
represented in Lisp, just as "traditionally" done in widget.el, but
_the text buffer version is *always* realized_, although if GUI is
available its display may (and for normal GUI users, will) be
suppressed.

Buffer point is always in the text buffer (by definition).  Text
gestures (such as C-s) move GUI "action focus" (I'm not sure if this
is the same as keyboard focus for our purposes) and optionally warp
the GUI pointer (wouldn't it be cool if C-s \line RET selected in the
DVI viewer the line segment corresponding to the LaTeX picture
command, and then you could immediately pick it up with the mouse and
change its coordinates by dragging and dropping?---I'm not necessarily
advocating this particular UI, but I'll bet the principle would have
applications).  Mouse gestures that move GUI "action focus" would warp
the buffer's (point), too.

I'm not sure what semantics "C-s" would be expected to have in the
case of text which is visible in the buffer representation, but not in
the GUI representation.  For example, in Custom, [...] is used for
buttons, <> for checkboxes, and () for radio buttons (IIRC).  These
are of course not visible in the GUI, but given this C-s [ has some
appeal as a "jump to the next button" keyboard shortcut.

If the underlying buffer object itself is actually a "widget", with
various "views" (Lisp, text widget, GUI widget) as subobjects, then
(possibly) by pulling variables like point out of the Lisp or text
implementation subobjects and into the parent buffer object we can
make the internal communication required by this model natural.  Maybe
even a lot would be implicit.

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

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

Who said anything about "this design causing pain"?  I have problems
with it, but I may just be totally missing the important points.  If
it's just me, there will be no "political" problems.  (Some XEmacs
people will undoubtedly have personal objections, but I don't see any
project-wide issues as long as it works.)

But you asked for GNU compatibility (which I mistakenly took as "code
which GNU might actually commit to Emacs CVS").  GNU has a coding and
design style that XEmacs people, by and large, dislike.  Personally, I
think pragmatically the XEmacs style leads to better, more robust,
more maintainable code.  YMMV.  Of course, I've also become used to
it.  Some people are quite religious about it, just as rms is adamant
that his style is right (for him and projects he maintains; AFAIK he
does not try to impose it on anyone else).

Do you begin to understand the sense of loss we would feel if we made
the effort to program in the GNU style, only to have the whole thing
rejected by the GNU Emacs project?  :-)

Maybe we should add a fourth freedom: (4) You may reindent the source
code.  :-)

    Tom> The impression I have of existing plans is that you want to
    Tom> add a GTk binding,

That's no plan, that's fact---it's in the stable code, has been since
2001/04/15, when 21.4 was released.  Just ./configure --with-gtk ... .

    Tom> then see what can be done with it.

*Nothing* has been done with it.  *I want that to change.*  That's why
I'm in this thread.

    Tom> If lisp programs are just popping up GTk windows,

That's not what happens.  What happens is that some widget.el widgets
have GUI equivalents.  If (a) a toolkit is available (build-time
option), (b) a GUI version of the widget is available, (c) the user
has enabled GUI dialogs (run-time option), and (d) the context is GUI
(ie, if you select File -> Open from the menubar, you get a file
selector dialog, if you use C-x C-f, you get traditional completion in
the minibuffer), a dialog with structure defined in Lisp will pop up
or (in a custom buffer) a GUI button is embedded.

I doubt this principle is going to change, unless we get a huge influx
of hackers from GTK-oriented projects.

    Tom> isn't that going to lead to questions like:

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

I wish it would induce such questions, but it doesn't.  I think that
basically what happens is that users of traditional Emacs keyboard-
oriented interfaces never see the widgets.  Users coming from the MS
world expect a broken interface, only demanding that it be broken in
the familiar way, which it is, especially on the Windows platforms.

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

It's not.  See above.

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

The answers for XEmacs are the same as they would be under your design.

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

The answers for XEmacs are the same as they would be under your design.


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