XEmacs at a crossroads

[Stephen J. Turnbull]

To all XEmacs supporters and users:

For the past decade, work on XEmacs has continued at a low level, and
mostly not visible in user-level features. In the meantime, GNU Emacs
has implemented almost all XEmacs features, and recently RMS has given
the green light to some form of dynamic loading of machine code. At
the same time, a number of features (jit-lock and lexical binding seem
important) that XEmacs lacks, and would require substantial effort to
port, have been implemented.

After some discussion on the XEmacs-Review mailing list, we decided to
open up a public discussion of the future of the XEmacs Project.
Please direct followups to the XEmacs Beta mailing list
(xemacs-***@xemacs.org). Reply-To is set for your convenience.

The present situation of the core developers who have responded is
that the developers who have been the primary contributors of code
currently have personal and professional commitments that prevent them
from devoting enough time to XEmacs to implement the large features
necessary for full compatibility with GNU Emacs for the foreseeable
future. Those who have mostly contributed work on infrastructure
generally don't have the skills or time to convert to heavy code
contributors. The bottom line is that we can not at present promise
full GNU Emacs compatibility in the foreseeable future.

If you would prefer to use an editor with the most recent features,
three core developers have ported personal configurations to GNU Emacs
with little difficulty, and say they expect no loss of functionality
in using GNU Emacs. For current XEmacs users, converting to GNU Emacs
would offer access to a few popular packages not publicly available
for XEmacs. I can mention nxhtml, org-mode[1] and magit[2] offhand.

I think all the core developers expect many users to stick with
XEmacs. Steve Youngs writes: "Everyone who either uses, or hacks on,
XEmacs does so for a reason, and we do so by choice. There are
probably as many reasons as there are XE users/devs, all I ask is that
you don't take away the choice." I think all the core developers feel
the same way. The reason this is coming up now is that several
developers who have contributed heavily in the past have acknowledged
that they *won't* be doing so for the foreseeable future. It's only
fair that we let you, our users and supporters, know about that.

We all do value XEmacs, its history, the codebase, and you, our
community. We are sad that XEmacs has fallen so far out of
competition with GNU Emacs, but it's time to admit that is the case,
and think about what we want to do now. Several alternative paths
have been suggested:

1. Close up shop and release the resources to other projects.
2. Close up shop and move en masse to GNU Emacs development.
3. Fork current GNU Emacs, and gradually recreate an XEmacs-
flavored GNU-Emacs-compatible language and editor.
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.

There is no consensus on closing up or on what to do if we did, and
therefore options 1 and 2 are off the table. (Individual developers
will (and should) do as they want, of course.) Option 3 has its
attractions[3], but no commitment from developers with a history of
substantial contributions of code. That leaves option 4, or maybe a
new "option 5" if somebody has a good suggestion.

For those who wish to continue using or developing XEmacs, we have
commitments from at least two of the infrastructure contributors to
provide minimal support for

- mailing lists
- tracker
- website
- source code repositories
- package buildbot
- binary packages

While binary package releases will continue to be provided in
"Pre-Releases", there are no plans yet for a full SUMO release. It's
quite possible, but there are some resource details (space on the
distribution site) to work out.

We would like to hear your thoughts. If you have private patches you
can contribute to XEmacs 21.5, please let us know about them. They
can be integrated. XEmacs 21.4 is very near end-of-life, but Vin
Shelton is still maintaining it.

We thank you for your support and contributions over the years!

With sincere regards from the XEmacs team,

Steve
XEmacs Beta Release Manager, for the XEmacs Reviewers


Footnotes:
[1] A couple of developers have private ports of org-mode, which may
be made available in the future.

[2] magit uses lexical binding, and so is likely to be difficult to
port to XEmacs.

[3] As well as the potential to upset a lot of people in the GNU
Emacs community.

[Uwe Brauer]

Post by Stephen J. Turnbull
For the past decade, work on XEmacs has continued at a low level, and
mostly not visible in user-level features.

Dear Stephen and all the other core developers,

First of all I want to thank you, the core developers, especially Aidan, Mats
and, before he left, Steve Youngs for all their contributions in general
and for their personal contributions to my problems in particular.

You Stephen (T) played an important role in keeping the project alive
(and maybe Xemacs would have reached that crossroad much earlier) in the
last decade. Your willingness to answer all but the silliest question,
your kindness (where others sometimes were blunt) helped a lot. Also you
were a sole voice in GNU emacs dev. Thank you!

I have been using Xemacs since 1992 and it is sad that it has come to
this point.

Post by Stephen J. Turnbull
In the meantime, GNU Emacs has implemented almost all XEmacs
features,

Right: take my favourite example x-symbol, which was released around
1997. It took GNU Emacs almost 20 years to implement a similar
functionality (pretty-symbol-mode), which is a bit uglier but may be
more efficient implemented, since it uses overlays.

Post by Stephen J. Turnbull
and recently RMS has given the green light to some form
of dynamic loading of machine code. At the same time, a number of
features (jit-lock and lexical binding seem important) that XEmacs
lacks, and would require substantial effort to port, have been
implemented.
for XEmacs. I can mention nxhtml, org-mode[1] and magit[2] offhand.

I think it is also fair to add, that even the packages which are *not*
incompatible with Xemacs, such as gnus and especially auctex, provide
*less* features in Xemacs than they do in GNU emacs.

Post by Stephen J. Turnbull
We are sad that XEmacs has fallen so far out of competition with
GNU Emacs, but it's time to admit that is the case, and think about
what we want to do now.

Sadly true.[1]

Post by Stephen J. Turnbull
Several alternative paths
1. Close up shop and release the resources to other projects.
2. Close up shop and move en masse to GNU Emacs development.
3. Fork current GNU Emacs, and gradually recreate an XEmacs-
flavored GNU-Emacs-compatible language and editor.
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.
Option 3 has its attractions[3], but no commitment from developers
with a history of substantial contributions of code.

Well I think it made much sense 20 years ago to fork GNU Emacs, since it
lacked X support. But today, in my opinion, it would look as a «cheap»
robbery. And wasn't the «data-abtraction» concept one core conflict? So
that would be given up?

Since switching to GNU emacs a couple of weeks ago, I am asking myself
what makes Xemacs different from GNU Emacs (besides lisp syntax
differences, and some UTF8 coding issues)? Well for me the menus/widgets
GNU Emacs provides are still very ugly compared to Xemacs. Could those
be ported to GNU emacs? What do others think what is the main difference
in functionality between both, what would you do differently?

Post by Stephen J. Turnbull
That leaves option 4, or maybe a
While binary package releases will continue to be provided in
"Pre-Releases", there are no plans yet for a full SUMO release. It's

I am still willing to maintain the auctex package, but I ask: why can't
it be moved to the official release? For the average user to dig out
actualized packages from the pre--release directory is cumbersome at
least.


Regards

Uwe Brauer

Footnotes:
[1] Although it might be a fascinating question for software
historians. How could a technical superior software lose so
much of its advantages?
Was it that GNU Emacs was easier to program, was its documentation
better?
Was it that the some core Xemacs developer considered Xemacs 21.4
already as mature?
Was it that some of the core developers forked
21.4 for their one projects?
For me one turning point was when Ben Wing left.

[Stephen J. Turnbull]

Post by Uwe Brauer
Well I think it made much sense 20 years ago to fork GNU Emacs, since it
lacked X support. But today, in my opinion, it would look as a «cheap»
robbery.

