From xemacs-m  Thu Sep 11 07:43:09 1997
Received: from rattlesnake (dave@gaea.hardlink.com [199.103.249.7])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id HAA07648
	for <xemacs-beta@xemacs.org>; Thu, 11 Sep 1997 07:43:07 -0500 (CDT)
Received: (from dave@localhost)
          by rattlesnake (8.8.4/8.8.4)
	  id IAA08407; Thu, 11 Sep 1997 08:46:20 -0400
Date: Thu, 11 Sep 1997 08:46:20 -0400
Message-Id: <199709111246.IAA08407@rattlesnake>
From: David Bakhash <cadet@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: xemacs-beta@xemacs.org
Subject: menus and compatibility
X-Mailer: VM 6.22 under 19.16 XEmacs Lucid (beta90)

On my end, I'll wrap up by just expressing an opinion.

If someone is about to write a(n) X/Emacs package then it's up to them
as to the direction in which to go to make it work in emacs or
XEmacs.  Since I primarily care about XEmacs, what I would do is to
write the package solely for XEmacs, as if emacs didn't exist,
therefore making no sacrifices along the way.  Then, at some point,
where you feel that the package is pretty much done, try to either
write a separate emacs port, or try to add those 

(if xemacsp (progn ...))

things.  To me, this will be sad if lots of people end up doing this
for emacs, because then I won't benefit from them, me being an XEmacs
user.  But at least that way, XEmacs packages will be more apt to take
full advantage of the added features of XEmacs.  Anyway, since the
likelyhood of emacs' advancement is higher than XEmacs' decline, then
it's also possible that what doesn't work in emacs now may very well
in a year or two.  And who knows?  Would RMS change the API for things
like inlining glyphs?  Or menus?  probably not.

dave

