Re: Not yet: kill-whole-line = always

Summary: I have some ideas about how to go about "proper control" of UI experimentation, but this is a good start. I really really would like to see this done as Ben has suggested here: put in the bindings he suggests in sample.init.el for the release, and turn them on in the new devel branch. IMO, further UI experiments should be done thoughtfully until we work out ways to do them somewhat systematically. That is, to make it convenient for general users to try them, and just inconvenient enough to turn them off that the testers give them a good trial before deciding they're just too bogus to live with. Ben> imho we have to put a limit on the amount of contortions Ben> we're going to make to avoid changing any existing key Ben> bindings. Agreed in principle, as a single reviewer. The global keymap is too full to have room for any sacred cows. But this is a matter for the Board; it is beyond the scope of "Release Manager." Ben> it is late, though, and you have a point. This is exactly the kind of thing that the Release Manager should not be empowered to enforce (IMHO), only to oppose. Ben> sample.init.el binds it to M-k and moves kill-sentence to M-K I've suggested basically that, of course I support this. Ben> we go ahead and do the movement suggested in sample.init.el Ben> in the next development branch. I think we should do this, too. Not only (given Robert Pluim's experiment) is this plausibly a clear improvement, but given the controversy so far it is an excellent test case. That is, for using the beta series to test exactly this kind of change. Ben> not just a Kyle-type "don't you dare change that binding Ben> because i like it where it is and don't want it moved" type Ben> of What Kyle says is somewhat different. Users should not have to read NEWS just because some sysadmin has upgraded XEmacs, and the sysadmin should not be editing users' .emacs to protect them from our randomness. True, in modern Linux and even Windows environments XEmacs users are typically self-admins. But they also tend to delegate much of that job to distro maintainers---the problem has not gone away. And Linux distro maintainers are not people we want to encourage to mess with our user interface (did you follow the Mandrake fiasco, where they patched XEmacs so that XEmacs could no longer distinguish Alt and Meta at all? we don't want to encourage that kind of thing). But we do need to address the problem of UI stasis curmudgeonliness causes when taken to extremes. This is best done (to my mind) by pointing out that we should be more forceful than wimpily saying "try it, you'll like it" when we have a UI change at least a few of us believe really is an improvement. But only on the beta testers, who after all have volunteered for a certain amount of disruption in their environments. Ben> curmudgeonly response. *chuckle* You're talking to the wrong guy; the Release Manager's job (as currently set up) is precisely to be a curmudgeon. But the RM's scope for that should be strictly limited, and I think it's high time we started treating the devel branch as a place for experiments (properly controlled) in evolving the UI, not just adding to it. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."