I agree that's the way it would look in the Emacs community, and I
think that's sad. I was attracted to "free" software because it was
about sharing. But then I met Richard (virtually) and discovered that
the Free Software Movement was not about writing and sharing code, but
rather about preventing "hoarders" from using "our" code. This is
very different from open source projects (eg, Python), where people
are very pragmatic about alternative implementations, including
commercial and closed-source implementations. Sure, there's friction
about "contributing back", and about who should take responsibility
for bugs in "relabeled" commercial implementations. But basically
forking is the order of the day. In fact, that's what Github calls a
personal branch: a fork.

Post by Uwe Brauer
And wasn't the «data-abtraction» concept one core conflict? So
that would be given up?

Not entirely, but more than I'm comfortable with. Emacs has become
more friendly to abstraction, but nowhere near as much so as XEmacs.
Richard is still reactionary on the subject (he still believes data
abstraction is antithetic to "hackability"), and the feeling in Emacs
that

[Some XEmacs] code was not the best match to the bell curve of
available intelligence for application programmers, with too
low-level concepts bleeding through to the API. XEmacs has more
opaque data types than Emacs, but I found the isolation of
low-level _concepts_ sometimes less than convincing. -- David
Kastrup, personal communication

remains strong, I think. I don't recall any of the Emacs-oriented
package maintainers (Michael Albinus, David himself, the JDEE guys,
yet another Michael who maintained ediff, ...) pining after XEmacs
core concepts. David himself encountered them mostly because of
preview-latex, I think. Otherwise, I don't think they "bleed through"
very much ... but there was that reputation.

Post by Uwe Brauer
Since switching to GNU emacs a couple of weeks ago, I am asking
myself what makes Xemacs different from GNU Emacs (besides lisp
syntax differences, and some UTF8 coding issues)? Well for me the
menus/widgets GNU Emacs provides are still very ugly compared to
Xemacs. Could those be ported to GNU emacs?

I don't know, but I doubt it would be straightforward graphics
programming. XEmacs by default uses a collection of widgets developed
by the Lucid people, while Emacs uses the platform widgets, although I
think the Lucid framework is still in there. XEmacs generally
implemented wrapper APIs as needed at the C level, whereas GNU tends
to hook directly into the platform features. Eg, their Windows/DOS
code is far more divergent from that for POSIX platforms than our is.
It might be possible to "theme" the GTK widgets more attractively,
though.

Post by Uwe Brauer
I am still willing to maintain the auctex package, but I ask: why can't
it be moved to the official release?

I'm not sure. Norbert has mentioned space issues on Tux. I'm going
to look into that. But that doesn't explain why they can't be mv'ed.
I hope that Norbert himself will talk about it briefly.

Post by Uwe Brauer
[1] Although it might be a fascinating question for software
historians. How could a technical superior software lose so
much of its advantages?

The main issue was personal history on the part of developers. One
developer spent a couple of years editing the Scheme standard.
Several developers graduated from school and got jobs. One went to
medical school. A couple have actually passed away. Ben was always
loosely attached to XEmacs; he would work in spurts. I think his
activity was often driven by consulting work, but he never limited
himself to just one task and was always willing to help others (in his
own way). It wasn't easy to recruit Emacs developers at all in the
5-year period 2000-2005. It was a point of dissension between Stefan
and myself (he claimed we had more developers than GNU Emacs did).

Post by Uwe Brauer
Was it that GNU Emacs was easier to program, was its
documentation better?

I think the main attraction of GNU Emacs is that it is a GNU project.
It has always been considered the mainline, except for a couple of
years in the early 90s when Richard was ignoring it in favor of free
software activism and Lucid Emacs was obviously leading development.

I don't think GNU was ever easier to program -- our C API was easier
to adapt to new platforms, and our Lisp more modern with many Common
Lisp features anabled by default. At that time our documentation was
better for programmers (remember, Lucid contributed a complete rewrite
of the manuals, and we had about 50% coverage of the design in the
Internals manual, which GNU still doesn't have, although a lot of
related material is in their Lisp reference), with the exception of
the material on specifiers, which as David Kastrup insisted was way
too technical and too little "tutorial" material.

Post by Uwe Brauer
Was it that the some core Xemacs developer considered Xemacs 21.4
already as mature?

Steve Baur and Martin Buchholz did, but they didn't try to hold the
rest of us back, and did contribute to the discussion.

Post by Uwe Brauer
Was it that some of the core developers forked
21.4 for their one projects?

Python and Linux have a lot more forks than Emacs does. Forking is a
sign of health, not of weakness.

Post by Uwe Brauer
For me one turning point was when Ben Wing left.

Ben didn't "leave" in the sense of turning his back on XEmacs. The
loss of Kyle Jones, Hrvoje Niksic, Martin Buchholz and Steve Youngs
were bigger in that sense, but you know what? Pretty much as soon as
Steve started SXEmacs, he returned to a friendly relationship with
XEmacs core, and there have been a number of contributions back and
forth (more large ones from the SXEmacs side since the fork, but of
course they got to start from XEmacs, and one of our big contributions
to them is a commitment to support SXEmacs in packages. I guess it
balances out -- you'd have to ask Steve or other SXEmacs'ers but we've
gotten along well ever since, so that's my impression).

[Uwe Brauer]

Hi Guys. Mi comments below.
On Tue, 01 Dec 2015 21:36:36 -0500,
GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw scroll bars) of
2015-04-21 on wari
That is the Lucid version.

Aha, I did not know about it. I will try out. Does it looks closer to
Xemacs this way?

Uwe Brauer

[Uwe Brauer]

Hi Andrés

Hi Uwe.
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--libexecdir=/usr/lib \
--localstatedir=/var \
--with-x-toolkit=lucid \
--mandir=/usr/share/man \
--pdfdir=/usr/share/doc/emacs/pdf \
--with-sound \
--without-gconf \
--with-xft
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs-lucid-git

That is odd as you can see from my screenshot the scrollbar is completely
black and therefore almost useless.


I will try to run
--with-x-toolkit=lucid
--without-gconf
--with-xft although I think the xft is per default.

Maybe my xaw3dg is too old?

Or to you have a setting for the scrollbar?
Thanks

Uwe

[Uwe Brauer]

Post by Uwe Brauer
Regards
ps: just for the record on my setup menu-bar, toolbar, scrollbar are
disabled. On the screenshot I started emacs with "-Q"

emacs -q (scrollbar black)
emacs -Q (scrollbar grey-white)

So there is some bizarre system-init file somewhere which screws up the
scrollbar. Any idea where?

Uwe

[Andrés Ramírez]

Hi Uwe

Post by Uwe Brauer
So there is some bizarre system-init file somewhere which screws up the
scrollbar. Any idea where?

For discarding This, run a kubuntu live usb (boot from it). And install
the emacs-lucid package there. See how it behaves. If problem is gone it is a
setting on your actual environment. If problem persist. It would be something
with the configure script.

Have You looked this page:
http://www.emacswiki.org/emacs/ScrollBar

Regards

[Uwe Brauer]

Hi Uwe. My comments below.
extra/libxaw 1.0.13-1 [installed]
X11 Athena Widget library

Ok mine is
1.0.7-1 which is a bit older.

