* Re: Key bindings proposal [Was: Emacs learning curve] @ 2010-07-29 0:08 Noah Lavine 2010-07-29 11:26 ` Uday S Reddy 0 siblings, 1 reply; 6+ messages in thread From: Noah Lavine @ 2010-07-29 0:08 UTC (permalink / raw) To: u.s.reddy; +Cc: emacs-devel Hello, I am writing because I am trying to understand exactly what the keybindings proposal requires. As I understand it, this chain of events will produce an undesired result: 1. Global keymap says "C-y" -> yank 2. You map "C-z" -> yank and send "C-y" to something else 3. Gzip major mode says "C-z" -> compress and "C-y" -> gzip-special-yank At this point typing "C-z" runs 'compress' and typing "C-y" runs 'gzip-special-yank', whereas the desired result was that "C-z" would be gzip-special-yank and "C-y" would be compress, because you have indicated your preference that "C-z" be used for yank instead of "C-y". Remap would not accomplish this (at least not by itself), because there is no standard command analogous to 'compress' that gzip-mode should have remapped. However, as long as there is a command anywhere in the keymap that is analogous to yank, then "C-z" should have been mapped to that, and its keybinding moved as necessary (perhaps to "C-y"). Is this an accurate statement of the idea? Noah ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Key bindings proposal [Was: Emacs learning curve] 2010-07-29 0:08 Key bindings proposal [Was: Emacs learning curve] Noah Lavine @ 2010-07-29 11:26 ` Uday S Reddy 2010-07-29 12:21 ` Key bindings proposal joakim 0 siblings, 1 reply; 6+ messages in thread From: Uday S Reddy @ 2010-07-29 11:26 UTC (permalink / raw) To: Noah Lavine; +Cc: u.s.reddy, emacs-devel Noah Lavine writes: > I am writing because I am trying to understand exactly what the > keybindings proposal requires. As I understand it, this chain of > events will produce an undesired result: > > 1. Global keymap says "C-y" -> yank > 2. You map "C-z" -> yank and send "C-y" to something else > 3. Gzip major mode says "C-z" -> compress and "C-y" -> gzip-special-yank > > At this point typing "C-z" runs 'compress' and typing "C-y" runs > 'gzip-special-yank', whereas the desired result was that "C-z" would > be gzip-special-yank and "C-y" would be compress, because you have > indicated your preference that "C-z" be used for yank instead of > "C-y". Nice example! If the Gzip major mode (is there such a thing?) defines direct key bindings as in your line 3, then the user is stuck. He has to alter the Gzip mode map in addition to altering the global map. The remapping idea is that the Gzip major mode can remap `yank' to `gzip-special-yank' (and continue to bind "C-z" to `compress'). If it does that, there will be a conflict when its keymap is constructed. There are two competing bindings for "C-z". My proposal says that this conflict should be detected when the keymap is constructed and there should be a rule about how to resolve the conflict. If the rule says that remapped bindings should take priority, then "C-z" should get bound to `gzip-special-yank' and there won't be a key for `compress'. If the rule says that direct key bindings should take priority, then one gets the native key bindings of Gzip mode. ("C-z" -> compress and "C-y" -> gzip-special-yank). The current remap implementation in Emacs 23 doesn't detect any conflict when it constructs the keymap. However, the semantics of remap seems to have the effect that the direct key bindings take priority. (Working this out is a bit tricky. The semantics is that, when a key is pressed, if its binding happens to be `yank' then Gzip will substitute it by `gzip-special-yank'. But because of line 2, there is no key you can press in Gzip mode to get `yank'. So, you get the native bindings.) The remap semantics is a "call-by-name" feature in an otherwise call-by-value programming language, which might be confusing in itself but its effect is to give the least possible priority to remap. > Remap would not accomplish this (at least not by itself), because > there is no standard command analogous to 'compress' that gzip-mode > should have remapped. However, as long as there is a command > anywhere in the keymap that is analogous to yank, then "C-z" should > have been mapped to that, and its keybinding moved as necessary > (perhaps to "C-y"). > > Is this an accurate statement of the idea? Yes, it is close enough a description of what remap needs to do to satisfy my requirements. Except that I am not requiring that Emacs should invent a key binding for `compress' on its own! Nobody would fault Emacs if "C-z" = `compress' is a binding specific to Gzip. But they would fault it for ignoring the user's preference to bind "C-z" = yank. Cheers, Uday ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Key bindings proposal 2010-07-29 11:26 ` Uday S Reddy @ 2010-07-29 12:21 ` joakim 2010-07-29 14:16 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: joakim @ 2010-07-29 12:21 UTC (permalink / raw) To: Uday S Reddy; +Cc: Noah Lavine, emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > Noah Lavine writes: > >> I am writing because I am trying to understand exactly what the >> keybindings proposal requires. As I understand it, this chain of >> events will produce an undesired result: >> >> 1. Global keymap says "C-y" -> yank >> 2. You map "C-z" -> yank and send "C-y" to something else >> 3. Gzip major mode says "C-z" -> compress and "C-y" -> gzip-special-yank >> >> At this point typing "C-z" runs 'compress' and typing "C-y" runs >> 'gzip-special-yank', whereas the desired result was that "C-z" would >> be gzip-special-yank and "C-y" would be compress, because you have >> indicated your preference that "C-z" be used for yank instead of >> "C-y". > > Nice example! > > If the Gzip major mode (is there such a thing?) defines direct key > bindings as in your line 3, then the user is stuck. He has to alter > the Gzip mode map in addition to altering the global map. > > The remapping idea is that the Gzip major mode can remap `yank' to > `gzip-special-yank' (and continue to bind "C-z" to `compress'). If it > does that, there will be a conflict when its keymap is constructed. > There are two competing bindings for "C-z". My proposal says that > this conflict should be detected when the keymap is constructed and > there should be a rule about how to resolve the conflict. > > If the rule says that remapped bindings should take priority, then > "C-z" should get bound to `gzip-special-yank' and there won't be a > key for `compress'. > > If the rule says that direct key bindings should take priority, then > one gets the native key bindings of Gzip mode. ("C-z" -> compress and > "C-y" -> gzip-special-yank). > > The current remap implementation in Emacs 23 doesn't detect any > conflict when it constructs the keymap. However, the semantics of > remap seems to have the effect that the direct key bindings take > priority. (Working this out is a bit tricky. The semantics is that, > when a key is pressed, if its binding happens to be `yank' then Gzip > will substitute it by `gzip-special-yank'. But because of line 2, > there is no key you can press in Gzip mode to get `yank'. So, you get > the native bindings.) The remap semantics is a "call-by-name" feature > in an otherwise call-by-value programming language, which might be > confusing in itself but its effect is to give the least possible > priority to remap. > >> Remap would not accomplish this (at least not by itself), because >> there is no standard command analogous to 'compress' that gzip-mode >> should have remapped. However, as long as there is a command >> anywhere in the keymap that is analogous to yank, then "C-z" should >> have been mapped to that, and its keybinding moved as necessary >> (perhaps to "C-y"). >> >> Is this an accurate statement of the idea? > > Yes, it is close enough a description of what remap needs to do to > satisfy my requirements. Except that I am not requiring that Emacs > should invent a key binding for `compress' on its own! > > Nobody would fault Emacs if "C-z" = `compress' is a binding specific > to Gzip. But they would fault it for ignoring the user's preference > to bind "C-z" = yank. This particular sub-problem annoys me a bit as well. I offer a concrete example: - I like to bind <C-return> to other-window, because its more convenient than c-x o, and I've read that some Emacs über-hackers like this binding. <C-return> is normaly free. When I sit down at a new Emacs I just use global-set-key, because I'm too lazy to make a local .emacs. In the future I'd like to use the new package system to retrieve my favorite customizations rather than fiddling with a local .emacs - In the pristine Emacs, I wind up in an xml-mode that for some reason binds <C-return> to completion, which is very annoying. (I dont have access to this Emacs atm) Normally I find the default bindings ok, so I dont rebind too much. I bind my own stuff to the keys that are defined to be free, so I dont get much collisions. I havent delved too deeply in the Emacs event binding machinery, so what I say here might be totaly naive and uninformed, but heres some of my observations of how I'd like stuff to work: - If I bind a key globaly, I'd like to tell Emacs that thats what I want always. (my <C-return> example above) - I want global dispatch functions for certain common operations. These are "completion" and "symbol lookup". As it is now, there are all manners of different completion systems. My hope is that more of these systems will use Semantic, and the different completion systems will use Semantic as a base, and I could bind completion to a single key and have that always work as well as possible. With symbol-lookup, there appears to be even less coherence. There is C-h S that binds to info-lookup-symbol, but thats that. All other symbol-lookup functions, gtk-lookup-symbol for instance, do things differently. Again, I think Semantic should figure out the details about the symbol at point, and then dispatch to whatever sub-symbol-help system that claims to know something about the symbol. And while it would be great if more API:s could provide info documentation, that is not reasonable in a wider context. (For instance, I'm working on a "dna debug" mode that looks up the SNP symbol at point on snpedia. There are currently 13k symbols, that I'd like to look up immediately on snpedia. Converting this rapidly changing information to info format wouldnt be friendly to anyone.) > > Cheers, > Uday > -- Joakim Verona ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Key bindings proposal 2010-07-29 12:21 ` Key bindings proposal joakim @ 2010-07-29 14:16 ` Stefan Monnier 0 siblings, 0 replies; 6+ messages in thread From: Stefan Monnier @ 2010-07-29 14:16 UTC (permalink / raw) To: joakim; +Cc: Uday S Reddy, Noah Lavine, emacs-devel > - If I bind a key globaly, I'd like to tell Emacs that thats what I want > always. (my <C-return> example above) You might want to use the emulation-mode-map-alists for that, then, since global-map is the keymap with the lowest priority. > - I want global dispatch functions for certain common operations. These > are "completion" and "symbol lookup". For completion, we now have such a function/command, it's called `completion-at-point' and dispatches on `completion-at-point-functions'. For symbol-lookup we don't have it yet. Patches welcome. Note that we don't have a key binding for either (tho completion-at-point can be available on TAB by setting tab-always-indent to `complete'). Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Key bindings proposal [Was: Emacs learning curve] @ 2010-07-26 22:01 Uday S Reddy 2010-07-27 3:17 ` Stephen J. Turnbull 0 siblings, 1 reply; 6+ messages in thread From: Uday S Reddy @ 2010-07-26 22:01 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Uday S. Reddy, Teemu Likonen, emacs-devel Stephen J. Turnbull writes: > It's trivial to change key bindings. M-x local-set-key RET > <keys-to-define> <command-name> RET and Bob's your uncle. Or maybe > you want a swap-keys command that would have the UI M-x swap-keys RET > <keys1> <keys2>. I don't have that function on the top of my head, > but I'm pretty sure it requires at most three lines to express. Hi Stephen, I was going to reply to this originally saying that `local-set-key' and `global-set-key' are destructive change operations which shouldn't be taken lightly. They are kind of heavy duty hammers that are looking for nails to hit on and of course everything looks like a nail. I thought better of it because this thread had already been too long and wandering. But a post in the gnu.emacs.help newsgroup today prompted me to come back to it. The poster says: > For example now I just installed ruby-tests.el from emacswiki, which (I > saw too late) unfortunately has some "global-set-keys" with combinations > that normally I use for other things. > Is there any way to revert back to the last global state (it might be > useful also in other cases of cours)? If Emacs did take key binding customization seriously, it would have provided a whole bunch of *declarative* methods for specifying key bindings, along with rules for how they override each other or not override, as the need may be. If and when a set of key bindings needs to be installed (e.g., when a mode is entered), it would go and compile the key bindings from all the sources, detect conflicts if necessary, and install the right set. The user would be protected. The user wouldn't have to mess with mode-hooks or whatever. This is not an out-of-the-world idea. Almost all customization systems out there work this way. Instead, Emacs acts rather like a grumpy child that believes that it has the best key bindings already cased. And, local-set-key and global-set-key are like "if you really must change a key binding, well, go right ahead. Go and change all the key bindings if you want. I don't care." A totally unhelpful attitude. Yidong asked for a specific proposal if there is one. So, here is mine: Redesign Emacs so that key bindings can be designed by end users or third party customizers and exchanged with each other. It should be possible to change the entire set of key bindings in a running Emacs with the click of a button. If there are conflicts between different sets of key bindings that users import, there should be clear rules for what to do in such a case, an analysis of what goes wrong and gentle feedback given to the users. If you think that Emacs is alredy capable of doing all of this, then demonstrate it by implementing a radically different set of key bindings. Show the users how it can be done. Cheers, Uday PS: By the way, I sort of speak from experience here. I had RSI some 15 years ago and explored a whole bunch of options for how to change things, including going to Vim or Viper, using speech recognition, hand-writing etc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Key bindings proposal [Was: Emacs learning curve] 2010-07-26 22:01 Key bindings proposal [Was: Emacs learning curve] Uday S Reddy @ 2010-07-27 3:17 ` Stephen J. Turnbull 0 siblings, 0 replies; 6+ messages in thread From: Stephen J. Turnbull @ 2010-07-27 3:17 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Uday S Reddy writes: > Yidong asked for a specific proposal if there is one. So, here is > mine: This is not a specific proposal. This is waving hands over an enormous cowpie. I'm sorry, but you've managed to get pretty much all of the standard misunderstandings exhibited by the CUA-by-default advocates into a single post. I hope you don't feel too battered when I'm done debunking them. > Stephen J. Turnbull writes: > > > It's trivial to change key bindings. M-x local-set-key RET > > <keys-to-define> <command-name> RET and Bob's your uncle. Or maybe > > you want a swap-keys command that would have the UI M-x swap-keys RET > > <keys1> <keys2>. I don't have that function on the top of my head, > > but I'm pretty sure it requires at most three lines to express. > > Hi Stephen, I was going to reply to this originally saying that > `local-set-key' and `global-set-key' are destructive change operations > which shouldn't be taken lightly. In context of this thread, that's what was wanted: a permanent change (to CUA by default). I think you're missing the point, or perhaps simply don't understand how keymapping works in Emacs if you think that's an important criticism of my statement. Bringing up broken ruby-related software, well, too bad for the rubes. It's always possible to abuse flexibility, and you know that crap would never get into Emacs as is. If a safe change to the global keymap is wanted, do (defvar saved-global-keymaps nil) (push global-keymap saved-global-keymaps) (setq global-keymap (copy-keymap global-keymap)) (In practice it would be simpler than that, but this shows the most general pattern.) Yes, it would be tedious to do this for a lot of keymaps, but it could be done, and there are only about a half-dozen important ones that more or less *must* be protected. The reason Emacs doesn't do this already is that it's not useful without a concrete proposal ("concrete" is defined below). > If Emacs did take key binding customization seriously, it would have > provided a whole bunch of *declarative* methods for specifying key > bindings, along with rules for how they override each other or not > override, as the need may be. I'm flabbergasted. What do you think a keymap is, if it isn't declarative? What do you think the cascade of keymaps, inheritance, and the like is, if not a set of rules for precedence? > If and when a set of key bindings needs to be installed (e.g., when > a mode is entered), it would go and compile the key bindings from > all the sources, detect conflicts if necessary, and install the > right set. The user would be protected. If you don't think Emacs has this feature already, what's your explanation for the coexistence of CC-mode (in multiple variants!), Gnus, VM, and AUCTeX in the same Emacs process? > The user wouldn't have to mess with mode-hooks or whatever. Configurable commands are a separate problem from changing bindings of keys to commands, although obviously they are closely related in the user's experience. That is out of context (it's about [remap command] specifically, not the problem of keymap conflicts), anyway. > This is not an out-of-the-world idea. Almost all customization > systems out there work this way. What you imply here is nonsense. First, an Emacs keymap has semantics nearly identical to what you claim you want. Second, almost all customization systems deal with very sparse keymaps, which makes collisions relatively unlikely. (BTW, IME none of them work well in practice; I have yet to find a GNOME-compatible WM whose stock bindings don't conflict with some application (usually Emacs :-).) Not so for Emacs, which gave up on "keymap wall-paper" when the wallpaper exceeded the area available on the Great Wall of China, ca. 1986. Look up "whack-a-mole effect" on wikipedia. That, not poor design, is why default Emacs keymappings are hard to change. If you don't need the default bindings at all, you can go wild. Cf. Gnus or viper. > Yidong asked for a specific proposal if there is one. So, here is > mine: > > Redesign Emacs so that key bindings can be designed by end users > or third party customizers and exchanged with each other. Don't you think you really ought to learn how Emacs works before suggesting that a redesign is needed? I'm really tired of hearing that Emacs is poorly designed in this respect. Sure, I disagree with the [remap command] feature, but that's minor, micro, nano, pico. Maybe even femto. > It should be possible to change the entire set of key bindings > in a running Emacs with the click of a button. It is possible. What do you think "M-x gnus" (or "M-x viper") does? The problem is "to what?" The "concrete" part of "concrete proposal" is a request to exhibit a reasonably complete alternative keymap. Without that, the whole exercise is pointless. > If there are conflicts between different sets of key bindings > that users import, there should be clear rules for what to do > in such a case, an analysis of what goes wrong and gentle > feedback given to the users. This is not possible IMSEO. The problem is the whack-a-mole effect. You want to put something on C-x C-s, Emacs comes back with Please, be careful. The old binding to `save-buffer' is very important. If you really want to bind C-x C-s, you should put `save-buffer' on another key sequence. I can do that for you. Choose a key sequence, or type C-g for none [C-x C-# C++ u r k]: _ After getting that warning for about seven commands in succession (the suggested keysequence "C-x C-# C++ u r k" isn't very appetizing :-), the user is not going to feel gently about the process of rebinding commands. And it's about three orders of magnitude worse if you're trying to design a new keymap "for the rest of us", who are hardly a group with homogeneous requirements. Cf. also the wild popularity (not) of http://www.jwz.org/software/xkeycaps. Great program with an excellent interface, but do Gentle Newbies use it? Uh-uh. The problem is that *nothing* goes *wrong*! Keymaps, for all the discussion spent on the colors of their bikesheds, are *arbitrary* (if you start from scratch). Even arbitrary alterations to the traditional full keymap can be correct depending on the user's intent. The whole problem here is specifying what users want, not implementing a set of requirements once you've got them. Specifying the requirements here involves, at a guess, thousands of interrelated decisions. If you want them made, maybe you should get started instead of asking Emacs developers, who would rather do something else, to do it. > If you think that Emacs is alredy capable of doing all of this, > then demonstrate it by implementing a radically different set of > key bindings. Show the users how it can be done. Why should I reinvent the wheel? It's been done, multiple times. CUA, viper, Gnus, and hey, *you* are the maintainer of VM, no? *You* show them radically different keybindings, they're right there at your fingertips. If you want a permutation of the default bindings for fundamental and the other "most common" modes, no, I don't think that's my job. The people who want that should produce it. viper is a fairly good example already, I should think. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-07-29 14:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-29 0:08 Key bindings proposal [Was: Emacs learning curve] Noah Lavine 2010-07-29 11:26 ` Uday S Reddy 2010-07-29 12:21 ` Key bindings proposal joakim 2010-07-29 14:16 ` Stefan Monnier -- strict thread matches above, loose matches on Subject: below -- 2010-07-26 22:01 Key bindings proposal [Was: Emacs learning curve] Uday S Reddy 2010-07-27 3:17 ` Stephen J. Turnbull
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.