Norbert Koch writes: I think it would be best. Their upstream maintainers have asked that they not be distributed. To prevent such slips in the future you could either remove the packages (and let any future maintainers recover them from the CVS Attic), or move them into a separate tree such as obsolete-packages. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Monday 23 February 2009, Norbert Koch wrote: Thanks. FWIW, I'd be in favour of additionally 'cvs rm'ing these packages. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Monday 23 February 2009, Rodney Sparapani wrote: Nope. The way it worked for me is: assuming you already know how vc in general works, just open a svn managed file from a svn working dir and enjoy ;). "svn" probably needs to be in your $PATH. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Monday 23 February 2009, Rodney Sparapani wrote: Both correct. There's some general (quite likely at least partially outdated) vc documentation at http://www.xemacs.org/Documentation/beta/html/xemacs_17.html#SEC148 . The GNU Emacs documentation on it might be closer to what we have now: http://www.gnu.org/software/emacs/manual/html_node/emacs/Version-Control.... However, at least the XEmacs doc above doesn't seem to cover how to auto-activate vc when opening files under control of supported version control systems ("backends"). The way I've always done it is this in my ~/.xemacs/init.el: (require 'vc-hooks) Dunno where that came from, it's been there for ages, probably longer than I've even understood what it means. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ville Skyttä writes: I think that's still the sanctioned way to enable VC. Some history, in case people would like to change this: I think the -hooks.el interface came originally from the Dark Age before auto-autoloads. The idea was to have one lightweight file that you could always require in your init file without pulling in a huge pile of machinery. A lot of packages used to have a -hooks.el to intialize them from the init file. XEmacs has a policy of not changing the UI just because a library's entry points are autoloaded. You need to explicitly run a command to initialize keymaps, hooks on standard commands, auto-recognize files, and so on. Ben had partially standardized this with his concept of behaviors, but unfortunately it's not well-documented and few behaviors have been defined. AIUI a behavior is an interface which allows you to specify that certain modes should always be on. What it adds to autoloads, custom, and the older -hooks.el mechanism is (1) a standard menu interface for *globally* enabling modes, and (2) it knows how to enable the mode in *existing* buffers, so you don't have to restart XEmacs. If somebody wants to do a lot of users a medium-sized favor, you could do worse than to study up on and document behaviors. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: They can be "dropped in", but they probably can't be merged. It would be very helpful if somebody would go through the current XEmacs documentation and look for XEmacs specifics, make a list of them (in original language to avoid copyright violation), and pass that list on, either to another volunteer or as a bug report in the tracker. Then we could just go with the GFDL (much as I hate using that for software documentation, being able to merge GNU versions would be very helpful ... damn these viral licenses, they mutate like flu, and are just as hard to treat.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: Actually, that's the historical situation which we inherited probably from the Lucid days. No, I don't think anybody did that much thinking about it. ;-) It's there because nobody has moved it. At this point, I think what should be done is to carve out the GNU VC-specific nodes from GNU's manuals, and install them as a GFDL module in our VC package[1], and the VC nodes (which are now rather inaccurate) removed from the XEmacs User Guide. It might be a good idea to have a package documentation menu in the XEmacs User Guide, with a prominent caveat that if you don't have the package installed the nodes won't exist. Footnotes: [1] This is not a license violation because it's "mere aggregation". However, it does mean that we can't copy docstrings from the code into the manual without the permission of the author. Annoying, but it's not that hard to just rewrite them. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta