11:15 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:37 a.m.
New subject: XEmacs at a crossroads
Raymond Toy writes:
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.
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).
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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:38 p.m.
New subject: XEmacs at a crossroads
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
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.
>
> 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).
> 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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:34 p.m.
New subject: XEmacs at a crossroads
Raymond Toy writes:
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.
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.
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.
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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:30 p.m.
New subject: XEmacs at a crossroads
Raymond Toy writes:
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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:40 p.m.
New subject: XEmacs at a crossroads
Stephen J. Turnbull wrote:
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.
--
＠-quartet live: Sunset/Sunside, Paris, Jan 26 2016 !
Book now: http://www.sunset-sunside.com/2016/1/artiste/2101/3453/
Lisp, Jazz, Aïkido: http://www.didierverna.info
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:43 p.m.
New subject: XEmacs at a crossroads
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> Raymond Toy writes:
> 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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:32 p.m.
New subject: XEmacs at a crossroads
Raymond Toy <toy.raymond(a)gmail.com> wrote:
>> 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).
--
＠-quartet live: Sunset/Sunside, Paris, Jan 26 2016 !
Book now: http://www.sunset-sunside.com/2016/1/artiste/2101/3453/
Lisp, Jazz, Aïkido: http://www.didierverna.info
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3436
days inactive
3442
days old
7 comments
4 participants
participants (4)
-
Didier Verna -
Raymond Toy -
Stephen J. Turnbull -
Uwe Brauer