"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> The reason is, that there is no benefit to keep this
compatibility in
> Tramp.
Of course there is. Major new features that depend on packages like
dbus.el won't work in XEmacs, but bug fixes and many pure-Lisp
improvements will, I'm sure. For example, the recent Mac OS X issue
(Mac OS X has a hard limit on the length of a named pipe or Unix
domain socket name, or maybe just the latter) was addressed much more
recently than 10 years ago. Heck, Apple didn't invent it until a
couple years ago. :-)
It's up to you whether the possibility that you will address issues
(heck, after the Bash envvar hack, I wouldn't bet that there aren't
bugs in TRAMP from 1999! ;-) that affect XEmacs users is worth the
effort to keep an "XEmacs clean" code base, but it's not "no
benefit."
Since I am engaged in Tramp (2002), no XEmacs hacker has jumped into
serious Tramp development. The only one I'm aware of was Daniel Pittman,
and this was even before I've started. This is another reason for
stopping XEmacs support (you know, Tramp maintenance is almost a one man
show, except the contributions from Jürgen Hötzel for tramp-adb and
tramp-gvfs).
You also seem to be unaware of some of the syncs that have taken
place
in XEmacs 21.5 (which is the recommended version for users who are
willing to report bugs, and don't insist on near bulletproofness):
Maybe. I have always been told that XEmacs 21.4 matters.
> All new features which have arrived in Tramp over the last 10
years
> are almost useless in XEmacs, because some of the underlying magic
> file name operations do not exist in XEmacs (for example
> process-file, start-file-process),
start-file-process is implemented in 21.5. I'm not sure how far
SXEmacs has progressed on such syncs.
Well, in my book there are 15 magic file name operations not available
in XEmacs 21.4. See the comments in tramp-file-name-for-operation. The
situation might be better with XEmacs 21.5, but not dramatically
better. And file-remote-p has a different argument list, which is
essential for Tramp compatibility.
> I'm willing to support Tramp 2.2.13 in the XEmacs
repository in case of
> serious problems.
That sounds like a reasonable compromise to me. I hope the bug in Mac
OS X I mentioned above would qualify as "serious"?
Yes. But I won't fix anything proactively, pls report problems/bugs. And
of course, every (S)XEmacs hacker is free to sync with future Tramp
releases. I'm still willing to support such an activity. The keyword is
*support*, not *perform*.
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta