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

[Stephen J. Turnbull]

The thread seems to be coming to a point where further discussion
requires code on the table, so I'm probably going to be slow in any
further responses.

Not to mention that with the delays at GNU, the usually niggling
annoyance of having two closely related subthreads is resulting in
serious cognitive dissonance for me.  (Hey, didn't I write that 5
posts ago? ... I did, it just wasn't delivered until much later.
Boy, those guys must _really_ be getting hammered by SoBig and
friends.)

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

    Tom> BTW, why does the xemacs.el version of "help.el" contain the
    Tom> string "-menu-" but the Emacs 20.3 version does not? [1]

Because GNU Emacs not only presents most (or all?) application
programmer-relevant events as key events, but implements them that
way, too.  XEmacs implements a number of different kinds of basic
events.  I haven't pressed very hard, so basically all I know is that
the people who did it this way considered it the RightThang[tm].

    Tom> As far as I can tell, generalized subwindows and glyphs
    Tom> generalize the idea of frame and window decorations --
    Tom> formerly limited to just menu bars and scrollbars. [1]

That's right.  You're getting hung up on the fact that XEmacs as
currently implemented will probably suck for production use of the
facilities you want to build.  And a breadboard circuit sucks for
embedding in smart ID cards, too.  All I'm saying is that you can
probably build what you want to in XEmacs Lisp without too much C
hacking, and then what needs to be faster can go into C, what clients
should not use can be encapsulated behind private interfaces, etc.

    Tom> *) You can get two copies of it with M-x split-window

You can't do this yet with arbitrary subwindow glyphs, because we
don't automatically blit from one subwindow to another instance of the
same glyph.  But with all other types you can (for those that are
visible in a window).  [By using specifiers, you can even give a
single glyph different appearances in different windows.]  Obviously,
with static data (character glyphs, pixmaps, etc) this is not an
issue, it's no harder to blit from the source data than it is from an
on-screen copy, and often easier because of the GraphicsExposure issue.

Unfortunately, AFAIK there is no general way to redirect window output
of a client to a pixmap from outside the client.  However, if there's
a good reason to use subwindows _inside_ of XEmacs, we can certainly
trap those calls (eg, by providing a standard internal API for
allocating a window) and use a pixmap buffer to implement replication.
But most internal XEmacs clients of that code simply regenerate their
drawing calls for each instance of the glyph anyway.

All the rest of your "you can'ts" are "You're not supposed to be able
to do that with the primitive facilities, but you can build something
that does with the primitive facilities."

    Tom> You don't like the idea of parsing text.  That's fine --
    Tom> there's other ways to do it.  However, I think there's some
    Tom> desirable properties of that idea to preserve, including:

    Tom> (a)externally represent an interface by a file with property
    Tom> annotations

    Tom> (b) "(point)" is meaningful.

    Tom> (c) most lisp programs should be agnostic about being called
    Tom> from a text display of the buffer or a GUI display of the
    Tom> buffer.

    Tom> (d) the buffer representation of the interface should double
    Tom> as such a display.

    Tom> Take it as hypothesis that a design satisfying (a..d) is
    Tom> possible and come up with your own!

I don't think that (d) is feasible, for the reasons given.  However,
most of the implementation of what I think is the right design (a
representation-to-be-named for the buffer itself, plus automatic
redisplay to text or GUI windows, separately or simultaneously) and
of your desiderata (a)--(d) should be common (in fact, in my design
there would have to be a text-to-RTBN translator in some sense, make
it explicit and then the implementation could be used for your design).

    Tom> No -- I don't care about arbitrary generality.  This is
    Tom> Emacs, not Java.  I care about the greatest amount of
    Tom> generality that "fits" -- which may very well turn out to be
    Tom> more useful than Java.

C'mon.  Expressive power means big chunks.  If you can express chunk A
in the system, and chunk B in the system, then it's natural to want a
combinator to "merge B into A".

I can't prove that you're wrong; I know that what I propose will work
(it's your proposal with some constraints relaxed).

    Tom>     The generalized subwindow / glyphs stuff doesn't appear
    Tom> to work as i would have expected.

Glyphs are very low-level, they interface the Lisp world to the
redisplay world.  You may be right that they should _not_ have Lisp
visible callbacks, only produce events.

    Tom>     You wonder why people aren't taking that functionality
    Tom> and running with it.

Not really.  What I'm wondering is "why aren't people saying 'but for
heaven's sake why did you stop after doing 50% of the job?!'?"

The fact is that they just don't seem to care.

    Tom>     And I think it could also use a different style of menu
    Tom> -- not pull-downs but a compact hypertext of commands divided
    Tom> into categories.

You mean like the way a current completion buffer on a large directory
looks, but sorted by file type, or by extension, or something like
that?  Plus appropriate annotations, maybe?

    Tom>     Above all, I want _uniformity_ -- so that these extra
    Tom> decorations simply fall out of my major mode definitions
    Tom> without having to do much else besides that --

You'll be happier with GNU Emacs, then, if they have the primitives to
support it.  Or maybe not; I'd be curious to see.  I think the things
that bother me about GNU's implementations probably won't bother you
at all.

    Tom> so that users really _get_ the taxonomy of frames, windows,
    Tom> and buffers at a visceral level.

What do you mean by that?

In my experience, if it matters whether something is a buffer or a
window, then both users and application programmers get confused and
unhappy.  Ditto frames.  Users think in terms of frames (which they
call windows, and interact with through the window manager), fields
(where they type, might be big and flexible, like an emacs window, or
small, like a zip code entry field), and gadgets they can manipulate
simply with the mouse (like buttons, checkboxes, and scrollbars).
They generally don't like them to interact in a complex way.

Programmers think in terms of buffers, which they expect to be
equivalent to windows (thus the confusion of the OP on c.e.x about the
rot13 hack I described).  Programmers ignore frames, which are the
business of the user and the window manager.  And they actively detest
gadgets, because they think as you do: they're guano that should just
"fall out".

(N.B.  When I say "users" and "programmers", I'm really talking about
the people that ask questions on c.e.x and xemacs-beta.)

    Tom>     Yes, I understand that for toolbars you're pretty much
    Tom> there (although why they don't generate events of types like
    Tom> [toolbar save-buffer] I can't figure).

If I read the logs right, the same guy who did subwindow glyphs did
toolbars.  He used to be an X programmer, now his day job is in the MS
Windows world, and he much prefers that environment for GUI programming.
"Good-enough" programming is the order of the day.

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