This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 helpful.


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 protocols.


(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 static libs.


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.


Cheers,
Nicholas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]