Nothing special for the scrollbar
Btw, I have noticed in your screenshot even the toolbar is grayed. Are
You using a theme on your destop environment?.

Well I am using TDE, trinity a KDE3 fork (Kubuntu)

Or perhaps smth on
"~/.Xdefaults"?

Yes I have .Xdefaults setting, but the same for Xemacs as for GNU emacs,
but only the GNU emacs scrollbar is black, here are my settings:

XEmacs.foreground: black
XEmacs.background: grey99
XEmacs.font: -*-courier-bold-r-*-*-18-180-*-*-*-*-*-*
XEmacs.geometry: 95x43+20+5

Emacs.foreground: black
Emacs.background: grey98
Emacs.font: -*-courier-bold-r-*-*-18-180-*-*-*-*-*-*
Emacs.geometry:105x63+20+5

Regards
ps: just for the record on my setup menu-bar, toolbar, scrollbar are
disabled. On the screenshot I started emacs with "-Q"

Aha, when I do this for emacs, indeed the scrollbar is «normal» grey.
Now I am puzzled, what could that be?

BTW while with the option lucid, the menus/widget are very Xemacs like,
that menus itself, that is the font of them are not they are the same
small font-difficult-to-read entries as always.

[Steve Youngs]

Post by Stephen J. Turnbull

Post by Uwe Brauer
For me one turning point was when Ben Wing left.

Ben didn't "leave" in the sense of turning his back on XEmacs. The
loss of Kyle Jones, Hrvoje Niksic, Martin Buchholz and Steve Youngs
were bigger in that sense, but you know what? Pretty much as soon as
Steve started SXEmacs, he returned to a friendly relationship with
XEmacs core, and there have been a number of contributions back and
forth (more large ones from the SXEmacs side since the fork, but of
course they got to start from XEmacs, and one of our big contributions
to them is a commitment to support SXEmacs in packages. I guess it
balances out -- you'd have to ask Steve or other SXEmacs'ers but we've
gotten along well ever since, so that's my impression).

Yep, we get on great. And I don't recall ever hearing anything from my
people that would suggest otherwise.

[Stephen J. Turnbull]

I have always thought why Lucid-x-toolkit is never updated?

Well, Lucid basically was out of business 20 years ago. The version
we have in XEmacs has been maintained and upgraded over the years (eg,
to add tabs, progress bars, and generic "native" widgets), and I am
sure it has diverged substantially from the version GNU Emacs uses. I
don't know how much they've improved their version but I know they
haven't added the additional widget support we have.

How the Lucid-x-toolkit got on GNU/Emacs?

I don't know; maybe the record is in their repo history. The rest of
Lucid Emacs was FSF-assigned, but curiously enough, this is the only
part of Lucid Emacs that was not assigned to the FSF (it was used in
other parts of the Lucid Energize suite, so they wouldn't let it go, I
guess). Even more curiously, RMS let it in; I don't know who owns
those copyrights now. (Maybe Richard Gabriel? yes, Richard "Worse Is
Better" Gabriel.)

Why there is no a 'prelude' (dot emacs distribution) equivalent or
something like that, just for downloading Xemacs, another tarball and
enjoy the full Xemacs experience quickly? (even downloading
automatically some mule-packages from the web)

In 2000, the logic was, Windows, MSFT is no help and you gotta buy a
compiler, OK, we'll provide an installer. Otherwise, all the distros
have it in their packages. It doesn't get quicker than that. After
that, we lost manpower and become ever more dependent on the distros
though we still

ps: that Lucid toolkit is a great piece of sw. It is still relevant
on 2015. And is going to be as long as the gtk bug is not closed
(not going to be closed on the near future)

Hard to believe it's 25 years old, isn't it? The only problem I have
with Lucid is that it's full of Lisp idioms ... but it's not part of
Emacs Lisp, it's a whole extra layer of API.

[Andrés Ramírez]

Hi Stephen. Mi comments below.

Post by Stephen J. Turnbull
In 2000, the logic was, Windows, MSFT is no help and you gotta buy a
compiler, OK, we'll provide an installer. Otherwise, all the distros
have it in their packages. It doesn't get quicker than that. After
that, we lost manpower and become ever more dependent on the distros
though we still

Mmm, Another just five years before behaviour in GNU/Emacs:
--8<---------------cut here---------------start------------->8---
The GNU/Emacs users share their dot emacs setup, so everybody who uses
the same packages on their workflow can benefit from it.
--8<---------------cut here---------------end--------------->8---

I have my setup migrated to support Xemacs 21.5 too (supports emacs-23.4
with package.el and superior versions also). I can share it. But
better would be to share it on a blog post, based on
org-mode. Right?.

What version of org-mode have been backported?

On this org-mode web page says it supports Xemacs 22.1. :)
at the beginning of this page:
http://orgmode.org/worg/org-tutorials/org4beginners.html

--8<---------------cut here---------------start------------->8---
Org-mode, as it says on the official web page is for keeping notes,
maintaining ToDo lists, doing project planning, and authoring with a
fast and effective plain-text system. Beginning with Emacs 22.2 and
XEmacs 22.1 it has been part of Emacs. The following is a simple
tutorial to help you get started using Emacs and org-mode.
--8<---------------cut here---------------end--------------->8---

Post by Stephen J. Turnbull
Hard to believe it's 25 years old, isn't it? The only problem I have
with Lucid is that it's full of Lisp idioms ... but it's not part of
Emacs Lisp, it's a whole extra layer of API.

You are Right. That is awesome. But as You are describing it. It have
been develop on the C layer, perhaps Richard Gabriel should have open
sourced it. And We would have another multi-platform x-toolkit besides
(gtk, Qt, etc).

Regards

[Raymond Toy]

Stephen> We all do value XEmacs, its history, the codebase, and you, our
Stephen> community. We are sad that XEmacs has fallen so far out of
Stephen> competition with GNU Emacs, but it's time to admit that is the case,
Stephen> and think about what we want to do now. Several alternative paths
Stephen> have been suggested:

I never thought of it being a competition (at least not for many, many
years).

Stephen> 1. Close up shop and release the resources to other projects.

What does that really mean, since XEmacs is open source?

Stephen> 2. Close up shop and move en masse to GNU Emacs development.
Stephen> 3. Fork current GNU Emacs, and gradually recreate an XEmacs-
Stephen> flavored GNU-Emacs-compatible language and editor.
Stephen> 4. Maintain infrastructure as a "caretaker" project, for the
Stephen> benefit of continuing users, and in case somebody wants to
Stephen> pick up the ball.

[snip]

Stephen> We would like to hear your thoughts. If you have private patches you
Stephen> can contribute to XEmacs 21.5, please let us know about them. They
Stephen> can be integrated. XEmacs 21.4 is very near end-of-life, but Vin
Stephen> Shelton is still maintaining it.

Stephen> We thank you for your support and contributions over the years!

And thank you and all of the contributors over the many years!

As a user from the original Lucid Emacs days, this is a rather sad
day. I have never switched to Emacs because there was never a reason
to. XEmacs always did everything I needed to do (fairly limited).

I blame myself for this state of affairs for not contributing
more. But like all of you, other things get in the way.

I don't have any suggestions on the way forward, but [3] seems like
not such a good idea.

Best wishes to all of you and many thanks for your hard work!

--
Ray

[Stephen J. Turnbull]

Post by Raymond Toy
I never thought of it being a competition (at least not for many,
many years).

It's not primarily a race for the gold medal, no.

However, there's another sense of "compete", which is competition for
resources. Mostly, that time spent using and working on anything else
is time not spent on XEmacs. While I've never believed that number of
contributors is a deterministic increasing function of number of
users, it certainly doesn't hurt to have a lot of enthusiastic users.

Richard certainly recognizes that sense of "compete", and so do many
GNU Emacs contributors. Richard has always discouraged GNU Emacs
developers from even looking at XEmacs code (for several reasons, the
most important of which is copyright paranoia), and actively solicited
our contributors and users to work on Emacs because "GNU's work is so
important" (he claims to believe that that would have no impact on
contributions to XEmacs, I'm an economist and know better).

On the other hand, part of what kept me going for years was the belief
that XEmacs was a better editor and closer to the users' needs than
Emacs, and that the XEmacs Project could be more responsive to
industrial users than Emacs was. You could say that that's just a
project with different goals, not a competition, but I always kept an
eye on relative position to Emacs when allocating time. :-) I can't
speak for the other developers in general, but Steve Baur and Ben Wing
definitely were motivated to be "better than Emacs" at least in part.

