Re: Whereto next?
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> Maybe it isn't all too bad if I can't indulge in fast exchanges...
You and me both, Brother Kastrup!
> > There's nothing wrong with that, either. Do we need two projects to
> > do that for Emacs? I don't know.
>
> I was talking about what makes a single project with a large programmer
> and user base desirable. I consider Emacs and XEmacs separate projects.
> What I was saying that the large platform and developer base of Emacs is
> an advantage for me as a mixed Emacs user/developer.
Sure, I understand that. And you've been pointing out for years that
you're not getting it from XEmacs. I recognize the value to you and
your users, and I recognize the cost to XEmacs and its users if you
decide you can't deal with it any more. But I can't make XEmacs
developers work differently from the way they do, and I can't do the
necessary work alone.
Sigh. Have you considered playing tennis? I find it amazing how hard
it is to bring a point across when you are on the court. You do this
zen-like watching thingie, and the next thing the spectators remember is
that the point veered off-course in all directions never hitting where
it was headed. Was that the backhand? Whatever, let's try again.
You asked for intermediate goals. The topic I put forward was that I
consider a core and API synch to Emacs-22 important so that you make
synching of post-20.3 code easier. That is a strategic investment of
resources since it levels integration access to packages not maintained
primarily for XEmacs.
Now you turn this into an AUCTeX complaint again. AUCTeX, at least the
main mantras being recited, does not really come into play here. That
is since AUCTeX still, in spite of all the thrashing I get for this
decision here and elsewhere, actively supports XEmacs, to a degree where
we offer a functioning XEmacs package which gets ignored. But that's
not an API problem. AUCTeX may be relevant only in so far that in
_spite_ of all our efforts and in _spite_ of ignoring the flak and
downstream sabotage of our efforts it has become impossible to have
AUCTeX work as well under XEmacs as under Emacs. The ancient font-lock
code which is inflexible, inefficient and buggy is probably one of the
worst offenders, with filling coming in afterwards. It is one of the
reasons for compatibility cruft in the AUCTeX code base.
We are getting in the situation that XEmacs can't be made to work well
even by package authors bending over backwards. But this is not what I
have been talking about primarily. I was talking about making things
easier in case that some package author is _not_ particularly interested
in XEmacs and somebody else has to do the honors.
It is my opinion that XEmacs development should strive to make it easy
to pick low-hanging fruit like that rather than deriding upstream until
the fruit get actually thrown at them (while the latter approach appears
to work well with AUCTeX, it depends too much on social engineering
rather than software engineering to be reliable). An API/code base
synch is an efficient and strategic investment of developer resources.
Of course, resources need to be there to do that kind of investment. I
don't know whether they are. But you were asking about good places to
invest, and I did not think it amiss to point out one place I thought
worthwhile.
So I'm asking our developers and users where *they* want to go.
> Let's say "considered, taken into account, weighed" or something
> like that. You would not expect to be able to actually set project
> development practices for Emacs, would you? That's really the
> choice of those doing the job, the project maintainers.
Of course I don't expect to set policy. But it's not just me and you
and ESR whose input is being thrown aside. Stefan and Yidong do not
have the appropriate freedom to experiment with new ways of doing
things, AFAICS.
They are working under project constraints. Those constraints
apparently don't preclude work being done and seem acceptable to them.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta