pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Steinar Bang]

Up to now, I've been using XEmacs 20.4 with Gnus and TM for news and
mail, and GNU emacs 20.2 MBSK for everything else.

But now I want to do away with TM, and switch to pgnus.

I still like the in-line features of XEmacs so if I'm stuck with using 
a single emacs I'll still use XEmacs for Gnus.

But I would like to have the option to use both.  Are there some
switches or options, that either XEmacs 20.4 or GNU emacs 20.3 can be
run with, to make them generate bytecode that the other can use? Will
they by default emit byte code that the other can use?

Or do I need to keep an XEmacs 19.16 executable around, to create byte 
code that all emacsen are able to read?


- Steinar

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Hrvoje Niksic]

Steinar Bang <sb@metis.no> writes:

> Up to now, I've been using XEmacs 20.4 with Gnus and TM for news and
> mail, and GNU emacs 20.2 MBSK for everything else.

If the question is not personal, I'd like to know why?  I could
imagine that you would do the reverse (FSF for Gnus, XEmacs for the
rest) because of the speed difference, but if XEmacs is good enough
for Gnus, why not run it for the rest of your editing tasks?  If you
have a specific problem, people at comp.emacs.xemacs and xemacs-beta
will be happy to help you.

> But I would like to have the option to use both.  Are there some
> switches or options, that either XEmacs 20.4 or GNU emacs 20.3 can
> be run with, to make them generate bytecode that the other can use?
> Will they by default emit byte code that the other can use?

You can set `byte-compile-emacs19-compatibility' to non-nil in XEmacs,
which will make it emit more or less the same code as 19.16.  However,
I wouldn't do that if I were you.  There are just too many ways to get
screwed by something like that, and your best bet is to byte-compile
separately.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Be nice to your kids.
They'll choose your nursing home.

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Alan Shutko]

>>>>> "H" == Hrvoje Niksic <hniksic@srce.hr> writes:

H> If the question is not personal, I'd like to know why?  I could
H> imagine that you would do the reverse (FSF for Gnus, XEmacs for the
H> rest) because of the speed difference, but if XEmacs is good enough
H> for Gnus, why not run it for the rest of your editing tasks?

My guess would be that he likes inline images, but for whatever
reason, doesn't like the rest of XEmacs.  For me, the large numbers of
differences between Emacs and XEmacs annoy the hell out of me and I
find my blood pressure increasing way too much... I know Emacs very
well, and would have to spend so much time learning the changes in
XEmacs that it's not worth it for me.  It's not that XEmacs has any
major flaws, but just billions of little differences.  Way too much
for me to worry about for the sake of proportional fonts and inline
images (for which I can wait until Emacs 20.5).

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
Visit beautiful Wisconsin Dells.

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Hrvoje Niksic]

Alan Shutko <ats@acm.org> writes:

> Way too much for me to worry about for the sake of proportional
> fonts and inline images (for which I can wait until Emacs 20.5).

XEmacs is much more than proportional fonts and inline images, but I
don't want to go into that.  I've just asked for Steinar to share the
reason he doesn't use XEmacs, not for speculations.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Those who like sausages, laws, and standards are well advised not
to learn how they are made.

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Steinar Bang]

>>>>> Alan Shutko <ats@acm.org>:

>>>>> "H" == Hrvoje Niksic <hniksic@srce.hr> writes:
H> If the question is not personal, I'd like to know why?  I could
H> imagine that you would do the reverse (FSF for Gnus, XEmacs for the
H> rest) because of the speed difference, but if XEmacs is good enough
H> for Gnus, why not run it for the rest of your editing tasks?

> My guess would be that he likes inline images, but for whatever
> reason, doesn't like the rest of XEmacs.

"Doesn't like" is a bit strong, but my reasoning is somewhat in this
direction, yes.

For me it was more than the inline images.  It was the fact that the
TM MIME support didn't work at all, for 20.2 MBSK.

> For me, the large numbers of differences between Emacs and XEmacs
> annoy the hell out of me and I find my blood pressure increasing way
> too much... I know Emacs very well, and would have to spend so much
> time learning the changes in XEmacs that it's not worth it for me.
> It's not that XEmacs has any major flaws, but just billions of
> little differences.

Quite so.

Most annoying for me (where I make the most mistakes), is:
 - marking for cut'n paste (it may be able to make XEmacs behave like
   GNU Emacs here, but I've never figured it out)
 - the kill ring doesn't seem to be activated after all yanks
 - The bookmarks menus are in "Edit" and not in "Search"
 - the iso-accents minor mode has a different behavior that results in 
   "e" and "n" characters being left after a C-e or a C-n in the
   wrong place, that I then have to move back to to delete
   ...

Nothing wrong exactly, but enough differences for me to be
uncomfortable in XEmacs.

But I'm more interested in making the byte code run on both
emacsen... does anybody know...? :-)

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Jan Vroonhof]

Steinar Bang <sb@metis.no> writes:

>  - marking for cut'n paste (it may be able to make XEmacs behave like
>    GNU Emacs here, but I've never figured it out)
>  - the kill ring doesn't seem to be activated after all yanks

If you mean with the mouse, checkout

http://www.math.ethz.ch/~vroonhof/emacs/fsf-mouse.el

>  - The bookmarks menus are in "Edit" and not in "Search"

(add-menu-button nil
    '("Search"		 
      ["Search..." isearch-forward]
      ["Search Backward..." isearch-backward]
      ["Replace..." query-replace]
      "----"
      ["Search (Regexp)..." isearch-forward-regexp]
      ["Search Backward (Regexp)..." isearch-backward-regexp]
      ["Replace (Regexp)..." query-replace-regexp]
      "----"
      ("Bookmarks"
       :filter bookmark-menu-filter))
    "Apps")


>  - the iso-accents minor mode has a different behavior that results in 
>    "e" and "n" characters being left after a C-e or a C-n in the
>    wrong place, that I then have to move back to to delete
>    ...

This might be a bug. Could give a recipe to reproduce. Does using the
iso-acc.el from FSF Emacs help?

> But I'm more interested in making the byte code run on both
> emacsen... does anybody know...? :-)

Hrvoje already answered that I think. You need the enable the v19
compatability variable.

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Steinar Bang]

>>>>> Jan Vroonhof <vroonhof@math.ethz.ch>:

>> But I'm more interested in making the byte code run on both
>> emacsen... does anybody know...? :-)

> Hrvoje already answered that I think. You need the enable the v19
> compatability variable.

So he did.  I never read that far.  I got caught up in the rest of the 
discussion.

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

>> But I would like to have the option to use both.  Are there some
>> switches or options, that either XEmacs 20.4 or GNU emacs 20.3 can
>> be run with, to make them generate bytecode that the other can use?
>> Will they by default emit byte code that the other can use?

> You can set `byte-compile-emacs19-compatibility' to non-nil in
> XEmacs, which will make it emit more or less the same code as 19.16.
> However, I wouldn't do that if I were you.  There are just too many
> ways to get screwed by something like that, and your best bet is to
> byte-compile separately.