Post by Raymond Toy
Stephen> 1. Close up shop and release the resources to other projects.
What does that really mean, since XEmacs is open source?

Of course XEmacs source code would continue to exist. AFAIK Bitbucket
has no policy to shut down inactive repos. But the project could shut
down. That is, no infrastructure support for users and would-be
developers. No MLs, no central archives, no binary packages. This
mailing list no longer costs me hours each week, but I'd guess I spend
an hour to two hours a month on moderation and maintenance. I imagine
the same is true for Norbert maintaining packages and Vin for 21.4.

And thre are proactive tasks that need to be done. The Tux
infrastructure is creaking (and so is their administration; the most
active admin there claims he isn't an admin and is more interested in
preventing spam than in delivering mail). We have an alternative host
in mind, but I need to free up some "round tuits" and implement it
(and that task gets more daunting all the time with each newsclip on
yet another exploit of some major site).

Post by Raymond Toy
I don't have any suggestions on the way forward, but [3] seems like
not such a good idea.

Yeah, we know that. But it's the only way we've thought of so far to
get back to feature parity.

Steve

[Raymond Toy]

Stephen> Raymond Toy writes:
Stephen> Richard certainly recognizes that sense of "compete", and so do many
Stephen> GNU Emacs contributors. Richard has always discouraged GNU Emacs
Stephen> developers from even looking at XEmacs code (for several reasons, the
Stephen> most important of which is copyright paranoia), and actively solicited
Stephen> our contributors and users to work on Emacs because "GNU's work is so
Stephen> important" (he claims to believe that that would have no impact on
Stephen> contributions to XEmacs, I'm an economist and know better).

That seems self-evident, even if you're not an economist.

Stephen> 1. Close up shop and release the resources to other projects.

Post by Raymond Toy
What does that really mean, since XEmacs is open source?

Stephen> Of course XEmacs source code would continue to exist. AFAIK Bitbucket
Stephen> has no policy to shut down inactive repos. But the project could shut
Stephen> down. That is, no infrastructure support for users and would-be
Stephen> developers. No MLs, no central archives, no binary packages. This

It would be unfortunate if the mailing list stopped. That doesn't
mean, however, that someone has to continue to handle spam and other
maintenance.

Stephen> And thre are proactive tasks that need to be done. The Tux
Stephen> infrastructure is creaking (and so is their administration; the most
Stephen> active admin there claims he isn't an admin and is more interested in
Stephen> preventing spam than in delivering mail). We have an alternative host
Stephen> in mind, but I need to free up some "round tuits" and implement it
Stephen> (and that task gets more daunting all the time with each newsclip on
Stephen> yet another exploit of some major site).

Post by Raymond Toy
I don't have any suggestions on the way forward, but [3] seems like
not such a good idea.

Stephen> Yeah, we know that. But it's the only way we've thought of so far to
Stephen> get back to feature parity.

Does anyone see this as a viable alternative? XEmacs would be Emacs
until someone puts in all of the XEmacs bits back in. That seems like
a fair bit of work. And then what? Won't XEmacs be in the same boat
as it is now, except that it's much closer to Emacs than it is now?

--
Ray

[Stephen J. Turnbull]

Post by Raymond Toy
It would be unfortunate if the mailing list stopped. That doesn't
mean, however, that someone has to continue to handle spam and
other maintenance.

Unfortunately, it does. There are moral (and possibly legal) risks to
running an unmonitored archived list (X- headers, keywords, and HTML
comments are known vectors for communicating stolen credit card
numbers and the like). Somebody has to monitor the postmaster
address. Somebody has to pay for the domain registration. Etc, etc.

In any case, it's not going to stop soon.

Post by Raymond Toy
Does anyone see this as a viable alternative? XEmacs would be
Emacs until someone puts in all of the XEmacs bits back in.

Oh, it's definitely technically viable. People fork Emacs all the
time, on GitHub etc. I think some XEmacs features would be added, or
replace the GNU equivalents, very quickly. For example adding native
widgets to lwlib. It wouldn't be the XEmacs we know and love today,
but it wouldn't be "Emacs", either. It doesn't have to be *all* of
XEmacs.

The question would be social viability. We can't know until we try
it. I admit the risks are great, the probability of much success not
so high.

Post by Raymond Toy
And then what? Won't XEmacs be in the same boat as it is now,

That really depends on a lot of things. Some of us won't work on
Emacs, but would contribute at least occasionally to XEmacs if it
continues to exist, for political or personal reasons. Such
contributions would be more frequent if we were closer to the bleeding
edge, I am quite sure. Whether we would attract new blood or not
depends on political factors, mostly. Some things that GNU won't do
soon for political reasons, we can do, like proper support for the Mac
and Qt in the main distribution, and close interfacing with LLVM for
refactoring support. All of those have attracted attention from many
people on emacs-devel, although they might not be willing to devote
time to working on them if XEmacs were the only way.

Post by Raymond Toy
except that it's much closer to Emacs than it is now?

"Much" closer changes the equation in a qualitative way. Technically,
XEmacs becomes an attractive (or at least "acceptable") platform for
experimentation again.

Regards,
Steve

[Uwe Brauer]

Post by Stephen J. Turnbull
Unfortunately, it does. There are moral (and possibly legal) risks to
running an unmonitored archived list (X- headers, keywords, and HTML
comments are known vectors for communicating stolen credit card
numbers and the like). Somebody has to monitor the postmaster
address. Somebody has to pay for the domain registration. Etc, etc.
In any case, it's not going to stop soon.
Oh, it's definitely technically viable. People fork Emacs all the
time, on GitHub etc. I think some XEmacs features would be added, or
replace the GNU equivalents, very quickly. For example adding native
widgets to lwlib. It wouldn't be the XEmacs we know and love today,
but it wouldn't be "Emacs", either. It doesn't have to be *all* of
XEmacs.
The question would be social viability. We can't know until we try
it. I admit the risks are great, the probability of much success not
so high.
That really depends on a lot of things. Some of us won't work on
Emacs, but would contribute at least occasionally to XEmacs if it
continues to exist, for political or personal reasons. Such
contributions would be more frequent if we were closer to the bleeding
edge, I am quite sure. Whether we would attract new blood or not
depends on political factors, mostly. Some things that GNU won't do
soon for political reasons, we can do, like proper support for the Mac
and Qt in the main distribution, and close interfacing with LLVM for
refactoring support. All of those have attracted attention from many
people on emacs-devel, although they might not be willing to devote
time to working on them if XEmacs were the only way.
"Much" closer changes the equation in a qualitative way. Technically,
XEmacs becomes an attractive (or at least "acceptable") platform for
experimentation again.

