[ITP] xemacs: A powerful, highly customizable open source text editor and application development system

[Nicholas Wourms]

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