Ben> -- remove kill-whole-line = always. Do you mean just the value, or the whole variable? I have a slight preference for having the variable go away and use a different function to get the behavior change (it looks like that is what you're proposing, since k-w-l doesn't seem to be fboundp), but that is personal opinion only. Ben> -- C-k continues as "kill to end of line". Ben> -- define M-k as kill-whole-line. Ben> -- move the current, vastly underused, This is false, again speaking personally only. I use that binding heavily (in fact, that and the sexp movement commands are the only ones I use enough to have learned to always use the Meta key for if it's available; others meta bindings I often use ESC <key> still). This is a very common gesture when editing text for me, more so than C-k, actually. Ben> binding of M-k (kill-sentence) to M-shift-k. this is still Ben> usable under tty's, as well. I don't have a problem with that as default (I'll just change it back in .emacs), but I suspect you will find that in general people who spend more time editing TeX than they do Lisp will be upset. If, as I suspect, this is Windows-centric thinking, you should at least add it to the when-running-ms-windows part of sample.emacs. We need EmacsKeyCaps.el, or at least `swap-bindings' (with a custom interface)! -- 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."

Daniel Pittman wrote: broadly used? -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

no this is not windows-centric thinking. it's just that a command to simply delete the entire line is far more useful than C-k = kill to end of line. It's especially useful in cutting blocks of lines and moving them -- just kill-whole-line repeatedly until you get your lines cut, then move and paste, voila! However, C-k to kill to end is also useful, so in the current about-to-be-released scheme, C-shift-k [should be M-shift-k for tty compliance] does "historical-kill-line" i.e. kill-line ignoring the kill-whole-line variable [remember it has another value of 't' which kills the whole line but only at the beginning], and you can set kill-whole-line = always to get C-k to just kill the damn line. Every other editor on earth has a "kill whole line" command -- including vi. those tex users are going to be a small minority of xemacs users. changing key bindings inevitably upsets someone. rather than do this, i tried to get around it with another setting, which is just a mess -- even more people who have to set a non-default to get useful behavior, etc. this new scheme is clean, works well by default, no more messy variables, and i think it will make many more people happy than annoyed, and those who are annoyed can either just learn the new keystroke or fix it trivially -- i'll even provide a menu option for this. "Stephen J. Turnbull" wrote: -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

I think changing the behaviour of C-k itself is bad - its too fundamental to emacs users. andy At 04:04 AM 2/22/01 -0700, Ben Wing wrote:

I think we've seen enough anti to insist that the two main bindings (C-k and M-k) not change in the release. I strongly encourage somebody to put it in sample.emacs for the release. Matthew> Seems natural to me. Why change it? Because the other way seems natural to other people, obviously. I don't think there's any way to see which is better except to try it. That's not good enough for the upcoming release, but I will support trying it for a while in the devel series. I think we should do more messing with the UI early in the devel series. This has two positive effects, IMHO. (1) People are forced to try things that seem unnatural to them. Note that the only person who has actually tried the experiment decided he likes "kill-whole-line = always"! (2) People who still hate all the changes will have an incentive to develop the keyboard customize interface we've been talking about for years. Bu-wha-ha-ha-ha! -- 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."

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

-- "David S. Harrison" <dsh(a)Magma-DA.COM&gt; spake thusly: The "little bit of e-lisp" required to do this is: (setq kill-whole-line t) And I agree that this should be the default. But then, I think about half of the customizations I've made should be the default (including binding ctrl-z to `undo' and moving `suspend-emacs' to ctrl-x, ctrl-z).

Ben Wing <ben(a)666.com&gt; writes: I use M-k all the time, as do other people who are used to moving by sentences. I must admit that I don't like this change. :-(

FWIW, I use it as "kill to the end of the line" all the time. I do a large amount of text editing and writing, as well as programming. When I want to kill the entire line instead of to the end of the line, I just C-A before C-K. Just piping up because I don't see a lot of people stating that they use the "kill to end of line" very much. I'm perfectly content with the behavior being controlled by a variable, I'm also content with adding keybindings. I'm not too keen on changing a current keybinding, but I'm not totally opposed to the idea, I'll just have to teach my fingers to do things differently. -- Gary F. ----- Original Message ----- From: "Robert Pluim" <rpluim(a)bigfoot.com&gt; To: "XEmacs beta list" <xemacs-beta(a)xemacs.org&gt; Sent: Thursday, February 22, 2001 5:39 AM Subject: Re: kill-whole-line = always realized what i you releasing to

Matt Tucker <tuck(a)whistlingfish.net&gt; writes: He also wants to change M-k to mean `kill-whole-line' rather than "vastly underused" kill-sentence. kill-sentence might be vastly underused by novice users, but many experienced users move through text sentence by sentence, and find kill-sentence very natural. Also, the `always' thing is actually a good feature, one I agreed with when Ben introduced it. I planned to try to set `kill-whole-line' to `always' and give it a spin.

Ok by me. andy At 02:02 AM 2/22/01 -0700, Ben Wing wrote:

Ben Wing <ben(a)666.com&gt; writes: Please don't proceed with it. The assertion that M-k is not used is untested. I think it's silly to retain M-a and M-e which move across sentences, but get rid of M-k which deletes a sentence. Then let's bind that to C-k. Which happens anyway when you set kill-whole-line to always. What exactly is wrong with that?