As I said in an earlier mail, forking GNU emacs, made a lot of sense 20
years ago because of two reasons.

- en RMS was not very keen to add X-support to GNU emacs or had
simply not enough time.

- But also from another point the situation was very different. The
starting code base was small and the list of the enthusiastic
hackers were large. Heck I remember when I had to switch around
1997/98 for some month to GNU emacs because our Sun workstation
could not deal with, I think was either Xemacs 19.16 or 20.2. GNU
emacs was smaller, compiled faster and needed much less RAM. Today
it is the other way around, the factor is around 3. It took me 3
times as much CPU to compile GNU than Xemacs, the resulting deb
pkg was around 3 times larger, and it needs 75 Mega of RAM
compared to 25 of Xemacs.

That means today we have a huge code base and very little enthusiastic
hackers. I don't think that is a path to success. Take for example BIDI,
it is great that GNU emacs has it, but it is quite complicated so what
if we take the code and then find a bug, who is going to fix it?[1]



Footnotes:
[1] which brings me to a bit off topic. From time to time I read D.
Knuth article about literate programming (basically you write more
documentation than code) which he claims made LaTeX much easier
to port to all sort of platforms. However I have never seen that
style used in any free/open software project I know, but maybe for
the forking purpose it would be very very useful.

[Didier Verna]

Some things that GNU won't do soon for political reasons, we can do,
like proper support for the Mac

What do you mean exactly ? One of the most important reasons I
switched to Emacs was because it had (has) a pretty good native Cocoa
version. Just configure --with-ns and you're done.

[Raymond Toy]

Post by Raymond Toy
except that it's much closer to Emacs than it is now?

Stephen> "Much" closer changes the equation in a qualitative way. Technically,
Stephen> XEmacs becomes an attractive (or at least "acceptable") platform for
Stephen> experimentation again.

This certainly appeals to me.

I've had to stop upgrading slime because too many emacisms have
slipped in that don't work on xemacs. I can live without lots of
packages, but I really need (well, want) GNUS, slime, C-mode,
javascript mode, git.el, and VC to work.

I did try switching to emacs a while ago, just to see. There were too
many differences between the two[1] that I just gave up because xemacs
just works.


Footnotes:
[1] Don't remember exactly what, but my existing (messy) .xemacs
directory didn't move over very cleanly.

--
Ray

[Didier Verna]

Post by Raymond Toy

Post by Raymond Toy
I don't have any suggestions on the way forward, but [3] seems
like not such a good idea.

Stephen> Yeah, we know that. But it's the only way we've thought
Stephen> of so far to get back to feature parity.
Does anyone see this as a viable alternative? XEmacs would be Emacs
until someone puts in all of the XEmacs bits back in. That seems like
a fair bit of work. And then what? Won't XEmacs be in the same boat
as it is now, except that it's much closer to Emacs than it is now?

In fact, I don't think it's such a bad idea at all and it would
certainly tickle my motivation again (to some extent). First, a fork
of Emacs is just a branch on github these days. I've actually done so
already for a couple of features that I wanted, which would likely not
be accepted as is (and weren't). Many other people have done this as
well already. Next, keeping up to date with Emacs is much simpler that
way, since it would boil down to merges (of course it's more
complicated than that, but I mean at least, the underlying RCS
infrastructure make the process much simpler).

Then of course, there's the (original) question of what you actually
want to do in the XEmacs "branch". As I said before, I don't miss any
end-user-level, practical, features. It's actually quite the
opposite. I do miss our level of data abstraction and some APIs. If we
manage to provide alternate APIs (say, extents) and make them co-exist
with the original ones, that's cool. Data abstraction is more
problematic (particularly if we turn things into opaque types) because
their current way of exposing every abstraction's family jewels to the
wild (boy, the number of things that are actually just lists!) makes
it likely, or at least easy for external packages to access every
single feature in every possible dirty way. We would likely break a
lot of code.

Let me just add one more thing: being an Emacs branch could also be an
incentive for them to actually incorporate things back from us, as
long as it boils down to merging (or accepting pull requests for that
matter).

[Henry S. Thompson]

Post by Stephen J. Turnbull
...
After some discussion on the XEmacs-Review mailing list, we decided to
open up a public discussion of the future of the XEmacs Project.
...
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.

I'm a small cog in this enterprise, but (like many others, I suspect) I
have a particular investment that I care about, namely keeping XEmacs
running under Windows, and, latterly, that has meant taking on getting
it running on 64-bit _as_ 64-bit, both via Cygwin and natively.

I suspect I'm a poster-child for precisely some of the problems you
identified in your post: I've largely succeeded (Cygwin and Mingw 32-
and 64-bit builds work now), and I've had a lot of help from people with
much deeper knowledge of XEmacs internals without which I wouldn't have
gotten this far. So far so good, but we haven't released a 64-bit
buildable set of sources, much less binaries, because I have _not_ been
able to get a fully native build (i.e. one using some
currently-available free version of Visual Studio) to work (32- or 64-
bit).

The problems I've encountered are in an area (failure to re-map the
dumped image) that are way beyond my ability to understand, but the
expert eyes that are needed to locate the problem are, I suspect, no
longer available. Note this is _not_ a complaint about that, just a
statement of fact.

Net-net: I'm willing to support option 4 by taking on responsibility for
maintaining Windows builds as best I can, but the bar will have to be
lower than in the past. That is, support for nmake/Visual-Studio builds
will be withdrawn (it hasn't worked for years in any case without a
10-year-old version of VS, which is no longer available), so the only
way that a native build can made will be with 32- or 64-bit mingw32-gcc.

ht

[Michael Sperber]

Post by Henry S. Thompson
The problems I've encountered are in an area (failure to re-map the
dumped image) that are way beyond my ability to understand, but the
expert eyes that are needed to locate the problem are, I suspect, no
longer available. Note this is _not_ a complaint about that, just a
statement of fact.

I know Marcus made the portable dumper work under Windows. He's still
around. So if you provide a bit more information on what the problem is,
maybe there's a way to resolve it.

[Stephen J. Turnbull]

Post by Michael Sperber

Post by Henry S. Thompson
The problems I've encountered are in an area (failure to re-map the
dumped image) that are way beyond my ability to understand, but the
expert eyes that are needed to locate the problem are, I suspect, no
longer available. Note this is _not_ a complaint about that, just a
statement of fact.

I know Marcus made the portable dumper work under Windows. He's still
around. So if you provide a bit more information on what the problem is,
maybe there's a way to resolve it.

It might be a "security feature" (address randomization comes to mind)
that needs to be disabled, eg, with a compiler or linker option.

[Marcus Crestani]

SJT> It might be a "security feature" (address randomization comes to mind)
SJT> that needs to be disabled, eg, with a compiler or linker option.

That would be my tip as well. Can you try building with ASLR disabled?

Here is how to disable ASLR in Visual Studio 2015:

https://msdn.microsoft.com/en-us/library/bb384887.aspx

