Mats Lidell writes: Great! I'm a non-fan of the function (I agree with I think it was Drew Adams), but since it's now a central feature of GNU, it's very good to have. People will expect it. The right place to put it is in a user theme. We just don't really have them yet. ;-) In the meantime, why not put it on C-l? It's mostly backward compatible, no? Of course there will be howls of protest, but mostly from people who know how to rebind keys. If they don't die down in a few months, we can switch back. My idea about user themes is that each version's UI changes would be added as a (cascading, like CSS) user theme, overlaid over the previous version's defaults (as amended by experience). Users who really dislike the whole new look can just disable the whole 'ui-improvements'[sic] theme; users who aren't quite sure what it is that they don't like know where to look for documentation. By "as amended by experience" I mean that the default would be to move the previous version's ui-improvements theme into the core, but if people really didn't like them, we could either back them out completely, put the right answer into core if that's really clear now, or try a "better idea" we're not 100% sure of in the new release's ui-improvements theme. That's the program, yes. However, this is a delicate matter. The basic idea is a good one, and what Steve B and I suppose Mike S had in mind in the first place. In fact, my long-run dream is to turn XEmacs into Xet, the "XEmacs editing toolkit, and what we now think of as "core XEmacs" into a sample implementation of an editor on top of Xet. (Steve B I can testify to, we talked a lot about this. Mike can speak for himself, but if as the editor of R6RS he put "call/cc" into the "base library" I think he might agree. ;-) The advantages to putting stuff in packages are (1) Packages can have a different development cycle from core, appropriate to their levels of maturity. (2) Users can pick and choose from various implementations of a given feature. (3) People interested in a given implementation of a feature can focus on it more closely. (4) A package system including a public repository of packages may make refactoring easier, so that high level packages can share implementations maintained in low-level packages. The disadvantages of packages are (1) Putting things in packages constrains API changes in both core and the packages. Especially if various packages and core have different maintainer teams. (2) Users can get confused by, or unable to find, multiple implementations of features maintained outside of core. (3) People working in a separate team will tend to focus on that, to some extent excluding work on core and other packages they have relevant expertise for. (4) Coordinating among interdependent packages will increase communication cost and decrease coding fun. In case it isn't already clear, each advantage of packages brings with it a corresponding disadvantage. Over the past two decades, it has become clear to me that the balance to be chosen is a very personal matter. In fact, most developers I've worked with don't have a systematic preference. Rather, if they're working on something that seems to require changes in core APIs, they want it in core. If they're happy with the core APIs, they want to be left alone to do their work without interference from well-meaning passers-by (ie, they want to be factored out, and a package will do the trick). My take on all this is that Mercurial is a usable VCS, and as the Pythonistas say (in a different context) "it's easier to ask for forgiveness than permission". We're a pretty small group, and even though some of us (at least me ;-) can be fractious about process, I don't think there's anybody who is opposed in principle to experimentation on trunk. (The only major exception I can think of is that everybody else hurts when Ben lands a megapatch, but he hasn't done that since we changed VCSes from CVS to hg. I don't expect it to do more than reduce the pain; we won't know how much until/unless Ben comes back.) I would like to do something about allowing users to more easily rollback UI changes they don't like, but we don't have the infrastructure for that yet. There was some work done on themes, but nobody really carried through on them, unfortunately. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: Not necessarily in core. You can put it in a package, add a trivial mode that just swaps recenter-top-bottom and recent in the global keymap. Or a trivial install command that permanently installs recenter-top-bottom. Or even change the keymap on loading the library. This scheme isn't perfect (especially because it doesn't scale, at least not without careful thought by each person who makes such a change), which is why I want a better theme infrastructure. But it will do for now as long as not too many similar changes are being made. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: If this depends on XEmacs core functionality not in 21.4, put it in core, next to `recenter' -- that's easiest. But if you're bringing all needed functionality over from GNU anyway, and it's usable in XEmacs 21.4, then it should probably go in xemacs-base (not xemacs-devel). I would suggest a file named ui-21-5.el. Give it a comment saying it was introduced in the *next* beta, ie, 21.5.33. Please, no. :-) I don't see why this need be so, at least not in this case. The basic functionality doesn't change. So document the command and the change in keybinding, and you're done, no? The TUTORIAL doesn't even need to change, as the -top-bottom functionality can be considered "advanced" (at least more so than just recenter). If we put UI improvements being tested into packages, I think the right thing to do is to update the XEmacs User Guide (xemacs.info) and the English TUTORIAL (and Swedish, if you like :-) to point to the documentation for the ui-x.y.z libraries, saying that if you have a beta version of XEmacs, the most recent such library contains UI improvements being tested. This isn't a problem, as far as I can see. XEmacs itself is now GPLv3. (If RMS wants to complain that XEmacs 21.4 is the stable version, we just do an immediate public release of 21.6 with whatever code we have and he has to shut up -- there are plenty of old versions of Emacs under v2 kicking around, even on gnu.org sites.) The fact that XEmacs 21.4 is GPLv2 doesn't prevent users from using GPLv3 code with it, or us from supporting 21.4 while distributing GPLv3 code in a different distribution. We can even add recenter-top-bottom to 21.4 (in private copies). The GPL only prevents us (and anyone else) from *redistributing that version*. The (potential) problem we used to have was that people could say that since we didn't distribute a GPLv3 XEmacs at all, the separation of packages from XEmacs was just a device to get GPLv3 code into the "real" XEmacs = GPLv2 core + GPLv3 packages. That's a no-no. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta