Re: off topic alert: XEmacs vs Emacs?

[Jan Vroonhof <vroonhof@math.ethz.ch>]

Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> On the other hand, I see that XEmacs behaves in, err, /unexpected/
> ways.  Two anecdotical examples: loading del-bs.el (or similar) does
> what one expect, *except* in Lisp Interaction mode.

In 21.1.x delbs.el consists of the following

===
(provide 'delbs)

(message "Use the variable `delete-key-deletes-forward' instead of delbs")
(sit-for 5)
===

delete-key-deletes-forward works in lisp-interaction-mode of course.

> Hm.  rcp.el doesn't work together with EFS because EFS expects to be
> the only remote-file handling package used (well, the only one which
> uses file names beginning with "/foo:").

The same holds for ange-ftp isn't it? It is just that you
  a. haven't implemented all the file-handler method's XEmacs use.
  b. can control the loading ange-ftp a bit better.

Why don't you simply use a syntax that _is_ unique?

/rsh|.. comes to mind.

Yes the remote file name syntax could have been designed better to allow 
for extension to other protocols, but that is historical baggage and
hardly XEmacs's fault.

> I get a vague feeling that the many packages included with XEmacs
> might not be so well thought-out and thoroughly-tested.

May be. In fact I am sure that are some packages that are
under tested. 

However my (biased) opinion is that those two particular
examples you mentioned EFS and the BS/DEL are solved _better_ under
XEmacs.

On the other hand, we just got a bug report that info.el doesn't
defvar it's hooks. That is also true for the FSF version. That is an 8 
year old bug!

> Yet, I'm sure that I would do injustice to XEmacs if I were to say
> it is less stable or less well tested.

Indeed :-).  

> Thoughts?

I am afraid you (in the rsh.el case) are simply being hit by one of those
annoying elisp compatibilities, made worse by an unfortunate choice of 
syntax for your remote files.

In fact if you were developing under XEmacs yourself you would
probably complain too but the other way round:

Why doesn't FSF Emacs
  1. Come with AucTeX
  2. Have add-minor-mode, define-error
  3. Preserve author version history when elisp has been bundled.
  4. Dump cl'el. 

etc etc. To name a few points where IMNSHO XEmacs is clearly better
elisp wise. I can also name a few points where FSF is clearly
better. But is doesn't matter. The fact is that there are two major
Emacsen and that has apart from benefits also problems. The good thing
is that on a lot of fronts cooperation has been good recently:
easy-menu synchronisation is a good example, my new custom themes
stuff has a good chance of being synced up in both versions etc. Which
is good, most of the incompatibilities are completely unnecessary, and
can be prevented with a bit of coordination.

Jan