[Henry S. Thompson]

Post by Marcus Crestani
SJT> It might be a "security feature" (address randomization comes to mind)
SJT> that needs to be disabled, eg, with a compiler or linker option.
That would be my tip as well. Can you try building with ASLR disabled?
https://msdn.microsoft.com/en-us/library/bb384887.aspx

Great, thank you! That moves me on a step, definitely. More details
later in the week, I hope.

ht

[Henry S. Thompson]

Great, thank you! [disabling ASLR] moves me on a step, definitely.
More details later in the week, I hope.

I can now compile and run an x86_64 xemacs using Visual Studio 2015.

_But_, there are over 2192 warnings (1880 _distinct_) about possible
data loss stemming from differences in size. Most of these arise from
the disconnect between the sizes of int, long, and EMACS_INT/VOID_P/and
friends:

int long EMACS_INT
Cygwin/gcc 64-bit: 4 8 8
Windows/VS2015 64-bit: 4 4 8

It seems . . . unlikely that _all_ of these warnings are harmless, so
short of slowly working through all of the cases I don't see that it's
plausible to make a release described as fully 64-bit-compatible.

Sigh.

Not sure about mingw, i.e. what ? is in a further row to the above
table:

Windows/x86_64-w64-mingw32-gcc 4 ? 8

Anybody besides me care about this?

ht

[Henry S. Thompson]

Post by Henry S. Thompson
It seems . . . unlikely that _all_ of these warnings are harmless, so
short of slowly working through all of the cases I don't see that it's
plausible to make a release described as fully 64-bit-compatible.

It’s not *that* unlikely, XEmacs is pretty 64-bit-clean. Grepping through
the source, the big thing I can see is Hashcode being long; does that
improve things much? Could you post your error log somewhere?

Will do.

Post by Henry S. Thompson
Anybody besides me care about this?

I use XEmacs on an Win64 machine regularly and am frustrated that the only
recent binary is not recent at all, if that helps.

Yes, it does -- doubles the size of my client base :-).

ht

[Henry S. Thompson]

Post by Henry S. Thompson
I can now compile and run an x86_64 xemacs using Visual Studio 2015.
...
It seems . . . unlikely that _all_ of [the warnings I get] are harmless, so
short of slowly working through all of the cases I don't see that it's
plausible to make a release described as fully 64-bit-compatible.

It’s not *that* unlikely, XEmacs is pretty 64-bit-clean. Grepping through
the source, the big thing I can see is Hashcode being long; does that
improve things much?

I'll see.

Could you post your error log somewhere?

Now available at

http://www.ltg.ed.ac.uk/~ht/nmake.log

Thanks in advance for any suggestions,

ht

[Stephen J. Turnbull]

Post by Henry S. Thompson
I can now compile and run an x86_64 xemacs using Visual Studio
2015.

Good news!

Post by Henry S. Thompson
Not sure about mingw,

Does mingw work at all? AFAIK there has never been any work done do
ensure that MinGW can be used to compile XEmacs, and I know that Emacs
doesn't build and run under VC, so VC and MinGW are actually quite
different environments.

[Mats Lidell]

Hi Henry,

Post by Henry S. Thompson
I can now compile and run an x86_64 xemacs using Visual Studio 2015.

Really good news. Good work fighting this.

Unfortunately I must tell you that I had to remove both 2013 and 2015 version
of the free version of visual studio from my windows development machine. So I
apologize for not being able to help you on this at the moment.

This decision to delete the visual studio tools was mostly triggered by that I
needed more disc for new virtual machines in the day job. However it would be
unfair not to come clean and admit that to some extent the "at the
crossroad"-discussion has resulted in that I have been exploring GNU Emacs
more.

So after moving to GNU Emacs on Linux a few weeks ago, to try out how hard it
would be and how it would feel, I also tried a Windows port (mingw32) of GNU
Emacs. My first impression on that exercise is that it seems OK. If that is
true or not and if there are dark corners somewhere I don't know. The thing
that was new to me was the fact that this thing even existed.

Yours Mats

[Henry S. Thompson]

Post by Michael Sperber

Post by Henry S. Thompson
The problems I've encountered are in an area (failure to re-map the
dumped image) that are way beyond my ability to understand, but the
expert eyes that are needed to locate the problem are, I suspect, no
longer available. Note this is _not_ a complaint about that, just a
statement of fact.

I know Marcus made the portable dumper work under Windows. He's still
around. So if you provide a bit more information on what the problem is,
maybe there's a way to resolve it.

Here's my summary [1] of the state of play:

I think the attached now builds cleanly all the way through to dumping
xemacs.exe and then trying to use it, which fails (see below).

...

The xemacs crash is reported as follows by VS2015

Unhandled exception at 0x00BCB1AC in xemacs.exe: 0xC0000005: Access
violation writing location 0x00EAE6A4.

The VS2015 backtrace is

xemacs.exe!pdump_load_finish() Line 2350 C++
xemacs.exe!pdump_load(const wchar_t * argv0) Line 2793 C++
xemacs.exe!xemacs_21_5_b34_i586_pc_win32(int argc, wchar_t * * argv, wchar_t * * unused_envp, int restart) Line 1408 C++
xemacs.exe!main(int argc, char * * argv, char * * unused_envp) Line 3204 C++

For "the attached" see the original posting:

[1] http://permalink.gmane.org/gmane.emacs.xemacs.beta/39286

[Steve Youngs]

[This turned into quite a lengthy post, I'm really sorry, and I hope you
don't mind]

On behalf of everyone who has ever been involved with SXEmacs, both past
and present, I would like to thank each and every one of you guys for
everything you've ever done for XEmacs. We (SXEmacs), quite literally,
would not exist if it weren't for you, so thank you, thank you very very
much!
[...]

Post by Stephen J. Turnbull
We all do value XEmacs, its history, the codebase, and you, our
community. We are sad that XEmacs has fallen so far out of
competition with GNU Emacs, but it's time to admit that is the case,
and think about what we want to do now. Several alternative paths
1. Close up shop and release the resources to other projects.
2. Close up shop and move en masse to GNU Emacs development.
3. Fork current GNU Emacs, and gradually recreate an XEmacs-
flavored GNU-Emacs-compatible language and editor.
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.

We (SXEmacs) have no plans of stopping or wrapping things up, regardless
of what the XEmacs team ultimately decides to do. I guess what I'm
saying is that if you enjoy hacking/using XEmacs but don't really want
to move to GNU, an option may be to come and talk to us. :-)

Some of you may be thinking: "SXEmacs? Didn't that die ages ago?" Well,
no, we're still very much alive. We just sometimes move at a different
pace to the rest of the world. :-) Yes, often that pace is slower, a lot
slower, but often it is also a lot faster than the world too. It all
depends on how excited, or how much fun we're having.

Some reasons why SXEmacs might be a good choice...

1) Copyright. Assigning away your copyright is NOT a requirement to
contributing to SXEmacs. We would never ask you to do that. You
can, if you want to, but I'll never ask, nor require it, of you.

2) We're not politically motivated. In fact, I do my best to keep
that sort of stuff right away from the project. Yes, I realise
that some things are political and you just can't keep away from
it, but they're never the reason we do what we do. On the flip
side, politics don't stop us from doing what we do, either. (don't
read too much into this, for the life of the SXEmacs project "the
politics" has never really ever come up, pretty much a total
non-issue)