Thanx for the info (even though it wasn't the news I wanted to hear)! 

Hm... does anybody know of any plans to merge the byte codes of
v. 20.x of the two emacsen, or will they diverge further?

How different are GNU emacs 20.3 and XEmacs 20.4 in this respect?
Hrvoje...?

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Alan Shutko]

>>>>> "S" == Steinar Bang <sb@metis.no> writes:

S> How different are GNU emacs 20.3 and XEmacs 20.4 in this respect?

Well, I have one bit of XEmacs 20.4 bytecode that crashes Emacs 20.3
on DUX.  8^) (I think I sent in the bug report... hmmm.)  I think the
major difference between the bytecode right now is the MULE changes
that Emacs has been going through, and we might see compatible
bytecode again when things settle down, but that's just a guess.

I'd love it, personally... not for things like Gnus and whatnot, but
for local packages we have here, so we can have one copy of the source
and byte-code in one place for all our users.

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
All's well that ends.

Re: pgnus and GNU emacs 20.3 and XEmacs 20.4 and byte-compile

[Hrvoje Niksic]

Steinar Bang <sb@metis.no> writes:

> Hm... does anybody know of any plans to merge the byte codes of
> v. 20.x of the two emacsen, or will they diverge further?

Prepare for bad news; they will certainly diverge further, and IMHO
this is a good thing.  The worst thing that can happen is this
situation of them being "almost" compatible, but in fact only screwing
up people who attempt to rely on this "compatibility".

If there were a huge difference between the bytecodes, we would at
least know where we stand.

> How different are GNU emacs 20.3 and XEmacs 20.4 in this respect?
> Hrvoje...?

Quite different.  Since the Mule bytecompiler features have been
turned on in XEmacs (20.3, I think), the bytecode XEmacs compiler
emits is more or less unreadable to GNU Emacs.  Look at the
documentation of `old-eq' to understand why.  (If you still don't
understand after reading it, mail me privately and I'll explain.)

When the actual Mule stuff is compiled in, things get even worse,
because XEmacs had implemented Mule before GNU Emacs, and Stallman
didn't follow the same compiled encoding.

However, when syncing changes with GNU Emacs, such as
`save-current-buffer', I tried to preserve the bytecode compatibility.
I don't think it will matter in the long run, though.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I luv the smell of nature in the morning.  Smells like manure!