xemacs vs emacs

[David Kastrup]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> David Kastrup writes:
>
> [...]
>
> Vin's right.  Nobody's going to persuade anybody to do anything
> differently, so let's just end this here.

If there was a way to persuade anybody to do anything, the "differently"
would not be an issue.  I don't care just how the XEmacs developers
choose to have external packages integrated as long as they actually
follow through.

But policies without workers are useless.

> I apologize for offending you.
>
> For my part, I would appreciate it if you would refrain from posting
> on the issue of the package system in general or the AUCTeX package in
> particular, unless you have a proposal that we might actually act on.

If you don't want me to set the record straight, then don't slander me
on publicly available mailing lists, pontificating about AUCTeX and my
purported "objection by principle" of its XEmacs packaging.  Again: I
have never objected, and certainly not "by principle" to anybody
integrating AUCTeX any way he likes into XEmacs (as long as the licence
is heeded) and have supported such endeavors in the past.

At the very least, leave it to the actual XEmacs developers working on
AUCTeX integration into Emacs to comment on my stance.  At least they
have a clue about what is being done by who, and what not, and why.  You
could at least ask them before starting your stories.

To give those willing to work on XEmacs a good point of reference, there
is a fully working XEmacs package provided already by AUCTeX (and has
been for years) which makes very clear what should get installed into
which place (starting from the original tarball) and what additional
files are generated in that course, and what content is supposed to be
in there (you could just check the generated files in, anyway).

I even posted the respective file move/copy/rename information from git
to get from our source tarball to our XEmacs package tarball.  So you
have your policies, you have a complete working reference package
generated from the original source, you have a list of what goes where
from where.

If it still takes years for existing volunteers to get things into place
(by the way, it is not that I have not also tried at some point and
given up in disgust after investing quite a lot of time before reverse
engineering the package layout and generating it manually), it means
that either the package system and/or the connected policies are
horribly broken and don't work for getting things done, or nobody works
on XEmacs anymore, or both.

And I refuse to make either of those my problem or accept blame for it.

-- 
David Kastrup