XEmacs support will be discontinued for new Tramp versions

[Michael Albinus]

Hi,

I have just merged the new Tramp 2.2.13 into the XEmacs package
repository. This will be the last Tramp version with XEmacs support.

The reason is, that there is no benefit to keep this compatibility in
Tramp. 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), or because needed GNU Emacs packages are not
available for XEmaxs (for example, dbus.el). Most of XEmacs users won't
notice this stopped support, I guess.

I'm willing to support Tramp 2.2.13 in the XEmacs repository in case of
serious problems. And I will also keep the separate remote file name
syntax ("/method:***@host:" vs "/[method/***@host]") in Tramp. If you
ever use GNU Emacs, set `tramp-syntax' to `sep', and you should get the
syntax you're used to.

Best regards, Michael.

[Steve Youngs]

Post by Michael Albinus
I have just merged the new Tramp 2.2.13 into the XEmacs package
repository. This will be the last Tramp version with XEmacs support.

To clarify, will the existing XEmacs code remain, or are you planning to
remove that in future release?

Post by Michael Albinus
The reason is, that there is no benefit to keep this compatibility in
Tramp.

There is for (S)XEmacs users and developers. :-)

Post by Michael Albinus
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), or because needed GNU Emacs packages are not
available for XEmaxs (for example, dbus.el). Most of XEmacs users won't
notice this stopped support, I guess.

My guess is that these things simply haven't made anyone here itchy
enough to scratch.

[Michael Albinus]

Post by Steve Youngs

Post by Michael Albinus
I have just merged the new Tramp 2.2.13 into the XEmacs package
repository. This will be the last Tramp version with XEmacs support.

To clarify, will the existing XEmacs code remain, or are you planning to
remove that in future release?

There will be a new release line Tramp 2.3.x, where XEmacs compatibility
code (and also GNU Emacs 22 compatibility code) has been removed.

Post by Steve Youngs

Post by Michael Albinus
The reason is, that there is no benefit to keep this compatibility in
Tramp.

There is for (S)XEmacs users and developers. :-)

They still have Tramp 2.2.13.

Best regards, Michael.

[Stephen J. Turnbull]

Post by Michael Albinus
I have just merged the new Tramp 2.2.13 into the XEmacs package
repository. This will be the last Tramp version with XEmacs
support.

Thank you for all your support over the years!

Post by Michael Albinus
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."

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

Post by Michael Albinus
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.

Post by Michael Albinus
or because needed GNU Emacs packages are not available for XEmaxs
(for example, dbus.el). Most of XEmacs users won't notice this
stopped support, I guess.
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"?

[Michael Albinus]

Post by Stephen J. Turnbull

Post by Michael Albinus
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).

Post by Stephen J. Turnbull
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

Maybe. I have always been told that XEmacs 21.4 matters.

Post by Stephen J. Turnbull

Post by Michael Albinus
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.

Post by Stephen J. Turnbull

Post by Michael Albinus
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.

[Stephen J. Turnbull]

(you know, Tramp maintenance is almost a one man show, except the
contributions from Jürgen Hötzel for tramp-adb and tramp-gvfs).

IOW, only one GNU Emacs hacker has jumped in to TRAMP development. ;-)
And yes, I'm well-aware that TRAMP has been a mostly one-man show
since around 1997 (maybe before); I do try to stay on top of who's
doing what in packages that are not maintained in XEmacs core. I know
very well how much extra work is involved in supporting both GNU Emacs
and XEmacsen, even though I don't have time to contribute much to them
directly.

Post by Stephen J. Turnbull
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

Maybe. I have always been told that XEmacs 21.4 matters.

It does in the sense that packages must not crash just because you're
running 21.4, but it's end-of-life, and new features can just signal:
`(error 'unimplemented "<feature> not supported in [XEmacs [21.4]]...")'.

Post by Stephen J. Turnbull
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.

Sure.

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

Sounds good to me!

Steve