3) Git. SXEmacs sources, and website, are managed with git. A few
may see that as a negative, but my guess is that you'd be in the
minority. Besides, it could've been a hell of a lot worse... I may
never have come to my senses about leaving tla behind. :-P

4) We forked from 21.4, so our roots are from a stable code base (oh,
I'm sure that 21.5 is quite stable too, I'm going on how things
were when we started, and that 21.4 is still advertised as the
"stable branch" on www.xemacs.org). Yes, that does mean that there
are 21.5 things that aren't in SXEmacs, but that just gives you the
opportunity to add them if you really need them, and perhaps even
make them better. It should be noted also that there is a lot in
SXEmacs which isn't in 21.5 (more on that in a bit).

5) I'm not RMS. Regardless of who is currently wearing the maintainer
hat over at GNU/Emacs, if RMS doesn't want something going into
Emacs, it won't go in. Convincing RMS to change his mind is not
the easiest thing in the world to do. Hmm, has that _ever_
actually happened, somebody got him to change his mind? Convincing
me that your code should get into SXEmacs is very often fairly
straight forward. Especially if you understand it well enough to
explain it to a dumbo like me. :-)

6) As I hinted at in #5, I am nowhere near as smart as the amazing
folk who are SXEmacs developers. That means that I never dismiss
your ideas because I think I know more than you, because I rarely
do. What it does mean is that often I ask a lot of questions, some
of them really basic and even stupid. And you know what? That has
many times lead to better design decisions and implementations.

7) We do it because we want to. Because we enjoy it.

Post by Stephen J. Turnbull
or maybe a new "option 5" if somebody has a good suggestion.

*wink* Hello! :-)

The cool and sexy. Here's that list of some of the things that we have
and love in SXEmacs that you guys don't have. Yes, I'm trying to whet
your appetite. :-)

1) FFI. It was one of the first major new features we introduced,
over a decade ago, and it has been a fantastic blessing ever since.

Because of FFI a virgin SXEmacs install can use the PUI tools
without having to pre-install the xemacs-base and EFS packages.

Because of FFI I do pretty much all of my photo and image editing
(and viewing) in SXEmacs. Got some red-eye in those holiday snaps?
SXEmacs can fix that.

Because of FFI I can read and manage the meta data in my music
collection.

Because of FFI I don't need to leave SXEmacs if I want to download
something from the net, and I'm not restricted to FTP. I can even
do it asynchronously.

FFI means never having to say "sorry, we can't do that" :-)

2) Raw strings. Actually I think you guys may have this one in 21.5.
Including it because I'm not 100% sure if you do. But goodbye
backslashitis. :-)

3) Embeddable keyboard macros. We heard you like macros, bro, so we
put macros in your macros.

4) Loads of crypto goodness with OpenSSL support (and gcrypt via FFI).

5) ENT (Enhanced Number Types). It's what you guys call "bignum",
except we go way beyond bignums, bigfloats, and ratios. Using GMP,
MPFR, MPC and a couple of others I think, we also have
multi-precision floats and complex numbers with correct rounding,
gaussian numbers, residue class rings, quaternions. And don't you
dare ask me about these because I haven't the foggiest, I can't
even pronounce half of them, let alone tell you what they are
for. :-) Suffice to say that SXEmacs can do the math.

6) TTY font-lock. SXEmacs on a tty looks damn nice! Up to 256
colours if the device supports it.

7) Network server sockets #'open-network-server-stream

8) CL in DSO. We have some of the CL stuff (mainly the loop macros)
in an emodule (DSO), and oh man, is it FAST!!! The elisp versions
are still available. We'd love to move a lot more of the CL stuff
out into DSOs.

Damn, this email is going on forever. So sorry about that. And so much
more to tell you. Erm, OK... bloom filters, skip lists, double linked
lists, cached compiled regexps, PulseAudio, Jack, ALSA, ao, SoX, FFmpeg
(broken), sndfile, Mad. And probably loads more that I can't think of
right now.

Oh, yeah, we spent a great deal of time and effort auditing the code
with the aid of the Coverity defect scan (see scan.coverity.com).

As you can see, we didn't sit around and do nothing, and there is loads
of cool stuff to play with. Come and say "hey" on Freenode IRC channel
"#sxemacs", you'll find me there as "SteveYoungs". Or you can contact
me privately, or on our dev list, sxemacs-***@sxemacs.org (it's
subscriber post only to keep spam at bay)

Post by Stephen J. Turnbull
For those who wish to continue using or developing XEmacs, we have
commitments from at least two of the infrastructure contributors to
provide minimal support for
- mailing lists
- tracker
- website
- source code repositories
- package buildbot
- binary packages
While binary package releases will continue to be provided in
"Pre-Releases", there are no plans yet for a full SUMO release. It's
quite possible, but there are some resource details (space on the
distribution site) to work out.

I know you have it under control currently, but if you ever need help
with these, drop me a line. I'd be happy to provide hosting resources
for much of these if needed.

[Marcus Harnisch]

Hi Steve

The situation you describe is no news to anyone involved in the XEmacs
project. The project has been in this very state for many years now
with small bursts of activity. Nothing more can be expected from
contributors putting their spare time into a project. Thank you all
for this.

Post by Stephen J. Turnbull
1. Close up shop and release the resources to other projects.

Which resources?

Post by Stephen J. Turnbull
2. Close up shop and move en masse to GNU Emacs development.

Probably not. Those who considered that as an option left a long time
ago.

Post by Stephen J. Turnbull
3. Fork current GNU Emacs, and gradually recreate an XEmacs-
flavored GNU-Emacs-compatible language and editor.

Unrealistic, IMHO. The core features that differentiate XEmacs are
fundamental and developers would presumably have a lot of work ahead
of them recreating these in a fork.

Post by Stephen J. Turnbull
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.

That'd be my personal preference. Basically just leave it the way it
is. Shout if you need help for keeping life-support going or to tell
us all to fork the repo in case it is taken down.

Perhaps someday a prince will come and kiss Sleeping Beauty.

Cheers
Marcus

[Stephen J. Turnbull]

Thanks for the suggestions, but I've already been through most of
these, and for most there are technical reasons for not doing them (I
could explain if you want). Some of your ideas are more directed at
improving the project than at reducing maintenance cost and I'd like
to highlight those.

- even move over to use pull requests at bitbucket?

Pull requests are worth discussing, since that would represent a
modernization of our workflows, and might make it easier to contribute.

- Drop the buildbots. With no or few commits coming it is not
worth the time and resources spent maintaining them.

Up to you, that's work you've been doing. But I regularly see
buildbot posts for the packages.

- Replace the old web pages with a simple static website on
bitbucket.

For practical purposes that's what we already have.

This will remove in one stroke a lot of info that is aged and
wrong. Just supply the very necessary information possibly by
lifting over the valuable pages from the old web.

The effort is in choosing "valuable". It would be just as easy to
create an "unmaintained and likely inaccurate hierarchy" on the current
site and move unreliable pages into that. (I propose "HereBeDragons"
for the name of the top directory of that hierarchy. ;-)

- Stop providing binary packages. They can be built from
source. The storage problem is removed and with no activity
there will hardly be any releases after all.

Storage is a one-off; I don't think it's difficult to fix. The bigger
issues are domain-maintenance things like DNS, which I really need to
get off of Tux. Sandy W. is still handling the registrar stuff.

