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

[Stephen J. Turnbull]

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

    Tom> Reference for Per's work, please?  If you mean his
    Tom> Scheme-on-Java-emacs ....

No, I'm talking about a different Per.  Per Abrahamsen, who wrote most
of widget*.el and custom*.el.

    Tom> Huh?  Are we really this far away from communication?

Not really.

You're talking about a generalized "display table" that automatically
maps "text gadgets" to GUI features.

For example, a couple of days ago somebody asked on comp.emacs.xemacs
why when he has "abcd" in a buffer, does rot13-other-window on the
buffer getting "nopq", and kills "no" in the rot13 window, when he
yanks he gets "ab".  Simple: the display-table hack effectively does
rot13 on redisplay's font indices, not on buffer contents.  So there
is nothing immediately accessible to Lisp which knows or cares whether
the user is seeing "abcd" or "nopq", unless you actually introspect
the display table.  Somewhat more generally, you can imagine a mode
which allows you to view and edit regexps in "egrep" syntax, and
automatically converts them to elisp regexps in the buffer (this isn't
possible without changing the buffer currently).  Then there's
preview-latex, which allows you to write TeX but see math.  The
closest in spirit, although most limited in functionality, to what
you're talking about is the rot13 display-table hack, of course.

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?

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.  An improvement over tab
groups, no doubt, but how does this generalize to "other media"?

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?  :-)

    Tom> We can add hair for such matters as necessary

Heh.  Famous last words....

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

    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.

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

GNU compatibility:

    Tom> I don't mind it being a fork of GNU.

Oh.  You mean, adopt non-GNU (existing XEmacs or newly-developed)
techniques where appropriate and convince us to adapt to whatever
version of Emacs you fork where that would be better?  But I wouldn't
consider that "portability to _GNU_ Emacs".

    Tom> Actaully, I'm arrogant enough to think that if this design
    Tom> were nailed, GNU would likely adopt it.

If the project itself looks like it will succeed, it makes a _lot_ of
sense for you to bet your time and effort on that, since you want this
architecture anyway, you're comfortable with the GNU aesthetic, etc.
If GNU doesn't adopt, you'll still feel at home.

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


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