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

[Stephen J. Turnbull]

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

    Tom> A couple of things:

    Tom> a) I can't even freekin' build out of the box on my box.
    Tom> This is lame.  The particular error message from configure
    Tom> says that it can't use certain combinations of options with
    Tom> the particular version of GCC that I use (and that I use for
    Tom> good reason).

What system and what is the error message?  What version of XEmacs?
Did you get it from xemacs.org or from a ports distribution?

    Tom>    Well, fine -- then don't use those options and compile.

I assume you've unset CFLAGS in the environment, and didn't use
--cflags?  The decision not to override those was deliberate, although
controversial.

    Tom>    I'm scared to imagine what other kinds of 3rd party
    Tom> packages i'll have to install and pass as params to Xemacs
    Tom> configure before it can show off.

XPM, Athena widgets, Xmu.  If they're in the standard places (/usr,
/usr/local) they will be autodetected.  If they're in a /usr/pkg tree,
you should be able to get by with just --site-prefix=/usr/pkg,
although I think they're normally autodetected there on *BSD systems.

The facilities I'm talking about require XPM support (to draw buttons
and stuff) and Athena widgets.  Won't be pretty with flat Xaw, but you
can fix that with a prettier widget set.

    Tom> b) I have the general impression, when you start talking
    Tom> about glyphs, that you mean you can put up a text buffer in
    Tom> which there are some embedded widgets.  That isn't what I
    Tom> proposed.

Yes.  The text can be empty, which is inelegant, but that could be
fixed.

    Tom>    Rather, I want certain buffers that, when I have a window
    Tom> on those buffers, the emacs text redisplay isn't involved at
    Tom> all.  Instead, there's a widget-tree in that window -- whose
    Tom> structure is (dynamically) determined by the contents of the
    Tom> text buffer.

You're right, this is not what we're doing.  What we have is a widget
tree whose structure and content is determined dynamically by Lisp
code.  Of course this could be computed, or (read) from user-supplied
text and (eval)'d.  I don't see the advantage in using (presumably)
unstructured text over Lisp code, especially in this context where a
lot of what we're doing looks like TeX's "a vbox containing a list of
hboxes containing a list of vboxes containing ... a list of primitive
functional widgets".

Show me (examples of) the proposed buffer contents and explain the
desired semantics.  I don't see how this can work to advantage.  As I
said, there was some messing with it, but basically you end up serving
both masters poorly.  The text gets cluttered with junk that is ugly
(like the *Note: tags in Info or the ALIGN attributes in HTML tags),
and the widget technology is constrained by the ambiguity of free-form
text.

    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.  It's not our choice, it's GNU's.  The offer
on the table is "abandon existing XEmacs code and reimplement it from
scratch in GNU Emacs."[1]  Oh, and "forget about abstract data types
and orthogonal APIs; they don't fit our programming style."  Not to
mention, "of course we'll look at all contributions, but the GNU
maintainer will make the final decisions on the basis of GNU's needs."
The same setup that was offered to Lucid---nothing has changed in 12
years, I think nothing will in the next 12.

Besides, it's nothing that individual programmers can't decide to do
on their own.  Some do.  Most of us have individual agendas that make
that offer highly unattractive.

    Tom> I'm trying to sketch a practical plan for improving it that
    Tom> is better than the plans you have advertised (with all due
    Tom> respect).

"All due respect" ain't much.  It's not really a plan, it's a
collection of more or less independent, partially implemented features
that could be reworked into a plan.  Now is a good time to do that,
and I appreciate your suggestions (more than I understand them, at
this point ;-).



Footnotes: 
[1]  An alternative would be to clarify the copyright status and get
assignments.  A thankless task (literally; rms characterized Steve
Baur's two-year campaign to get XEmacs developers to assign their code
to the FSF as "useless to me" ... true, I think, but brutal).

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