BTW, there is hardly "no activity" in packages. In fact people are
committing to packages quite regularly.

- Don't know what to do with the tracker. It could be moved into
the bitbucket issue tracker but I fear that will be much work
and we will loose info. Maybe if can be dumped in some format
for reference and new issues handled at bitbucket.

The tracker is actually zero-maintenance, and I use it. I could check
the access log if you like.

[Mats Lidell]

Some of your ideas are more directed at improving the project than at
reducing maintenance cost and I'd like to highlight those.

Yes, maybe we can improve and rationalize at the same time as we remove
unnecessary tasks and free resources . Let's see ;-)

[ About xemacs-patches ]

Pull requests are worth discussing, since that would represent a
modernization of our workflows, and might make it easier to contribute.

I haven't really checked bitbucket but I'd would think that pull requests
would be a possibility for the contributor to choose. If you would like to
contribute and get the commit inspected before pushing you could do a pull
request. So it would zero cost for us at the moment.

For developers who would like to push directly that would still be possible
and IMHO the preferred way for this size of a project.

So it is more like an answer to anyone missing xemacs-patches - How do I get
my patch inspected: Answer: Do a pull request.

[ About the buildbot services ]

Up to you, that's work you've been doing. But I regularly see
buildbot posts for the packages.

Remember we are at the crossroad. Looking into the mirror and extrapolate that
into the future isn't IMO the right thing when the core developers, you and I
included, more or less unanimously said there is no time for doing anything in
the foreseeable future.

What I'm also asking is our opinion on if this service is really worth
maintaining. If we drop it we would at least theoretically free resources to
do other stuff. [1][2]

[ About the web xemacs.org ]

The effort is in choosing "valuable". It would be just as easy to
create an "unmaintained and likely inaccurate hierarchy" on the current
site [...]

There will be one service less to maintain since everything will be hosted on
bitbucket. It will also be easier if things would take of again since the fork
from bitbucket will have all without thinking about xemacs.org at all.

Storage is a one-off; I don't think it's difficult to fix.

This is what the at the crossroad is all about I think. The storage problem
has been there for what, a year, two years? Is it important? Yes. Have we
fixed it? No. So let's remove the problem because it will not be easier in the
future.

The bigger issues are domain-maintenance things like DNS, which I really
need to get off of Tux. Sandy W. is still handling the registrar stuff.

Well I don't understand the problem probably because I just run my own home
server. I bought the domain address a few years ago, configured the DNS in the
providers control panel and then I have payed the bills for the name. That is
it. What more do we need?

BTW, there is hardly "no activity" in packages. In fact people are
committing to packages quite regularly.

See at the crossroad argument above.

The tracker is actually zero-maintenance, and I use it. I could check
the access log if you like.

No that is not necessary. I feel that there is valuable info in the tracker
for anyone who would like to hack on XEmacs so it would be terrible to loose
that info. How often that is accessed now is not important.

So if you don't feel you loose hours that could be spent better it will be a
valuable service to keep I think.

Yours Mats

Footnotes:
[1] Well, this argument to free resources to put into work
elsewhere is I guess applicable to all of this discussion.

[2] I checked the package smoke test just now and realized that it has been
hanging since the end of October. It sort of tells you the state of affairs
right. I haven't noticed. No one has complained. I need to spend a few hours
(maybe) getting it up and running again.

[Mats Lidell]

[Resending because I by mistake sent to the announce list which of course
bounced so you did not see it . Sorry for that. For completeness here is
another go at it.]

Hi Stephen,

That leaves option 4, or maybe a new "option 5" if somebody has a good
suggestion.

[...]

For those who wish to continue using or developing XEmacs, we have
commitments from at least two of the infrastructure contributors to
provide minimal support for
- mailing lists
- tracker
- website
- source code repositories
- package buildbot
- binary packages
While binary package releases will continue to be provided in
"Pre-Releases", there are no plans yet for a full SUMO release. It's
quite possible, but there are some resource details (space on the
distribution site) to work out.

To me the minimal support lists as given above sounds quite a bit as business
as usual for us. So I suggest an option 5 where we change the infrastructure
to be more in level with our activities.

That could mean:

- Protect the mailing lists from spam by just allowing posts from
members. This ought to reduce the maintenance needs I hope.

- Drop mailing lists we don't use much. Could xemacs-patches go into
xemacs-beta or even move over to use pull requests at bitbucket?

- Drop the buildbots. With no or few commits coming it is not worth the time
and resources spent maintaining them.

- Replace the old web pages with a simple static website on bitbucket. This
will remove in one stroke a lot of info that is aged and wrong. Just
supply the very necessary information possibly by lifting over the
valuable pages from the old web.

- Stop providing binary packages. They can be built from source. The storage
problem is removed and with no activity there will hardly be any releases
after all.

- Don't know what to do with the tracker. It could be moved into the
bitbucket issue tracker but I fear that will be much work and we will
loose info. Maybe if can be dumped in some format for reference and new
issues handled at bitbucket.


Disclaimer: If you feel that continuing your effort in some of these field is
what you want then that is of course fine.

Yours

[David Kastrup]

Post by Stephen J. Turnbull
Several alternative paths
1. Close up shop and release the resources to other projects.
2. Close up shop and move en masse to GNU Emacs development.
3. Fork current GNU Emacs, and gradually recreate an XEmacs-
flavored GNU-Emacs-compatible language and editor.
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.
There is no consensus on closing up or on what to do if we did, and
therefore options 1 and 2 are off the table. (Individual developers
will (and should) do as they want, of course.) Option 3 has its
attractions[3], but no commitment from developers with a history of
substantial contributions of code.

[...]

Post by Stephen J. Turnbull
[3] As well as the potential to upset a lot of people in the GNU
Emacs community.

with regard to footnote 3: I doubt it. A concerted replacement of current
XEmacs (regarding distributions, this may mean either 21.5 or even 21.4)
with a current fork of Emacs would result in a sigh of relief from many,
many Emacs developers trying to maintain XEmacs compatibility.

Of course, the sigh of relief would not last as the new XEmacs fork would
likely start trailing behind, at least once merges became non-trivial.

Emacs these days can be extended in packages, and at least the MELPA package
archive does not require copyright assignments from its contributors.

People with strong enough programming-foo to want to hack the core of their
editor and with strong enough no-thanks-Richard-foo to not want to assign
copyright of their work to FSF or see their contributions managed by FSF and
more likely the Emacs developer community will continue to work with either
current XEmacs or such an Emacs fork.

I am pretty certain that this set remains non-empty. But at the current
point of time, I don't see that it is large enough to carry the weight for a
project of Emacs' size.

Free Software is something that gets carried forward by a mixture of
pragmatic and of idealistic developers. The current Emacs development has
changed in categories where either would have considered Emacs less
attractive previously. The course of the current maintainer John Wigley is
still developing, but he comes from a more pragmatic background and has met
RMS in person before agreeing to the role.

So I think there is reason for careful optimism that most of the concerns
that resulted in the fork of Lucid Emacs and the continued upkeep of XEmacs
have abated to a level where it is likely the sanest choice to work with or
on Emacs (possibly on external non-assigned packages) and think about a
fresh fork should enough people start considering the situation untenable again.

I am pretty sure that a fresh fork would aggravate package maintainers much
less (at least initially) than the current XEmacs/Emacs fork does.