off topic alert: XEmacs vs Emacs?

off topic alert: XEmacs vs Emacs?

[Kai Großjohann]

I think quite a few of you have lots of experience with both flavors
of Emacs.  I haven't really used XEmacs for anything, though.

When people ask about the pros and cons of each version, it is easy to
come up with nifty XEmacs features like toolbar buttons, the Motif
scroll bars, tooltips, inline images, the many preconfigured add-on
packages, and stuff.

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.  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:").

I get a vague feeling that the many packages included with XEmacs
might not be so well thought-out and thoroughly-tested.  Yet, I'm sure
that I would do injustice to XEmacs if I were to say it is less stable
or less well tested.

Thoughts?

If you feel this discussion is inappropriate in this group, feel free
to say so and I'll go elsewhere.

kai
-- 
Life is hard and then you die.

Re: off topic alert: XEmacs vs Emacs?

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>  on Tue, 20 Jul 1999
| When people ask about the pros and cons of each version, it is easy to
| come up with nifty XEmacs features like toolbar buttons, the Motif
| scroll bars, tooltips, inline images, the many preconfigured add-on
| packages, and stuff.

None of which I use; in fact, I compile XEmacs without any of them.  I
switched to XEmacs specifically because I can build it without the
"features" for which I have no use.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3lQjKgl+vIlSVSNkRAiSpAKD95tCQOTU/9kg0XuAcMNDFCoNEhQCg1/N3
1EpokCPnhdR40upfj6Xy35g=
=Cggb
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

\201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Karl Eichwalder]

(That's not a bug report, but kind of)

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

|   * Kai Gro johann <Kai.Grossjohann@CS.Uni-Dortmund.DE>  on Tue, 20 Jul 1999
--->--->--->-^^^^
Do you see the \201 here?  I do :-(((

|   None of which I use; in fact, I compile XEmacs without any of them.  I
|   switched to XEmacs specifically because I can build it without the
|   "features" for which I have no use.

I fear, I've to do the same.  Even with Emacs 20.4 the \201 "problem"
isn't solved.  Chaching an article which contains perfectly valid
encoded From lines will add spurious \201s.  Starting with --unibyte
seems to "work".  I'll update Pgnus and than do more tests.

One of the manuals (the Emacs or the Gnus manual) should have a concise
section about setting up Emacs if you want to use Gnus in the 8859
world.  Emacs has a lengthy chapter about Mule but that's not what is
needed (sorry that I've to say this).  I didn't find an section about
the modeline indicators.  Often there are two dashes (= multibyte?),
sometimes there is "-1" (= 8859-1?) but in Gnus or Message buffers I'm
seeing "-=" before the ":".

Other \201 bits are obviously "fixed" with Emacs 20.4 (e.g., umlauts in
menue entries are valid).

I'm not able to say anything about XEmacs which I never used seriously.

-- 
Karl Eichwalder

Re: \201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Kai Großjohann]

Karl Eichwalder <ke@gnu.franken.de> writes:

> [...] One of the manuals (the Emacs or the Gnus manual) should have
> a concise section about setting up Emacs if you want to use Gnus in
> the 8859 world. [...]

FWIW, I do the following:

,-----
| (set-language-environment "Latin-1")
| (setq default-input-method "german-prefix")
`-----

Of course, the second line isn't really needed.  Sometimes, I get
\201, but somehow they seem to go away after someone has changed some
package.

I think I used to get \201 in the draft groups, but hitting `D e' made
them go away, and I didn't try to investigate...

Is this From line better?  I changed from "name <address>" to "address
(name)" which seems to work better with non-ASCII characters in the
name. 

kai
-- 
Life is hard and then you die.

Re: off topic alert: XEmacs vs Emacs?

[Hrvoje Niksic]

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.  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:").
> 
> I get a vague feeling that the many packages included with XEmacs
> might not be so well thought-out and thoroughly-tested.

Have you considered actually reporting a bug?  I don't know what
"packages included with XEmacs" means to you, so I can't comment if
they are "so well thought-out and thoroughly-tested".  I do know that
the XEmacs development process is just as thorough as the FSF one.

It often happens that the FSF code is debugged before it's included in
XEmacs, or that it's simply not included because of its inferior
quality.  The reverse also happens -- bad code gets introduced to
XEmacs and it needs fixing.  But that's not an inherent fault of
XEmacs.

If you wish to try XEmacs *seriously*, try it.  If you find a bug,
report it or, better yet, try to fix it.  You have the knowledge.

> If you feel this discussion is inappropriate in this group, feel
> free to say so and I'll go elsewhere.

So.

Re: off topic alert: XEmacs vs Emacs?

[Jan Vroonhof]

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

Re: \201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Karl Eichwalder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

|   ,-----
|   | (set-language-environment "Latin-1")
|   | (setq default-input-method "german-prefix")
|   `-----

Thanks for the hint.  The explicit language environment setting isn't
needed; Emacs seems to recognize my environment.

I do see \201s only in header lines iff the article is cached -- but
before digging deeper, I'll update pgnus.

|   I think I used to get \201 in the draft groups, but hitting `D e' made
|   them go away, and I didn't try to investigate...

Isn't one \201 already too much?

|   Is this From line better?  I changed from "name <address>" to "address
|   (name)" which seems to work better with non-ASCII characters in the
|   name.

It's surely not your fault; your header line is and was valid.  If the
error will occur after updating pgnus, I'll try to write an useful bug
report.

-- 
Karl Eichwalder

Re: \201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Kai Großjohann]

Karl Eichwalder <ke@gnu.franken.de> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> |   I think I used to get \201 in the draft groups, but hitting `D e' made
> |   them go away, and I didn't try to investigate...
> 
> Isn't one \201 already too much?

Well, it was only there when looking at a message in the draft group.
And how long do you look at your messages in your draft group before
typing `D e' to continue editing them?  Like I said, the \201 went
away as soon as I typed `D e'.

kai
-- 
Life is hard and then you die.

Re: \201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Karl Eichwalder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

|   Well, it was only there when looking at a message in the draft
|   group.

I don't want to argue.

But I want to inform you that the misbehaving went away after updating
pgnus :)

-- 
Karl Eichwalder

Re: \201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Neil Crellin]

Karl Eichwalder <ke@gnu.franken.de> writes:
> I do see \201s only in header lines iff the article is cached -- but
> before digging deeper, I'll update pgnus.

Did you cache this article with a much earlier version of pgnus?
I observed exactly similar problems with cached articles, and it
turned out that the solution was to nnml-generate-nov-databases-1 for 
the corresponding cache .overview (News/cache/..../) and the \201's
went away.  Have you tried this?  It may solve your problems also.

-- 
Neil Crellin <neilc@wallaby.cc>

Re: \201s in Gnus buffers (Re: off topic alert: XEmacs vs Emacs?)

[Lars Magne Ingebrigtsen]

Karl Eichwalder <ke@gnu.franken.de> writes:

> |   * Kai Gro johann <Kai.Grossjohann@CS.Uni-Dortmund.DE>  on Tue, 20 Jul 1999
> --->--->--->-^^^^
> Do you see the \201 here?  I do :-(((

I do, too, but I didn't see that in the original article.  I saw an ß
instead.

But you're using pgnus 0.84 which is kinda old.  Try upgrading.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen