Are GNU- and XEmacs hoplessly forked?
Grimnir
of interest to me. I started using XEmacs when I saw a screen shot in
Rosen, Rosinski and Faber. The GUI was what I found attractive. Now I
barely use the tool bar, and I'm trying to learn all the key cords to do
things. I haven't used GNU Emacs much, so I really don't know how the two
compare. It seems to me that (X)Emacs is somewhat neglected by developers
these days. Everybody has moved on to using all the cool things which were
originally coded using (X)Emacs.
I have the feeling there are certain aspects of (X)Emacs which set them
apart and above the other editors available. Ease of use is NOT one of
these features. I believe the motivation behind XEmacs was right minded.
There is a great deal which could be improved WRT user friendliness. I can
honestly say I have spent hours trying to figure out how to accomplish
things which take a few clicks of a mouse in other editors.
With the small number of programmers actually working on (X)Emacs these
days, it doesn't make a lot of sense (to me) to have two very similar yet
distinct projects. As I have read on www.xemacs.org, part of the reason
for the fork is due to some less than pedantic attributing of authorship on
the part of the XEmacs coders. There also seem to be some strong wills and
opinions involved as well.
I'd like to pose these questions:
* Are GNU Emacs and XEmacs hopelessly forked?
* What would it take to merge them?
* Is a merge desirable?
I really don't want to start a flame war. This is not a troll, it is a
serious inquiry.
Regards,
Steven
Simon Josefsson
> * Are GNU Emacs and XEmacs hopelessly forked?
> * What would it take to merge them?
> * Is a merge desirable?
Merging Emacs and XEmacs now seems pointless, but two things seems
worth doing to me:
* Synching elisp code between the two emacsen. This probably means
more to users than various C level differences.
* Get Guile Emacs to work, and then migrate all Elisp from both XEmacs
and Emacs to Guile. In the long run, this would benefit many other
projects as well.
Rodney Sparapani
> Merging Emacs and XEmacs now seems pointless, but two things seems
> worth doing to me:
>
> * Synching elisp code between the two emacsen. This probably means
> more to users than various C level differences.
>
> * Get Guile Emacs to work, and then migrate all Elisp from both XEmacs
> and Emacs to Guile. In the long run, this would benefit many other
> projects as well.
I think Simon is right on. This would make all of the developers (which
there are a large number of, contrary to the first post) very happy and
would improve the quality of elisp code. Not having to worry about
whether the code is running on GNU Emacs or XEmacs would be a huge
headache removed. And, if we are going to get anywhere, we have to
get the users to upgrade too. Beyond the GNU Emacs/XEmacs duality,
supporting different versions of emacs is just as big of a problem.
Maybe
we should start with the distributors of code. Our Solaris 8 came with
XEmacs 20.0 last year. No offense to the XEmacs Development Team,
but that release has some particularly annoying problems. So, we need
to get Sun to wake up and to get XEmacs 21.4.x on there.
--
Rodney Sparapani Medical College of Wisconsin
Sr. Biostatistician Patient Care & Outcomes Research (PCOR)
rspa...@mcw.edu http://www.mcw.edu/pcor
Was 'Name That Tune' rigged? WWLD -- What Would Lombardi Do
Florian Lindner
> and Emacs to Guile. In the long run, this would benefit many other
> projects as well.
What's Gulie Emacs?
Florian
Simon Josefsson
Guile is GNU's script language, not very different from Emacs Lisp,
only cleaner and better. It has threads for one thing. :-) Try
googling for it.
One main problem is that there doesn't seem to be much non-ascii
non-unicode support.
Steven T. Hatton
Let's see if I understand here. Are you proposing YAE(Yet Another Emacs)?
I'm not wholy dismissive of the idea. The obvious concern I have regaurding
such a proposition is the potential for it to become YAFE. It seems there
whould need to be a considerable amount of buy in from both existing camps
in order for this to become a convergance rather than another fork.
I cannot comment on the desierability of porting the existing Emacs to
Guile. I know little about lisp and less about guile.
If recoding the whole thing would lead to a rethinking of how the features,
command and options are presented to the user I'd be all for it. As it
stands, I suspect most truly skilled (X)Emacsers learned by having a more
experienced person teach them. Perhaps I simply have the wrong kind of
personality to learn to use a tool such as this, but I find it very
difficult to get a handle on.
Steven
Stephen J. Turnbull
Simon> Grimnir <hat...@bellatlantic.net> writes:
>> * Are GNU Emacs and XEmacs hopelessly forked?
Yes.
>> * What would it take to merge them?
An epiphany on the part of the Sun legal department or Richard
Stallman, followed by lots and lots of work.
If Sun were to assign its copyrights to the FSF, there still would be
a lot of work involved in tracking down which code is still not
assigned. I think most of the individuals could eventually be
persuaded to assign, but it will take a long time. The remainder
would have to be removed. On the FSF side, the public reason for
refusing to merge, or even use any XEmacs code at all, is that lack of
assignment may make it impossible to enforce the copyright, and you
could imagine that case law or other factors might make that seem less
essential. But I believe that the FSF has a number of other strong
reasons, in support of their long-term strategy to rid the world of
non-free software, to insist on assignments. Don't hold your breath.
Besides the legal work of verifying copyright, which the FSF would
insist on, there would be substantial organizational change involved.
AFAICT, although nominally retired from Emacs management, Richard
still holds a "golden share" in GNU Emacs, and nothing can be done if
he firmly opposes it. XEmacs, on the other hand, gives individual
developers a much freer hand to create their own versions of XEmacs,
with a view to merger to mainline, sooner or later. XEmacs developers
are not expected to subordinate their project to the needs of a
movement. Reconciling these styles may be impossible in practice.
Finally, there's the actual code. There are very difficult technical
issues dividing the two implementations. It would take years of work
to unify the implementations.
>> * Is a merge desirable?
Yes, at least of the projects. Just as commercial developers provide
different versions of their products targeted to different audiences,
open source projects could too.
It would be really cool if Emacs and XEmacs gurus could hang out on
the same mailing lists and newsgroups without feeling uncomfortable,
as we sometimes do. Eli Zaretskii, as heated as the arguments we get
into are, can't keep himself from answering XEmacs FAQs when he knows
the answer, as I participate in the same way on the comp.emacs
newsgroup. For most purposes, there really is only one Emacs from the
point of view of users, although the defaults and some of the features
vary, giving rather different "look and feel" to the two
implementations. It would be nice if the channels reflected this.
It would also be really cool to have common code in the same
repository so that synching would be unnecessary. It would be really
cool to know in detail what the other team is up to on projects of
common interest, even if we disagree about implementation.
Consider, there are at least five major publically available variants
of XEmacs right now (mainline XEmacs in several versions, Infodock,
UTF-2000 XEmacs from m17n.org, Ben Wing's "new Mule" branch, and the
Tuebingen GC branch mentioned below). Three of them coexist happily
in the XEmacs repository. Ben's branch is in process of merger to the
mainline, the Tuebingen branch is eventually intended for merger, but
that's way off. A fifth (GTK XEmacs) was merged to the mainline last
year. But UTF-2000 XEmacs is unlikely to ever be merged, although we
may borrow some of its features. It is kept in a separate repository
for the convenience of its maintainer, but there's no reason in
principle why it couldn't be in the main repository at cvs.xemacs.org.
Infodock was kept separate for commercial reasons; I'm afraid it's now
moribund, but the code is available as a SourceForge project.
This can be chaotic, and creates some management problems. I am
convinced it also allows XEmacs to be more responsive to the needs of
XEmacs users than having a single line of public releases. Given that
in practice there are going to be two Emacsen for the foreseeable
future, it would be nice if we could agree to disagree where
necessary, and cooperate to satisfy developer urges and user needs
where convenient or urgent.
There is no technical reason why it couldn't work for XEmacs and GNU
Emacs, but for both legal and organizational reasons I doubt that GNU
would be happy with it. Certainly there is a long history of attempts
to merge from the XEmacs side, met with stringent conditions from the
GNU side.
Simon> Merging Emacs and XEmacs now seems pointless, but two
Simon> things seems worth doing to me:
I don't think it's pointless. Just impossible.
Simon> * Synching elisp code between the two emacsen. This
Simon> probably means more to users than various C level
Simon> differences.
I agree, this is very important. Unfortunately, in practice the GNU
Emacs team refuses to cooperate on synchronization.
In some cases cooperation is philosphically impossible. Eg, Richard
Stallman refused to participate in a project to make various remote
file access protocols, eg, EFS, ange-ftp, and TRAMP, work and play
well together. In his opinion it promoted the use of SSH, then not
available in a free implementation, to an unacceptable degree.[1]
Members of the GNU Emacs team do work individually on synching, third
parties contribute a fair amount, and the XEmacs team does make
regular efforts to synchronize Lisp APIs with GNU. But GNU is
unwilling to promise to devote resources to it, and never consults
with XEmacs about API changes, etc, so it's a very reactive process,
reacting to GNU Emacs initiatives.
Simon> * Get Guile Emacs to work, and then migrate all Elisp from
Simon> both XEmacs and Emacs to Guile. In the long run, this
Simon> would benefit many other projects as well.
It might, but Guile has zero support on the XEmacs team AFAIK. The
Schemers manage not to mention it on their "feasible implementations"
page, and the Common Lispers consider it to be, well, a Scheme
variant. :-) See
http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-generation/
for a summary. Ben Wing (and Jamie Zawinski, who though retired from
XEmacs is a very smart guy with very public opinions) oppose spending
effort on the Lisp engine at all, although they support an improved
GC. See
http://www.xemacs.org/Architecting-XEmacs/lisp-engine.html
(_Architecting XEmacs_ is a generally good resource for exploring
ideas for improving XEmacs, and implicitly GNU Emacs as well.)
There are experiments being made, I believe with RScheme, to implement
a subset of Emacs Lisp on top of a Scheme engine. As horrible as it
sounds, the initial test results are that this is hardly less
efficient than the "native" Emacs Lisp engines used in the Emacsen.
This result might apply to Guile as well, but I don't know any
results. In any case, Lisps are quite good at supporting each other's
features in Lisp code. So it's not clear that you even need to port
much Elisp.
As for Guile's advantages and disadvantages, I think it basically
comes down to cleaner code, better support as more people get involved
in maintenance, and (presumably) better garbage collection, which is
always the Achilles heel of C code in Emacsen. The threading is quite
irrelevent AFAICT, as redisplay is not thread-safe. I don't think
that the lack of support for Mule code is technically a problem. I'm
hoping that XEmacs will move to Unicode internal representation,
possibly in the release after next. Support for external
representations is something that we know a lot about, and (at least
for XEmacs) the current code should be easily portable to a different
Lisp implementation. The only real problem to worry about is Han
unification.
The bottom line, sadly, is that for the foreseeable future cooperation
between GNU Emacs and XEmacs will be based almost entirely on the
independent efforts of individual developers, and XEmacs's desire to
stay reasonably in synch with GNU Emacs APIs and UIs.
Footnotes:
[1] He may have changed his mind or clarified the policy recently.
But that's the way it was then.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
Eli Zaretskii
>
> GNU [...] never consults with XEmacs about API changes, etc,
The lack of discussions about future development trends is mutual.
Friedrich Domincus
>
> I don't think it's pointless. Just impossible.
Impossible? Well I don't buy that. Just nobody feels it's urgent
enought to spend time with it.
>
> Simon> * Synching elisp code between the two emacsen. This
> Simon> probably means more to users than various C level
> Simon> differences.
>
> I agree, this is very important. Unfortunately, in practice the GNU
> Emacs team refuses to cooperate on synchronization.
Well I do not know what problems have occured porting software. I've
taken a bunch of Emacs Lisp from Emacs and it simply runs under
XEmacs. There may be package where this does not work. But I don't
have encountered it till now.
>
> In some cases cooperation is philosphically impossible. Eg, Richard
> Stallman refused to participate in a project to make various remote
> file access protocols, eg, EFS, ange-ftp, and TRAMP, work and play
> well together. In his opinion it promoted the use of SSH, then not
> available in a free implementation, to an unacceptable degree.[1]
Well things change and it now works. I've installed TRAMP and it
worked with OpenSSH. I think Richards view on software is well known
and therefor his decisions are quite easy to forsee.
>
> Members of the GNU Emacs team do work individually on synching, third
> parties contribute a fair amount, and the XEmacs team does make
> regular efforts to synchronize Lisp APIs with GNU. But GNU is
> unwilling to promise to devote resources to it, and never consults
> with XEmacs about API changes, etc, so it's a very reactive process,
> reacting to GNU Emacs initiatives.
Well I better should keep my mouth. But I don't see why the XEmaca
guys should not give up on it.
>
> Simon> * Get Guile Emacs to work, and then migrate all Elisp from
> Simon> both XEmacs and Emacs to Guile. In the long run, this
> Simon> would benefit many other projects as well.
>
> It might, but Guile has zero support on the XEmacs team AFAIK. The
> Schemers manage not to mention it on their "feasible implementations"
> page, and the Common Lispers consider it to be, well, a Scheme
> variant. :-) See
>
>
>http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-generation/
Well my opinion to guile is two-faced. I've used it with SCWM and
found it quite ok. But I encountered too Common Lisp and comparing to
it it falls more than short. Well yes now I feel Guile is just
another (incompatible?) Scheme Variant. Fact is that Scheme is less
related to Emacs Lis than is Common Lisp. So in fact I would prefer a
CL-Emacs. (But again nobody seems to feel the urgent need to change
things, so we simply stick to Emacs Lisp)
>
> There are experiments being made, I believe with RScheme, to implement
> a subset of Emacs Lisp on top of a Scheme engine. As horrible as it
> sounds, the initial test results are that this is hardly less
> efficient than the "native" Emacs Lisp engines used in the Emacsen.
Well one may think about some of the features of Lisp, especially
Macros. So embedding languages is
a) "easy"
b) "fast"
some URLS for those who are interested:
http://www.red-bean.com/guile/notes/emacs-lisp.html
http://www.splode.com/~friedman/software/emacs-lisp/
http://gemacs.sourceforge.net/
> This result might apply to Guile as well, but I don't know any
> results. In any case, Lisps are quite good at supporting each other's
> features in Lisp code. So it's not clear that you even need to port
> much Elisp.
Well maybe not porting. But I could imagine that a bunch of Code could
and should? be cleaned up. If one looks over all the packages one will
see that this two datastructures are used
a) Lists
b) Accociated List
Well without extensions Emacs Lisp has no support for Datastructures,
Hash Tables
and/or Objects. A lot of code is still around which was written with
just the two data-structures above. Well it seems not to be a good
choice choosing always those datastructures. IMHO this makes the code
much more difficult to understand. And if you want to extend it it's
really difficult to say where to start. Of course Objects are not
"silver bullets" to change that, but I could imagine that having alls
this extensions in an OO-framework would easy undertakings of
understanding and extending.
>
> As for Guile's advantages and disadvantages, I think it basically
> comes down to cleaner code, better support as more people get involved
> in maintenance, and (presumably) better garbage collection, which is
> always the Achilles heel of C code in Emacsen.
Well why do you think that the support will get better? I doubt that
there are as many Guile programmers than there are e.g Common Lis
programmers. Extensions to Common Lisp have proved there usefullness
even for implementing an OS in it. Well there may be some prototyp for
a Scheme-OS, but it's quite a difference to have "just" a prototype or
having a fully-fledged OS.
> The bottom line, sadly, is that for the foreseeable future cooperation
> between GNU Emacs and XEmacs will be based almost entirely on the
> independent efforts of individual developers, and XEmacs's desire to
> stay reasonably in synch with GNU Emacs APIs and UIs.
Well is it worth it?
Friedrich
Per Abrahamsen
> Let's see if I understand here. Are you proposing YAE(Yet Another Emacs)?
Not really, since Guile is the planned future for Emacs (but not XEmacs).
However, the Lisp community itself has divided into two camps, Scheme
(a minimalistic Lisp which Guile is an implementation of) and Common
Lisp (a maximalistic Lisp). And many Emacs developers are also part
of the Lisp community, and there is at least one developer who have
started a "Common Lisp Emacs" project. So we might just get a
different division of the Emacs community.
Of course, a Scheme[1] vs. Common Lisp division would make a lot more
sense than what we have currently, which is basically just come down
to both RMS and JWZ being alpha males, and some pride and hurt
feelings that keep the division going, even with one of the alphas out
of the picture.
Footnotes:
[1] Ignoring that the leading Scheme advocate on the XEmacs camp
wants a different Scheme implementation than Guile.
Per Abrahamsen
> AFAICT, although nominally retired from Emacs management, Richard
> still holds a "golden share" in GNU Emacs, and nothing can be done if
> he firmly opposes it.
RMS is back as the official maintainer.
Per Abrahamsen
> With the small number of programmers actually working on (X)Emacs these
> days, it doesn't make a lot of sense (to me) to have two very similar yet
> distinct projects.
Not to me, either. I sometimes fear vim has more active developers
than both emacsen, combined. It almost certainly has more users.
In dark moment, I think we should let both projects die, and
contribute some good Emacs emulation to vim instead.
> * Is a merge desirable?
Obviously, yes. The Emacs community have plenty of external
competition (from editors like vim, Visual SlickEdit, and from IDE's
like Visual Studio) to keep us on our toes, so we don't have to divide
resources into creating internal competition.
The time where Emacs was head and shoulders ahead of everything is
long past.
> * What would it take to merge them?
There is some merging going on, both on packages maintained by third
parties, and an active Emacs to XEmacs merge of relevant parts of the
code. There is also a small amount of XEmacs to Emacs merging.
To merge the projects, one of the projects would have to die. I guess
if that happened, half the developers from the dead project would
start contributing to the surviver (at first the features the missed
from the dead editor), and the other half would find other things to
do, often by contributing to other free software projects.
I sincerely believe that the death of either project would be a huge
win for Emacs users (who would get a better editor), third party
developers (who would get a single API with more users), free software
(new developers plus a better Emacs as a developing tool), and text
editors in general (who would once again have Emacs to look for
inspiration).
> * Are GNU Emacs and XEmacs hopelessly forked?
I can't see RMS backing down, he is not the type. And XEmacs have
survived four? five? maintainers.
Maybe it has to get a lot worse before it gets better.
Stephen J. Turnbull
Friedrich> I think Richards view on software is well known and
Friedrich> therefor his decisions are quite easy to forsee.
I have not found it so. Many things, yes. Others, no.
Friedrich> But I don't see why the XEmaca guys should not give up
Friedrich> on it.
Because there is a lot of software that we would like to have work on
XEmacs, and the better we can synch to GNU Emacs, the more there will
be.
Friedrich> Well without extensions Emacs Lisp has no support for
Friedrich> Datastructures, Hash Tables and/or Objects.
It's true that the CL extensions available in XEmacs are written in
Emacs Lisp, but they are considered full-fledged parts of XEmacs
Lisp. cl.el is dumped into XEmacs, cl-extras.el autoloaded. XEmacs
has long had hash tables and other specialized types. Generic
objects, no, and no support for inheritence etc, it's true. But a lot
more than just lists and association lists.
In fact, this willingness to use abstract data types is one of the
things that distinguishes XEmacs from Emacs.
Friedrich> Well is it worth it?
I believe so, as I wrote. Others disagree, but the majority feeling
is that at least as long as there are volunteers to do synching, which
there are, we should not cut the ties now.
Stefan Monnier <foo@acm.com>
> I sincerely believe that the death of either project would be a huge
> win for Emacs users (who would get a better editor), third party
> developers (who would get a single API with more users), free software
> (new developers plus a better Emacs as a developing tool), and text
> editors in general (who would once again have Emacs to look for
> inspiration).
(with-sorrow (with-aol-mode (me-too)))
Stefan
Friedrich Domincus
>
> It's true that the CL extensions available in XEmacs are written in
> Emacs Lisp, but they are considered full-fledged parts of XEmacs
> Lisp. cl.el is dumped into XEmacs, cl-extras.el autoloaded. XEmacs
> has long had hash tables and other specialized types. Generic
> objects, no, and no support for inheritence etc, it's true. But a lot
> more than just lists and association lists.
I'm quite aware of the cl-stuff (I used it always) but fact is many of
the package are just written with lists and associaton lists, and all
thos accessor and the like just to hide that one is running on list is
well at list arguable.
>
> In fact, this willingness to use abstract data types is one of the
> things that distinguishes XEmacs from Emacs.
>
> Friedrich> Well is it worth it?
>
> I believe so, as I wrote. Others disagree, but the majority feeling
> is that at least as long as there are volunteers to do synching, which
> there are, we should not cut the ties now.
Well freedom of choice. If you think it worth it, it'll be fine for me
too. But I do disagree. I tried to point out why I would not bother
but please mark that's just my opionion.
Regards
Friedrich
David Masterson
> Grimnir <hat...@bellatlantic.net> writes:
>> * Are GNU Emacs and XEmacs hopelessly forked?
>> * What would it take to merge them?
>> * Is a merge desirable?
> Merging Emacs and XEmacs now seems pointless, but two things seems
> worth doing to me:
> * Synching elisp code between the two emacsen. This probably means
> more to users than various C level differences.
The best way of achieving that (IMHO) would be a standard "packaging"
tool. The reason being would be that *MOST* of the Elisp could be put
into packages that are maintained independently of (X)Emacs (hopefully
by the original author of the package). The XEmacs packaging system
is getting there, but it could use:
* Reverse installation -- this would be to allow anyone to generate a
development area where they could work on the package.
* Source storage -- because of the above, the source (Makefiles, etc.)
would need to be stored in the installation tree.
* Package building tools -- these may be available, but I haven't
looked at them yet, so I don't know what state they're in.
A few things I want to look into (if someone else doesn't) once I get
my home system more stable.
> * Get Guile Emacs to work, and then migrate all Elisp from both XEmacs
> and Emacs to Guile. In the long run, this would benefit many other
> projects as well.
Sounds like the *VERY* long run.
--
David Masterson dmaster AT synopsys DOT com
Sr. R&D Engineer Synopsys, Inc.
Software Engineering Sunnyvale, CA
Friedrich Domincus
> Grimnir <hat...@bellatlantic.net> writes:
>
> > With the small number of programmers actually working on (X)Emacs these
> > days, it doesn't make a lot of sense (to me) to have two very similar yet
> > distinct projects.
>
> Not to me, either. I sometimes fear vim has more active developers
> than both emacsen, combined. It almost certainly has more users.
>
> In dark moment, I think we should let both projects die, and
> contribute some good Emacs emulation to vim instead.
Well I do not think about that in dark moments. Anyway I do think both
Emacses show well bit-rot is the wrong word, but there ancient base.
>
> > * Is a merge desirable?
>
> Obviously, yes.
Definitly not. Freedom of choice have brought us XEmacs, why should I
give up on anything from it.
> The Emacs community have plenty of external
> competition (from editors like vim, Visual SlickEdit, and from IDE's
> like Visual Studio) to keep us on our toes, so we don't have to divide
> resources into creating internal competition.
>
> The time where Emacs was head and shoulders ahead of everything is
> long past.
This is definitly not true. Emacs can handle all sort of texte
conveniently and it's much mor than just an editor. It's a whole
Personal Information manage, not just an editor. And it's
extensible. which one can not say about Visual Studio. (well not quite
true any longer) but it feels much more closed.
But all the other editors can't do all what Emacs can. I can read and
write mails, news. I can do programming in it not just for one or two
or even ten languages but at least a few dozens.
Anyway as pointed out before it seem to be the right time for
reorganize the code. But that's quite a bunch of work IMHO.
>
> To merge the projects, one of the projects would have to die.
Which one?
> I sincerely believe that the death of either project would be a huge
> win for Emacs users (who would get a better editor), third party
> developers (who would get a single API with more users), free software
> (new developers plus a better Emacs as a developing tool), and text
> editors in general (who would once again have Emacs to look for
> inspiration).
I have no idea why you think so. What would it buy just having on
Emacs?
>
> > * Are GNU Emacs and XEmacs hopelessly forked?
>
> I can't see RMS backing down, he is not the type. And XEmacs have
> survived four? five? maintainers.
Well I do not know how getting a maintainer works or how this guys can
do what they do, because as I understand they all are volunteers. I
know that there was a time when Infodock was activly sold (I was quite
happy about it and bough a copy for quite a bunch of money, but I
encountered later (as I got more proficient in (X)Emacs that)
integrating other package was not straigt forward and switched back to
"simple" (X)Emacs. Some of the old packages are out there, but I think
not many are using them...
>
> Maybe it has to get a lot worse before it gets better.
What's so worse about the Emacses. They work.
Regard
Friedrich
Stefan Monnier <foo@acm.com>
> Which one?
Doesn't matter. Whichever it is, the other project will quickly get
the missing features added, simply because the users of the corpse
will port the code from the corpse to the project that's still alive.
> I have no idea why you think so. What would it buy just having on
> Emacs?
For one, it would double the number of active core developers.
Also it would save time for the various elisp hackers who could concentrate
on actual hacking rather than on dealing with the various differences
between Emacs and XEmacs.
Stefan
Per Abrahamsen
> Definitly not. Freedom of choice have brought us XEmacs, why should I
> give up on anything from it.
XEmacs has cost me the freedom to use one good emacs. Instead, I have
the freedom to choose between two mediocre emacsen.
A net loss, in my book.
[ I hate the Linux wanabee mentality that seem to presume that
developer resources are infinite, so the more we divide the
resources, the better the end result. The "competition is good"
mantra is apparently used as a substitute for thinking, at least on
/.. ]
> And it's extensible. which one can not say about Visual
> Studio. (well not quite true any longer) but it feels much more
> closed.
I increasingly often see packages that "plug into" Visual Studio. And
vim already has a truly impressive array of plug-ins.
> But all the other editors can't do all what Emacs can. I can read
> and write mails, news.
Right. I don't want the build in mail and news clients to be the main
selling point of Emacs. I want to to be superior as a text editor.
> I can do programming in it not just for one or two
> or even ten languages but at least a few dozens.
So does vim, and Visual Studio might be near it.
I'm almost certain Emacs still has the lead in number of text formats
supported, which I consider the main selling point, however I suspect
that is only true because of its age. It is likely that vim has the
lead in _new_ text formats being supported.
> Anyway as pointed out before it seem to be the right time for
> reorganize the code. But that's quite a bunch of work IMHO.
There is a constant reorganizing of the code going on, in both
projects. This is how it should be.
>> To merge the projects, one of the projects would have to die.
> Which one?
Either one.
>> I sincerely believe that the death of either project would be a huge
>> win for Emacs users (who would get a better editor), third party
>> developers (who would get a single API with more users), free software
>> (new developers plus a better Emacs as a developing tool), and text
>> editors in general (who would once again have Emacs to look for
>> inspiration).
>
> I have no idea why you think so. What would it buy just having on
> Emacs?
Read the parenthetical remarks. Which one didn't you understood?
> Well I do not know how getting a maintainer works or how this guys can
> do what they do, because as I understand they all are volunteers.
You have to volunteer for the job, and be trusted by the other
developers.
>> Maybe it has to get a lot worse before it gets better.
> What's so worse about the Emacses. They work.
ed works too, and it is the standard editor.
I want more from Emacs than that.
Per Abrahamsen
>> I have no idea why you think so. What would it buy just having on
>> Emacs?
>
> For one, it would double the number of active core developers.
Hardly double, there will be some could not agree with the development
process, or the developers, or even the code-base itself, of the
surviving project. My wild guess would be a 50% increase in core
developers.
Stephen J. Turnbull
David> The XEmacs packaging system is getting there, but it could
David> use:
David> * Reverse installation -- this would be to allow anyone to
David> generate a development area where they could work on the
David> package.
cvs -d :pserver:cvs.xemacs.org:/pack/xemacscvs login (password "cvs")
cvs -d :pserver:cvs.xemacs.org:/pack/xemacscvs checkout $package
There's not much point in trying to work around this, as it's
basically the only way to ensure that your patches apply. Since over
95% of patches do apply now, I and the other reviewers simply return
the other 5% with a request for a patch that will apply. If we don't
get one, someday (maybe) we do something about figuring out how to
make the patch apply.
David> * Source storage -- because of the above, the source
David> (Makefiles, etc.) would need to be stored in the
David> installation tree.
Same as above. There used to be the concept of a "source package".
However, what we found is that because of the nature of Lisp macros,
this tends to result in broken .elcs.
David> * Package building tools -- these may be available, but I
David> haven't looked at them yet, so I don't know what state
David> they're in.
Checkout from the same place as above, module package-control IIRC.
Making a complex package (eg, Gnus or JDEE) is still non-trivial, but
a simple package requires only a very stylized Makefile with a few
variable definitions filled in by the developer. All the build
support is in the Make include files, especially XEmacs.rules.
What the package system currently is missing is a distinction between
build-time and runtime dependencies, and there are some minor design
bugs that are more inelegant than real problems at the present state.
Simon Josefsson
> Grimnir <hat...@bellatlantic.net> writes:
>
>> With the small number of programmers actually working on (X)Emacs these
>> days, it doesn't make a lot of sense (to me) to have two very similar yet
>> distinct projects.
>
> Not to me, either. I sometimes fear vim has more active developers
> than both emacsen, combined. It almost certainly has more users.
>
> In dark moment, I think we should let both projects die, and
> contribute some good Emacs emulation to vim instead.
Maybe adding Guile support to vim is one idea, and then porting Gnus.
At least vim seem to have good i18n/m17n stuff (unicode based, binary
safe). GVIM (vim-x11) is quite spiffy. Hopefully the license issues
will be resolved soon as well.
(RedHat recently added a alias for "vi" to "vim", and it even has font
locking for elisp code on by default. We are still waiting for Emacs
to do this..)
Simon Josefsson
>> Merging Emacs and XEmacs now seems pointless, but two things seems
>> worth doing to me:
>
>> * Synching elisp code between the two emacsen. This probably means
>> more to users than various C level differences.
>
> The best way of achieving that (IMHO) would be a standard "packaging"
> tool. The reason being would be that *MOST* of the Elisp could be put
> into packages that are maintained independently of (X)Emacs (hopefully
> by the original author of the package).
Yup. The XEmacs package stuff has done alot to improve the lisp
situation. I wish someone would port the XEmacs package stuff to
Emacs, and get RedHat and Debian or similar to include it (RMS doesn't
seem interested), then the XEmacs package stuff could be The
repository for elisp code. I see no reason it couldn't contain Emacs
specific code as well, assuming the package system would handle that.
The XEmacs package stuff doesn't work well with RPM though (and
probably not DEB either).
>> * Get Guile Emacs to work, and then migrate all Elisp from both XEmacs
>> and Emacs to Guile. In the long run, this would benefit many other
>> projects as well.
>
> Sounds like the *VERY* long run.
Yes. But it would "infiltrate" your entire system, if many
applications is extended with Guile. Imagine, you could invoke gnus
from your bash prompt! :-)
Guile need unicode (etc) support, buffers and good GTK (QT?) support
though. Untrivial.
Kyle Jones
> Friedrich Domincus <fr...@q-software-solutions.com> writes:
>
> > Definitly not. Freedom of choice have brought us XEmacs, why should I
> > give up on anything from it.
>
> XEmacs has cost me the freedom to use one good emacs. Instead, I have
> the freedom to choose between two mediocre emacsen.
>
> A net loss, in my book.
>
> [ I hate the Linux wanabee mentality that seem to presume that
> developer resources are infinite, so the more we divide the
> resources, the better the end result. The "competition is good"
> mantra is apparently used as a substitute for thinking, at least on
> /.. ]
Yes, but developer resources aren't necessarily fungible. The
work that I found the energy to do in the XEmacs development
environment might not been available if I had to deal with the
GNU Emacs dev environment. You can't factor out the people
involved. It would be great if we could all just get along,
but we can't. Some people just naturally grate on each other.
To avoid bloodshed, reasonable people who can't live together
peacefully get away from each other and work separately.
The fact that XEmacs continues to survive as a project and
to attract developers suggests that there's a good deal of
untapped developer energy that's found a home in the XEmacs
camp. But maybe I'm wrong about that. Could some of the
people who've been atracted to the XEmacs camp explain why
they aren't contributing to Emacs instead? And maybe the
folk contributing to Emacs instead of XEmacs could do the
same. It would be useful to know what attracts the various
developers and why.
My own initial reason for contributing to XEmacs instead of Emacs
was copyright assignment. It seemed to me to be unreasonable that I
had assign copyright to the FSF just to have my code _distributed_
with Emacs. In essence I would become a supplicant, needing the
copyright holder's permission (the FSF) to modify my application. I
had no reason to believe that permission would be withheld, but the
principle of the thing still bothered me. Thus, the only code of
mine distributed with Emacs is stuff that I've abandoned.
Simon Josefsson
> >> * What would it take to merge them?
>
> An epiphany on the part of the Sun legal department or Richard
> Stallman, followed by lots and lots of work.
The legal issue seems weird to me, there is alot of code under GPL
where the legal copyright holder is != FSF. E.g. GNOME, I think. I
assume the Sun owned stuff is under GPL.
The actual merge of C code seems like too much work though. Since the
added functionality by merging the codes would be rather small, there
isn't much point in doing it.
> It would also be really cool to have common code in the same
> repository so that synching would be unnecessary.
Yes! FWIW, this is why I dislike changing elisp files when doing
syncs from Emacs -- all these minor changes ("GNU Emacs" -> "XEmacs")
makes the resulting file different, when in theory alot of lisp files
could be synched by a CVS-bot.
> Simon> * Get Guile Emacs to work, and then migrate all Elisp from
> Simon> both XEmacs and Emacs to Guile. In the long run, this
> Simon> would benefit many other projects as well.
>
> It might, but Guile has zero support on the XEmacs team AFAIK. The
> Schemers manage not to mention it on their "feasible implementations"
> page, and the Common Lispers consider it to be, well, a Scheme
> variant. :-) See
>
> http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-generation/
>
> for a summary. Ben Wing (and Jamie Zawinski, who though retired from
> XEmacs is a very smart guy with very public opinions) oppose spending
> effort on the Lisp engine at all, although they support an improved
> GC. See
>
> http://www.xemacs.org/Architecting-XEmacs/lisp-engine.html
>
> (_Architecting XEmacs_ is a generally good resource for exploring
> ideas for improving XEmacs, and implicitly GNU Emacs as well.)
I agree completely with not spending any time on the Lisp engine,
replacing it with anything that someone spent time designing would be
better. The reason I picked Guile and not CL simply was that there
isn't a GPL CL implementation AFAIK. Also, Guile doesn't have all the
baggage of old Lisp implementations, which is nice when you want to do
new stuff.
In theory I'd want a Haskell based emacs, but then I'd get both the
Guile and CL camp against me. :-)
The conclussion seems to be that emacs shouldn't be tied to one script
language at all. Have it support Guile, CL, Haskell, Perl and Python
and whatnot. Just like a operating system.
> The threading is quite irrelevent AFAICT, as redisplay is not
> thread-safe.
Display stuff should REALLY be thread-safe, it should even be run in a
separate thread so that background job doesn't affect the user
interface. This is about the first thing you learn if you go to a
usability design class.
Christopher Browne
> I agree completely with not spending any time on the Lisp engine,
> replacing it with anything that someone spent time designing would
> be better.
And I'd contend that being too "doctrinaire" about that is silly as
many other bits of politics associated with The Emacs (I guess it's
not obvious on the face of it that that's plural!).
If there was some not-too-difficult improvement to the existing Lisp
engine that would make it behave better whilst not breaking existing
code too badly, that would seem a good thing to do.
Architecting a new "underneath" isn't going to be a quick thing, and
if some bit of thing improved performance now, it seems quasi-criminal
to me to choose to ignore that.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
Never take life seriously. Nobody gets out alive anyway.
William M. Perry
> Guile need unicode (etc) support, buffers and good GTK (QT?) support
> though. Untrivial.
The GTK bindings are pretty decent. Should also get better when Gtk 2.0
comes out.
-bp
--
Ceterum censeo vi esse delendam
Stephen J. Turnbull
Christopher> Centuries ago, Nostradamus foresaw when Simon
Christopher> Josefsson <j...@extundo.com> would write:
>> I agree completely with not spending any time on the Lisp
>> engine, replacing it with anything that someone spent time
>> designing would be better.
I'm sorry, I managed to drop the necessary qualifier. Ben and Jamie
agree that "no time should be spent on CHANGING the Lisp engine," and
thus are in full agreement with Christopher:
Christopher> If there was some not-too-difficult improvement to
Christopher> the existing Lisp engine that would make it behave
Christopher> better whilst not breaking existing code too badly,
Christopher> that would seem a good thing to do.
That's what Martin Buchholz thought, Martin spent a lot of time on it,
and on the byte compiler. Martin proposed cooperative work on the
byte compiler to Gerd, and that's one of the things that "Emacs
doesn't have time to even think about right now, we'll get back to
you." Well, Martin is now offline.
The main point is that there is a lot of existing expertise in the
community on the Emacs Lisp engine. This means that people can go
"oh, this is stupid," and fix it. All that will go to waste, for
what?
As Kyle points out some people _want_ to do work like changing the
Lisp engine. If that's what they want to contribute and they do a
good job of it, I see no reason why they shouldn't.
Friedrich Domincus
>
> In theory I'd want a Haskell based emacs, but then I'd get both the
> Guile and CL camp against me. :-)
Well than you might be interested in Efuns. Check it out ;-)
Regardfs
Friedrich
Friedrich Domincus
> Friedrich Domincus <fr...@q-software-solutions.com> writes:
>
> > Definitly not. Freedom of choice have brought us XEmacs, why should I
> > give up on anything from it.
>
> XEmacs has cost me the freedom to use one good emacs. Instead, I have
> the freedom to choose between two mediocre emacsen.
Well I disagree. I like (X) Emacs and I won't give up on it. It's a
good Emacs so having it is a win for me. (Though I could live with
Emacs)
>
> > And it's extensible. which one can not say about Visual
> > Studio. (well not quite true any longer) but it feels much more
> > closed.
>
> I increasingly often see packages that "plug into" Visual Studio. And
> vim already has a truly impressive array of plug-ins.
>
> > But all the other editors can't do all what Emacs can. I can read
> > and write mails, news.
>
> Right. I don't want the build in mail and news clients to be the main
> selling point of Emacs. I want to to be superior as a text editor.
Well than work in that area. I want to do most of my tasks within one
environement which I can extend to my liking XEmacs gives me this.
>
> > I can do programming in it not just for one or two
> > or even ten languages but at least a few dozens.
>
> So does vim, and Visual Studio might be near it.
really? Well than show me how you can make it work e.g with Eiffel or
Ocaml or ...
>
> > Anyway as pointed out before it seem to be the right time for
> > reorganize the code. But that's quite a bunch of work IMHO.
>
> There is a constant reorganizing of the code going on, in both
> projects. This is how it should be.
Well yes, but I was thinking about putting all the packages into a
sorto of OO Framewark. With less code doubled etc. I do not know how
much it would buy and because I'm just talking about a "feeling" it
might be even a bad idea..
>
>
> >> To merge the projects, one of the projects would have to die.
> > Which one?
>
> Either one.
Ok let it be Emacs...
>
> >> I sincerely believe that the death of either project would be a huge
> >> win for Emacs users (who would get a better editor), third party
> >> developers (who would get a single API with more users), free software
> >> (new developers plus a better Emacs as a developing tool), and text
> >> editors in general (who would once again have Emacs to look for
> >> inspiration).
> >
> > I have no idea why you think so. What would it buy just having on
> > Emacs?
>
> Read the parenthetical remarks. Which one didn't you understood?
who would get a better editor. I can' see any evidence for that.
third party developers ?? Hardly
I don't think that there is a middle between I like Emacs I disklike
Emacs. Either you want to have more than just an editor than you have
Emacs if you don't like it use something else. My preference is using
Emacs as it is.
>
> > Well I do not know how getting a maintainer works or how this guys can
> > do what they do, because as I understand they all are volunteers.
>
> You have to volunteer for the job, and be trusted by the other
> developers.
Well, I was thinking it worked that way. Now see the difference to
some of the alternatives. You mentioned VisualStudio. Well I ask how
many work full-time on it and get paid for it? How many can work
full-time on Emacses and got paid for it?
So you would prefer having a better Editor, but what is lacking in
Emacs and why don't you extend Emacs to you liking? You don't have to
care about beeing portable if you have make you Emacs choice. So what
keep you from making Emacs the way you like to have it?
>
> >> Maybe it has to get a lot worse before it gets better.
> > What's so worse about the Emacses. They work.
>
> ed works too, and it is the standard editor.
This is a no argument.
>
> I want more from Emacs than that.
Well you got much more.
Friedrich
Friedrich Domincus
> Per Abrahamsen <abr...@dina.kvl.dk> wrote:
> > Friedrich Domincus <fr...@q-software-solutions.com> writes:
> >
> > > Definitly not. Freedom of choice have brought us XEmacs, why should I
> > > give up on anything from it.
> >
> > XEmacs has cost me the freedom to use one good emacs. Instead, I have
> > the freedom to choose between two mediocre emacsen.
> >
> > A net loss, in my book.
> >
> > [ I hate the Linux wanabee mentality that seem to presume that
> > developer resources are infinite, so the more we divide the
> > resources, the better the end result. The "competition is good"
> > mantra is apparently used as a substitute for thinking, at least on
> > /.. ]
>
> Yes, but developer resources aren't necessarily fungible. The
> work that I found the energy to do in the XEmacs development
> environment might not been available if I had to deal with the
> GNU Emacs dev environment. You can't factor out the people
> involved. It would be great if we could all just get along,
> but we can't. Some people just naturally grate on each other.
> To avoid bloodshed, reasonable people who can't live together
> peacefully get away from each other and work separately.
very well said.
>
> The fact that XEmacs continues to survive as a project and
> to attract developers suggests that there's a good deal of
> untapped developer energy that's found a home in the XEmacs
> camp. But maybe I'm wrong about that. Could some of the
> people who've been atracted to the XEmacs camp explain why
> they aren't contributing to Emacs instead?
Well I just can tell from a point of view of a user. I'm not a
maintainer or have contributed anything. Just some postings here...
But XEmacs has looked nicer
and I told before I bouht Infodock which was/is based on XEmacs.
Well I would choose to work for XEmacs because I disklike the radical
view on software from RMS, Emacs stands for this. I prefer people
which let other people decide what's good for them or what they do
like to do. XEmacs stand for tha for me.
> And maybe the
> folk contributing to Emacs instead of XEmacs could do the
> same. It would be useful to know what attracts the various
> developers and why.
Why do you think it would help anyone?
>
> My own initial reason for contributing to XEmacs instead of Emacs
> was copyright assignment. It seemed to me to be unreasonable that I
> had assign copyright to the FSF just to have my code _distributed_
> with Emacs.
Well it's quite simular to what I wrote above... ;-)
Regards
Friedrich
Pavel Janík
Date: Tue, 19 Feb 2002 22:39:38 -0000
> My own initial reason for contributing to XEmacs instead of Emacs
> was copyright assignment. It seemed to me to be unreasonable that I
> had assign copyright to the FSF just to have my code _distributed_
> with Emacs. In essence I would become a supplicant, needing the
> copyright holder's permission (the FSF) to modify my application.
This (at least the last sentence) is crystal clear misunderstanding of the
GNU GPL license. Yes, I agree, that legal work is sometimes boring etc.,
but you should not think about the current moment, just think of future...
--
Pavel Janík
It is not a raid board ... it is a raid lie
-- Andre Hedrick in linux-kernel about Promise RAID
Stephen J. Turnbull
From: kyle_...@wonderworks.com (Kyle Jones)
Date: Tue, 19 Feb 2002 22:39:38 -0000
> with Emacs. In essence I would become a supplicant, needing the
> copyright holder's permission (the FSF) to modify my application.
Pavel> This (at least the last sentence) is crystal clear
Pavel> misunderstanding of the GNU GPL license.
The GNU GPL is exactly the permission under discussion. The fact that
the _license_ is granted a priori by the FSF does not make it any less
_permission_.
Maybe that philosophical fine point doesn't bother you. I see no
reason why it should. I also understand (perhaps) why Kyle _is_ deeply
bothered by it. Writing software is a personal thing, and the sense of
property (ie, "this entity is somehow part of me") can be very strong.
YMMV, but please don't assume that that means alternative
interpretations are mistaken.
Per Abrahamsen
> Emacs, and get RedHat and Debian or similar to include it (RMS doesn't
> seem interested)
Have you asked him?
Per Abrahamsen
> The legal issue seems weird to me, there is alot of code under GPL
> where the legal copyright holder is != FSF. E.g. GNOME, I think. I
> assume the Sun owned stuff is under GPL.
I think it is understandable that they want the best legal defense
possible for each package, rather than make the least protected GNU
package the standard for all of GNU. They'd probably like a key
ingredient like Gnome to have assignment papers too, but that is too
late now.
> The actual merge of C code seems like too much work though. Since the
> added functionality by merging the codes would be rather small, there
> isn't much point in doing it.
I suspect there is very little merging at that level going on now.
However, if both emacsen would use the same standard for loadable
modules, that would be a big help.
> The conclussion seems to be that emacs shouldn't be tied to one script
> language at all. Have it support Guile, CL, Haskell, Perl and Python
> and whatnot. Just like a operating system.
I disagree, more scripting languages would make Emacs much harder to
understand and debug. I.e., if I notice a bug in the calendar
application, I should not have to learn INTERCAL in order to fix it,
just because that was the language the author was most comfortable
with. Today I only have to learn two languages in order to enhance
Emacs, Emacs Lisp and C. That should be plenty.
Nonetheless, the idea behind Guile is that it is not a language, but a
system consisting of a Scheme back end and various translators from
Perl, Python, TCL, Emacs Lisp and other front ends. I.e. it should be
the GCC of scripting languages. Whether anyone still believe it will
or can ever be that is another matter.
Per Abrahamsen
> I'm sorry, I managed to drop the necessary qualifier. Ben and Jamie
> agree that "no time should be spent on CHANGING the Lisp engine," and
> thus are in full agreement with Christopher:
Should that be read as
"no time should be spent on REPLACING the Lisp engine,"
or
"no time should be spent on MODIFYING the Lisp engine,"
?
Stephen J. Turnbull
>> Either one.
Friedrich> Ok let it be Emacs...
Please, let's not go there.
Friedrich> So you would prefer having a better Editor, but what is
Friedrich> lacking in Emacs and why don't you extend Emacs to you
Friedrich> liking?
Nor there. Yes, I too would like to know why Per is despairing. But
that's precisely because he not only ranks among those who have done
most to extend and make Emacs fit _his own_ liking, but he's done it
in such a way as to enable others to fit _theirs_.
Eli Zaretskii
>
> You can't factor out the people
> involved. It would be great if we could all just get along,
> but we can't. Some people just naturally grate on each other.
Is that really ``people'', or just one man, RMS?
Yes, people cannot be factored out, but that doesn't mean we have to accept
the fatalist vision that ``sh*t happens'' and live with that. Failure to
cooperate is just that--a failure. It is a Bad Thing, not something we
should agree to live with, let alone praise.
One should struggle to cooperate in spite of disagreements, under the
assumption that the truth is never on one side. There are quite a few
people who succeeded to cooperate with RMS. Do you really think those
people are less opinionated and stubborn than those who failed to
cooperate? Well, think again--or maybe read some of my more heated
messages to get a perspective on my vice in that area ;-)
Assuming that Emacs development is deemed important, there's always a
possibility to find a compromise that both sides can live with.
Experience, both my own and that of others, shows that given enough
ingenuity and will to cooperate for the benefit of a common goal, you can
get along with RMS.
> To avoid bloodshed, reasonable people who can't live together
> peacefully get away from each other and work separately.
The notion that the only two alternatives are bloodshed and separation is
IMHO an affront to intelligence.
> My own initial reason for contributing to XEmacs instead of Emacs
> was copyright assignment. It seemed to me to be unreasonable that I
> had assign copyright to the FSF just to have my code _distributed_
> with Emacs.
If FSF's obsession with copyright assignments is in your opinion a reason
good enough for the fork, then I think you are equally obsessed with that
issue, it's just that your obsession has an opposite sign. IMHO,
obsessions and dogmatism should be met with flexibility, not with another
obsession. After all, it's not that the copyright assignment is requested
for some dark purposes.
Eli Zaretskii
>
> The fact that
> the _license_ is granted a priori by the FSF does not make it any less
> _permission_.
But it does make the whole point of being bothered by that a bit moot.
Per Abrahamsen
> Yes, but developer resources aren't necessarily fungible.
True, which is why I estimated a 50% efficiency in the transferring
process.
> The fact that XEmacs continues to survive as a project and
> to attract developers suggests that there's a good deal of
> untapped developer energy that's found a home in the XEmacs
> camp.
Sure. But I'm certain some, at least initially, choose XEmacs because
it was their favorite editor. And some would have contributed despite
minor annoyances like the work of signing a paper, or the (back then)
opaque development process. And some would have contributed to third
party projects, like Gnus or VM. And some would have contributed to
other worthy free software projects, like Gnome or KDE.
So I suspect the net loss in developers would be small.
> And maybe the folk contributing to Emacs instead of XEmacs could do
> the same.
XEmacs didn't exist when I started contributing, and it wasn't usable
for my purposes the first years (no termcap support).
> My own initial reason for contributing to XEmacs instead of Emacs
> was copyright assignment.
It is possible to negotiate some sort of disclaimer instead, i.e. "we
won't sue you for distributing this". See `charset.c' for example.
Of course, that is not the preferred option.
> In essence I would become a supplicant, needing the
> copyright holder's permission (the FSF) to modify my application.
Actually, you get a counter-contract when signing over copyright that
grant you additional rights over GPL, including the right to use the
code in a proprietary application.
Eli Zaretskii
>
> Well I would choose to work for XEmacs because I disklike the radical
> view on software from RMS, Emacs stands for this.
I don't follow: what does RMS's radical views have to do with the
software? Does GNU Emacs pop ads with RMS's views now and then or
something? Does it perhaps smell differently?
> I prefer people
> which let other people decide what's good for them or what they do
> like to do.
The point is that, given a larger development team, you could have a
freedom to decide. Emacs can already be compiled as several different
versions (with and without Motif/Lesstif, with and without Xaw3d, etc.).
One could imagine a possiblity of a version that is more slated to users
who are mouse-and-GUI-oriented as well. It doesn't take a fork to make
that happen.
Eli Zaretskii
>
> Per Abrahamsen <abr...@dina.kvl.dk> writes:
>
> > XEmacs has cost me the freedom to use one good emacs. Instead, I have
> > the freedom to choose between two mediocre emacsen.
> Well I disagree. I like (X) Emacs and I won't give up on it. It's a
> good Emacs so having it is a win for me.
Would you oppose to have a better (X)Emacs? I bet you won't.
FWIW, I completely agree with Per: both Emacsen fall behind the current
technology. There are too many innovations out there that we should have
supported, but don't. The main reason is very clear to me: it is simply
ridiculous to assume that such a large project can be developed and
maintained by less than 10 active developers working on their free time.
I'm amazed that this should be explained at all.
Working on two competing projects makes the scarce resources more scarce,
so it's definitely not something we should consider a Good Thing.
I sadly concur with others: the fork will probably stay with us unless one
of the projects dies. But that doesn't mean we should regard it as
desirable.
> > I want to to be superior as a text editor.
> Well than work in that area.
Per _does_ work in that area. But do you really think that a single
individual can do _any_ job, no matter how large it is? There are features
that a single volunteer simply cannot make happen. If we had 2 or 3 or 5
individuals where we now have only one, that might have allowed us to do
what today is a pipe dream.
Friedrich Domincus
> >>>>> "Friedrich" == Friedrich Domincus <fr...@q-software-solutions.com> writes:
>
> >> Either one.
>
> Friedrich> Ok let it be Emacs...
>
> Please, let's not go there.
you can see what difference an X makes ;-)
Of course it should have been XEmacs ....
Regards
Friedrich
Friedrich Domincus
> Friedrich Domincus wrote:
> >
> > Well I would choose to work for XEmacs because I disklike the radical
> > view on software from RMS, Emacs stands for this.
>
> I don't follow: what does RMS's radical views have to do with the
> software? Does GNU Emacs pop ads with RMS's views now and then or
> something? Does it perhaps smell differently?
Well yes it does (for me)
>
> > I prefer people
> > which let other people decide what's good for them or what they do
> > like to do.
>
> The point is that, given a larger development team, you could have a
> freedom to decide. Emacs can already be compiled as several different
> versions (with and without Motif/Lesstif, with and without Xaw3d, etc.).
> One could imagine a possiblity of a version that is more slated to users
> who are mouse-and-GUI-oriented as well. It doesn't take a fork to make
> that happen.
Well the fork has happend in the past and the question is should it
stay that way. I haven no problems with either of the solutions as
long as XEmacs persists ;-)
Regards
Friedrich
Stephen J. Turnbull
Per> Should that be read as
Sheesh, I'm gonna have to get some sleep.
Per> "no time should be spent on REPLACING the Lisp engine,"
Yeah, what he said.
As I remarked elsewhere, there are people who want to do this, just
because they want to. So it probably will happen, despite the
opinions of ben and jwz. Ben even treats the issue seriously in
Architecting XEmacs, though he concludes he thinks it a waste of
effort.
Stephen J. Turnbull
>> The actual merge of C code seems like too much work though.
>> Since the added functionality by merging the codes would be
>> rather small, there isn't much point in doing it.
Per> I suspect there is very little merging at that level going on
Per> now.
APIs and external programs (eg, etags for sure, and occasionally
gnuclient), AFAIK. And <crunch> <bonk> <screech> I see the big CVS
machinery grinding away on Ben's "new mule" merge. With that, for the
editor stuff, there are no common insides left, although several of us
are looking longingly at Stefan's syntax and regex code.
One of the things that 21.4 still needs to digest is Matt Tucker's
port of the local syntax table support, but that was a graft, not a
merge.
Per> However, if both emacsen would use the same standard for
Per> loadable modules, that would be a big help.
I thought that was a stone, cold, oaken-stake-through-the-heart, dead
issue in GNU Emacs? Is there an API standard (the Lispref mentions
"dso", "dll", and "loadable" not at all, and "module" only in the
GPL)? Loadable modules are under quasi-active development in the
XEmacs project, and there are at least two large projects dependent on
XEmacs DSO support. Should I ask those guys about the Emacs DSO
support (I know nothing about it at this point)?
Per> Nonetheless, the idea behind Guile is that it is not a
Per> language, but a system consisting of a Scheme back end and
Per> various translators from Perl, Python, TCL, Emacs Lisp and
Per> other front ends. I.e. it should be the GCC of scripting
Per> languages. Whether anyone still believe it will or can ever
Per> be that is another matter.
Yikes! My evaluation of the plausibility of Guile just took a big
step down. But I'll ask people who are a lot longer on clue than me
before I confirm that.
Per Abrahamsen
> Yes, people cannot be factored out, but that doesn't mean we have to accept
> the fatalist vision that ``sh*t happens'' and live with that.
It is free software and volunteer time. If it is no longer fun, we
should find somewhere else to volunteer our time. There are plenty of
worthy and interesting free software projects.
> The notion that the only two alternatives are bloodshed and separation is
> IMHO an affront to intelligence.
I can certainly find contexts for the literal notion, both in .il and
.dk, where I would agree with you.
However, free software development is not such a context.
Per Abrahamsen
> Does GNU Emacs pop ads with RMS's views now and then or
> something?
Yes. Try to start emacs, and read the minibuffer.
Eli Zaretskii
I had that disabled for years ;-)
Anyway, that's ``now''. There's no ``then''.
Eli Zaretskii
>
> It is free software and volunteer time. If it is no longer fun, we
> should find somewhere else to volunteer our time.
It's never pure fun. It's a priority call, as always.
> > The notion that the only two alternatives are bloodshed and separation is
> > IMHO an affront to intelligence.
>
> I can certainly find contexts for the literal notion, both in .il and
> .dk, where I would agree with you.
>
> However, free software development is not such a context.
I think it is. Just tell yourself that those are just ones and zeros, not
something real such as whose land it is ;-)
Per Abrahamsen
>> > I can do programming in it not just for one or two
>> > or even ten languages but at least a few dozens.
>>
>> So does vim, and Visual Studio might be near it.
> really? Well than show me how you can make it work e.g with Eiffel or
> Ocaml or ...
Visual Studio:
Eiffel: <http://www.dotnet.eiffel.com/vsnet/>
Ocaml: Nope. There is an SML project from Microsoft Research with
Visual Studio support, but it is not released yet.
Vim:
Eiffel: <http://www.eiffel-forum.org/archive/fiat/vim.htm>
Ocaml: < http://www.ai.univie.ac.at/~markus/home/ocaml_hints.html >
> who would get a better editor.
The users.
> I can' see any evidence for that.
Increasing the number of developers should improve the surviving
editor.
> third party developers
Having a single API would decrease the amount of compatibility work
needed, giving more time to add features and fix bugs. Having a
single development line would make it possible to drop backward
compatibility sooner, and thus decrease maintenance work.
And the "then drop compatibility" option requires even more work, as
the developer would have to port or reimplement new features and bug
fixes someone else added to a similar package for the "other emacs".
By maintaining compatibility, the tpd can expect to get fixes and
enhancements for his package from users of both emacsen.
> So you would prefer having a better Editor, but what is lacking in
> Emacs and why don't you extend Emacs to you liking?
Why do you presume I don't extend Emacs to my liking?
Unfortunately, I don't have time to do all the stuff I'd like to do.
Fortunately, other people are also extending Emacs in ways I like.
Unfortunately, these people are still to few to do all the cool stuff
that ought to be done.
Per Abrahamsen
>>>>>> "Per" == Per Abrahamsen <abr...@dina.kvl.dk> writes:
>
> Per> However, if both emacsen would use the same standard for
> Per> loadable modules, that would be a big help.
> I thought that was a stone, cold, oaken-stake-through-the-heart, dead
> issue in GNU Emacs?
It might be, if RMS fear dynamic loading may be used to defeat the
GPL (the courts might not agree with his interpretation).
However, it has been mentioned a couple of times lately, without it
being shot down. Wmperry tend to comment on such threads, which
should increase the chance that it will not be totally dissimilar to
XEmacs, was it ever to happen.
> Is there an API standard (the Lispref mentions
> "dso", "dll", and "loadable" not at all, and "module" only in the
> GPL)?
Oh, there _is_ nothing. I was speaking hypothetically, as a mechanism
for sharing C code.
Ralf Fassel
| Could some of the people who've been atracted to the XEmacs camp
| explain why they aren't contributing to Emacs instead?
My guess is that today it's a question of which emacs version you run
into first, which in turn might be a question of what your favourite
Linux distro configures as `emacs'. People might not even *know*
there are two (or even more) emacsen when they first pop up xemacs
because that's what is `there'.
Plus there is nowadays a move towards GUIish programs, away from the
keyboard-driven. IMHO emacs is and has always been runner-up when it
comes to GUI compared to xemacs. This might have changed in the
recent past (emacs catching up), but since I do not use the GUI much I
haven't checked and I don't care. People who do use the GUI might
care however.
| And maybe the folk contributing to Emacs instead of XEmacs could do
| the same. It would be useful to know what attracts the various
| developers and why.
When I started with emacs way back in the 18.57(58?) days xemacs was
just about becoming useable. So there wasn't a great problem in
deciding which one to use. I now try to code for both variants, but
the difference in API is sometimes frustrating.
R'
Ralf Fassel
| Having a single API would decrease the amount of compatibility work
| needed, giving more time to add features and fix bugs.
As an add-on to your point, snipped from our site-start (and that's
not yet the local packages, just the startup!):
grep -n xemacs site-start.el /dev/null
site-start.el:3:;; please make sure everything in this file works for emacs AND xemacs
site-start.el:13:(setq xemacs (string-match "XEmacs" emacs-version))
site-start.el:46: ;; xemacs has defaults set up ok, but needs explicit loading
site-start.el:62:(cond (xemacs
site-start.el:82: (cond (xemacs
site-start.el:83: ;; xemacs needs it one way, emacs the other way
site-start.el:332: ;; xemacs has this by default in 21.4.5
site-start.el:333: (or xemacs (pc-bindings-mode))
site-start.el:397: (if xemacs
site-start.el:432:(if (and xemacs (not (fboundp 'copyright)))
site-start.el:441:(if xemacs
R'
Stephen J. Turnbull
Per> However, it has been mentioned a couple of times lately,
Per> without it being shot down. Wmperry tend to comment on such
Per> threads, which should increase the chance that it will not be
Per> totally dissimilar to XEmacs, was it ever to happen.
Oh, way cool!
>> Is there an API standard (the Lispref mentions "dso", "dll",
>> and "loadable" not at all, and "module" only in the GPL)?
Per> Oh, there _is_ nothing. I was speaking hypothetically, as a
Per> mechanism for sharing C code.
Also cool, at least there's nothing to argue about yet. I'll talk to
Bill, and add yet another archive that I have to browse regularly.
Stephen J. Turnbull
Eli> Kyle Jones wrote:
>> You can't factor out the people involved. It would be great if
>> we could all just get along, but we can't. Some people just
>> naturally grate on each other.
Eli> Is that really ``people'', or just one man, RMS?
That's unfair, because you (should) know that the answer is "yes, and
yes, too." There are recent examples not involving rms in many major
projects, including internal to XEmacs. But in any attempt to merge,
rms would certainly be central.
Eli> There are quite a few people who succeeded to cooperate with
Eli> RMS.
So what? The point is that there are a lot who failed.
Go reread The Thread[1] again, starting from the assumption that rms,
rpg, and jwz were all _honestly_ interested in establishing what they
understood as "cooperation". It only requires a little bit of effort
to maintain that hypothesis throughout, for me, anyway.
They tried, they tried harder, they failed.
Not much fun, profit, or advancement of free software in that.
IMO, if we are going to find ways to cooperate, for quite a while we
are going to have to be realistic and look for ways that allow people
who are quite unlikely to get along to work in separate offices, as it
were. (un?)Fortunately, there are plenty of projects that would do
good here and now that can be done that way.
Footnotes:
[1] http://www.jwz.org/doc/lemacs.html is more complete than the
version on Per's home page.
Stephen J. Turnbull
Kyle> Could some of the people who've been atracted to the XEmacs
Kyle> camp explain why they aren't contributing to Emacs instead?
0. As rms is always at pains to point out, "also" is a possibility in
principle.
I don't have a problem with the assignment of my code, but in
practice, my attempts have been thwarted by various bureaucratic
hurdles (like getting others) and attendent snafus (coordinating
add-on to add-on submission). Not to mention laziness. I'll keep
trying, but I won't criticize those who don't try at all.
There are a number of reasons I'm attracted to XEmacs.
1. The original occasion to join XEmacs: I had a problem with Mule +
XIM, due to non-replicability by the principal developers (Kenichi
Handa of ETL, then not yet part of GNU Emacs, and Martin Buchholz
for XEmacs), I had to work out the problem for myself.
After looking at the relevant code, I found that of XEmacs more
modular, at a more appropriate level of abstraction, and clear.
This feeling (YMMV) was confirmed through further experience and
continued through Emacs 20.x. I can't speak about Emacs 21.1 yet.
2. XEmacs people have been very good to me, though I can be rather
abrasive. I don't think of this as an "advantage" over GNU Emacs,
but it is attractive.
3. When I first tried to submit code to GNU Emacs, I was somewhat
offended that rms took the assignment, showed no interest in the
code, and immediately asked me to join GNU Emacs. I am not a
resource to be stockpiled. Argue that that's childish if you
like; it's the truth that I feel that way, and it affects my
attitude toward GNU Emacs while rms continues to lead the
project.
FWIW I do not interpret it, as many XEmacs people do, as a
deliberate attempt to suborn XEmacs developers. AFAICT, rms is
simply an overworked manager with an understaffed project, doing
his best to get the job done by recruiting every prospect.
4. rms clearly subordinates the quality of the product from the
user's point of view to fine points of principle I disagree with
completely, and to legal theories/scenarios I assess as highly
unlikely to result in significant damage to any one project, let
alone the whole GNU Project. I don't _know_ that it really hurts
quality all that much, but I do not wish to work under those
constraints since I don't think they buy anything.[1]
5. (This is probably extremely specific to me, but maybe there's some
broader applicability.)
I doubt I could have made a significant contribution to Emacs over
the past 5 years. I'm not a fast excellent coder, I'm analytical,
a standards geek, and an organizer. Emacs needs organizers, but
rms is one rallying point nobody could ever substitute for, and
the other organizational role, Emacs maintainer, AFAICT requires
much more development skill than I can muster, even now.
In XEmacs I've been able to contribute much more extensively,
because I'm in a more limited role, suited to my abilities.
Though I've had my ups and some real downs, nobody has yet told me
that I've been a net negative. So given the circumstances and my
abilities, XEmacs provided an opportunity for contribution and
personal growth that I can't imagine having been possible _for me_
in GNU.
As for the Per/Stefan contention that killing of one of the projects
would probably increase available development manpower by 50%, I
rather suspect I'm part of the other 50%. I'd probably end up as
staff economist at the OSI.
Footnotes:
[1] This has no relation to a comparison of XEmacs vs. GNU Emacs
quality; this is "what GNU Emacs is" vs. "what GNU Emacs could be",
and to my mind, what it _should_ be.
William M. Perry
> "Stephen J. Turnbull" <ste...@xemacs.org> writes:
>
>>>>>>> "Per" == Per Abrahamsen <abr...@dina.kvl.dk> writes:
>>
>> Per> However, if both emacsen would use the same standard for
>> Per> loadable modules, that would be a big help.
>
>> I thought that was a stone, cold, oaken-stake-through-the-heart, dead
>> issue in GNU Emacs?
>
> It might be, if RMS fear dynamic loading may be used to defeat the GPL
> (the courts might not agree with his interpretation).
There is still some legitimate fear, and my suggestions for a foreign
function interface similar to what I did for XEmacs to get the GTK bindings
easily was politely shot down.
Something like the FFI exposes emacs much more than the module API though.
> However, it has been mentioned a couple of times lately, without it being
> shot down. Wmperry tend to comment on such threads, which should
> increase the chance that it will not be totally dissimilar to XEmacs, was
> it ever to happen.
If I don't scream loudly if something incompatible gets merged into the CVS
tree, that means I'm either dead or lost the use of both my hands, feet,
and voice. :)
-bp
--
Ceterum censeo vi esse delendam
Eli Zaretskii
>
> >> You can't factor out the people involved. It would be great if
> >> we could all just get along, but we can't. Some people just
> >> naturally grate on each other.
>
> Eli> Is that really ``people'', or just one man, RMS?
>
> That's unfair, because you (should) know that the answer is "yes, and
> yes, too."
It's not unfair. For the benefit of those who don't know enough about the
issue, we should all try to be as accurate as possible. It's one thing to
say you don't get along with RMS, and it's quite another to say you don't
get along with the development team or several of its members.
> Eli> There are quite a few people who succeeded to cooperate with
> Eli> RMS.
>
> So what? The point is that there are a lot who failed.
The important point is that there are both those who failed and those who
succeeded. To me, this says that it's possible.
> Go reread The Thread[1] again
I don't need to re-read it, I have it sitting on my desk and read it all the
time.
> They tried, they tried harder, they failed.
IMHO, they didn't try hard enough.
> IMO, if we are going to find ways to cooperate, for quite a while we
> are going to have to be realistic and look for ways that allow people
> who are quite unlikely to get along to work in separate offices, as it
> were.
We can (and it seems will have to) live with a failure, but we should know
that it's a failure, not something that is good for the community.
Per Abrahamsen
> The important point is that there are both those who failed and those who
> succeeded. To me, this says that it's possible.
This is silly, I have never had the slightest problem working with
RMS, but I could name five other emacs people[1] with whom I find
cooperation as painful as using vi for text editing.
Obviously, it is individual who you can enjoy working with.
Footnotes:
[1] No current members of either core team.
Deepak Goel
[...]
> To merge the projects, one of the projects would have to die.
> I sincerely believe that the death of either project would be a huge
> win
me-too....
the problem is there is no one to 'bell the cat'..
Wish something like this could be carried out:
Generate enough interest and momentum for killing a project. Then
take a community- or developer- vote "which project should die"...
Yes, there will be no one to enforce the vote, but hopefully many
developers will respect the vote and switch... 'tis like recycling...
all voluntary.. and even a quarter of the developers swithching sides
may help the death-effort because of the resulting asymmetry...
Eli Zaretskii
>
> Eli Zaretskii <el...@is.elta.co.il> writes:
>
> > The important point is that there are both those who failed and those who
> > succeeded. To me, this says that it's possible.
>
> This is silly, I have never had the slightest problem working with
> RMS, but I could name five other emacs people[1] with whom I find
> cooperation as painful as using vi for text editing.
But you didn't get out and started your own PA-Emacs fork because of that,
did you?
> Obviously, it is individual who you can enjoy working with.
Who said anything about enjoying working with people? Programmers generally
enjoy programming; if that can be combined with enjoyable personal
relationship, it's even better. But it isn't necessarily a must, and IMHO
it doesn't mean one should start one's own fork each time you meet with some
other developer who's got his or her tact filter on backwards.
Kyle Jones
> > could do the same. It would be useful to know what attracts
> > the various developers and why.
>
If we have as Per says, two mediocre Emacses instead of one good
one, we could use more developers. Instead of luring existing
developers from one camp or the other we could try to attract new
ones. To do that, we need to know what attracts developeors in
the first place.
David Masterson
> Who said anything about enjoying working with people? Programmers
> generally enjoy programming; if that can be combined with enjoyable
> personal relationship, it's even better. But it isn't necessarily a
> must, and IMHO it doesn't mean one should start one's own fork each
> time you meet with some other developer who's got his or her tact
> filter on backwards.
From someone on the outside (but who's observed the whole thing), the
history of the Emacs fork seems to suggest that it didn't occur so
much from two different camps not being able to get along with each
other as thru a series of unrecognized communication messups and
breakdowns. The problem seems to have been that *after* the fork
occurred, both camps were too invested in their side of the fork to
back off and spend the proper time to reintegrate. The key theme that
seems to come through from JWZ's web-page is "Time To Market" -- both
sides had a TTM window that they were trying to meet (more so on the
Lucid side than the FSF side, but both seemed to have this issue) and
any delays from (possibly major) rearchitecting would've blown TTM.
Once the mindshare of each fork became established and the history of
the communication problems spread, there was too much investment in
the forks for them to come back together easily and not enough
personal desire to force them back together.
--
David Masterson dmaster AT synopsys DOT com
Sr. R&D Engineer Synopsys, Inc.
Software Engineering Sunnyvale, CA
Kyle Jones
> Stephen J. Turnbull wrote:
> > The fact that the _license_ is granted a priori by the FSF
> > does not make it any less _permission_.
>
> But it does make the whole point of being bothered by that a bit moot.
A bit. But there is principle. Think of something you consider
valuable. Now I come to you and say "Please assign your rights to
this item to me. I'll let you have full use of it, of course, for
as long as you like. But in the eyes of the law the item will
henceforth belong to me." Wouldn't this make you feel uneasy?
IPmonger
> A bit. But there is principle. Think of something you consider
> valuable. Now I come to you and say "Please assign your rights to
> this item to me. I'll let you have full use of it, of course, for as
> long as you like. But in the eyes of the law the item will
> henceforth belong to me." Wouldn't this make you feel uneasy?
That depends.
If all I want from ownership is the /utility value/ and I don't want
the hassle of maintainership, then I'd actually feel better if you
owned it.
On the other hand, if you were a bad maintainer, I'd be frustrated
and I'd take the burden of ownership upon myself in order to have a
higher quality tool to use.
One nice thing about the GPL is that I can have it the first way,
which I prefer for some things, and not give up my ability to have it
the second way at a later time.
The one niggling little point about copyright assignment would be
that you might later change the license on a new version so that I
couldn't derive the utility value from the new version, but you
haven't deprived me of anything since I still have the old version
with "my" part in it. Of course, that is not worse a situation than
if I just released it under another (any other?) non-GPL Open Source
license.
-IPmonger
--
------------------
IPmonger
ipmo...@delamancha.org
Simon Josefsson
> Simon Josefsson <j...@extundo.com> writes:
>
>>
>> In theory I'd want a Haskell based emacs, but then I'd get both the
>> Guile and CL camp against me. :-)
> Well than you might be interested in Efuns. Check it out ;-)
ML isn't Haskell. :-) But maybe close enough.
Haskell is nice because HUGS (interactive haskell evaluator) had some
nice X11 stuff last time I looked, and GHC actually compiles haskell
into machine code.
Simon Josefsson
> Simon Josefsson <j...@extundo.com> writes:
>
>> Emacs, and get RedHat and Debian or similar to include it (RMS doesn't
>> seem interested)
>
> Have you asked him?
One thread on this:
http://groups.google.com/groups?hl=en&th=ace2caac7cb9679f&seekm=4rrr4qpd.fsf%40blue.sea.net
I remember more discussions about this related to the lispmeralda project,
but I cannot find them.
Simon Josefsson
> Per Abrahamsen <abr...@dina.kvl.dk> writes:
>
>> "Stephen J. Turnbull" <ste...@xemacs.org> writes:
>>
>>>>>>>> "Per" == Per Abrahamsen <abr...@dina.kvl.dk> writes:
>>>
>>> Per> However, if both emacsen would use the same standard for
>>> Per> loadable modules, that would be a big help.
>>
>>> I thought that was a stone, cold, oaken-stake-through-the-heart, dead
>>> issue in GNU Emacs?
>>
>> It might be, if RMS fear dynamic loading may be used to defeat the GPL
>> (the courts might not agree with his interpretation).
>
> There is still some legitimate fear, and my suggestions for a foreign
> function interface similar to what I did for XEmacs to get the GTK bindings
> easily was politely shot down.
>
> Something like the FFI exposes emacs much more than the module API though.
Actually Richard suggested implementing GNU TLS support by way of
loading it as a separate module or something like that. So maybe it
will happen. If I understood what implementing FFI would require, I
might take a stab at it, if I find some time.
Simon Josefsson
You don't lose copyright on or right to the code (nothing can make you
lose copyright on something you made, by the Geneva convention, I
believe), so you can re-license it or do whatever you want it anyway.
You are only making FSF the legal owner of the code as well. I think
you are supposed to get counter-signed papers revoking FSFs rights if
you want as well.
I don't enjoy doing the paperworks, and I don't understand why there
are certain rules for some GNU projects and other rules for other
projects.
This discussion sort of remind me of EGCS vs GCC. GCC is really a
core component, so the difficulties had to be solved. Emacs vs XEmacs
seem to have similar differences, but there isn't enough pressure to
resolve the problems so they haven't been resolved.
Stephen J. Turnbull
ipmonger> The one niggling little point about copyright
ipmonger> assignment would be that you might later change the
ipmonger> license on a new version so that I couldn't derive the
ipmonger> utility value from the new version,
No, that actually isn't a problem because the assignment says that the
code must remain free software as long as it is distributed by the FSF
or its assigns. The wording might be shaky but the intent is clear; I
think it's enforceable.
But there is a much worse problem. I filed a bug report, admitted to
be a bug by rms (ISTR on consultation with his lawyer), against the
assignment I signed. That bug is that the FSF could abandon the
copyright by placing my code in the public domain.
This bug is still not fixed AFAIK; I have not received new documents
to sign from the FSF, nor a notice that upon review, they found that
it is not an issue. I don't know if new versions of the standard
assignments have the bug fixed; last I checked they were not
publically available.
As usual, you can say "but rms would never do _that_." Principles,
principles, who's got principles? rms does; he acknowledged the bug.
He did not say "I wouldn't _ever_ do _that_."
Stephen J. Turnbull
Simon> You don't lose copyright on or right to the code (nothing
Simon> can make you lose copyright on something you made, by the
Simon> Geneva convention, I believe),
AFAIK that depends on the national rules. I don't think the Geneva
Convention attempts to turn the U.S., where selling your copyright has
historically been possible, into Germany, where it is not.
In any case, it is crystal clear that the FSF believes that it can buy
copyright, lock, stock, and barrel. Given the legal conservatism they
show, they would not add dangerously ambiguous clauses to their
assignments if the rights thus granted were already available to
authors.
Stephen J. Turnbull
>>>>> "Eli" == Eli Zaretskii <el...@is.elta.co.il>
>>>>> "sjt" == "Stephen J. Turnbull"
>>>>> "kj" == Kyle Jones
kj> You can't factor out the people involved. It would be great
kj> if we could all just get along, but we can't. Some people
kj> just naturally grate on each other.
Eli> Is that really ``people'', or just one man, RMS?
sjt> That's unfair, because you (should) know that the answer is
sjt> "yes, and yes, too."
Eli> It's not unfair. For the benefit of those who don't know
Eli> enough about the issue, we should all try to be as accurate
Eli> as possible. It's one thing to say you don't get along with
Eli> RMS, and it's quite another to say you don't get along with
Eli> the development team or several of its members.
"There you go again." You focus on rms and the Emacs fork, but Kyle
does not. Kyle didn't _want_ to say either of those things, taking
his statement at face value. Evidently Kyle's reality does not
involve singling out rms or anyone on the Emacs team, but does seem to
have symmetry between those on that team and those not. Isn't that a
positive thing?
It's true that I have now had several years of acquaintance with Kyle,
and you haven't. So I actually have strong reason[1] to respect his
exact phrasing. But it seems to me that, as a general strategy,
cooperation starts by respecting another's words, and trying to deduce
his reality from them.
I think it is unfair, and inaccurate, to fail to respond to Kyle's
intended meaning.
>> They tried, they tried harder, they failed.
Eli> IMHO, they didn't try hard enough.
Noted. But you weren't there.
Anyway, it is the future, not the past, that can be changed. Go talk
to Richard Stallman about it, and see if you can get him to "try
harder." _I'll_ go work on my hardliners.
Footnotes:
[1] In fact, this space used to contain 15 lines of "more in sorrow
than in anger" diatribe. I know that won't work; let's try Kyle-style.
Eli Zaretskii
>
> Per Abrahamsen <abr...@dina.kvl.dk> writes:
>
> > Simon Josefsson <j...@extundo.com> writes:
> >
> >> Emacs, and get RedHat and Debian or similar to include it (RMS doesn't
> >> seem interested)
> >
> > Have you asked him?
>
> One thread on this:
>
> http://groups.google.com/groups?hl=en&th=ace2caac7cb9679f&seekm=4rrr4qpd.fsf%40blue.sea.net
This just says that the packaging system is too heavy-weight. I don't see
anything wrong with looking for simpler solutions, if they exist.
Eli Zaretskii
It would, if I had the slightest reason to believe that the copyright I
assign could ever be used for some purpose I might disagree with. I cannot
see how can this be the case with whatever the FSF does with my code.
Eli Zaretskii
>
> Evidently Kyle's reality does not
> involve singling out rms or anyone on the Emacs team, but does seem to
> have symmetry between those on that team and those not.
But that's exactly why I asked whether RMS alone was the issue. You said
it was, or so I understood. Now you seem to say it isn't; I'm confused.
> It's true that I have now had several years of acquaintance with Kyle,
> and you haven't. So I actually have strong reason[1] to respect his
> exact phrasing.
I respect the phrasing, too, but I wanted to be sure I understand the
intent. I don't find anything wrong with asking questions to that end.
> [1] In fact, this space used to contain 15 lines of "more in sorrow
> than in anger" diatribe. I know that won't work; let's try Kyle-style.
Thanks for trying.
Per Abrahamsen
> Who said anything about enjoying working with people? Programmers generally
> enjoy programming; if that can be combined with enjoyable personal
> relationship, it's even better.
That is your priorities. I wouldn't take a paid job with people I
dislike, no matter how interesting it might otherwise be. And I'm
certainly not going to do the same in a volunteer job.
> But it isn't necessarily a must, and IMHO it doesn't mean one should
> start one's own fork each time you meet with some other developer
> who's got his or her tact filter on backwards.
I don't think anyone in this thread have actually suggested doing
that, so I don't see the relevance of that comment.
Stephen J. Turnbull
Eli> But that's exactly why I asked whether RMS alone was the
Eli> issue. You said it was, or so I understood. Now you seem to
Eli> say it isn't; I'm confused.
Progress, of a sort. :-) I've been there (and will be there again).
Eli> I respect the phrasing, too,
I'm sorry, but in fact the phrasing in your post severely distorted
Kyle's phrasing by turning it into a question of individuals, and all
on one side, rather than relationships involving both sides.
Adjusting a relationship requires either capitulation, or cooperation.
Here capitulation is inappropriate, the issues are too important to
the participants. Cooperation is unlikely, since the relationships
are already problematic.
In my experience focusing on the individuals in a relationship leads
to inflooping over "he should, but ... she should, but ... he should,
but ...". Imperative, pointer-chasing, C thinking, as it were. But
if you make things symmetric and focus on the relationship as an
entity, you often see that "oh, this relationship may be bad, but it's
very stable ... let's direct our energy to something more likely to be
adjustable to everyone's benefit." Functional, object-oriented, Lisp
thinking.
So the original way of putting it, to my mind, is more likely to
result in useful cooperation, than trying to accurately specify the
"problem node."
Per Abrahamsen
> That bug is that the FSF could abandon the
> copyright by placing my code in the public domain.
Is, in fact, possible to abandon copyright in the US? I never found
any clause in Danish copyright law that allowed that. I have tried
looking in US copyright law, but I find the language incomprehensible.
Mats Lidell
Kyle> Could some of the people who've been atracted to the XEmacs camp
Kyle> explain why they aren't contributing to Emacs instead?
The most important reason for me start to _use_ XEmacs was the
existence of the elisp-tar-ball. (This goes back to the time when it
was Lucid Emacs. I don't remember if it really was a separate
e-lisp-tar-ball. I think it was more or less a part of the
distribution back then.) Why was that important to me? I got all the
packages I wanted in a simple way. After all it is the e-lisp stuff
you want.
And when you have started out as beeing a user the camp you contribute
to isn't that hard to figure out.
Yours
--
%% Mats
Simon Josefsson
> Simon> You don't lose copyright on or right to the code (nothing
> Simon> can make you lose copyright on something you made, by the
> Simon> Geneva convention, I believe),
[s/Geneva/Berne/]
>
> AFAIK that depends on the national rules. I don't think the Geneva
> Convention attempts to turn the U.S., where selling your copyright has
> historically been possible, into Germany, where it is not.
>
> In any case, it is crystal clear that the FSF believes that it can buy
> copyright, lock, stock, and barrel. Given the legal conservatism they
> show, they would not add dangerously ambiguous clauses to their
> assignments if the rights thus granted were already available to
> authors.
You can't buy the "moral rights" to it. This is what would matter for
a contributor, I would think.
Quoting article 6bis from <URL:http://clea.wipo.int/lpbin/lpext.dll/clea/LipEN/46e4b/46e4c?f=file%5Bdocument.htm%5D#JD_388eb>:
[Moral Rights: 1. To claim authorship; to object to certain modifications and other derogatory actions; 2. After the author?s death; 3. Means of redress]
(1) Independently of the author's economic rights, and even after the
transfer of the said rights, the author shall have the right to
claim authorship of the work and to object to any distortion,
mutilation or other modification of, or other derogatory action in
relation to, the said work, which would be prejudicial to his
honor or reputation.
If the FSF started distributing my contributions without providing
source code (in effect violating GPL), I would have the right the
object to this according to that article, and still claim ownership of
it.
I think there is a difference between economic rights to a work and
the basic copyright (moral right) to it. You can transfer the first
but not the second.
Why doesn't ever lawyers participate in these discussions? :-)
Jerry James
<abr...@dina.kvl.dk> wrote:
> Is, in fact, possible to abandon copyright in the US? I never found
> any clause in Danish copyright law that allowed that. I have tried
> looking in US copyright law, but I find the language incomprehensible.
Have you tried putting your brain in a blender and selecting puree? I
hear that helps.
Seriously, though, Title 17 (<URL:http://www.loc.gov/copyright/title17/>)
seems to imply that abandoment is not possible. See Chapter 3, Sections
302 and 303.
--
Jerry James
"A child of five would understand this. Send someone to fetch a child
of five!" -- Groucho Marx
Glyn Millington
Glyn
--
"One does not wait for (X)Emacs to load,
one jumps up and down with excitement."
-- Henrik Enberg
Stephen J. Turnbull
Jerry> On Thu, 21 Feb 2002 at 11:49:34 +0100, Per Abrahamsen
Jerry> <abr...@dina.kvl.dk> wrote:
>> Is, in fact, possible to abandon copyright in the US? I never
>> found any clause in Danish copyright law that allowed that. I
>> have tried looking in US copyright law, but I find the language
>> incomprehensible.
Jerry> Seriously, though, Title 17
Jerry> (<URL:http://www.loc.gov/copyright/title17/>) seems to
Jerry> imply that abandoment is not possible. See Chapter 3,
Jerry> Sections 302 and 303.
Oops. "Abandon" has specific meaning in law, doesn't it. What I
meant was "transfer to the public domain." Curiously enough, I
couldn't find any reference to how a work enters the public domain,
except by expiration of copyright, in the Copyright Act.
So maybe it's not possible. However, the discussion of ways to avoid
assignment and still have your code incorporated in a GNU Project
program on www.gnu.org certainly suggest that transfer to the public
domain is possible.
This would have the effect of allowing third parties to use your code
in proprietary works.
Stephen J. Turnbull
Simon> You can't buy the "moral rights" to it. This is what would
Simon> matter for a contributor, I would think.
No. If you sell your previously GPLed work to Microsoft, and they
proceed to un-GPL it, the moral rights give you no redress.
You might, however, be able to complain that standard Windows
decorations constitute "mutilation", and prevent them from using it in
Windows. ;-)
Simon> If the FSF started distributing my contributions without
Simon> providing source code (in effect violating GPL), I would
Simon> have the right the object to this according to that
Simon> article, and still claim ownership of it.
I don't see that at all. The moral rights have nothing to do with
that. Moral rights might come into play for Larry Wall and Donald
Knuth, who might be able to say "that doesn't act like perl or TeX
(respectively), and therefore you may distribute it but not call it
`perl' or `tex'." They might come into play for Sun, who might be
able to prevent Microsoft from using the word "Java" to describe
Microsoft's bastardized version. These usages tend to cause harm to
the author's reputation and collateral damage to the reputation of
their other products, so would be covered under the "moral rights."
But the right to specify license terms for distribution of the work is
clearly an "economic right" in the law, whatever you or Richard
Stallman or anybody else may think about the moral foundation of
intellectual property. That is exactly what you transfer when you
assign the copyright.
What protects your intention from FSF malice or error is the
assignment contract and the FSF's articles of incorporation, not
copyright law itself.
Simon> Why doesn't ever lawyers participate in these discussions?
Simon> :-)
They do. Try gnu.misc.discuss, or kuro5hin, or FSB.
Glyn Millington
> Not sure if I want this to wokr or not
>
Idiocy!! Just a test after building Xemacs/Gnus. Thought I had killed
this, not sent it - many apologies.
Glyn
--
David Kastrup
> My own initial reason for contributing to XEmacs instead of Emacs
> was copyright assignment. It seemed to me to be unreasonable that I
> had assign copyright to the FSF just to have my code _distributed_
> with Emacs.
THe thing here is not distributing it with Emacs, but distributing it
as part of Emacs. The FSF wants to have copyright on the entire
Emacs it distributes, in order to be able to enforce the GPL on it.
It can't if it is the sole copyright holder.
> In essence I would become a supplicant, needing the copyright
> holder's permission (the FSF) to modify my application.
It must be noted that when you assign copyright of some code of yours
to the FSF, you get a waiver back from them that essentially allows
you to do anything with it, including generating proprietary code sold
under different licenses.
> I had no reason to believe that permission would be withheld, but
> the principle of the thing still bothered me. Thus, the only code
> of mine distributed with Emacs is stuff that I've abandoned.
As you wish.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Ljóssálfr
> In my experience focusing on the individuals in a relationship leads
> to inflooping over "he should, but ... she should, but ... he should,
> but ...". Imperative, pointer-chasing, C thinking, as it were. But
> if you make things symmetric and focus on the relationship as an
> entity, you often see that "oh, this relationship may be bad, but it's
> very stable ... let's direct our energy to something more likely to be
> adjustable to everyone's benefit." Functional, object-oriented, Lisp
> thinking.
>
> So the original way of putting it, to my mind, is more likely to
> result in useful cooperation, than trying to accurately specify the
> "problem node."
This seems like as good a place as any to interject this.
From my POV, (X)Emacs is conceptually a wonderful tool. It has
accreted ideas from many leaders in the field of computer science, and
has capabilities, such as the way it handles source code indentation,
which I have not found in any other editor. Since it is the product
of decades of development, it also contains the kinds of structure
which has been determined by experience to hinder program mainenance
and enhancement. The cannonical dogma of the day will tell us such a
program needs to be refactored, or replaced.
I find such a project to be a challenge to the open source community.
I'm no expert on refactoring. And I'm not even sure it has been
applied successfully enough times to justify the popularity of the
prectice. Nonetheless, I have a gut instinct that it is a good idea
in general. I also believe a program such as XEmacs is a wonderful
candidate for refactoring. It can server as an example to the world
that such efforts are worth undertaking. It can also serve as a
perfect example of a real world situation in which very smart people
have worked very hard together for many years to create a seemingly
(to me) intractible maze of interconnected 'components'.
Now, to get back to the subject of the forking of Emacs; I submit that
what might pass FSF mustart is a virtually rewritten XEmacs which
provides the same functionality, (and hopefully much more) but with a
far better foundational infrastructure. Perhaps such a project is
beyond the scope of what others are interested in doing. Perhaps it
would be virtually impossible to accomplish in the context of the
incremental modification process which seems to typify the recent life
of XEmacs.
I will suggest that there are many ideas, and perhaps a considerable
amount of code which could be borrowed from the Mozilla project if
XEmacs were to attempt the reinvent itself. I'm thinking specifically
of the NSPR
http://www.mozilla.org/projects/nspr/index.html, perhaps the editor
http://www.mozilla.org/editor/, and perhaps the XPcom frame work
http://www.mozilla.org/projects/xpcom/
I my mind, EXmacs has the potential for being a significant
productivity enhancement tool, but is so difficult to us that all of
its advantages are overshadowed by its faults. I have the feeling the
monolithic nature of the 'kernel' is something of an obsticle to
continued growth and imporvement for the program.
I haven't been successful in getting it to build and run, but there is
a port of Emacs to kawa. http://www.gnu.org/software/kawa/ This may
hold some insight into how the refactoring of XEmacs might proceed.
There is another editor which I find far more friendly than EXmacs,
but far less powerfull. That is JEdit. http://www.jedit.org/.
Perhaps I simply need to get some sleep and wake up with a clear head.
Any opinions?
Lucid
Christopher Browne
> Any opinions?
Have you taken a look at the body of Elisp code and tried to come up
with some metrics as to how much of _that_ would get broken by your
attempts to 'refactor' (Foo)Emacs.
The problem with modifying both GNU Emacs and XEmacs is _not_ with
those systems directly; it falls out of the fact that they are used as
engines to run a whopping huge set of Elisp code.
If you change their behaviour, this may break the applications that
people are running on top of their favorite Emacs.
Compare this to the notion of "refactoring" Microsoft Windows.
I'm sure there would be lots of interesting results in taking the code
base for Windows and "cleaning it up." The problem with that is that
there's a whole lot of code that is dependent on Windows working the
way it does now.
If you change its behaviour, other peoples' code will break.
And all you would see is another split:
-> People not using _any_ Elisp code might be happy with your
NewEmacs.
-> Some would prefer to stay with GNU Emacs, and their code that
depends on it.
-> Others would prefer to stay with XEmacs, and their code that
depends on it.
If the project does not address the "oops, I broke other peoples' .el"
issue, not only does it not "unify" anything; all it does is to build
further divisions.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/emacs.html
"Anyway I know how to not be bothered by consing on the fly."
-- Dave Moon
Adrian Aichner
<lines deleted by Adrian>
fjolsvit> I my mind, EXmacs has the potential for being a
Make that XEmacs.
fjolsvit> significant productivity enhancement tool, but is so
fjolsvit> difficult to us that all of its advantages are
fjolsvit> overshadowed by its faults. I have the feeling the
OK, we might fix all the faults right away as soon as you tell us what
they are, specifically :-)
fjolsvit> monolithic nature of the 'kernel' is something of an
fjolsvit> obsticle to continued growth and imporvement for the
fjolsvit> program.
fjolsvit> I haven't been successful in getting it to build and
fjolsvit> run, but there is a port of Emacs to kawa.
What platform have you tried building on?
What version of XEmacs have you tried to build?
Have you read
http://www.xemacs.org/Install/index.html
yet?
With kawa you are referring to following?
http://www.gnu.org/software/kawa/
fjolsvit> http://www.gnu.org/software/kawa/ This may hold some
fjolsvit> insight into how the refactoring of XEmacs might
fjolsvit> proceed. There is another editor which I find far more
Does even GNU Emacs support kawa yet?
fjolsvit> friendly than EXmacs, but far less powerfull. That is
fjolsvit> JEdit. http://www.jedit.org/.
How long have you use Emacs?
How long have you used jEdit?
fjolsvit> Perhaps I simply need to get some sleep and wake up with
fjolsvit> a clear head.
fjolsvit> Any opinions?
I have almost always woken up with a clearer head than the one it took
to bed. :-)
fjolsvit> Lucid
--
Adrian Aichner
mailto:adr...@xemacs.org
http://www.xemacs.org/
David Kastrup
> Now, to get back to the subject of the forking of Emacs; I submit
> that what might pass FSF mustart is a virtually rewritten XEmacs
> which provides the same functionality, (and hopefully much more) but
> with a far better foundational infrastructure. Perhaps such a
> project is beyond the scope of what others are interested in doing.
> Perhaps it would be virtually impossible to accomplish in the
> context of the incremental modification process which seems to
> typify the recent life of XEmacs.
I just hate a lot of keybindings and lots of other idiosyncrasies of
XEmacs, including its usual look and colors and stuff and little
differences. I assume that the reverse holds for quite a few XEmacs
users: why should things be different if people did not prefer them
that way?
So in order to reunify the engines, one would need (at least) two
personalities to place on top of that.
This is not trivial.
> Perhaps I simply need to get some sleep and wake up with a clear head.
> Any opinions?
> Lucid
If you want to be a good pacifier, get a name change. "Lucid" will
not exactly enthuse GNU Emacs hardcorists.
Adrian Aichner
David> fjol...@netscape.net (Ljóssálfr) writes:
>> Now, to get back to the subject of the forking of Emacs; I submit
>> that what might pass FSF mustart is a virtually rewritten XEmacs
>> which provides the same functionality, (and hopefully much more) but
>> with a far better foundational infrastructure. Perhaps such a
>> project is beyond the scope of what others are interested in doing.
>> Perhaps it would be virtually impossible to accomplish in the
>> context of the incremental modification process which seems to
>> typify the recent life of XEmacs.
David> I just hate a lot of keybindings and lots of other
David> idiosyncrasies of XEmacs, including its usual look and
David> colors and stuff and little differences. I assume that the
Hi David,
does this mean that you did not have to customize any keybindings and
face colors under GNU Emacs to your liking?
I hate the fact that font-lock-comment-face is RED by default under
XEmacs.
I would feel punished for every since comment I type in any language.
So I just came up with colors I like some 8 years ago.
I love my forest green comments and feel rewarded for each comment
line I type.
BUT, is GNU Emacs and XEmacs all about choice and customization?
I bet both Emacsen could have better defaults in places, but who's to
decide?
David> reverse holds for quite a few XEmacs users: why should
David> things be different if people did not prefer them that way?
I think part of the problem might be that negociating colors,
keybindings, menu item hierarchies, etc is not a very fun job to do so
nobody wants to touch this area.
I think Emacs could benefit a lot towards usability for newbies from
work in this area.
David> So in order to reunify the engines, one would need (at
David> least) two personalities to place on top of that.
David> This is not trivial.
I agree.
>> Perhaps I simply need to get some sleep and wake up with a clear head.
>> Any opinions?
>> Lucid
David> If you want to be a good pacifier, get a name change. "Lucid" will
David> not exactly enthuse GNU Emacs hardcorists.
I thought the name was Ljóssálfr.
Now, how do you pronounce that?
Adrian
David> --
David> David Kastrup, Kriemhildstr. 15, 44793 Bochum
David> Email: David....@t-online.de
Adrian Aichner
APA> BUT, is GNU Emacs and XEmacs all about choice and customization?
I did it again: I meant to write "isn't" instead of "is" above.
David Kastrup
> >>>>> "David" == David Kastrup <David....@t-online.de> writes:
>
> David> I just hate a lot of keybindings and lots of other
> David> idiosyncrasies of XEmacs, including its usual look and
> David> colors and stuff and little differences. I assume that the
>
> does this mean that you did not have to customize any keybindings
> and face colors under GNU Emacs to your liking?
Correct. I get along fine with the keybindings, and I don't fancy
angry fruit salad, anyhow. From the very few times that I have
actually demonstrated font-lock to people, I think I remember that
Emacs had more decent colours.
From the time when I tried XEmacs, I remember that I had to fight it
really hard in order to make it black on white instead of mud-on-mud,
the font sizes and choices were ugly, and so forth and so on.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Adrian Aichner
David> Adrian Aichner <adr...@xemacs.org> writes:
>> >>>>> "David" == David Kastrup <David....@t-online.de> writes:
>>
David> I just hate a lot of keybindings and lots of other
David> idiosyncrasies of XEmacs, including its usual look and
David> colors and stuff and little differences. I assume that the
>>
>> does this mean that you did not have to customize any keybindings
>> and face colors under GNU Emacs to your liking?
David> Correct. I get along fine with the keybindings, and I don't fancy
David> angry fruit salad, anyhow. From the very few times that I have
David> actually demonstrated font-lock to people, I think I remember that
David> Emacs had more decent colours.
David> From the time when I tried XEmacs, I remember that I had to
David> fight it really hard in order to make it black on white
David> instead of mud-on-mud, the font sizes and choices were
David> ugly, and so forth and so on.
Well, I don't want to spoil your genuine feelings for XEmacs, but
customizing the 'default face and not turning on font-lock seems like
all you'd need.
David Kastrup
> >>>>> "David" == David Kastrup <David....@t-online.de> writes:
>
> David> From the time when I tried XEmacs, I remember that I had to
> David> fight it really hard in order to make it black on white
> David> instead of mud-on-mud, the font sizes and choices were
> David> ugly, and so forth and so on.
>
> Well, I don't want to spoil your genuine feelings for XEmacs, but
> customizing the 'default face and not turning on font-lock seems like
> all you'd need.
This was before the time of customize. The font-lock bit was more or
less easy. Finding out in the manual that the default face was
responsible for background and foreground colors was the hard part.
In particularly since I did not know what a "face" was supposed to
be. And I remember that the manual was not going out of its way to
be helpful.
In case of doubt, I usually found the XEmacs (user and Lisp) manual
quite more taxing than its GNU Emacs counterpart. The differences in
the manuals are, of course, mostly in the areas where no
correspondence in GNU Emacs exists. On repeated occasions I have
found the XEmacs manual far too much focused on wallowing in the
greatness of technical implementation details while conveniently
forgetting about how to employ them. A total lack of any example code
did not improve the impression. Call me stupid, but stupid people
also need to work with editors, and my lack of intelligence has made
me finally turn back to GNU Emacs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Adrian Aichner
David> Adrian Aichner <adr...@xemacs.org> writes:
>> >>>>> "David" == David Kastrup <David....@t-online.de> writes:
>>
David> From the time when I tried XEmacs, I remember that I had to
David> fight it really hard in order to make it black on white
David> instead of mud-on-mud, the font sizes and choices were
David> ugly, and so forth and so on.
>>
>> Well, I don't want to spoil your genuine feelings for XEmacs, but
>> customizing the 'default face and not turning on font-lock seems like
>> all you'd need.
David> This was before the time of customize. The font-lock bit
David> was more or less easy. Finding out in the manual that the
Good.
David> default face was responsible for background and foreground
David> colors was the hard part. In particularly since I did not
I agree. I didn't know about the 'default face for a long time.
David> know what a "face" was supposed to be. And I remember that
David> the manual was not going out of its way to be helpful.
There is a hint about the default face in the XEmacs info manual today
but it leaves much to be desired.
David> In case of doubt, I usually found the XEmacs (user and
David> Lisp) manual quite more taxing than its GNU Emacs
David> counterpart. The differences in the manuals are, of
I would be thankful for any examples although I realize that you don't
have much interest in XEmacs anymore.
David> course, mostly in the areas where no correspondence in GNU
David> Emacs exists. On repeated occasions I have found the
David> XEmacs manual far too much focused on wallowing in the
David> greatness of technical implementation details while
David> conveniently forgetting about how to employ them. A total
All I can offer is to pay attention to reports from XEmacs users about
difficult or missing documentation.
I'll try to get these specific problems areas resolved if I can.
David> lack of any example code did not improve the impression.
David> Call me stupid, but stupid people also need to work with
David> editors, and my lack of intelligence has made me finally
David> turn back to GNU Emacs.
It's invaluable to the XEmacs developers to get feedback from users
reporting what they find hard to understand or undocumented.
Best regards,
Adrian
David Kastrup
> David> In case of doubt, I usually found the XEmacs (user and
> David> Lisp) manual quite more taxing than its GNU Emacs
> David> counterpart. The differences in the manuals are, of
>
> David> course, mostly in the areas where no correspondence in GNU
> David> Emacs exists. On repeated occasions I have found the
> David> XEmacs manual far too much focused on wallowing in the
> David> greatness of technical implementation details while
> David> conveniently forgetting about how to employ them. A total
> David> lack of any example code did not improve the impression.
> I would be thankful for any examples although I realize that you don't
> have much interest in XEmacs anymore.
Well, just recently I tried to understand image support in XEmacs.
Forget it. There were vague talks about specifiers and instantiators.
They cross-referenced to one another. I could not find much of an
explanation of the difference, and what they were supposed to achieve,
and what to put in what, and even examples of the syntax valid for
each. No hands-on examples for, say, getting some images displayed
were in the manual at all. It was about impossible to find out when
terms like "specifier" were supposed to refer to a certain abstract
kind of data structure (like "array" or "vector"), or to a data
structure intended to serve for a particular task.
This is just from memory, so it might be exaggerated or no longer
valid. But I don't remember having felt as utterly stupid about
something in the same way for a long time.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Ralf Fassel
| BUT, is GNU Emacs and XEmacs all about choice and customization?
Partly yes. I have emacs up and running with my favourite look& feel.
These customizations have added up over the years and I simply have
forgotten how they were done (which variable to set, which hook to
use). When using xemacs, I have to find those out again, since the
menus and customization buffers (which one is this feature on?)
sometimes don't offer ways to customize exactly _that_, and the hooks
use slighty different API's. I'm not sure whether I can use the
customizations from xemacs in emacs, since I run into the casual lisp
error, and are in danger of losing all of them.
Keeping my .emacs readable by both is another hassle.
R', satisfied so far with 19.34.
Adrian Aichner
Ralf> * Adrian Aichner <adr...@xemacs.org>
Ralf> | BUT, is GNU Emacs and XEmacs all about choice and customization?
Ralf> Partly yes. I have emacs up and running with my favourite
Ralf> look& feel. These customizations have added up over the
Ralf> years and I simply have forgotten how they were done (which
Ralf> variable to set, which hook to use). When using xemacs, I
You're not alone :-)
Ralf> have to find those out again, since the menus and
Ralf> customization buffers (which one is this feature on?)
Ralf> sometimes don't offer ways to customize exactly _that_, and
Ralf> the hooks use slighty different API's. I'm not sure whether
I can't follow. You don't have to use any menus in XEmacs if you
don't want to.
In fact to search for variables and functions I use
C-h a (hyper-apropos)
and lately
i runs the command Info-index
, runs the command Info-index-next
in info manuals for xemacs or lispref
Once you found a variable you can use
customize-variable
or
set-variable
or
(setq ...)
The choice is all yours.
Ralf> I can use the customizations from xemacs in emacs, since I
Ralf> run into the casual lisp error, and are in danger of losing
Ralf> all of them.
I can't understand the previous sentence, please rephrase.
Ralf> Keeping my .emacs readable by both is another hassle.
Well, yes, that is a hassle. But that is not the exclusive fault of
one Emacs or the other.
Ralf> R', satisfied so far with 19.34.
Is that GNU Emacs 19.34?
Whow, that's like using XEmacs 19.14, I guess.
You don't know how much fun in GNU Emacs 21.1 and XEmacs 21.1.14 you
are missing :-)
For Windows I'd recommend XEmacs 21.4, even though it's not the stable
version yet.
See
http://www.xemacs.org/Download/win32/
Best regards,
Adrian