This is the mail archive of the
mailing list for the Cygwin project.
Re: [ITP] xemacs: A powerful, highly customizable open source texteditor and application development system
Charles Wilson wrote:
Nicholas Wourms wrote:
Charles> would expect...an X-only drag-n-drop wouldn't be that
Why not? We have other X11 packages which could utilize this. Plus,
Harold's on a mission to knock the number of X11 packages sky-high, so
undoubtly we'll see many more applications which will utilize this.
XEmacs speaks the following two dragndrop dialects: CDE, and Offix. Not
the opendesktop one, nor the KDE one, nor the Gnome one. So, of
Harold's new packages, which ones support CDE or Offix style dragndrop?
None, but as I mention later on, I had heard that it supported other dnd
(Now, I believe the GTK-XEmacs build sprechen se Gnome/opendesktop
dragndrop -- but GTK-XEmacs isn't under discussion. (At least, not
until we get a glib, atk, pango, and gtk package.)
The last time I heard, Xemacs also spoke the official X11 XDnD and
Motif/Lesstif DnD protocols. Even if not fully supported yet, I'm
pretty sure there was some support for those protocols.
We can make an xemacs-extra package, but there's still the conflict
with the ctags package.
Are the source code differences mutually exclusive or is one a subset
of the other. Perhaps merging the changes into the other packages
might be the way to go? AFAIK, ctags and friends don't depend on any
emacs-specific share libs, right?
I dunno. The point is, that on Mandrake at least, these conflicting
files were moved into a separate package so that one could install both
Emacs / XEmacs / Ctags / etc. That is, if there are conflicts, minimize
and segregate them.
As I'm sure you know, RPM handles conflicts gracefully while setup
mostly does not. Therefore, this makes things more complicated on
Cygwin, since conflicting packages can actually lead to conflicting
files not being installed at all. I would *strongly* urge that we not
intentionally allow any conflicts at all (at least not at this point),
as it can lead to all sorts of problems. IIRC from the last ctags/emacs
fiasco, Corinna made her stance on conflicting ctags known: she would
have none of that. However, since these conflicts all share a similar,
albeit forked, codebase, wouldn't it be better, in the long run, if we
just merged them into a single package? Since I'm the one asking, I'll
check out the sources later on and see if this is possible. If nothing
else, I'm pretty good at merging code from forks :-).
Not necessarily, those aren't your only options. If he's using it
statically, then all that is really needed is to provide the source in
the xemacs tarball and have the build script build it. There is no
need to ITP the whole thing if all that you want is the client library
part. This is done by a couple of other packages which use external
Sure. Personally, I view that as even MORE work than just ITP'ing LDAP.
I'm curious as to why you think this is so? Surely providing a small
portion of the script for compiling, but not installing, a static
openldap client lib is going to be much easier in the long run?
Otherwise, you'd have to package the full development libraries, not to
mention the server itself, and you'd have to be willing to provide
support, as well. I'm not trying to doubt the capabilities or
motivations of Dr. Zell, but why advocate he volunteer to maintain the
entire kitchen sink when all he needs is water? If Dr. Zell actually
wants to provide and support the entire package, then more power to him.
Otherwise, I see OpenLDAP as being at least as much, if not more, of a
maintenance burden as Apache currently is. Thus, it would be much more
work in the long-run supporting it rather then building it as an
internal static client lib.