* Key bindings proposal [Was: Emacs learning curve] @ 2010-07-26 22:01 Uday S Reddy 2010-07-27 3:17 ` Stephen J. Turnbull 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier 0 siblings, 2 replies; 277+ 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] 277+ 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 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier 1 sibling, 0 replies; 277+ 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] 277+ messages in thread
* Re: Key bindings proposal 2010-07-26 22:01 Key bindings proposal [Was: Emacs learning curve] Uday S Reddy 2010-07-27 3:17 ` Stephen J. Turnbull @ 2010-07-27 10:32 ` Stefan Monnier 2010-07-27 11:30 ` Eric M. Ludlam ` (3 more replies) 1 sibling, 4 replies; 277+ messages in thread From: Stefan Monnier @ 2010-07-27 10:32 UTC (permalink / raw) To: Uday S Reddy; +Cc: Stephen J. Turnbull, Teemu Likonen, emacs-devel > 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 understand what you want. But, I'm not 100% sure what a good solution would look like, and I'm even less clear on how we could get to such a solution starting from Emacs's current system. The main problem is not whether the method is declarative or not, but rather the problem is to make intentions clear. The issue with "intentions" is typically along the lines of "do you want to bind `foo' to C-x C-x or do you want to bind it to the C-x key within the main prefix keymap, or do you want to bind it to the repetition of the key-sequence to which this main keymap is bound, or maybe only to the repetition of just the last key in this key-sequence, or maybe to the repetition of C-"the key above my "alt" key, or maybe you want to bind it to whichever key `foobar' is bound in such-and-such-mode, ..." If all Emacs packages could replace their `define-key' calls by others that make the intentions clear, then it would be a lot easier/cleaner to redefine key-bindings. But if you look at the average quality of Elisp code, you'll quickly learn that most authors have much better things to do than to worry about such problems (i.e. their main worry is to get it to work for the very specific Emacs they're currently using, with their current .emacs). Using `remap' is one way to express such an intention. I would welcome patches that try to make intentions more clear (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the place) and have myself replaced bindings to TAB and to M-q many times by settings of indent-line-function and fill-paragraph-functions. We can keep improving in that direction, but the important part is that such changes should be made in such a way that it's easy for coder to follow the new style (ideally: easier than using the old inflexible style). > it would go and compile the key bindings from all the sources, detect > conflicts if necessary, and install the right set. That's yet more difficult. It means that the author and/or the user needs to explicitly indicate when something should take precedence over something else, and when not. In most cases I know of, this tends to be too heavy to use and instead the system is designed to use a default precedence scheme (witness the "use first matching pattern" rule in ML-style or Prolog pattern matching). So I'd expect "conflict detection" to come with a lot of user complaints (already we have occasional bug-reports about the errors signaled by define-key when you define a binding for C-a C-b when C-a is already bound to a command). Stefan ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier @ 2010-07-27 11:30 ` Eric M. Ludlam 2010-07-27 11:32 ` Stephen J. Turnbull ` (2 subsequent siblings) 3 siblings, 0 replies; 277+ messages in thread From: Eric M. Ludlam @ 2010-07-27 11:30 UTC (permalink / raw) To: emacs-devel On 07/27/2010 06:32 AM, Stefan Monnier wrote: >> 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 understand what you want. But, I'm not 100% sure what a good solution > would look like, and I'm even less clear on how we could get to such > a solution starting from Emacs's current system. > > The main problem is not whether the method is declarative or not, but > rather the problem is to make intentions clear. > > The issue with "intentions" is typically along the lines of "do you want > to bind `foo' to C-x C-x or do you want to bind it to the C-x key within > the main prefix keymap, or do you want to bind it to the repetition of > the key-sequence to which this main keymap is bound, or maybe only to > the repetition of just the last key in this key-sequence, or maybe to > the repetition of C-"the key above my "alt" key, or maybe you want to > bind it to whichever key `foobar' is bound in such-and-such-mode, ..." Hi, While it may not cover the gamut of possible keybinding remapping, one way to express intention is to make all the commands that get bound into global maps be overridable in some way. Some commands like beginning/end of line have this feature already. Modes of all sorts would then override the behavior they want to change instead of binding their custom functions to keys. This would then make it much easier to just move all the Emacs core commands around while allowing the modes to follow easily. Using something like mode-local.el is one way to do this in a declarative way which I used extensively in CEDET. Eric ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier 2010-07-27 11:30 ` Eric M. Ludlam @ 2010-07-27 11:32 ` Stephen J. Turnbull 2010-07-27 12:03 ` Stefan Monnier 2010-07-29 15:28 ` Uday S Reddy 2010-07-30 2:04 ` coding guidelines? (was Re: Key bindings proposal) Joe Brenner 3 siblings, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-07-27 11:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: Uday S Reddy, Teemu Likonen, emacs-devel Stefan Monnier writes: > The issue with "intentions" is typically along the lines of "do you want > to bind `foo' to C-x C-x or do you want to bind it to the C-x key within > the main prefix keymap, or do you want to bind it to the repetition of > the key-sequence to which this main keymap is bound, or maybe only to > the repetition of just the last key in this key-sequence, or maybe to > the repetition of C-"the key above my "alt" key, or maybe you want to > bind it to whichever key `foobar' is bound in such-and-such-mode, > ..." In most cases the intention is "bind it to a short sequence I personally don't use otherwise, and otherwise arbitrary," I would expect. > Using `remap' is one way to express such an intention. Not really. Remap is about deprecating a command, not really about key sequence choice. People who are worried about mapping issues define whole keymaps (viz Miles's caps-lock-mode, with *one* binding in it). People who aren't, don't. The question here is whether you're willing to make life painful for people who don't pay attention to keymaps *as maps* to force them to pay attention to keymaps: > I would welcome patches that try to make intentions more clear > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over > the place) Heh. Just make define-key error on any keysequence with a prefix bound to a keymap, unless there's a nonnil FORCE argument. Alternatively, you could have define-key normally recurse into keymaps the way lookup-key and *-key-binding do, unless there's a non-nil FORCE argument. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 11:32 ` Stephen J. Turnbull @ 2010-07-27 12:03 ` Stefan Monnier 2010-07-27 16:41 ` Uday S Reddy 2010-07-27 16:41 ` Stephen J. Turnbull 0 siblings, 2 replies; 277+ messages in thread From: Stefan Monnier @ 2010-07-27 12:03 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Uday S Reddy, Teemu Likonen, emacs-devel > In most cases the intention is "bind it to a short sequence > I personally don't use otherwise, and otherwise arbitrary," > I would expect. Indeed, that's how it's been used, and it works OK for such uses. >> Using `remap' is one way to express such an intention. > Not really. Remap is about deprecating a command, not really about > key sequence choice. Not at all. `remap' is typically not used by the user in his .emacs but by major/minor modes to locally/temporarily replace particular commands by other ones (and to do so in a declarative way ;-), so that if the user (or some other mode) has rebound this command elsewhere, the remapping still works as intended. Before that, packages used substitute-key-definition for that purpose, but that was not as declarative and it only adapted to changes in global bindings. Stefan ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 12:03 ` Stefan Monnier @ 2010-07-27 16:41 ` Uday S Reddy 2010-07-27 23:32 ` Miles Bader 2010-07-27 16:41 ` Stephen J. Turnbull 1 sibling, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-07-27 16:41 UTC (permalink / raw) To: Stefan Monnier Cc: Uday S Reddy, Teemu Likonen, Stephen J. Turnbull, emacs-devel Stefan Monnier writes: > Not at all. `remap' is typically not used by the user in his .emacs but > by major/minor modes to locally/temporarily replace particular commands > by other ones (and to do so in a declarative way ;-), so that if the > user (or some other mode) has rebound this command elsewhere, the > remapping still works as intended. Before that, packages used > substitute-key-definition for that purpose, but that was not as > declarative and it only adapted to changes in global bindings. Indeed. Not only is it declarative, but it is also object-oriented (or "subtyped" or "conformant"). When you bind [remap undo] to a mode-specific undo operation, you are inheriting the key binding made for undo somewhere else. At least for this operation, you are conforming to some global theme that has been established for the user. The world outside Emacs is heavily object-oriented. And, that has brought a tremendous amount of order to the world of user interfaces. We take it for granted that every application will have a suitable implementation for generic operations like "open", "close", "refresh" and "help". Unfortunately, all of this civilizational progress is passing Emacs by. Just a few weeks ago, somebody here was bemoaning how the inconsistency of "refresh" in Emacs modes drives him nuts. However, I think we can do better than remap. remap allows ad-hoc inheritance to grow up in fits and sneezes wherever it feels like. It is not proper subtyping. Oscar Fuentes had a proposal here on 7/17 which I am drawn to: > I possible solution for this problem is to use `actions'. An action is a > generic concept like `fordward-line', or `undo', or `save', or `yank' > (`paste', if you prefer.) `universal-argument', > `execute-extended-command' and `C-x' (whatever is officially called on > Emacs jargon) would be actions as well. > > Currently a mode defines its keymap relating keys to functions. An > action-aware mode relates actions to functions. At a higher level, there > is a mapping of keys into actions. When a mode is activated for a > buffer, the keymap is constructed looking up the corresponding keys > assigned to the actions the mode implements. A mode inherits the > key->action mapping from its parent mode, but can define its own actions > that overrides its parent's. It seems to me that these "actions" are a form of abstract operations. The actions implemented by a mode can be regarded as its interface. Some of these actions might have globally defined key bindings, some might be local, and some might have no key bindings. It might be possible to invoke actions with the M-x prefix or something like it. Emacs would immediately feel a lot more object-oriented than it currently does. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 16:41 ` Uday S Reddy @ 2010-07-27 23:32 ` Miles Bader 2010-07-29 14:05 ` Stefan Monnier 0 siblings, 1 reply; 277+ messages in thread From: Miles Bader @ 2010-07-27 23:32 UTC (permalink / raw) To: emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > It seems to me that these "actions" are a form of abstract operations. > The actions implemented by a mode can be regarded as its interface. I think it's a good idea (and have advocated it before), but no, it won't solve the problem of re-skinning. It would be nice for bringing a bit of order to commonly used operations, treated as singular events, but it does not do anything for uncommon operations -- which are probably the _majority_ of bindings in emacs (as opposed to simple editors like notepad) -- nor does it offer any help in avoiding conflicts (the "whack-a-mole problem" as someone in this thread so aptly put it) or preserving patterns which are an important feature of Emacs' current bindings or [e.g. the "n/f type bindings go forward", etc]. The thing is, so far everybody advocating "binding change" has been waving their hands, making vague feel-good statements, trotting out buzzwords, etc -- but to _really_ do it, somebody has to sit down and actually work out the painful details of how to handle the problems. Hand-waving and buzzwords aren't enough. -Miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 23:32 ` Miles Bader @ 2010-07-29 14:05 ` Stefan Monnier 0 siblings, 0 replies; 277+ messages in thread From: Stefan Monnier @ 2010-07-29 14:05 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel >> It seems to me that these "actions" are a form of abstract operations. >> The actions implemented by a mode can be regarded as its interface. > I think it's a good idea (and have advocated it before), Yes, although we already do have something similar: - the function-key-map can be used to map <key-sequence> to <logical-key>, where logical key is similar to <action>. It is not used much in this way (mostly for TAB and DEL and a handful more at best). - the key remapping (where the remapped command acts as the <action> as well as its default binding). - things like fill-paragraph-function, line-indent-function, ... The last one is usually the most effective (since it can affect several related bindings at the same time, and do it in the right way). > but no, it won't solve the problem of re-skinning. Indeed. > problem" as someone in this thread so aptly put it) or preserving > patterns which are an important feature of Emacs' current bindings or > [e.g. the "n/f type bindings go forward", etc]. For these, I think it would be good to be able to have "(de?)composed bindings", where you could bind `n' and `f' to some special keymap-like thingies and then therein bind C-, M-, and M-C- to other special thingies. The intention would be to reflect the structure directly into the keymap. This would apply to several other cases. Stefan ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 12:03 ` Stefan Monnier 2010-07-27 16:41 ` Uday S Reddy @ 2010-07-27 16:41 ` Stephen J. Turnbull 2010-07-27 17:52 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-07-27 16:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: Uday S Reddy, Teemu Likonen, emacs-devel Stefan Monnier writes: > >> Using `remap' is one way to express such an intention. > > Not really. Remap is about deprecating a command, not really about > > key sequence choice. > > Not at all. `remap' is typically not used by the user in his .emacs but > by major/minor modes to locally/temporarily replace particular commands > by other ones So what? Presumably there is some mnemonic relationship between the old command and the new one, otherwise it would make more sense to choose a mnemonic key sequence and not use remap. Ie, it's about the commands, not the keys. I don't see how this use of remap helps Uday or the CUA-should-be-default crowd, since much of the time no such relationship applies. For example, `forward-sexp' is hardly useful in VM Summary mode, but that doesn't mean that (define-key vm-summary-map [remap 'forward-sexp] #'vm-summary-next) makes any sense whatsoever. (define-key vm-summary-map [remap next-line] #'vm-summary-next) does make sense to me, but guess what? #'next-line is a useful command in VM Summary mode, even if much less useful than it is in most modes. So I'd be very bummed if Uday used [remap] instead of an explicit keystroke binding there. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 16:41 ` Stephen J. Turnbull @ 2010-07-27 17:52 ` Uday S Reddy 2010-07-28 5:57 ` Stephen J. Turnbull 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-07-27 17:52 UTC (permalink / raw) To: Stephen J. Turnbull Cc: Uday S Reddy, Teemu Likonen, Stefan Monnier, emacs-devel Stephen J. Turnbull writes: > I don't see how this use of remap helps Uday or the > CUA-should-be-default crowd, since much of the time no such > relationship applies. This is not a solution to the broad problem I posed. I shouldn't pretend that it is. But it helps partially in the following sense. The irritation for the user is that it is not enough to just rebind keys at the global level, but he/she must go and rebind them for every mode. The latter is hard, and one needs to be reasonably expert at the innards of Emacs to do it correctly. The remap idea helps in that the modes can piggy back on the global bindings at least to some extent. But the applicability is limited. I was just looking at dired-mode, which seems to have some 100 odd key-bindings, but only 2 remap's. Not much of a win. To catch the majority of the other generic bindings, something like the "action" idea seems necessary. > (define-key vm-summary-map [remap next-line] #'vm-summary-next) > > does make sense to me, but guess what? #'next-line is a useful > command in VM Summary mode, even if much less useful than it is in > most modes. So I'd be very bummed if Uday used [remap] instead of an > explicit keystroke binding there. You are right. But, if there were action-based bindings, I could do: (define-key vm-summary-map [action quick-next-line] #'vm-summary-next) and the quick-next-line action might be bound to the key `n' (or `C-n' or `M-n' or whatever else the user might wish). Gnus, Dired, buff-menu and a host of other modes that need "quick" actions could all share their key bindings without having to do anything. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 17:52 ` Uday S Reddy @ 2010-07-28 5:57 ` Stephen J. Turnbull 2010-07-28 18:32 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-07-28 5:57 UTC (permalink / raw) To: Uday S Reddy; +Cc: Teemu Likonen, Stefan Monnier, emacs-devel Uday S Reddy writes: > Stephen J. Turnbull writes: > > > I don't see how this use of remap helps Uday or the > > CUA-should-be-default crowd, since much of the time no such > > relationship applies. > > This is not a solution to the broad problem I posed. I shouldn't > pretend that it is. But it helps partially in the following sense. > > The irritation for the user is that it is not enough to just rebind > keys at the global level, but he/she must go and rebind them for every > mode. IME, users just don't do this, or want to do it; I really don't understand what you're talking about. Please be more specific about the use cases. In any case, your claim is mostly false for the keys where any of the redesign vaporware could apply. In most modes, the mode keymap is sparse; most of the shared bindings like self-insert-command, movement commands, file opening commands, and buffer-switching commands are *inherited* from the global map. They don't need to be changed. Most of the remaining bindings are very specialized; it's likely that any replacements will also be idiosyncratic. IOW, remap only helps if the user (or a minor mode) is already moving the command around in the map. Sure, occasionally it's useful or perhaps necessary. But how can that be a good idea on a regular basis? > The remap idea helps in that the modes can piggy back on the global > bindings at least to some extent. They already do in a big way, of course -- at least, I'd like to say "of course", but evidently you don't know about it. :-( > But the applicability is limited. I was just looking at dired-mode, > which seems to have some 100 odd key-bindings, but only 2 remap's. > Not much of a win. To catch the majority of the other generic > bindings, something like the "action" idea seems necessary. Sure, but we already have a concept of `action' (ie, a symbol denoting a function): most Emacs commands follow this pattern. Most "generic" bindings are simple enough to just inherit from the global map *already*. Complex generic bindings like "fill-paragraph" and "revert-buffer" provide hooks *already* so that modes can augment or even entirely replace default implementations. > You are right. But, if there were action-based bindings, I could do: > > (define-key vm-summary-map [action quick-next-line] #'vm-summary-next) This extra indirection is *useless*; its entire functionality is already subsumed by `defun' and `remap'. You *must* defun `vm-summary-next', doing so creates no extra work. For the generic version, (defun next-line-and-operate () "Move to the next line in a buffer and operate on the line. Useful in modes that use buffer lines as a menu-like device." (interactive) ;; do something intuitive and possibly useful (next-line)) and finally in `vm-mode' or whatever (define-key ACTION-MAP [remap next-line-and-operate] #'vm-summary-next) (where ACTION-MAP might be the global map or some sort of sharable map, maybe a minor mode map would do). However, it's not at all obvious to me that this is a better idea than (defvar operate-on-line-function nil) (make-variable-buffer-local 'operate-on-line-function) (defun next-line-and-operate () (interactive) (when operate-on-line-function (funcall operate-on-line-function))) and in vm-summary.el (unless operate-on-line-function (setq operate-on-line-function #'vm-summary-recenter)) (or whatever it is that `vm-summary-next' does after `next-line'). The point is that the `operate-on-line' function can be shared among next-, previous-, and goto-line-and-operate. Possibly others (`incremental-search-and-operate-on-line', anyone?) > or `M-n' or whatever else the user might wish). Gnus, Dired, > buff-menu and a host of other modes that need "quick" actions could > all share their key bindings without having to do anything. Uh, what's a "quick action"? (I have no clue what you mean by that, except "like vm-summary-next", which leaves a host of possibilities.) Do you have a list of them? Does your list agree with those of the maintainers of Gnus, Dired, buff-menu, and a host of other maintainers? Do you all agree that you want these actions on the same keys? If you can get definition, list, and agreement with *some* modes for *some* "actions", you can get started. If you do actually make any progress, let me know; I'll port/implement [remap] in XEmacs (and SXEmacs if they don't have it yet). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-28 5:57 ` Stephen J. Turnbull @ 2010-07-28 18:32 ` Uday S Reddy 2010-07-29 5:47 ` Stephen J. Turnbull 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-07-28 18:32 UTC (permalink / raw) To: Stephen J. Turnbull Cc: Uday S Reddy, Teemu Likonen, Stefan Monnier, emacs-devel Stephen J. Turnbull writes: > IME, users just don't do this, or want to do it; I really don't > understand what you're talking about. Please be more specific about > the use cases. I refer you to Teemu Likonen's post on the July 17, especially his comment that "there's not enough abstraction on that front [the key bindings of modes". In fact, a good part of the discussion in the "Emacs learning curve" was about the difficulty of changing key bindings, why the CUA mode can't be made the default etc. At least one use case that seems to be implemented in Gnu Emacs is to bind [remap undo] in modes that need it. So, if a user binds C-z to undo, he/she gets the appropriate undo in all modes (as long as they use remap for the key). I don't know if remap helps for rebinding C-c and C-x. That seems like too hard a problem for remap. The current practice is not necessarily indicative of what the users want to do. Many of us expected the key bindings of Emacs to be customizable, tried it, found it to be too hard and gave up. Some people persist because it is really important to them. It is their exasperation that keeps this debate alive. > In any case, your claim is mostly false for the keys where any of the > redesign vaporware could apply. In most modes, the mode keymap is > sparse; most of the shared bindings like self-insert-command, movement > commands, file opening commands, and buffer-switching commands are > *inherited* from the global map. They don't need to be changed. It might have been Barbara Liskov that said that the inheritance of implementation is not all that interesting, but the inheritance of interface is the interesting one. A have heard the comment from a lot of other people too. So, let us take inheritance of implementation for granted. There is nothing in particular to be said about it. remap allows you to inherit the interface (key-binding) and plug in a new implementation. > Most of the remaining bindings are very specialized; it's likely > that any replacements will also be idiosyncratic. IOW, remap only > helps if the user (or a minor mode) is already moving the command > around in the map. Sure, occasionally it's useful or perhaps > necessary. But how can that be a good idea on a regular basis? It is most helpful for people who want to move commands around the map, and they might want to do it on a regular basis. But I am proposing that "actions" should also be usable with the M-x prefix (or some similar prefix, since people will complain if the semantics of M-x is changed). So, one should also be able to do `M-x undo' in a dired buffer and get `dired-undo', and get `vm-undo' in a VM buffer and so on. This doesn't seem too hard to implement, but it requires us to separate the idea of actions/interfaces from keymaps. [Why allow this? Some people, me included, prefer to use memorable function names instead of remembering zillion key bindings. At the moment, the long names are made longer by the mode name prefixes like "dired-", "vm-" etc. It would be preferable to have simpler, general action names. If one uses speech recognition, key bindings are basically useless and actually get in the way. One would unbind all plain keys, and utter function names instead. Having to utter "dired blah" for every dired command is extremely cumbersome. So, we end up creating an additional layer of indirection at the speech level, translating "blah" into "dired blah". I don't yet see how the "action" idea can help with that. But I am hopeful.] Thirdly, I am proposing that interface inheritance need not only be from the global-keymap, but it could also be from generic local-keymaps. So, there could be, for instance, a generic-quick-actions keymap, which normally binds `n' to a `quick-next-line' action, `x' to a `quick-expunge' action etc. Both dired and VM could use this keymap, so that the user gets uniformity of key bindings. Moreove, the user can rebind keys in this generic keymap, e.g., move `quick-expunge' to `#' and leave `x' unbound. That would take effect in all modes that implement the generic-quick-actions keymap. That is a big win. You asked what "quick" actions are. They are the things that one would normally bind to plain keys. For example, `n' would be bound to `quick-next-line' whereas `C-n' is bound to `next-line'. How `quick-next-line' is performed is for the modes to determine. Dired might just do `next-line' in response, but VM Summary mode might display the next email message. > Sure, but we already have a concept of `action' (ie, a symbol denoting > a function): most Emacs commands follow this pattern. Most "generic" > bindings are simple enough to just inherit from the global map > *already*. Complex generic bindings like "fill-paragraph" and > "revert-buffer" provide hooks *already* so that modes can augment or > even entirely replace default implementations. Actions are *not* symbols denoting functions. They are symbols that sit on their own. They are bits of interfaces. It is possible, as you note, to make interfaces just be ordinary functions with dummy implementations. Smalltalk did that, but I think they found that the take-up was sporadic. Most developers just did implementation-inheritance and didn't bother with interface inheritance. On the other hand, when Java added interfaces as a first class concept, it had better success with the take-up. > Uh, what's a "quick action"? (I have no clue what you mean by that, > except "like vm-summary-next", which leaves a host of possibilities.) > Do you have a list of them? Does your list agree with those of the > maintainers of Gnus, Dired, buff-menu, and a host of other > maintainers? Do you all agree that you want these actions on the same > keys? I am not too fussed about the "quick" keyword. It was just the first thing that came to mind. Perhaps "modal" to mean that it depends on the mode. I am hoping that we all don't have to agree on the keys. The whole idea is to empower the user to allow for his/her favorite key bindings. But the actions, we would have to agree on, as far as the common actions go. That seems nontrivial, but not insurmountable. > If you can get definition, list, and agreement with *some* modes for > *some* "actions", you can get started. If you do actually make any > progress, let me know; I'll port/implement [remap] in XEmacs (and > SXEmacs if they don't have it yet). Ok, we have a deal! Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-28 18:32 ` Uday S Reddy @ 2010-07-29 5:47 ` Stephen J. Turnbull 0 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-07-29 5:47 UTC (permalink / raw) To: Uday S Reddy; +Cc: Teemu Likonen, Stefan Monnier, emacs-devel Uday S Reddy writes: > Stephen J. Turnbull writes: > > IME, users just don't do this, or want to do it; I really don't > > understand what you're talking about. Please be more specific > > about the use cases. > > I refer you to Teemu Likonen's post on the July 17, especially his > comment that "there's not enough abstraction on that front [the key > bindings of modes". That's not a use case. A use case is a specific usage or programming problem, typically with data, which can be addressed by providing code. As much as I respect Teemu, as a matter of free software development practice, theoretical claims of lack of abstraction are much more likely to be lack of understanding on the claimant's part than of actual language design deficiencies. The only way to demonstrate it is to give a concrete use case showing how the abstraction could be used to do something that cannot be done concisely in the stock language. It's not your job to prove it can't be done, it's our job to show how the use case can be addressed in idiomatic, stock elisp. But conversely, it's your job, not ours, to provide the use case. > In fact, a good part of the discussion in the "Emacs learning > curve" was about the difficulty of changing key bindings, why the > CUA mode can't be made the default etc. Sure, but this is not a user use case either. It has nothing to do with users specifying keymaps, it's about a lack of choice of keymap. That is because developers don't provide keymaps. I have seen zero evidence that "redesigning the key mapping system" is anything but a hobgoblin of lazy folks who want work done but are unwilling to bear the burden themselves. It's true that laziness is the Mother of Hackerly Invention, but this is the wrong kind of laziness. The Keymap Problem is a *combinatorial explosion* problem, not a *data structures + algorithms* problem. The only way to solve the Keymap Problem is to start enumerating the combinations. > At least one use case that seems to be implemented in Gnu Emacs is to > bind [remap undo] in modes that need it. So, if a user binds C-z to > undo, he/she gets the appropriate undo in all modes (as long as they > use remap for the key). Right, so users don't need to know about [remap] (in the sense above, it is NOT a user use case), and Emacs already has the necessary structures. The problem is identifying more of these use cases, and changing modes to respect them. (N.B. Stefan has been doing this for years; I imagine he'd appreciate help.) > I don't know if remap helps for rebinding C-c and C-x. That seems > like too hard a problem for remap. Again, I have no clue what you're talking about. Is this the CUA bogeyman again? Several people have pointed out that rebinding C-c and C-x are actually (conceptually) easy because they're bound to keymap variables (not even keymaps). The pragmatic problem is that many modes, especially minor modes, don't use those keymaps (especially the C-c map) properly. A SMOP. It might be possible to change `define-key' so that it starts in the indicated keymap, but instead of simply installing a mapping for a key sequence in the indicated keymap, it recurses into subkeymaps bound to prefixes of the sequence and changes only the ultimate binding. This is a bit delicate because of key sequences common across modes; you'd need to be sure you're binding the in the mode-specific keymap. > The current practice is not necessarily indicative of what the > users want to do. Many of us expected the key bindings of Emacs to > be customizable, tried it, found it to be too hard and gave up. I'm not talking about current practice, I'm talking about what questions users post. What did you try to customize and find to be too hard? Maybe the particular task *is* hard (whacking the mole aka enumerating all combinatorial possibilities). Maybe it's just tedious and you lost patience, but it could easy if you asked somebody like Stefan or Miles to cook up a helper function (eg, to swap keys is a nearly trivial example). But if you don't ask *here*, why would you expect these helper functions to exist? And I don't understand what could be so hard about keymapping. Keymaps are a little bit complex because of inheritance. But you asked for inheritance and object-orientation, so I assume you understand them. Is it that you don't understand keymaps as objects? Is it that whacking the mole gets tedious? > Some people persist because it is really important to them. It is > their exasperation that keeps this debate alive. Let them stew in their exasperation if they refuse to learn or ask to be taught. > It might have been Barbara Liskov that said that the inheritance of > implementation is not all that interesting, but the inheritance of > interface is the interesting one. A have heard the comment from a lot > of other people too. So, let us take inheritance of implementation > for granted. There is nothing in particular to be said about it. The keymap, not the individual keybinding, *is* the interface, and it *does* provide inheritance of interface, in several ways, including via [remap]. "The" Emacs keymap is a highly compressed and dynamic specification of how to accomplish pretty much all personal information processing tasks without ever resorting to a named command or menu. Note "compressed". Just as there really is no good way to locally edit a zipped file -- you need to decompress, edit, and recompress it -- there is not going to be a good *universal* way to "locally edit" the keymap. Not *-set-key, not define-key, and not [remap]. The keymap *does* have more structure than a zipfile, of course. For very minor (one new keystroke) additions, there is the reserved personal bindings C-c <letter>. Keymaps are recursive; ie, a keystroke may be bound to a keymap. If you respect this structure, you *can* do local editing of the keymap; this is precisely how minor modes work. But making random changes and hoping the rest of the keymap will pure-f'cking-magically rearrange itself, sorry, All Hope Abandon Ye. > But I am proposing that "actions" should also be usable with the M-x > prefix (or some similar prefix, since people will complain if the > semantics of M-x is changed). So, one should also be able to do `M-x > undo' in a dired buffer and get `dired-undo', and get `vm-undo' in a > VM buffer and so on. This doesn't seem too hard to implement, but it > requires us to separate the idea of actions/interfaces from > keymaps. It does not. It is *already* implemented, cf. fill-paragraph, comment-region, etc. etc. I showed how to implement this in boilerplate for "quick actions", and even pointed out that this method probably leads to internal simplification of modes like VM and Gnus, as well as cross-mode code sharing between them! You've got egg in your beer right there, what do you want, a birthday cake too? It already dramatically sucks that other commands with substantial commonality across modes do not share code. The proposal to define actions would institutionalize a worst practice, don't you see? It would encourage modes to write completely independent implementations (so much for quoting Liskov; inheriting implementation is *not* trivial; it needs to be encouraged by interface!) > [Why allow this? That's not the question. It's already allowed and encouraged, it's just that mode writers are too lazy to do it well. > It would be preferable to have simpler, general action names. You already have them, via remap. It's just a simple matter of going through all the keymaps and identifying the generic actions, and replacing mode-specific bindings with remaps. This would have to be done with a separate action feature, too. > Thirdly, I am proposing that interface inheritance need not only be > from the global-keymap, but it could also be from generic > local-keymaps. Yes, [remap] gives you that, too. > You asked what "quick" actions are. They are the things that one > would normally bind to plain keys. Yeah, I kinda thought you'd say something like that. The problem is this: > Actions are *not* symbols denoting functions. They are symbols that > sit on their own. They are bits of interfaces. Well, yes, symbols sit on their own, and are interfaces. However, there *must* be a common functional semantics for each symbol, or there is no point in having a common interface. > It is possible, as you note, to make interfaces just be ordinary > functions with dummy implementations. Smalltalk did that, but I think > they found that the take-up was sporadic. Most developers just did > implementation-inheritance and didn't bother with interface > inheritance. On the other hand, when Java added interfaces as a first > class concept, it had better success with the take-up. Ah, I see. Your true goal here is to make programming in Emacs LISP at least as painful as programming in Java. Good luck getting takeup on that! :-) The point is that unless you make actions *mandatory*, as Java does (and as C++ does), you still won't get any takeup, because it's a *rule*, and if there's one thing Emacs hackers have trouble doing, it's following rules. BTW, I'm not so sure about the success of Java interfaces. From comments on various VCS lists (!), I gather that arsing around with interfaces is one of the most enthusiasm-draining tasks in Java. > I am not too fussed about the "quick" keyword. It was just the first > thing that came to mind. Perhaps "modal" to mean that it depends on > the mode. I'm not fussed about the word, either (but "modal" is a terrible word, since the point of having common actions is the commonality across modes, not the differences). I'm fussed about the ambiguity and the lack of a list. Don't you see, the whole problem is constructing the list? The rest is a SMOP. And in this case the MOP truly is S. It's also VT (for very tedious). > I am hoping that we all don't have to agree on the keys. For remap, there needs to be a default binding, or it won't work. In the case of a separate set of actions, you don't need to agree on keys, that's true. The tradeoff is that the most likely outcome will be that 3rd party modes will define their own actions rather than look up the generic ones. Cf. /usr/include/X11/*key*.h. So you'll need to do substantial work defining them, and educating mode hackers to use them. Cf. "Emacs hackers and rules" above. I don't envy you that task. ;-) Note that you also have to define the interface to each action. Users will not be pleased to discover that C-u C-z means something quite different (eg, redo vs. undo 4 times) when in VM than when in Gnus. One advantage of the remap approach is that generally there will be existing default implementations that can be overridden. > The whole idea is to empower the user to allow for his/her favorite > key bindings. That idea is dead in the water, and sinking fast. By your own testimony, you weren't able to do that. In general, the best that users will be able to do is select from a menu of pre-designed keymaps. A few users will do things like swap bindings they use frequently with more convenient keys whose bindings they don't use much, but that's probably as far as it will go. What *can* happen here is to make the task of designing keymaps a little more attractive to developers, since setting up a new keymap based on an existing group of generic commands or actions will work for all modes using that group of generic commands. Specifically, it might make sense for somebody to design a quick-action-map as you suggest, and then graft that on to VM, Gnus, dired, PCL-CVS, etc. I suspect you will find that process a lot more painful than you expect, though. > But the actions, we would have to agree on, as far as the common > actions go. That seems nontrivial, but not insurmountable. Agreed. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier 2010-07-27 11:30 ` Eric M. Ludlam 2010-07-27 11:32 ` Stephen J. Turnbull @ 2010-07-29 15:28 ` Uday S Reddy 2010-07-29 16:05 ` Andreas Röhler 2010-07-31 7:16 ` Mathias Dahl 2010-07-30 2:04 ` coding guidelines? (was Re: Key bindings proposal) Joe Brenner 3 siblings, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-07-29 15:28 UTC (permalink / raw) To: Stefan Monnier Cc: Uday S Reddy, Stephen J. Turnbull, Teemu Likonen, emacs-devel Stefan Monnier writes: > The main problem is not whether the method is declarative or not, but > rather the problem is to make intentions clear. The reason for asking for declarative methods is that they are easier for users and/or third-party customizers to deal with. The whac-a-mole effect is hard enough for them to address. Side-effects would introduce unseen interactions which would make it even harder to figure out what is going on. The way X windows deals with X resources is a perfectly fine way to provide customization information. I don't see why we can't duplicate that in Emacs. > The issue with "intentions" is typically along the lines of "do you want > to bind `foo' to C-x C-x or do you want to bind it to the C-x key within > the main prefix keymap, or do you want to bind it to the repetition of > the key-sequence to which this main keymap is bound, or maybe only to > the repetition of just the last key in this key-sequence, or maybe to > the repetition of C-"the key above my "alt" key, or maybe you want to > bind it to whichever key `foobar' is bound in such-and-such-mode, ..." > > If all Emacs packages could replace their `define-key' calls by others > that make the intentions clear, then it would be a lot easier/cleaner to > redefine key-bindings. It is laudable goal, but I think it may be way too ambitious. If you can try and do it for one mode out there and demonstrate how it can be done, then we could make some progress. But I have a feeling that we have the key binding stuff blown way out of proportion. When RMS started Gnu Emacs, he seemed to have a clear sense that the most important and frequently used functions would be bound to keys, the rest would be done using M-x. But that idea is totally lost now. Most Emacs coders today seem to think that every function has to be on a key or people won't use it. And the key combinations keep getting weirder and weirder. Like M-s a C-s to do an isearch! It would be a good idea for us to question ourselves why we are so obsessed with key bindings whereas the rest of the world gets by perfectly fine with very few key bindings. Here are two answers that come to my mind (and perhaps there are others). - In most modern OS's, one can navigate menus with keys. Emacs doesn't use this mode of usage at all. The menu items don't have key strokes associated with them, and the menus look totally disorganized. In principle, this can give us much more "real estate" to work with, without having to memorize arcane key bindings that make our fingers twist. - We have totally ignored the potential of command names. I can type `M-x isearch' a lot faster than I can type `M-s a C-s', but the later is supposed to a holy cow whereas "isearch" doesn't exist as a concept. Why can't we have two name spaces of global commands and local commands, and bind them to functions? I am not digressing. If we can start exploring some of these other options, they can reduce the burden that the key bindings are having to carry at the moment. > But if you look at the average quality of Elisp code, you'll quickly > learn that most authors have much better things to do than to worry > about such problems (i.e. their main worry is to get it to work for > the very specific Emacs they're currently using, with their current > .emacs). Then let us discourage them from binding too many keys, and leave it to the users to bind their own keys. There is only a limited amount of key space out there! The predefined key bindings are even defeating the remap-bindings as we have just discovered. > That's yet more difficult. It means that the author and/or the user > needs to explicitly indicate when something should take precedence over > something else, and when not. In most cases I know of, this tends to be > too heavy to use and instead the system is designed to use a default > precedence scheme (witness the "use first matching pattern" rule in > ML-style or Prolog pattern matching). > So I'd expect "conflict detection" to come with a lot of user complaints > (already we have occasional bug-reports about the errors signaled by > define-key when you define a binding for C-a C-b when C-a is already bound > to a command). My feeling is that, if we have a decent infrastructure for developing and exchanging keymaps, people will do the work for themselves. (I recall that when X Windows first started, people found it to be a nightmare to customize them. But, very quickly, people started writing .Xdefaults files and exchanging them and the knowhow spread around. We can ask ourselves why people find it so much harder to do keymaps as compared to Xdefaults.) I guess we will discover what precedence rules are needed as we play with these features. For instance, it would have been much nicer if remap had precedence over the hard-coded bindings whereas it is the other way around at present. I think it would be best if the user can say which way the precedence should go. I will continue playing with the features you mentioned and see how well they work. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-29 15:28 ` Uday S Reddy @ 2010-07-29 16:05 ` Andreas Röhler 2010-07-31 7:16 ` Mathias Dahl 1 sibling, 0 replies; 277+ messages in thread From: Andreas Röhler @ 2010-07-29 16:05 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Am 29.07.2010 17:28, schrieb Uday S Reddy: > Stefan Monnier writes: > > >> The main problem is not whether the method is declarative or not, but >> rather the problem is to make intentions clear. >> > The reason for asking for declarative methods is that they are easier > for users and/or third-party customizers to deal with. The > whac-a-mole effect is hard enough for them to address. Side-effects > would introduce unseen interactions which would make it even harder to > figure out what is going on. > > The way X windows deals with X resources is a perfectly fine way to > provide customization information. I don't see why we can't duplicate > that in Emacs. > > >> The issue with "intentions" is typically along the lines of "do you want >> to bind `foo' to C-x C-x or do you want to bind it to the C-x key within >> the main prefix keymap, or do you want to bind it to the repetition of >> the key-sequence to which this main keymap is bound, or maybe only to >> the repetition of just the last key in this key-sequence, or maybe to >> the repetition of C-"the key above my "alt" key, or maybe you want to >> bind it to whichever key `foobar' is bound in such-and-such-mode, ..." >> >> If all Emacs packages could replace their `define-key' calls by others >> that make the intentions clear, then it would be a lot easier/cleaner to >> redefine key-bindings. >> > It is laudable goal, but I think it may be way too ambitious. If you > can try and do it for one mode out there and demonstrate how it can be > done, then we could make some progress. > > But I have a feeling that we have the key binding stuff blown way out > of proportion. When RMS started Gnu Emacs, he seemed to have a clear > sense that the most important and frequently used functions would be > bound to keys, the rest would be done using M-x. But that idea is > totally lost now. Most Emacs coders today seem to think that every > function has to be on a key or people won't use it. And the key > combinations keep getting weirder and weirder. Like M-s a C-s to do > an isearch! > > It would be a good idea for us to question ourselves why we are so > obsessed with key bindings whereas the rest of the world gets by > perfectly fine with very few key bindings. Here are two answers that > come to my mind (and perhaps there are others). > > - In most modern OS's, one can navigate menus with keys. Emacs > doesn't use this mode of usage at all. The menu items don't have key > strokes associated with them, and the menus look totally > disorganized. In principle, this can give us much more "real estate" > to work with, without having to memorize arcane key bindings that make > our fingers twist. > > - We have totally ignored the potential of command names. Hi, thanks mentioning it. Also command names are mnemonic, while keys are not. BTW Info should always start with the command name IMHO, delivering the default key-binding secondly only. Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ > I can type > `M-x isearch' a lot faster than I can type `M-s a C-s', but the later > is supposed to a holy cow whereas "isearch" doesn't exist as a > concept. Why can't we have two name spaces of global commands and > local commands, and bind them to functions? > > I am not digressing. If we can start exploring some of these other > options, they can reduce the burden that the key bindings are having > to carry at the moment. > > >> But if you look at the average quality of Elisp code, you'll quickly >> learn that most authors have much better things to do than to worry >> about such problems (i.e. their main worry is to get it to work for >> the very specific Emacs they're currently using, with their current >> .emacs). >> > Then let us discourage them from binding too many keys, and leave it > to the users to bind their own keys. There is only a limited amount > of key space out there! The predefined key bindings are even > defeating the remap-bindings as we have just discovered. > > >> That's yet more difficult. It means that the author and/or the user >> needs to explicitly indicate when something should take precedence over >> something else, and when not. In most cases I know of, this tends to be >> too heavy to use and instead the system is designed to use a default >> precedence scheme (witness the "use first matching pattern" rule in >> ML-style or Prolog pattern matching). >> So I'd expect "conflict detection" to come with a lot of user complaints >> (already we have occasional bug-reports about the errors signaled by >> define-key when you define a binding for C-a C-b when C-a is already bound >> to a command). >> > My feeling is that, if we have a decent infrastructure for developing > and exchanging keymaps, people will do the work for themselves. (I > recall that when X Windows first started, people found it to be a > nightmare to customize them. But, very quickly, people started > writing .Xdefaults files and exchanging them and the knowhow spread > around. We can ask ourselves why people find it so much harder to do > keymaps as compared to Xdefaults.) > > I guess we will discover what precedence rules are needed as we play > with these features. For instance, it would have been much nicer if > remap had precedence over the hard-coded bindings whereas it is the > other way around at present. I think it would be best if the user can > say which way the precedence should go. > > I will continue playing with the features you mentioned and see how > well they work. > > Cheers, > Uday > > > ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-29 15:28 ` Uday S Reddy 2010-07-29 16:05 ` Andreas Röhler @ 2010-07-31 7:16 ` Mathias Dahl 2010-07-31 10:04 ` Uday S Reddy 2010-08-23 13:45 ` Juri Linkov 1 sibling, 2 replies; 277+ messages in thread From: Mathias Dahl @ 2010-07-31 7:16 UTC (permalink / raw) To: Uday S Reddy Cc: Stephen J. Turnbull, Teemu Likonen, Stefan Monnier, emacs-devel > function has to be on a key or people won't use it. And the key > combinations keep getting weirder and weirder. Like M-s a C-s to do > an isearch! I just use C-s. In my Emacs the binding you mention does not exist, so it is probably a quite new invention. And my guess is that it is there for completeness, someone decided (I did not even know about M-s until now and I have used Emacs since 1997) to keep all search related stuff on M-s and for completeness isearch was placed there too. I assume the idea is to type M-s to get into "search mode" and from there type a few keys to execute the particular search command you want. I agree that the extra "a C-s" lacks a good "flow". Why not just "a s" (what does the "a" stand for?). But, again, isearch has its own top level binding, so most will use that. > It would be a good idea for us to question ourselves why we are so > obsessed with key bindings whereas the rest of the world gets by > perfectly fine with very few key bindings. I have asked myself the same thing. I think in many other programs users use the menus (using the mouse) and/or the toolbar and other widgets. Around me, at work, very few people use the keybindings that do exists in those other programs. They limit themselves to cut, paste, copy, save and new, at tops. > - In most modern OS's, one can navigate menus with keys. Emacs > doesn't use this mode of usage at all. I see very few navigating the menus by keys although I find this to be an excellent replacement when a command does not have its own keybinding. After some tries I learn the path to the command I want so that it in practice gets a keybinding (like M-f s, or whatever). > ... and the menus look totally disorganized. Oh come on. There might be some items that are not where you would expect but to say that the menus look totally disorganized is unfair. Why not suggest a new structure in a new thread? > In principle, this can give us much more "real estate" > to work with, without having to memorize arcane key bindings that make > our fingers twist. M-x is right there, no one forces you to use arcane bindings (I agree that some are, for example those starting with C-@, which is very hard to type on a Swedish keyboard layout) and you can use F10 to reach the menus, or M-x tmm to navigate the menus as text. Or use the mouse (Gaaaah! :) > - We have totally ignored the potential of command names. Oh, have "we"? I use M-x all the time and have learned how to use partial completion to more quickly execute commands with long names. > I can type > `M-x isearch' a lot faster than I can type `M-s a C-s' Again, its there for completeness (my guess anyway). Use C-s instead if this is something you do a lot. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-31 7:16 ` Mathias Dahl @ 2010-07-31 10:04 ` Uday S Reddy 2010-07-31 14:07 ` Alan Mackenzie ` (3 more replies) 2010-08-23 13:45 ` Juri Linkov 1 sibling, 4 replies; 277+ messages in thread From: Uday S Reddy @ 2010-07-31 10:04 UTC (permalink / raw) To: emacs-devel On 7/31/2010 8:16 AM, Mathias Dahl wrote: > I just use C-s. In my Emacs the binding you mention does not exist, so it is > probably a quite new invention. I think we are talking at cross purposes. This whole discussion has been about how to organize the key bindings for local keymaps set up by Emacs modes in such a way that users can modify them easily. Modifying the global bindings is a piece of cake. So, they are not under discussion. (Well, not as far as they don't impinge on local keymaps.) M-s a C-s is indeed a recent key binding. The ChangeLog.14 file gives a date of 2008-07-28, and grep shows that there are four modes that use it: buff-menu, dired, ibuffer and vc-dir. I was giving this as an example of how Emacs developers feel *compelled* to put functions on keys. The reasons could be (a) they believe that all commands are supposed to be on keys, or (b) they think the users won't use them otherwise, or (c) they think the users won't notice them otherwise. The problem (a) is a policy issue. I don't know if there is a policy that all commands are supposed to be on keys. But, if there is one, it can be changed easily. So, this is not a big deal. The problem (b) is a real one. Practically nobody is going to type M-x dired-do-isearch to invoke this function. So, even these twisted key bindings will probably get used by those that need them. My idea was why can't one type something like "M-x isearch" to get this function, instead of "M-x dired-do-isearch" which is too long-winded and "M-s a C-s" which is too twisted and unmemorable? This requires a new concept for Emacs, bindable command names that can vary across modes. (Stephen Turnbull is going to say that you can already get its effect through some other means. That is all well and good. The discussion right now is really about how to set up an architecture that is functional for the users. Not everything whose effect can be achieved by other means becomes part of the architecture unless we use it appropriately!) The problem (c) is a real one too. But the solution is self-defeating. Once all the developers start scrambling for the limited keymap space in an effort to attract the users' attention, the keymaps grow and grow and they stop attracting anybody's attention. To get to C-s a M-s in the dired-mode's doc string, I had to do some 12 page-downs! Doubtless my attention has wandered off before then. I stopped reading mode doc-strings somewhere around Emacs 19, when they started getting longer than Unix man pages. (And, I stopped using Unix when its man pages became unreadable too.) Fortunately, Emacs has info, which I use regularly. But my impression is that the vast majority of Emacs users don't use info. Xah Lee is right that the info manual has begun to read more and more like a PhD thesis than a user manual, and unfit to look up information quickly unless you already know its structure well. But let me not go into that issue here. Keyboard navigation of the menubar is a potential solution for both the problems (b) and (c). But, as I mentioned earlier, this idea hasn't yet been taken seriously in Emacs. The menu entries don't have key strokes associated with them. At least on Windows, one can get to each menu item by typing the first letter of the item. But this gets tedious if - there are many menu items starting with the same letter (for example, look under the "Mark" menu in dired) and - when there is no way to sort the menu items alphabetically. On second thought, perhaps the menus are not as disorganized as I had imagined. I haven't yet begun to use them seriously. Since you seem to have first-hand experience with their use, I should go by your word that they work well. I would personally prefer if the menu items had key strokes associated with them rather than the default first-letter-selection mechanism. This would also be in line with all the well-designed GUI applications out there. Coming back to the original issue, the over-reliance on key bindings gets in the way of users trying to move the key bindings around. Even the remapping idea, which is good in concept, is defeated if the mode developers have hard-wired key bindings. And, a lot of the time the mode developers have used up pretty much all the key space there is. So, the remapping idea becomes useless. To give a concrete example, let us say that a user wants to use i-j-k-m mnemonics for movement instead of p-b-f-n. He can bind C-m to next-line etc at the top-level however hard it might be. But then every mode will probably have some bindings that depend on the p-b-f-n mnemonics. The dired mode had C-n bound to dired-next-line, which has now been changed to [remap next-line]. That helps the user. But dired mode also has `n' bound to dired-next-line. It is not possible to move it to `m' by remapping. In some other modes (e.g., VM summary mode), C-n is not used, but just `n' for the mode-specific movement. Thus the user has to solve the same problem again and again. This is not the whac-a-mole problem because it is the *same* mole that crops up in each mode, not a different one. So, the more keys the developers bind, the harder it is for the users to move them around. Getting away from the key binding culture will help such users. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-31 10:04 ` Uday S Reddy @ 2010-07-31 14:07 ` Alan Mackenzie 2010-07-31 18:17 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 0 replies; 277+ messages in thread From: Alan Mackenzie @ 2010-07-31 14:07 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Good afternoon, Uday! On Sat, Jul 31, 2010 at 11:04:50AM +0100, Uday S Reddy wrote: > On 7/31/2010 8:16 AM, Mathias Dahl wrote: > >I just use C-s. In my Emacs the binding you mention does not exist, so it > >is probably a quite new invention. > I think we are talking at cross purposes. This whole discussion has been > about how to organize the key bindings for local keymaps set up by Emacs > modes in such a way that users can modify them easily. Modifying the > global bindings is a piece of cake. So, they are not under discussion. > (Well, not as far as they don't impinge on local keymaps.) How often do users want to do a massive rebinding of keys? Approximately never is the answer. > M-s a C-s is indeed a recent key binding. The ChangeLog.14 file gives a > date of 2008-07-28, and grep shows that there are four modes that use it: > buff-menu, dired, ibuffer and vc-dir. I was giving this as an example of > how Emacs developers feel *compelled* to put functions on keys. The > reasons could be (a) they believe that all commands are supposed to be on > keys, or (b) they think the users won't use them otherwise, or (c) they > think the users won't notice them otherwise. Oh come on, get real! Many, possibly most, commands are unusable by typing M-x plus <command name>. Not all commands have keybindings, not by a long shot. The scenario you've pictured is ludicrous. > The problem (a) is a policy issue. I don't know if there is a policy that > all commands are supposed to be on keys. But, if there is one, it can be > changed easily. So, this is not a big deal. You're turning into something like a conspiracy theorist here. It is simply the case that typing a key sequence is easier and faster than M-x + name. There is no policy involved such as you've sketched. > The problem (b) is a real one. Practically nobody is going to type M-x > dired-do-isearch to invoke this function. So, even these twisted key > bindings will probably get used by those that need them. Your (a), (b) and (c) aren't problems to anybody bar yourself. > My idea was why can't one type something like "M-x isearch" to get this > function, instead of "M-x dired-do-isearch" which is too long-winded and > "M-s a C-s" which is too twisted and unmemorable? This requires a new > concept for Emacs, bindable command names that can vary across modes. Well, for deity's sake stop flooding this mailing list with long screeds and start hacking out a solution. If you think you can show something is a good idea, and expect "Somebody" (tm) to code it up for you, you're mistaken. That's not the way development groups work, at least not this one. If you really believe you've identified problems, fix them! > (Stephen Turnbull is going to say that you can already get its effect > through some other means. That is all well and good. The discussion right > now is really about how to set up an architecture that is functional for > the users. Not everything whose effect can be achieved by other means > becomes part of the architecture unless we use it appropriately!) Design and code up that architecture. Post a patch on this mailing list. Then, and only then, will your ideas get taken seriously. > The problem (c) is a real one too. But the solution is self-defeating. > Once all the developers start scrambling for the limited keymap space in an > effort to attract the users' attention, the keymaps grow and grow and they > stop attracting anybody's attention. To get to C-s a M-s in the > dired-mode's doc string, I had to do some 12 page-downs! Doubtless my > attention has wandered off before then. > I stopped reading mode doc-strings somewhere around Emacs 19, when they > started getting longer than Unix man pages. (And, I stopped using Unix > when its man pages became unreadable too.) Fortunately, Emacs has info, > which I use regularly. But my impression is that the vast majority of > Emacs users don't use info. Xah Lee is right that the info manual has > begun to read more and more like a PhD thesis than a user manual, and unfit > to look up information quickly unless you already know its structure well. > But let me not go into that issue here. OK, I will instead. Yes, it takes time to learn to use Emacs's info pages, but once you've learned how they work, they are a joy to use. A bit like Emacs itself. > Keyboard navigation of the menubar is a potential solution for both the > problems (b) and (c). But, as I mentioned earlier, this idea hasn't yet > been taken seriously in Emacs. Well YOU start taking it seriously. Or have you done so already? > The menu entries don't have key strokes associated with them. At least > on Windows, one can get to each menu item by typing the first letter of > the item. But this gets tedious if > - there are many menu items starting with the same letter (for example, > look under the "Mark" menu in dired) and > - when there is no way to sort the menu items alphabetically. Contribute such a sorting. > On second thought, perhaps the menus are not as disorganized as I had > imagined. I haven't yet begun to use them seriously. Since you seem to > have first-hand experience with their use, I should go by your word that > they work well. I would personally prefer if the menu items had key > strokes associated with them rather than the default first-letter-selection > mechanism. This would also be in line with all the well-designed GUI > applications out there. All, or nearly all, of the mouse ambages have keyboard equivalents. What I think you mean is that they are not all displayed in the menu. I agree with you that they probably should be, but I can't be bothered any more than you can about implementing this; I don't even use menus in Emacs. > Coming back to the original issue, the over-reliance on key bindings gets > in the way of users trying to move the key bindings around. Even the > remapping idea, which is good in concept, is defeated if the mode > developers have hard-wired key bindings. And, a lot of the time the mode > developers have used up pretty much all the key space there is. So, the > remapping idea becomes useless. Read the elips page on bindings. The key bindings C-c C-<letter> are allocated to major modes. C-c <letter> are allocated to users. Other C-c bindings are allocated to minor modes. Mode developers tend to stay within these strictures. > To give a concrete example, let us say that a user wants to use i-j-k-m > mnemonics for movement instead of p-b-f-n. He can bind C-m to next-line > etc at the top-level however hard it might be. But then every mode will > probably have some bindings that depend on the p-b-f-n mnemonics. The > dired mode had C-n bound to dired-next-line, which has now been changed to > [remap next-line]. That helps the user. But dired mode also has `n' bound > to dired-next-line. It is not possible to move it to `m' by remapping. In > some other modes (e.g., VM summary mode), C-n is not used, but just `n' for > the mode-specific movement. Thus the user has to solve the same problem > again and again. This is not the whac-a-mole problem because it is the > *same* mole that crops up in each mode, not a different one. > So, the more keys the developers bind, the harder it is for the users to > move them around. Getting away from the key binding culture will help such > users. Then get hacking, and sort this "problem" out! I honestly can't see what all the big fuss is about. Your solution will involve an immense amount of work amending Info pages and doc strings, for questionable benefit. Just because Emacs is very configurable, it doesn't follow that extreme customisation should be made very easy, at the cost of who knows what. I've only seen one other person wanting this, his name's Xah Lee, and he's forked Emacs to do this. Search for "ergoemacs" to find it. > Cheers, > Uday -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-07-31 10:04 ` Uday S Reddy 2010-07-31 14:07 ` Alan Mackenzie @ 2010-07-31 18:17 ` Drew Adams 2010-08-02 14:59 ` Uday S Reddy 2010-08-02 9:42 ` Stuart Hacking 2010-08-02 10:12 ` Tassilo Horn 3 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-07-31 18:17 UTC (permalink / raw) To: 'Uday S Reddy', emacs-devel I really do not want to go down the rat hole of this thread. But I will make a couple of comments. Suffice it to say, beyond these comments, that I agree with those old diehards ;-) who have been trying to say that this thread is misguided in general. > My idea was why can't one type something like "M-x isearch" > to get this function, instead of "M-x dired-do-isearch" > which is too long-winded and "M-s a C-s" which is too > twisted and unmemorable? This requires a new concept In many or most cases, the mode's specialized version of a command does not simply replace that command in all situations or for all purposes. That is the case here, for example. You might well want to use the general command `isearch' (e.g. `C-s') in a Dired buffer, in addition to wanting (for other purposes) to use the more specialized command `dired-isearch-filenames' (bound to `M-s f C-s'). The latter does not simply replace the former for everything when in Dired. You are wrong in assuming that a subtype/subclass analogy holds in general for this kind of thing. `dired-isearch-filenames' is not `isearch', and both can be useful in Dired mode. Not to mention `dired-do-isearch', which is the command that you mentioned. That command is for searching within the marked files themselves. It has nothing to do with searching within the Dired buffer (`isearch'). (Did you notice the similarity: `M-s f C-s', `M-s a C-s'? There is a key-binding logic here. You might prefer a different logic, but there is one.) > To get to C-s a M-s in the dired-mode's doc string, I had > to do some 12 page-downs! Obviously, in a mode as rich as Dired, you should not expect to use `C-h m' as your primary means of discovery of what is possible in Dired. Menus. Menus. Menus. Menus are your friend. Menus are an excellent way to _discover_ features, including command names and key bindings. The menu for a mode tells you about its main features, organizes them in some logical or pedagogical way, and gives you the keyboard shortcuts for the menu items. Menus are _organized_, and that is one of their main advantages for discovery and memory (infrequent access). What was that command/key that let me do such-and-such? You can try `apropos' and `C-h b', but you can also explore menus to take advantage of their logical organization. If you're not doing this, then I suggest you're missing the boat. Yes, Emacs menus are not always as good as they could be, partly because the Emacs developers who add a feature have already discovered it. ;-) In Dired, the `Operate' menu (the one for operating on marked files), has these menu items: Isearch Files... M-s a C-s Isearch Regexp Files... M-s a C-M-s And the `Immediate' menu has these: Isearch in File Names... M-s f C-s Isearch Regexp in File Names-... M-s f C-M-s [Personally (dired+.el), I put the latter items on the `Subdir' menu, not on the `Immediate' menu - they are not actions that apply to a single file. (And I rename `Immediate' to `Single', `Operate' to `Multiple', and `Subdir' to `Dir'.)] Perhaps these same search items should also appear on the `Search' menu (under `Edit'). But the point is that you should, like newbies everywhere (and we are all newbies in some contexts) use _menus_, not just `C-h m' or `C-h b', to discover. To discover, use menus, use the fine manual, and use `apropos'. Wrt the key bindings for these commands: Again, there is a logic there - a logic that facilitates discovery and memory. And you can easily use your own, personally superior, alternative bindings. And you need not use any binding if you prefer to use a command or menu. It is trivial in Emacs to get the command name from the menu item (here, but not always - e.g. easymenu): `C-h k'. And it is trivial to provide a shorter command name (alias) if you want to use `M-x my-foo' instead of `M-x the-long-weird-obscure-fooish-command'. Honestly, I do not know of an application where it is so easy to discover and access commands as it is in Emacs. Could discovery be even easier? Yes, IMO. Icicles users have the equivalent of `apropos' available on the fly every time they use the minibuffer for anything. Could the menus be improved? Yes. Could menu access from the keyboard be improved? Yes, IMO (though `tmm' is OK) - La Carte, especially together with Icicles, gives you excellent menu access and menu discovery from the keyboard. And other improvements are always possible. But Emacs is _better_, not worse, than most apps wrt command discovery and access. The complaints here about weird Emacs keybindings are surprising to me, coming from you, Uday, who are familiar with Emacs. They sound like the superficial comments of a vi'er or someone unfamiliar with Emacs - someone who has the impression that one is _required_ to use `M-x a C-s' in order to search. It is trivial to use `M-x', trivial to use the menu, and trivial to bind a simpler key to something that you use often. > I stopped reading mode doc-strings somewhere around Emacs 19, > when they started getting longer than Unix man pages. I'm the opposite. I like a mode doc string that gives me almost a mini-manual for the feature (mode). People are different. But a doc string is not intended to _replace_ a manual. That is why doc strings link to the manual (or they should more often), as well as to Customize. > (And, I stopped using Unix when its man pages became > unreadable too.) Wow, that's quite extreme. With GNU/Linux you can of course help improve the man pages. ;-) > Fortunately, Emacs has info, which I use regularly. Amen. > But my impression is that the vast majority of Emacs users don't > use info. I do not have that impression. What makes you think that? > Xah Lee is right that the info manual has begun to read more > and more like a PhD thesis than a user manual, I disagree. I use Emacs 20 often, and I do not see any special trend/change from Emacs 20 to Emacs 24 that could be so characterized. And I do not find either the 20 or 24 manual to be thesis-like. It is true that some sections are more difficult to read than others - they are more reference-like. The Emacs manual is not just a user manual in the sense of an intro, guide-you-by-the-hand, user guide. It is that to some extent, but it is also a _reference_ manual. Likewise (even more so), the Elisp manual. > and unfit to look up information quickly unless you > already know its structure well. Dunno why you say that. But there are ways to improve Info as well, and some of them have recently been added to vanilla Emacs (mostly by Juri). Virtual books, history lists, etc. speak directly to the "structure". If you use Icicles then you have even more help navigating Info and dealing with its structure. > But let me not go into that issue here. Yes, a separate thread please, if you really want to get into Info. > Keyboard navigation... hasn't yet been taken seriously in > Emacs. The menu entries don't have key strokes associated > with them. See above. You're wrong on both counts, IMO: keyboard navigation of menus and presence of keyboard-shortcut indications in menu items. > At least on Windows, one can get to each menu > item by typing the first letter of the item. > But this gets tedious if > - there are many menu items starting with the same letter > (for example, look under the "Mark" menu in dired) and > - when there is no way to sort the menu items alphabetically. Try Icicles and La Carte. You can easily sort items on the fly and you can easily get to any item, no matter where it is in the menu tree. I'm not trying to pitch Icicles or La Carte here. I'm trying to say that Emacs can easily give excellent menu access and provide excellent menu discovery. Out of the box it is OK, and it could easily be made even better. > On second thought, perhaps the menus are not as disorganized > as I had imagined. I haven't yet begun to use them seriously. Please do. You will thank yourself. And you will no doubt file menu bugs or enhancement requests or provide patches for improvements. Welcome. I agree that Emacs menus could be improved. Emacs developers do not always take them very seriously. But you do - or will ;-). > Coming back to the original issue, the over-reliance on key > bindings That is a misconception. Think of key bindings as an extra, if you like. Use commands and menus most of the time, if you like. Emacs does not require anyone to use keys all the time or even most of the time. > the mode developers have used up pretty much all the > key space there is. It is trivial to define your own, preferred key bindings. Think of the existing bindings as a default, fallback behavior. Or think of them as only suggestions. Define your own, if you like. As others have said here, there is a reason to Emacs's key-binding madness, but you are free to ignore that organization, especially in any given context/mode. > So, the more keys the developers bind, the harder it is for > the users to move them around. Getting away from the key > binding culture will help such users. I think you misunderstand the "key binding culture". But I won't get into a discussion about it with you. I already wrote more than I intended to. If what I wrote helps, fine. If not, ignore. IMO, this discussion has not been and will probably not be very fruitful. But don't let that single opinion stop you. ;-) And I do hope that you will help concretely to improve Emacs menus and manuals. Dealing with a concrete problem/improvement is more likely to yield results than is initiating a general or vague discussion about revamping Emacs. Of course, for fundamental change we would need fundamental discussion. But I don't see that need the way you do. I think you misunderstand some of the existing design. That doesn't mean that your observations can't be helpful. But I suspect that if you attack more specific targets/needs then everyone will learn more and there will be more improvement. Just a suggestion. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-07-31 18:17 ` Drew Adams @ 2010-08-02 14:59 ` Uday S Reddy 2010-08-02 17:59 ` Drew Adams 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-02 14:59 UTC (permalink / raw) To: Drew Adams; +Cc: 'Uday S Reddy', emacs-devel Drew Adams writes: > I really do not want to go down the rat hole of this thread. But I > will make a couple of comments. Suffice it to say, beyond these > comments, that I agree with those old diehards ;-) who have been > trying to say that this thread is misguided in general. Dear Drew, the point of this thread is to explore possible technical solutions to the problems that have been raised in the previous threads: "emacs learning curve", "efforts to attract more users" etc. Instead of having religious debates about which key bindings are better and which bindings should be used and whether there is any need to change key bindings at all etc., my idea is that, if Emacs provides the right set of technical tools allowing users to rebind keys, then more people will be satisfied. So, this is a *technical* discussion. If people want to continue the religious debates, they can go back to the old threads and extend them. > In many or most cases, the mode's specialized version of a command > does not simply replace that command in all situations or for all > purposes. As I said in my reponse to Tassilo, there is no intent to replace the global search commands. `M-x isearch' is meant to represent a generic operation that will be defined in specific modes like dired (and Buffer menu, VM, Gnus etc.) People that like to type `M-s a C-s' can happily go on typing it. But that doesn't have to be the only way to invoke this function. > Menus. Menus. Menus. Menus are your friend. Menus are an > excellent way to _discover_ features, including command names and > key bindings. Glad we agree on something! > Could discovery be even easier? Yes, IMO. Icicles users have the > equivalent of `apropos' available on the fly every time they use the > minibuffer for anything. Could the menus be improved? Yes. Could > menu access from the keyboard be improved? Yes, IMO (though `tmm' > is OK) - La Carte, especially together with Icicles, gives you > excellent menu access and menu discovery from the keyboard. > > And other improvements are always possible. But Emacs is _better_, > not worse, than most apps wrt command discovery and access. Oh, that self-congratulation again! At least on Windows, you don't need any special libraries to access the stadard menubar by keyboard. If you press the Alt-key once, the menubar gets selected. Then you type keys as follows (in the dired-mode menubar): o - goes to Options o - goes to Operate RET - selects the Operate menu i - goes to Isearch Files RET - selects Isearch Files A Windows developer or Java developer that cares about access would have also associated key strokes with each menu title and menu item. These appear as underscored characters in the menus. For instance, one could have chosen `p' in `Operate' as the selected key stroke. Then typing `p' would have taken you directly to `Operate' without stopping at `Options'. When there are unique key strokes associated with the menu items, no RET character is needed for selection. So, in an accessible Windows application, the above navigation could have been done with 2 keystrokes instead of the 5 that Emacs requires. This is something like 10-15 year old technology. Just open Thunderbird and play with keys to navigate the menus. You will get the idea. Do you still want to claim that Emacs is better than most apps for access? When I talk about associating key strokes with menu items, people here don't even seem to know what I am talking about! > The complaints here about weird Emacs keybindings are surprising to > me, coming from you, Uday, who are familiar with Emacs. They sound > like the superficial comments of a vi'er or someone unfamiliar with > Emacs - someone who has the impression that one is _required_ to use > `M-x a C-s' in order to search. It is trivial to use `M-x', trivial > to use the menu, and trivial to bind a simpler key to something that > you use often. I didn't "complain" about the weird key bindings. I gave the weird bindings as an example to talk about the over-reliance of Emacs on key bindings. Obviously the developers went to the weird keys after all the normal keys were exhausted. But, unless there were idle normal keys, the `remap' idea - proposed by Stefan as a possible solution for local key bindings - is ineffective. At best, it can protect the global key bindings as you go down to modes. But it doesn't help the problem of local key bindings. What I have been arguing for is the idea of abstract commands (a variant of Oscar's "actions"). It is a clean solution, well-understood in programming language theory, and I think it can be made to work for Emacs modes. > Try Icicles and La Carte. You can easily sort items on the fly and > you can easily get to any item, no matter where it is in the menu > tree. Can they match the 3-key stroke access (Alt p i) to "Isearch Files" in the dired menu? > > On second thought, perhaps the menus are not as disorganized as I > > had imagined. I haven't yet begun to use them seriously. > > Please do. You will thank yourself. And you will no doubt file > menu bugs or enhancement requests or provide patches for > improvements. Welcome. I will be quite happy to use menus if the menu items have keystrokes associated with them like on Windows & Java applications. Without that, they are quite inefficient. I will check to see if La Carte and Icicles can help. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-02 14:59 ` Uday S Reddy @ 2010-08-02 17:59 ` Drew Adams 2010-08-02 18:10 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 277+ messages in thread From: Drew Adams @ 2010-08-02 17:59 UTC (permalink / raw) To: 'Uday S Reddy'; +Cc: 'Lennart Borgman', emacs-devel > > Could discovery be even easier? Yes, IMO. Icicles users have the > > equivalent of `apropos' available on the fly every time they use the > > minibuffer for anything. Could the menus be improved? Yes. Could > > menu access from the keyboard be improved? Yes, IMO (though `tmm' > > is OK) - La Carte, especially together with Icicles, gives you > > excellent menu access and menu discovery from the keyboard. > > > > And other improvements are always possible. But Emacs is _better_, > > not worse, than most apps wrt command discovery and access. > > Oh, that self-congratulation again! At least on Windows, you don't > need any special libraries to access the stadard menubar by keyboard. > If you press the Alt-key once, the menubar gets selected. Then you > type keys as follows (in the dired-mode menubar): > > o - goes to Options > o - goes to Operate > RET - selects the Operate menu > i - goes to Isearch Files > RET - selects Isearch Files > > A Windows developer or Java developer that cares about access would > have also associated key strokes with each menu title and menu item. > These appear as underscored characters in the menus. For instance, > one could have chosen `p' in `Operate' as the selected key > stroke. Then typing `p' would have taken you directly to `Operate' > without stopping at `Options'. When there are unique key strokes > associated with the menu items, no RET character is needed for > selection. So, in an accessible Windows application, the above > navigation could have been done with 2 keystrokes instead of the 5 > that Emacs requires. This is something like 10-15 year old > technology. Just open Thunderbird and play with keys to navigate the > menus. You will get the idea. AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka menu accelerators) - see his library `menacc.el'. And AFAIK La Carte supports Lennart's addition. I have not tried this feature myself because I am not interested in using it. But AFAIK it is available (though not in vanilla Emacs, and only on Windows). FYI, it was unclear to me that you were talking about this particular kind of keyboard navigation of menus (menu accelerators). You seemed also/instead to be claiming that menu items were not associated with keyboard shortcuts, which is not true for the most part. But those keyboard shortcuts are something different from menu accelerators. > Do you still want to claim that Emacs is better than most apps for > access? Yep. And I said "discovery and access", and most of what I wrote had to do with _discovery_. Why? Because discovery is the strong point of menus, IMHO. And yes, IMO Emacs beats "most apps" in both respects. But I am no expert on all available apps - I could be wrong. ;-) Menu accelerators are one thing. There you might have a point, though I'm not sure how important such a feature is. Perhaps they could be added to Emacs more generally than just for Windows. I'm no help for that. However, I have a feeling (but again, I'm ignorant and unpracticed here) that using menus via accelerators on a regular basis is not the way to go. Menus are about organizing commands. They are helpful for discovery (and rediscovery of infrequently used commands). Regularly using menus (e.g. via accelerators) to access frequently used commands sounds like a bad habit - to me. But again, I do not really know what I'm talking about here. ;-) That sounds like just substituting an alternative set of key bindings, one that reflects the menu structure instead of another key organization. And while menu structure has a certain logic to it (which is why it can be helpful), that logic is not necessarily the best key-binding logic. It is a logic aimed at a particular purpose, IMO: discovery (and rediscovery): finding the needle in the haystack). In any case, when it comes to keyboard access of menus in general (not menu accelerators), Emacs is not lacking. Likewise when it comes to discovery of menu items. As I said, Emacs is OK out of the box (`tmm'), and it shines with a little extra help (e.g. La Carte, Icicles). There is really no reason that an Emacs user, new or old, should not use menus to discover Emacs functionality. And thereby learn keyboard shortcuts (they are indicated in the menus). _That's_ why I introduced menus into the discussion: because you were talking about discovery in Emacs without mentioning menus. > > The complaints here about weird Emacs keybindings are surprising to > > me, coming from you, Uday, who are familiar with Emacs. They sound > > like the superficial comments of a vi'er or someone unfamiliar with > > Emacs - someone who has the impression that one is _required_ to use > > `M-x a C-s' in order to search. It is trivial to use `M-x', trivial > > to use the menu, and trivial to bind a simpler key to something that > > you use often. > > I didn't "complain" about the weird key bindings. I gave the weird > bindings as an example to talk about the over-reliance of Emacs on key > bindings. That statement (claim) is all the talking you did about it, AFAICT. I think you did not give any argument or examples to support the claim of an "over-reliance" on key bindings. You did not even explain what you mean by that. You seemed to suggest that users are _required_ to use the default key sequences (whether seemingly weird ones such as `M-s a C-s' or not), or at least that they are _required_ to use keyboard keys (as opposed to menus or `M-x'). I countered that there is no such over-reliance. But you didn't make clear what you mean by that, so my rebuttal can only guess. If you mean that Emacs forces users to use keyboard key bindings, weird or not, then I disagree. And especially if you mean that Emacs forces users to use particular key bindings (the defaults). > > Try Icicles and La Carte. You can easily sort items on the fly and > > you can easily get to any item, no matter where it is in the menu > > tree. > > Can they match the 3-key stroke access (Alt p i) to "Isearch Files" in > the dired menu? AFAIK, they support Lennart's addition of `&' to menu items to support Windows keyboard navigation of menus. (I have not tested that.) So if Lennart has added menu accelerators for this menu item, and if those accelerators give you a key sequence as short as `Alt p i', then yes. Otherwise no. But that's not why I pointed you to Icicles and La Carte. You asked about _sorting_, so I mentioned Icicles, which lets you change sort orders on the fly, including to any sort orders you define yourself (which is simple). And I mentioned _direct access_ to a menu item anywhere in the tree. The entire path to a menu item is matchable, so you can match a deep item directly. And you can use multiple simple match patterns (regexps, substrings, fuzzy match,...) instead of using a single complex pattern. (You can of course also drill down menu by menu, just as you do with your Windows key navigation or with `tmm'. That is simply a special case of prefix matching.) I do not mention direct access to a menu item in order to promote the use of menus on a regular basis, as a substitute for the usual key bindings. I mention it in the context of discoverability. You can _very_ easily discover what menu items there are that involve searching files (or any other functionality) - regardless of what the menu organization might be. Just type `ear S-SPC file' to see all menu items that contain both `ear' (for "search") and `file', in either order. You can even filter to find all menu items that do _not_ match some pattern, or that match this but not that, where "this" and "that" are as complex as you like. And you can check the doc strings for any of the matching menu items - on the fly. If you cycle among some or all of them, the first line of the doc string is shown in the mode line of *Completions*. And you can see (in *Help*) the entire doc string for any of them (cycling or picking one or more directly). I emphasize discovery because to me that is where menus come into their own. If you want to use menus on a regular basis to access everything, then menu accelerators might be interesting to you. To me, menus are interesting because they _organize_ commands. And that organization can help you (a) find something and (b) learn what commands are available and (c) what keys they are bound to. I would not recommend that organization as the best keyboard access - e.g. menu accelerators, but I don't speak from practice here. > > > On second thought, perhaps the menus are not as disorganized as I > > > had imagined. I haven't yet begun to use them seriously. > > > > Please do. You will thank yourself. And you will no doubt file > > menu bugs or enhancement requests or provide patches for > > improvements. Welcome. > > I will be quite happy to use menus if the menu items have keystrokes > associated with them like on Windows & Java applications. Without > that, they are quite inefficient. > > I will check to see if La Carte and Icicles can help. Whether or not La Carte and Icicles can help you personally is one thing. The point in mentioning them here was, as I said, to show "that Emacs can easily give excellent menu access and provide excellent menu discovery. Out of the box it is OK, and it could easily be made even better." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 17:59 ` Drew Adams @ 2010-08-02 18:10 ` Lennart Borgman 2010-08-03 9:45 ` Jan Djärv 2010-08-03 2:09 ` Stephen J. Turnbull 2010-08-03 11:56 ` Uday S Reddy 2 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-02 18:10 UTC (permalink / raw) To: Drew Adams; +Cc: Uday S Reddy, emacs-devel On Mon, Aug 2, 2010 at 7:59 PM, Drew Adams <drew.adams@oracle.com> wrote: > > AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka > menu accelerators) - see his library `menacc.el'. Yes and we were also discussing adding this to GNU/Linux but it has not happened yet. A problem is of course that Emacs uses the Alt key by default as Emacs META key. (I have a patch for this for w32 as I have said before many times). There are some bugs in menuacc.el (it depends on tmm), but it works reasonably well. I have postponed further development on it until it is included in Emacs. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 18:10 ` Lennart Borgman @ 2010-08-03 9:45 ` Jan Djärv 2010-08-03 10:02 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-03 9:45 UTC (permalink / raw) To: Lennart Borgman; +Cc: emacs-devel 2010-08-02 20:10, Lennart Borgman skrev: > On Mon, Aug 2, 2010 at 7:59 PM, Drew Adams<drew.adams@oracle.com> wrote: >> >> AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka >> menu accelerators) - see his library `menacc.el'. > > > Yes and we were also discussing adding this to GNU/Linux but it has > not happened yet. > It would be a different implementation for native menus (probably not worth it), Lucid, Motif/Lesstif, Nextstep and Gtk+. Motif doesn't have a marker character, you must at the C level tell the widget in question which letter to use. The Emacs C level could perhaps translate a marker character to this. Gtk+ has _ as marker character, and Lucid currently has no keyboard handling in menus except arrow keys. I don't know what Nextstep uses. > A problem is of course that Emacs uses the Alt key by default as Emacs > META key. (I have a patch for this for w32 as I have said before many > times). > How do you handle buffer names (for the Buffer menu) that have the marker character in them (& I think for W32)? Wouldn't it be better to use a text property at the lisp level and let each platform specific code sort this out? Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 9:45 ` Jan Djärv @ 2010-08-03 10:02 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-03 10:02 UTC (permalink / raw) To: Jan Djärv; +Cc: emacs-devel On Tue, Aug 3, 2010 at 11:45 AM, Jan Djärv <jan.h.d@swipnet.se> wrote: > 2010-08-02 20:10, Lennart Borgman skrev: >> >> On Mon, Aug 2, 2010 at 7:59 PM, Drew Adams<drew.adams@oracle.com> wrote: >>> >>> AFAIK, Lennart added support for the MS Windows menu navigation >>> keystrokes (aka >>> menu accelerators) - see his library `menacc.el'. >> >> >> Yes and we were also discussing adding this to GNU/Linux but it has >> not happened yet. >> > > It would be a different implementation for native menus (probably not worth > it), Lucid, Motif/Lesstif, Nextstep and Gtk+. > Motif doesn't have a marker character, you must at the C level tell the > widget in question which letter to use. The Emacs C level could perhaps > translate a marker character to this. Gtk+ has _ as marker character, and > Lucid currently has no keyboard handling in menus except arrow keys. > I don't know what Nextstep uses. Thanks for the info. >> A problem is of course that Emacs uses the Alt key by default as Emacs >> META key. (I have a patch for this for w32 as I have said before many >> times). >> > > How do you handle buffer names (for the Buffer menu) that have the marker > character in them (& I think for W32)? Wouldn't it be better to use a text > property at the lisp level and let each platform specific code sort this > out? Yes I think so (or perhaps rather a cons ("menu-string" . pos)). But this would require some changes on a lower level and I do not want to do that until it is moved into Emacs. (I have too many patches.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-02 17:59 ` Drew Adams 2010-08-02 18:10 ` Lennart Borgman @ 2010-08-03 2:09 ` Stephen J. Turnbull 2010-08-03 11:56 ` Uday S Reddy 2 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-03 2:09 UTC (permalink / raw) To: Drew Adams; +Cc: 'Uday S Reddy', 'Lennart Borgman', emacs-devel Drew Adams writes: > However, I have a feeling (but again, I'm ignorant and unpracticed > here) that using menus via accelerators on a regular basis is not > the way to go. > > Menus are about organizing commands. They are helpful for discovery (and > rediscovery of infrequently used commands). Regularly using menus (e.g. via > accelerators) to access frequently used commands sounds like a bad habit - to > me. But again, I do not really know what I'm talking about here. ;-) To you, Emacs is a professional tool, like a mechanic's wrench or an eye surgeon's laser. The class of users Uday wants Emacs to serve better is quite different. They're not interested in a tool that allows them to do work well and efficiently (in a science of mechanics sense). They're interested in a tool that allows them to work without *ever* thinking about the tool. Ie, they are *not* the equivalent of the surgeon who after 25 years of practice almost never thinks about her fingers or the laser, just about the eye and where to cut and where to weld. They're the equivalent of the typical driver who after 10 hours of practice and passing the written test never thinks about the car again. There's nothing wrong with serving those users (what they're doing makes economic sense, conserving their most valuable resource, and unlike letting them drive, the odds are that there will be very few fatalities due to Emacs use while intoxicated), but I think it would be a terrible waste of Emacs developer time. They won't thank us. Not with words, and not with new Emacs features and bug fixes -- precisely because they're so busy *not* thinking about the tool. And they have no need for Emacs to serve them; any old thing will do for them, and there are plenty of old things out there. It's true that some of those users, given an Emacs comfortable for them *now*, will *eventually* trip over Emacs itself and catch the spirit. But many of that type of user will anyway. I had a 10-year exclusive user of vi, and a vim hacker, contact me the other day because there are some things that can't practically be done *in* vim, and he wants his *editor*, not a separate script, to do them. So he wants to try Emacs. It's not like the people with the skills we need and the hacker spirit that will make them produce more tools for us don't know where to find us. If Uday et amis *want* to serve those users, that's a different story -- more power to them. I'm sure they'll come up with interesting problems, and other Emacs hackers will want to help solve them. But they're going to have to do the scutwork and in the process discover the interesting problems. It's definitely possible to get started on the scutwork -- Uday has admitted several times that everything he wants can be done with current Emacs features, but it's inconvenient. They shouldn't let that inconvenience stop them. ;-) ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-02 17:59 ` Drew Adams 2010-08-02 18:10 ` Lennart Borgman 2010-08-03 2:09 ` Stephen J. Turnbull @ 2010-08-03 11:56 ` Uday S Reddy 2010-08-03 14:04 ` Juanma Barranquero ` (2 more replies) 2 siblings, 3 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-03 11:56 UTC (permalink / raw) To: Drew Adams; +Cc: 'Uday S Reddy', 'Lennart Borgman', emacs-devel Drew Adams writes: > > Do you still want to claim that Emacs is better than most apps for > > access? > > Yep. And I said "discovery and access", and most of what I wrote > had to do with _discovery_. Why? Because discovery is the strong > point of menus, IMHO. Access is also a strong point of menus. And, access is what this thread is about. So, I hope you won't mind if I ignore the issues of discovery, though I think they are interesting. > However, I have a feeling (but again, I'm ignorant and unpracticed > here) that using menus via accelerators on a regular basis is not > the way to go. > > Menus are about organizing commands. They are helpful for discovery > (and rediscovery of infrequently used commands). Regularly using > menus (e.g. via accelerators) to access frequently used commands > sounds like a bad habit - to me. But again, I do not really know > what I'm talking about here. ;-) Menu navigation by keys is actually the best form of interaction for me, having been an RSI sufferer, because both control keys and the mouse tax my fingers. somebody pointed out that the world out there uses menus a lot more than key bindings. But you jump the gun a bit here. Not everything is a "frequently used command". Menu access is useful for such operations that might be used occasionally. This is not about discovery. You might know there is a command and you remember where it is on the menus. But you don't know or care to remember its key binding. For such cases, menus are your friend. But I am glad that you are at least open to people that choose different modes of interaction from you. Many others here are rather closed minded, quite disappointingly. > That statement (claim) is all the talking you did about it, AFAICT. > I think you did not give any argument or examples to support the > claim of an "over-reliance" on key bindings. You did not even > explain what you mean by that. What I mean is that Emacs hasn't explored and developed other modes of interaction enough because of its belief that key bindings are enough. A long function name such as dired-do-search doesn't bother Emacs developers because they expect it to be used via its key binding. The fact that the menus don't have keyboard accelerators (which is 10-year old technology in Windows and Java - don't know about Linux) doesn't bother them because only idiots that can't remember key bindings will be using the menus anyway. So on. So, while Emacs used to be a leader in user interaction when it started, now it is a reluctant laggard that comes in kicking and screaming only after the whole world has already moved on with innovations. No wonder that the Emacs user base has been shrinking. (By the way, we in the Universities have known for a quite a while that Emacs has been losing ground. We don't need Google to tell us that. Some time around 2002 or 2003, we stopped recommend Emacs to students because we appeared to be total nut cases to them. Even if we recommended it, it didn't serve any purpose. They went home and used JDeveloper.) When new users come to using a tool like Emacs, their first mode of interaction is via the menubar, used with the mouse. The second might be to use keyboard accelerators. Only after they have settled down to using the tool would they begin to learn some of its key bindings. And, they will learn them selectively based on the frequency of use and what they care about. They almost definitely won't start by reading the manual. Whatever we might think about it, that is not the way the world works any more. They will look up the manual when they are stuck on something or want to learn about some particular feature. If the manual dwells on the fundamentals too much, it will get in the way. New users use Emacs in totally different ways to us. For instance, they almost never use the keyboard for find-file and save-file. They go to the menu. And, they use the mouse and cut-and-paste the way they are used to doing in other tools. If and when they decide to use the keyboard, they will try C-o and C-s (Windows key bindings), find that they don't work, and give up. As long as Emacs was the only game in town, we could do things which ever way we pleased. But now there is a larger world out there. And, Emacs has to fit in. The way to fit in is to make Emacs flexible and customizable so that the new users with completely different needs from us can do things their own way. If people like Xah Lee or Lennart have to fork Emacs in order to make it suitable to groups of users, then Emacs hasn't lived up to its challenge. Ideally, they should be able to publish a customization file, something along the lines of a .Xdefaults file, which the users can customize and load. I am hoping that this thread can move us in that direction. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 11:56 ` Uday S Reddy @ 2010-08-03 14:04 ` Juanma Barranquero 2010-08-03 15:02 ` Lennart Borgman 2010-08-05 8:39 ` Key bindings proposal Uday S Reddy 2010-08-03 15:54 ` Stephen J. Turnbull 2010-08-04 12:57 ` Stefan Monnier 2 siblings, 2 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-03 14:04 UTC (permalink / raw) To: Uday S Reddy; +Cc: Lennart Borgman, Drew Adams, emacs-devel On Tue, Aug 3, 2010 at 13:56, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > If people like Xah Lee or Lennart have to fork Emacs > in order to make it suitable to groups of users, then Emacs hasn't > lived up to its challenge. That's one possible interpretation. I don't think it is necessary to fork Emacs to make it appealing to Windows users, for example. Improvements can be made, of course. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 14:04 ` Juanma Barranquero @ 2010-08-03 15:02 ` Lennart Borgman 2010-08-03 15:16 ` Juanma Barranquero 2010-08-03 15:18 ` David Kastrup 2010-08-05 8:39 ` Key bindings proposal Uday S Reddy 1 sibling, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-03 15:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Uday S Reddy, Drew Adams, emacs-devel On Tue, Aug 3, 2010 at 4:04 PM, Juanma Barranquero <lekktu@gmail.com> wrote: > On Tue, Aug 3, 2010 at 13:56, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > >> If people like Xah Lee or Lennart have to fork Emacs >> in order to make it suitable to groups of users, then Emacs hasn't >> lived up to its challenge. > > That's one possible interpretation. I don't think it is necessary to > fork Emacs to make it appealing to Windows users, for example. > Improvements can be made, of course. My intention has not been to fork (though you seemed to believe that, Juanma). Instead I have made quite a lot of patches to show it is working. Then I thought the changes would be adopted (since there are quite a few users of my patched version, at least before). The problem is that it is very hard to get them accepted. Thousands of users using them without trouble does not seem enough. Another problem is that this kind of trouble has taken too much time. (Not only my time.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 15:02 ` Lennart Borgman @ 2010-08-03 15:16 ` Juanma Barranquero 2010-08-03 15:54 ` Lennart Borgman 2010-08-03 15:18 ` David Kastrup 1 sibling, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-03 15:16 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Drew Adams, emacs-devel On Tue, Aug 3, 2010 at 17:02, Lennart Borgman <lennart.borgman@gmail.com> wrote: > My intention has not been to fork (though you seemed to believe that, Juanma). No, I don't think that was your intention, though I think (and apparently I'm not the only one) that's what you've done. I dislike that, because it seems like a wasted effort. I'd rather see you working on standard Emacs. Seems unlikely. But anyway, my comment wasn't about your fork, just noting that it is possible to serve the needs of the Windows users without forking. Udday seemed to imply otherwise. > The problem is that it is very hard to get them accepted. Thousands of > users using them without trouble does not seem enough. We've rehashed this many times, most recently a few weeks ago. There are many reasons why the patches have not yet been accepted. "Thousand of users using them without trouble" is a good start, but not a conclusive argument per se. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 15:16 ` Juanma Barranquero @ 2010-08-03 15:54 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-03 15:54 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Uday S Reddy, Drew Adams, emacs-devel On Tue, Aug 3, 2010 at 5:16 PM, Juanma Barranquero <lekktu@gmail.com> wrote: > On Tue, Aug 3, 2010 at 17:02, Lennart Borgman <lennart.borgman@gmail.com> wrote: > >> My intention has not been to fork (though you seemed to believe that, Juanma). > > No, I don't think that was your intention, though I think (and > apparently I'm not the only one) that's what you've done. I dislike > that, because it seems like a wasted effort. I'd rather see you > working on standard Emacs. Seems unlikely. I am working on the standard Emacs. Though that does not always pass this list. (I want to keep the discussions to a minimum.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 15:02 ` Lennart Borgman 2010-08-03 15:16 ` Juanma Barranquero @ 2010-08-03 15:18 ` David Kastrup 2010-08-03 15:51 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: David Kastrup @ 2010-08-03 15:18 UTC (permalink / raw) To: emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > On Tue, Aug 3, 2010 at 4:04 PM, Juanma Barranquero <lekktu@gmail.com> wrote: >> On Tue, Aug 3, 2010 at 13:56, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: >> >>> If people like Xah Lee or Lennart have to fork Emacs >>> in order to make it suitable to groups of users, then Emacs hasn't >>> lived up to its challenge. >> >> That's one possible interpretation. I don't think it is necessary to >> fork Emacs to make it appealing to Windows users, for example. >> Improvements can be made, of course. > > My intention has not been to fork (though you seemed to believe that, > Juanma). Instead I have made quite a lot of patches to show it is > working. Then I thought the changes would be adopted (since there are > quite a few users of my patched version, at least before). > > The problem is that it is very hard to get them accepted. Thousands of > users using them without trouble does not seem enough. They are mostly orthogonal to code acceptance issues. If people tell you what problems keep your code from being mergeable, there is little point in gathering street support rather than addressing the issues. > Another problem is that this kind of trouble has taken too much time. > (Not only my time.) If you'd rather not have other Emacs developers' time wasted, there are a few thread topics you could killfile, as your participance is not likely improving the balance. -- David Kastrup ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 15:18 ` David Kastrup @ 2010-08-03 15:51 ` Lennart Borgman 2010-08-03 15:58 ` no forking relation (was: Key bindings proposal) Drew Adams 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-03 15:51 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel On Tue, Aug 3, 2010 at 5:18 PM, David Kastrup <dak@gnu.org> wrote: >> >> The problem is that it is very hard to get them accepted. Thousands of >> users using them without trouble does not seem enough. > > They are mostly orthogonal to code acceptance issues. If people tell > you what problems keep your code from being mergeable, there is little > point in gathering street support rather than addressing the issues. So you say that if people like the way the patches work and developers here say it is not worth the efforts then I should ... do what? >> Another problem is that this kind of trouble has taken too much time. >> (Not only my time.) > > If you'd rather not have other Emacs developers' time wasted, there are > a few thread topics you could killfile, as your participance is not > likely improving the balance. I think it is. It is ok if you do not like it, but please do not pretend that you know better. If you think I am being unkind or that my arguments really are wrong then I am glad if you tell me. ^ permalink raw reply [flat|nested] 277+ messages in thread
* no forking relation (was: Key bindings proposal) 2010-08-03 15:51 ` Lennart Borgman @ 2010-08-03 15:58 ` Drew Adams 0 siblings, 0 replies; 277+ messages in thread From: Drew Adams @ 2010-08-03 15:58 UTC (permalink / raw) To: 'Lennart Borgman', 'David Kastrup'; +Cc: emacs-devel > I should ... do what? You should start a new thread. ;-) You guys are no longer discussing any key-bindings proposal. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 14:04 ` Juanma Barranquero 2010-08-03 15:02 ` Lennart Borgman @ 2010-08-05 8:39 ` Uday S Reddy 2010-08-05 9:22 ` Juanma Barranquero 1 sibling, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 8:39 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Uday S Reddy, Lennart Borgman, Drew Adams, emacs-devel Juanma Barranquero writes: > That's one possible interpretation. I don't think it is necessary to > fork Emacs to make it appealing to Windows users, for example. > Improvements can be made, of course. In that case, I would like to understand at least the key binding aspects of this divergence. How do you think Lennart could have changed the key bindings for the needs of W32 users? And, Lennart, if you can follow up please. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 8:39 ` Key bindings proposal Uday S Reddy @ 2010-08-05 9:22 ` Juanma Barranquero 2010-08-05 11:00 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-05 9:22 UTC (permalink / raw) To: Uday S Reddy; +Cc: Lennart Borgman, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 10:39, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > In that case, I would like to understand at least the key binding > aspects of this divergence. I don't think they are the main reason behind the fork, but I could be wrong. > How do you think Lennart could have > changed the key bindings for the needs of W32 users? What are the specific key bindings needs for W32 users that standard Emacs does not support? We have CUA mode, and it's not hard to load a package to rebind whatever is necessary. AFAIK, Lennart has code to make using the Alt key as alt easier, but I'd like to know what are the specific troubles that require so, and how necessary it really is. Also, note that I've said "to make it appealing to Windows users", not "to make it a clone of every Windows application". Of course if you need that *everything* works in Emacs *exactly* as in Notepad, then use Notepad. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 9:22 ` Juanma Barranquero @ 2010-08-05 11:00 ` Lennart Borgman 2010-08-05 11:24 ` Juanma Barranquero 2010-08-05 13:10 ` Uday S Reddy 0 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 11:00 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Uday S Reddy, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 11:22 AM, Juanma Barranquero <lekktu@gmail.com> wrote: > On Thu, Aug 5, 2010 at 10:39, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > >> In that case, I would like to understand at least the key binding >> aspects of this divergence. > > I don't think they are the main reason behind the fork, but I could be wrong. Yes, it is. There were three main things I wanted to work: - Using the windows keys (or other key, for example shift-lock) as Emacs META so that Alt key could be freed. - Getting sticky keys (accessibility) to work. - Getting menus to work. The events where handled in wrong order, but I think it is hard to notice this unless you use the Alt keys to acces the menus. (BTW Firefox had a similar bug.) Later I have put some other patches there too. And once again: I do not consider it a fork. Some people have indeed asked me to make it a fork but I have stayed here, hoping things should change. In the beginning some of my libraries came only with my patched version of Emacs. I did not think that was good so I instead created nXhtml where nearly all my librarries now are. (The name is unfortunate since there are quite a few things that is not about XHTML or web development, but it is too much work to change it.) This can be used everywhere where Emacs can be used (but requires often a newer version). >> How do you think Lennart could have >> changed the key bindings for the needs of W32 users? > > What are the specific key bindings needs for W32 users that standard > Emacs does not support? We have CUA mode, and it's not hard to load a > package to rebind whatever is necessary. AFAIK, Lennart has code to > make using the Alt key as alt easier, but I'd like to know what are > the specific troubles that require so, and how necessary it really is. Please excuse me, Juanma, but I find this a bit annoying. I have explained this several times before here. And I also find it a bit hopeful. Using the right and left windows keys as Emacs META requires that a low level keyboard hook is used. Just read the documentation at MS to see that. (I have given link to it previously.) This is actually a rather simple change. The other two changes above are more complicated. > Also, note that I've said "to make it appealing to Windows users", not > "to make it a clone of every Windows application". Of course if you > need that *everything* works in Emacs *exactly* as in Notepad, then > use Notepad. I would be glad if you (and others) did not try to make other people look silly. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 11:00 ` Lennart Borgman @ 2010-08-05 11:24 ` Juanma Barranquero 2010-08-05 12:16 ` Lennart Borgman 2010-08-05 13:10 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-05 11:24 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 13:00, Lennart Borgman <lennart.borgman@gmail.com> wrote: > Yes, it is. I stand corrected. > There were three main things I wanted to work: > - Using the windows keys (or other key, for example shift-lock) as > Emacs META so that Alt key could be freed. Why is that *necessary* for Windows users? > - Getting sticky keys (accessibility) to work. Have you filed a bug report about the specific problems in standard Emacs vs. sticky keys? > - Getting menus to work. The events where handled in wrong order, but > I think it is hard to notice this unless you use the Alt keys to acces > the menus. You discussed this on emacs-devel, but it was a long time ago, so I don't remember which were the specific problems included in "getting menus to work". Sorry. > And once again: I do not consider it a fork. Some people have indeed > asked me to make it a fork but I have stayed here, hoping things > should change. It's a matter of definition. > Please excuse me, Juanma, but I find this a bit annoying. I have > explained this several times before here. There's a difference between "I would like for Emacs to work in such-and-such way", and "Windows users do need such-and-such feature to feel comfortable with Emacs". Obviously all of your changes fall into the first category, but I'm not so sure about the second one. I know of a few seasoned Windows users which apparently do not need them. So stop trying to conflate both categories. And, I'd like to note that I was answering Uday about the second category; I have no saying in what *you* prefer or need for your Emacs. > And I also find it a bit hopeful. Using the right and left windows > keys as Emacs META requires that a low level keyboard hook is used. > Just read the documentation at MS to see that. (I have given link to > it previously.) Yes, but you need to use the Windows key as meta *because* you want to use Alt for alt, and you want to use Alt for alt because some menu troubles, isn't so? And the question is, are really these troubles so big? (And if they are, shouldn't you work to get the keyboard handling patch into Emacs... and then we're back to the same old discussion). > I would be glad if you (and others) did not try to make other people look silly. I would be glad if you (and others) did not try to make Emacs developers look like old farts that do not accept your changes out of sheer complacency or negligence. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 11:24 ` Juanma Barranquero @ 2010-08-05 12:16 ` Lennart Borgman 2010-08-05 13:59 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 12:16 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Uday S Reddy, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 1:24 PM, Juanma Barranquero <lekktu@gmail.com> wrote: > >> There were three main things I wanted to work: >> - Using the windows keys (or other key, for example shift-lock) as >> Emacs META so that Alt key could be freed. > > Why is that *necessary* for Windows users? Oh, I forget META-TAB too, which is used heavily in Emacs. >> - Getting sticky keys (accessibility) to work. > > Have you filed a bug report about the specific problems in standard > Emacs vs. sticky keys? We have discussed it on this list. >> And once again: I do not consider it a fork. Some people have indeed >> asked me to make it a fork but I have stayed here, hoping things >> should change. > > It's a matter of definition. Rather bashing. >> Please excuse me, Juanma, but I find this a bit annoying. I have >> explained this several times before here. > > There's a difference between "I would like for Emacs to work in > such-and-such way", and "Windows users do need such-and-such feature > to feel comfortable with Emacs". Obviously all of your changes fall > into the first category, but I'm not so sure about the second one. I > know of a few seasoned Windows users which apparently do not need > them. So stop trying to conflate both categories. Have I done that? When? Perhaps you misunderstood something? >> And I also find it a bit hopeful. Using the right and left windows >> keys as Emacs META requires that a low level keyboard hook is used. >> Just read the documentation at MS to see that. (I have given link to >> it previously.) > > Yes, but you need to use the Windows key as meta *because* you want to > use Alt for alt, and you want to use Alt for alt because some menu > troubles, isn't so? And the question is, are really these troubles so > big? Yes, I thnink so. There is also the trouble with META-TAB. (And if they are, shouldn't you work to get the keyboard > handling patch into Emacs... and then we're back to the same old > discussion). They are there in my patched version. Just grab them. >> I would be glad if you (and others) did not try to make other people look silly. > > I would be glad if you (and others) did not try to make Emacs > developers look like old farts that do not accept your changes out of > sheer complacency or negligence. I hope I have not done that. (But I am not responsible for your answers.) I know time is a big issue, but I have spent a lot of time on this. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 12:16 ` Lennart Borgman @ 2010-08-05 13:59 ` Uday S Reddy 2010-08-05 14:07 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 13:59 UTC (permalink / raw) To: Lennart Borgman; +Cc: Juanma Barranquero, emacs-devel, Drew Adams, Uday S Reddy Lennart Borgman writes: > > > (And if they are, shouldn't you work to get the keyboard > > handling patch into Emacs... and then we're back to the same old > > discussion). > > They are there in my patched version. Just grab them. I am beginning to see why things haven't been working. It would be quite hard for the Emacs team to just take your patched version and figure out what is what. They would need a precise patch for each feature. After you give it to them, they will still have quite a bit work to do: to test it, document it, and to figure out if there is any interference with other stuff etc. I understand that you have spent a lot of time in doing the coding. Can't you spend a bit more in getting to the Emacs team in a usable form? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:59 ` Uday S Reddy @ 2010-08-05 14:07 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 14:07 UTC (permalink / raw) To: Uday S Reddy; +Cc: Juanma Barranquero, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 3:59 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Lennart Borgman writes: > >> >> > (And if they are, shouldn't you work to get the keyboard >> > handling patch into Emacs... and then we're back to the same old >> > discussion). >> >> They are there in my patched version. Just grab them. > > I am beginning to see why things haven't been working. It would be > quite hard for the Emacs team to just take your patched version and > figure out what is what. They would need a precise patch for each > feature. After you give it to them, they will still have quite a bit > work to do: to test it, document it, and to figure out if there is any > interference with other stuff etc. Unfortunately sending a precise patch is not enough. The patch can sometimes be complicated (as for emacsclient) and we need time to minimize that work. (And because of a lot of misunderstanding we have not been able to move forward there.) Other times it is the feature itself that has not been thought of as important enough (as in the case of beeing able to move Emacs META or accessibility). I would be glad if we could move forward though. A problem is of course that I have forgotten the details now since the code was written several years ago. And that I have less time. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 11:00 ` Lennart Borgman 2010-08-05 11:24 ` Juanma Barranquero @ 2010-08-05 13:10 ` Uday S Reddy 2010-08-05 13:13 ` Juanma Barranquero ` (2 more replies) 1 sibling, 3 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 13:10 UTC (permalink / raw) To: Lennart Borgman; +Cc: Juanma Barranquero, emacs-devel, Drew Adams, Uday S Reddy Lennart Borgman writes: > Yes, it is. > > There were three main things I wanted to work: > - Using the windows keys (or other key, for example shift-lock) as > Emacs META so that Alt key could be freed. > - Getting sticky keys (accessibility) to work. > - Getting menus to work. The events where handled in wrong order, but > I think it is hard to notice this unless you use the Alt keys to acces > the menus. (BTW Firefox had a similar bug.) > > Later I have put some other patches there too. I agree with Juanma that these things do not seem to warrant a fork. These are general features that Gnu Emacs can and should have for supporting Windows. There is no incompatibility. (I don't know if you were around then, but the original development of Emacs for Windows also happened in a sort-of fork, called NT Emacs. That has now been integrated with Gnu Emacs.) > And once again: I do not consider it a fork. Some people have indeed > asked me to make it a fork but I have stayed here, hoping things > should change. I don't know the history, but I would encourage you to stay on and do whatever is necessary to get the changes accepted. There can be quite a bit of work involved in getting there, to document, test, and fit things into the existing structure. I do some of such work for VM, trying to integrate the add-ons that have been contributed over the years. It does involve quite a bit of work even when the packages are quite straightforward. There is quite a bit of distance between a prototype (what is often contributed) and a finished product (what goes into the system). > And I also find it a bit hopeful. Using the right and left windows > keys as Emacs META requires that a low level keyboard hook is used. > Just read the documentation at MS to see that. (I have given link to > it previously.) Like Juanma, I also don't know why it is essential to use the Windows key as meta. I am able to use Alt as the meta key in Emacs and also get Alt+TAB to switch W32 windows. I can momentarily depress Alt to activate the menubar. > > Also, note that I've said "to make it appealing to Windows users", not > > "to make it a clone of every Windows application". Of course if you > > need that *everything* works in Emacs *exactly* as in Notepad, then > > use Notepad. > > I would be glad if you (and others) did not try to make other people look > silly. Indeed, it would be good to drop the frequent references to Notepad. As far as I know, the Notepad-users and Emacs-users are mutually exclusive. So, Notepad is not at issue. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:10 ` Uday S Reddy @ 2010-08-05 13:13 ` Juanma Barranquero 2010-08-05 13:22 ` Lennart Borgman 2010-08-05 20:33 ` Óscar Fuentes 2 siblings, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-05 13:13 UTC (permalink / raw) To: Uday S Reddy; +Cc: Lennart Borgman, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 15:10, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > As far as I know, the Notepad-users and Emacs-users are mutually exclusive. Not so. I use Notepad quite frequently (though, to be fair, lately I use Notepad2 instead). Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:10 ` Uday S Reddy 2010-08-05 13:13 ` Juanma Barranquero @ 2010-08-05 13:22 ` Lennart Borgman 2010-08-05 13:48 ` Uday S Reddy 2010-08-06 0:50 ` Jason Rumney 2010-08-05 20:33 ` Óscar Fuentes 2 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 13:22 UTC (permalink / raw) To: Uday S Reddy; +Cc: Juanma Barranquero, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 3:10 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > > I agree with Juanma that these things do not seem to warrant a fork. I do not know if that is Juanmas position but I agree with you. > I don't know the history, but I would encourage you to stay on and do > whatever is necessary to get the changes accepted. There can be quite > a bit of work involved in getting there, to document, test, and fit > things into the existing structure. Those patches have been used quite a long time now and I have had no complaints. (But part of it could be written better, perhaps.) Unfortunately I do not have that much time to spend on this now. (I have spent quite a lot of time on nXhtml. Parts of it are complicated.) > Like Juanma, I also don't know why it is essential to use the Windows > key as meta. I am able to use Alt as the meta key in Emacs and also > get Alt+TAB to switch W32 windows. You can not override Alt-TAB so that you can use it to switch w32 windows is because ms has decided it to work that way. However in Emacs META-TAB is frequently used for completion functions. That can not work on w32 (and with some other window managers if I understood it correctly). >I can momentarily depress Alt to activate the menubar. Can you? Please give more details. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:22 ` Lennart Borgman @ 2010-08-05 13:48 ` Uday S Reddy 2010-08-05 14:01 ` Lennart Borgman 2010-08-06 0:50 ` Jason Rumney 1 sibling, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 13:48 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel, Drew Adams, Juanma Barranquero Lennart Borgman writes: > You can not override Alt-TAB so that you can use it to switch w32 > windows is because ms has decided it to work that way. > > However in Emacs META-TAB is frequently used for completion functions. > That can not work on w32 (and with some other window managers if I > understood it correctly). Indeed, I have gotten used to doing ESC-TAB for completion, which is a bit of a chore I admit. Ok, so, it is quite useful to remap the Windows key but it doesn't seem criticial. > >I can momentarily depress Alt to activate the menubar. > > Can you? Please give more details. I was trying to recall if I did anything special to get it but couldn't. So, I looked up O'Reilly's Windows XP in a Nutshell. It says under "Keyboard Accelerators", "In any any window that has a menu, press the Alt key or the F10 key to active the manu bar, and use the cursor keys to move around. Press Enter to activate the currently selected item or Esc to cancel." Then it goes on to talk about using Alt+letter to go directly to a particular menu. What I can't do in Emacs is the latter. I can't press Alt+F to go the File menu. In Firefox/Thunderbird, I can. To me personally, that is not a big price to pay. You might think otherwise. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:48 ` Uday S Reddy @ 2010-08-05 14:01 ` Lennart Borgman 2010-08-05 14:01 ` Lennart Borgman [not found] ` <19546.51009.703000.960158@gargle.gargle.HOWL> 0 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 14:01 UTC (permalink / raw) To: Uday S Reddy; +Cc: Juanma Barranquero, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 3:48 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Lennart Borgman writes: > >> You can not override Alt-TAB so that you can use it to switch w32 >> windows is because ms has decided it to work that way. >> >> However in Emacs META-TAB is frequently used for completion functions. >> That can not work on w32 (and with some other window managers if I >> understood it correctly). > > Indeed, I have gotten used to doing ESC-TAB for completion, which is a > bit of a chore I admit. Ok, so, it is quite useful to remap the > Windows key but it doesn't seem criticial. You can not use ESC-TAB if you are using Viper. (Which I and many others do.) So it is critical. >> >I can momentarily depress Alt to activate the menubar. >> >> Can you? Please give more details. > > I was trying to recall if I did anything special to get it but > couldn't. So, I looked up O'Reilly's Windows XP in a Nutshell. It > says under "Keyboard Accelerators", > > "In any any window that has a menu, press the Alt key or the F10 key > to active the manu bar, and use the cursor keys to move around. Press > Enter to activate the currently selected item or Esc to cancel." > > Then it goes on to talk about using Alt+letter to go directly to > a particular menu. > > What I can't do in Emacs is the latter. I can't press Alt+F to go the > File menu. In Firefox/Thunderbird, I can. To me personally, that is > not a big price to pay. You might think otherwise. I can either press Alt and then F to open the file menu. Can you? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 14:01 ` Lennart Borgman @ 2010-08-05 14:01 ` Lennart Borgman 2010-08-05 17:08 ` Uday S Reddy [not found] ` <19546.51009.703000.960158@gargle.gargle.HOWL> 1 sibling, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 14:01 UTC (permalink / raw) To: Uday S Reddy; +Cc: Juanma Barranquero, Drew Adams, emacs-devel On Thu, Aug 5, 2010 at 4:01 PM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > I can either press Alt and then F to open the file menu. Can you? => I can't either press Alt and then F to open the file menu. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 14:01 ` Lennart Borgman @ 2010-08-05 17:08 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 17:08 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel, Drew Adams, Juanma Barranquero Lennart Borgman writes: > > > I can either press Alt and then F to open the file menu. Can you? > > => I can't either press Alt and then F to open the file menu. After discussing this with Lennart, it turns out that he uses a feature called "sticky keys" in Windows which allows him to type `Alt' and `f' separately to send the Alt+F (or Alt-f) event. Emacs is currently not interpreting this type of an event (except by mapping it to Meta-f via the w32-alt-is-meta setting). But the interpretation needed for a Windows user is to activate the menubar item that begins with "f" (e.g., the File menu). Pressing `Alt' and `f' separately doesn't work for Lennart because he uses sticky keys. I hope that clarifies the conflusion. Lennart needs the Alt+character events interpreted by Emacs to access the menus via keyboard. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <19546.51009.703000.960158@gargle.gargle.HOWL>]
* Re: Key bindings proposal [not found] ` <19546.51009.703000.960158@gargle.gargle.HOWL> @ 2010-08-05 14:18 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 14:18 UTC (permalink / raw) To: Uday S Reddy, Emacs-Devel devel On Thu, Aug 5, 2010 at 4:14 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Lennart Borgman writes: > >> I can either press Alt and then F to open the file menu. Can you? > > Yes. That is what I was talking about. Alt+F doesn't work (because > Emacs intercepts the event), but Alt and F pressed separately works. That does not work for me (with the unpatched version). Maybe it is because I am using sticky keys. (I think it is very essential that sticky keys should work.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:22 ` Lennart Borgman 2010-08-05 13:48 ` Uday S Reddy @ 2010-08-06 0:50 ` Jason Rumney 2010-08-06 1:28 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-06 0:50 UTC (permalink / raw) To: emacs-devel On 05/08/2010 21:22, Lennart Borgman wrote: > You can not override Alt-TAB so that you can use it to switch w32 > windows is because ms has decided it to work that way. > When I search the web for information about Low Level Keyboard Hooks, about 80% of the results are about using them to override Alt-TAB behaviour. I find it curious that you claim this cannot be done as part of your justification for moving Meta from Alt to the Windows key, when your solution involves what would be the solution to the Alt-TAB problem. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 0:50 ` Jason Rumney @ 2010-08-06 1:28 ` Lennart Borgman 2010-08-06 1:35 ` Jason Rumney 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 1:28 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 2:50 AM, Jason Rumney <jasonr@gnu.org> wrote: > On 05/08/2010 21:22, Lennart Borgman wrote: > >> You can not override Alt-TAB so that you can use it to switch w32 >> windows is because ms has decided it to work that way. >> > > When I search the web for information about Low Level Keyboard Hooks, about > 80% of the results are about using them to override Alt-TAB behaviour. I > find it curious that you claim this cannot be done as part of your > justification for moving Meta from Alt to the Windows key, when your > solution involves what would be the solution to the Alt-TAB problem. That is interesting. Something might have changed since I did this - after all some years has passed and MS are now and then changing these things. Can you please give some links? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 1:28 ` Lennart Borgman @ 2010-08-06 1:35 ` Jason Rumney 2010-08-06 1:41 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-06 1:35 UTC (permalink / raw) To: Lennart Borgman; +Cc: emacs-devel On 06/08/2010 09:28, Lennart Borgman wrote: > On Fri, Aug 6, 2010 at 2:50 AM, Jason Rumney<jasonr@gnu.org> wrote: > >> When I search the web for information about Low Level Keyboard Hooks, about >> 80% of the results are about using them to override Alt-TAB behaviour. I >> find it curious that you claim this cannot be done as part of your >> justification for moving Meta from Alt to the Windows key, when your >> solution involves what would be the solution to the Alt-TAB problem. >> > That is interesting. Something might have changed since I did this - > after all some years has passed and MS are now and then changing these > things. Can you please give some links?\ > http://support.microsoft.com/kb/226359 http://msdn.microsoft.com/en-us/magazine/cc302329.aspx http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 1:35 ` Jason Rumney @ 2010-08-06 1:41 ` Lennart Borgman 2010-08-06 1:58 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 1:41 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote: > On 06/08/2010 09:28, Lennart Borgman wrote: >> >> On Fri, Aug 6, 2010 at 2:50 AM, Jason Rumney<jasonr@gnu.org> wrote: >> >>> >>> When I search the web for information about Low Level Keyboard Hooks, >>> about >>> 80% of the results are about using them to override Alt-TAB behaviour. I >>> find it curious that you claim this cannot be done as part of your >>> justification for moving Meta from Alt to the Windows key, when your >>> solution involves what would be the solution to the Alt-TAB problem. >>> >> >> That is interesting. Something might have changed since I did this - >> after all some years has passed and MS are now and then changing these >> things. Can you please give some links?\ >> > > http://support.microsoft.com/kb/226359 > http://msdn.microsoft.com/en-us/magazine/cc302329.aspx > http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke Thanks. I will test the last one and see. That is a recent article. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 1:41 ` Lennart Borgman @ 2010-08-06 1:58 ` Lennart Borgman 2010-08-06 2:16 ` Óscar Fuentes 2010-08-06 2:34 ` Lennart Borgman 0 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 1:58 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote: >> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke > > > Thanks. I will test the last one and see. That is a recent article. This article code uses HasAltModifier to test for Alt in the low level keyboard hook. It seems to be some c++ variant. What can I do instead in Emacs? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 1:58 ` Lennart Borgman @ 2010-08-06 2:16 ` Óscar Fuentes 2010-08-06 2:38 ` Lennart Borgman 2010-08-06 2:34 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: Óscar Fuentes @ 2010-08-06 2:16 UTC (permalink / raw) To: emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman > <lennart.borgman@gmail.com> wrote: >> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote: > >>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke >> >> >> Thanks. I will test the last one and see. That is a recent article. > > This article code uses HasAltModifier to test for Alt in the low level > keyboard hook. It seems to be some c++ variant. What can I do instead > in Emacs? HasAltModifier is defined right there at the bottom, on the same code example. If you want C examples for any OS version down to Windows 95 and NT 3.51, the first link on Jason's list shows the way. BTW, intercepting Alt+Tab, Ctrl+Esc and even Ctrl-Alt-Del is a common requirement. Have you ever seen a kiosk-mode application? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 2:16 ` Óscar Fuentes @ 2010-08-06 2:38 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 2:38 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Fri, Aug 6, 2010 at 4:16 AM, Óscar Fuentes <ofv@wanadoo.es> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman >> <lennart.borgman@gmail.com> wrote: >>> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote: >> >>>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke >>> >>> >>> Thanks. I will test the last one and see. That is a recent article. >> >> This article code uses HasAltModifier to test for Alt in the low level >> keyboard hook. It seems to be some c++ variant. What can I do instead >> in Emacs? > > HasAltModifier is defined right there at the bottom, on the same code > example. If you want C examples for any OS version down to Windows 95 > and NT 3.51, the first link on Jason's list shows the way. Ah, thanks. I will never learn to read C. > BTW, intercepting Alt+Tab, Ctrl+Esc and even Ctrl-Alt-Del is a common > requirement. Have you ever seen a kiosk-mode application? Yes, but it looks like maybe for those you instead toggle CoolSwitch in the registry: http://stackoverflow.com/questions/2970683/disable-windows-and-alt-tab-key-combos But I am not sure, see my prev post. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 1:58 ` Lennart Borgman 2010-08-06 2:16 ` Óscar Fuentes @ 2010-08-06 2:34 ` Lennart Borgman 2010-08-06 2:55 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 2:34 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 3:58 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman > <lennart.borgman@gmail.com> wrote: >> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote: > >>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke >> >> >> Thanks. I will test the last one and see. That is a recent article. > > This article code uses HasAltModifier to test for Alt in the low level > keyboard hook. It seems to be some c++ variant. What can I do instead > in Emacs? I tested with code similar to this: case VK_TAB: /* Tip from Jason 2010-08-05 regarding suppressing Alt-TAB in the hook: http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke For the computer user instead, using registry setting of [HKEY_CURRENT_USER\Control Panel\Desktop] "CoolSwitch"="0" http://stackoverflow.com/questions/2970683/disable-windows-and-alt-tab-key-combos */ { //if (HasAltModifier(pkbdllhook->flags)) if ((pkbdllhook->flags & LLKHF_ALTDOWN) != 0) { // return new IntPtr(1); return TRUE; } } It surprised me in several ways: - It actually suppressed Alt-TAB, but for ALL RUNNING PROGRAMS! (That make me think of that Eli once said that the low level keyboard hook would affect all programs. It normally does not so there is something strange here.) So the code above can not be used in Emacs. Does someone has any idea of what is wrong here? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 2:34 ` Lennart Borgman @ 2010-08-06 2:55 ` Lennart Borgman 2010-08-06 3:11 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 2:55 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 4:34 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Fri, Aug 6, 2010 at 3:58 AM, Lennart Borgman > <lennart.borgman@gmail.com> wrote: >> On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman >> <lennart.borgman@gmail.com> wrote: >>> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote: >> >>>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke >>> >>> >>> Thanks. I will test the last one and see. That is a recent article. >> >> This article code uses HasAltModifier to test for Alt in the low level >> keyboard hook. It seems to be some c++ variant. What can I do instead >> in Emacs? > > I tested with code similar to this: > > case VK_TAB: > /* > Tip from Jason 2010-08-05 regarding suppressing > Alt-TAB in the hook: > > http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke > > For the computer user instead, using registry setting of > [HKEY_CURRENT_USER\Control Panel\Desktop] > "CoolSwitch"="0" > > http://stackoverflow.com/questions/2970683/disable-windows-and-alt-tab-key-combos > */ > > { > //if (HasAltModifier(pkbdllhook->flags)) > if ((pkbdllhook->flags & LLKHF_ALTDOWN) != 0) > { > // return new IntPtr(1); > return TRUE; Removing "return TRUE" and instead doing bHandle = NILP(Vw32_pass_alt_to_system); break; made this work as Jason suggested. I.e. it allows the use of Alt-TAB as M-TAB on w32. (The back draw is that you then can not switch to other applications using Alt-TAB when in Emacs.) Other application will still respond the normal way to Alt-TAB. I must say again I am surprised that this worked. I wonder though is this is documented behavior. If it is, then maybe it is time to include the low level keyboard hook in Emacs? (I myself does not like this behavior, but others might want it.) > } > } > > It surprised me in several ways: > > - It actually suppressed Alt-TAB, but for ALL RUNNING PROGRAMS! (That > make me think of that Eli once said that the low level keyboard hook > would affect all programs. It normally does not so there is something > strange here.) > > So the code above can not be used in Emacs. Does someone has any idea > of what is wrong here? > ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 2:55 ` Lennart Borgman @ 2010-08-06 3:11 ` Lennart Borgman 2010-08-06 6:05 ` Jason Rumney 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 3:11 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > > made this work as Jason suggested. I.e. it allows the use of Alt-TAB > as M-TAB on w32. (The back draw is that you then can not switch to > other applications using Alt-TAB when in Emacs.) > > Other application will still respond the normal way to Alt-TAB. If this should be usable at all then there must be a way to get into the normal Alt-TAB behavior from withing Emacs. A possible solution is maybe to treat Alt-Shift-Tab as usual. Is there anyone who remember how to catch SHIFT in a low level keyboard hook? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 3:11 ` Lennart Borgman @ 2010-08-06 6:05 ` Jason Rumney 2010-08-06 15:07 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-06 6:05 UTC (permalink / raw) To: Lennart Borgman; +Cc: emacs-devel On 06/08/2010 11:11, Lennart Borgman wrote: > On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman > <lennart.borgman@gmail.com> wrote: > >> made this work as Jason suggested. I.e. it allows the use of Alt-TAB >> as M-TAB on w32. (The back draw is that you then can not switch to >> other applications using Alt-TAB when in Emacs.) >> >> Other application will still respond the normal way to Alt-TAB. >> > > If this should be usable at all then there must be a way to get into > the normal Alt-TAB behavior from withing Emacs. > Does the following still work after Alt-TAB is overridden? (w32-send-sys-command #xf040) This can be bound to whatever event the user wants. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 6:05 ` Jason Rumney @ 2010-08-06 15:07 ` Lennart Borgman 2010-08-06 15:29 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 15:07 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 8:05 AM, Jason Rumney <jasonr@gnu.org> wrote: > On 06/08/2010 11:11, Lennart Borgman wrote: >> >> On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman >> <lennart.borgman@gmail.com> wrote: >> >>> >>> made this work as Jason suggested. I.e. it allows the use of Alt-TAB >>> as M-TAB on w32. (The back draw is that you then can not switch to >>> other applications using Alt-TAB when in Emacs.) >>> >>> Other application will still respond the normal way to Alt-TAB. >>> >> >> If this should be usable at all then there must be a way to get into >> the normal Alt-TAB behavior from withing Emacs. >> > > Does the following still work after Alt-TAB is overridden? > > (w32-send-sys-command #xf040) > > This can be bound to whatever event the user wants. Yes, it minimizes Emacs. Unfortunately it still seems to have focus so you can not use Alt-TAB after that either. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 15:07 ` Lennart Borgman @ 2010-08-06 15:29 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 15:29 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 6, 2010 at 5:07 PM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Fri, Aug 6, 2010 at 8:05 AM, Jason Rumney <jasonr@gnu.org> wrote: >> On 06/08/2010 11:11, Lennart Borgman wrote: >>> >>> On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman >>> <lennart.borgman@gmail.com> wrote: >>> >>>> >>>> made this work as Jason suggested. I.e. it allows the use of Alt-TAB >>>> as M-TAB on w32. (The back draw is that you then can not switch to >>>> other applications using Alt-TAB when in Emacs.) >>>> >>>> Other application will still respond the normal way to Alt-TAB. >>>> >>> >>> If this should be usable at all then there must be a way to get into >>> the normal Alt-TAB behavior from withing Emacs. >>> >> >> Does the following still work after Alt-TAB is overridden? >> >> (w32-send-sys-command #xf040) >> >> This can be bound to whatever event the user wants. > > Yes, it minimizes Emacs. Unfortunately it still seems to have focus so > you can not use Alt-TAB after that either. > Incorrect. The frame is not minimized, but put at the bottom of the w32 window list. It still has input focus though (both mouse and keyboard). Using #xf020 (minimize) works ok. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 13:10 ` Uday S Reddy 2010-08-05 13:13 ` Juanma Barranquero 2010-08-05 13:22 ` Lennart Borgman @ 2010-08-05 20:33 ` Óscar Fuentes 2010-08-05 21:26 ` Uday S Reddy 2010-08-06 3:21 ` Stephen J. Turnbull 2 siblings, 2 replies; 277+ messages in thread From: Óscar Fuentes @ 2010-08-05 20:33 UTC (permalink / raw) To: emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: [snip] > Like Juanma, I also don't know why it is essential to use the Windows > key as meta. +1. But maybe I'm missing something. > I am able to use Alt as the meta key in Emacs and also get Alt+TAB to > switch W32 windows. Yep. > I can momentarily depress Alt to activate the menubar. Nope. Have you some setting in .emacs for that? It doesn't work with emacs -Q (nor I'll appreciate that behavior.) [snip] ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 20:33 ` Óscar Fuentes @ 2010-08-05 21:26 ` Uday S Reddy 2010-08-05 22:55 ` Lennart Borgman 2010-08-06 0:05 ` Drew Adams 2010-08-06 3:21 ` Stephen J. Turnbull 1 sibling, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 21:26 UTC (permalink / raw) To: emacs-devel On 8/5/2010 9:33 PM, Óscar Fuentes wrote: >> I can momentarily depress Alt to activate the menubar. > > Nope. Have you some setting in .emacs for that? It doesn't work with > emacs -Q (nor I'll appreciate that behavior.) Good guess! I was wondering the whole afternoon. Setting w32-pass-alt-to-system to t does the trick. The manual says: Emacs compiled as a native Windows application normally turns off the Windows feature that tapping the <ALT> key invokes the Windows menu. The reason is that the <ALT> serves as <META> in Emacs. When using Emacs, users often press the <META> key temporarily and then change their minds; if this has the effect of bringing up the Windows menu, it alters the meaning of subsequent commands. Many users find this frustrating. You can re-enable Windows' default handling of tapping the <ALT> key by setting w32-pass-alt-to-system to a non-nil value. ---- The first paragraph is a bit misleading. But, more mysteriously there is no doc-string for this variable. So, it is quite hidden. I will file a bug report. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 21:26 ` Uday S Reddy @ 2010-08-05 22:55 ` Lennart Borgman 2010-08-06 0:05 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-05 22:55 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel On Thu, Aug 5, 2010 at 11:26 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > On 8/5/2010 9:33 PM, Óscar Fuentes wrote: > >>> I can momentarily depress Alt to activate the menubar. >> >> Nope. Have you some setting in .emacs for that? It doesn't work with >> emacs -Q (nor I'll appreciate that behavior.) > > Good guess! I was wondering the whole afternoon. Setting > w32-pass-alt-to-system to t does the trick. > > The manual says: > > Emacs compiled as a native Windows application normally turns off the > Windows feature that tapping the <ALT> key invokes the Windows menu. The > reason is that the <ALT> serves as <META> in Emacs. When using Emacs, users > often press the <META> key temporarily and then change their minds; if this > has the effect of bringing up the Windows menu, it alters the meaning of > subsequent commands. Many users find this frustrating. > > You can re-enable Windows' default handling of tapping the <ALT> key by > setting w32-pass-alt-to-system to a non-nil value. This does not work when sticky keys are enabled. It does however in my patched Emacs. (Starting from "emacs -Q" and just setting w32-pass-alt-to-system to t.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-05 21:26 ` Uday S Reddy 2010-08-05 22:55 ` Lennart Borgman @ 2010-08-06 0:05 ` Drew Adams 2010-08-06 7:46 ` Eli Zaretskii 1 sibling, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-06 0:05 UTC (permalink / raw) To: 'Uday S Reddy', emacs-devel > there is no doc-string for this variable [`w32-pass-alt-to-system']. I see this doc string for it: "Non-nil if Alt key presses are passed on to Windows. When non-nil, for example, Alt pressed and released and then space will open the System menu. When nil, Emacs processes the Alt key events, and then silently swallows them." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 0:05 ` Drew Adams @ 2010-08-06 7:46 ` Eli Zaretskii 0 siblings, 0 replies; 277+ messages in thread From: Eli Zaretskii @ 2010-08-06 7:46 UTC (permalink / raw) To: Drew Adams; +Cc: u.s.reddy, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Thu, 5 Aug 2010 17:05:27 -0700 > Cc: > > > there is no doc-string for this variable [`w32-pass-alt-to-system']. > > I see this doc string for it: > > "Non-nil if Alt key presses are passed on to Windows. > When non-nil, for example, Alt pressed and released and then space will > open the System menu. When nil, Emacs processes the Alt key events, and > then silently swallows them." I guess Uday was looking in Emacs 23, where this variable indeed was not documented. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 20:33 ` Óscar Fuentes 2010-08-05 21:26 ` Uday S Reddy @ 2010-08-06 3:21 ` Stephen J. Turnbull 2010-08-06 3:25 ` Lennart Borgman ` (2 more replies) 1 sibling, 3 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-06 3:21 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > > [snip] > > > Like Juanma, I also don't know why it is essential to use the Windows > > key as meta. > > +1. But maybe I'm missing something. It's not essential, but I really appreciate having Meta on the outside (where my little finger can press it). It's also nice in X because of the number of window managers that willy-nilly steal Alt for their own use. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 3:21 ` Stephen J. Turnbull @ 2010-08-06 3:25 ` Lennart Borgman 2010-08-06 5:22 ` Stephen J. Turnbull 2010-08-06 5:09 ` Miles Bader 2010-08-06 17:32 ` Uday S Reddy 2 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-06 3:25 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel On Fri, Aug 6, 2010 at 5:21 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote: > > It's not essential, but I really appreciate having Meta on the outside > (where my little finger can press it). It's also nice in X because of > the number of window managers that willy-nilly steal Alt for their own > use. Maybe using CapsLock as the default META would be good? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 3:25 ` Lennart Borgman @ 2010-08-06 5:22 ` Stephen J. Turnbull 2010-08-06 6:21 ` Tassilo Horn 0 siblings, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-06 5:22 UTC (permalink / raw) To: Lennart Borgman; +Cc: Óscar Fuentes, emacs-devel Lennart Borgman writes: > On Fri, Aug 6, 2010 at 5:21 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote: > > > > It's not essential, but I really appreciate having Meta on the outside > > (where my little finger can press it). It's also nice in X because of > > the number of window managers that willy-nilly steal Alt for their own > > use. > > Maybe using CapsLock as the default META would be good? Dunno. I wouldn't find that useful. I use CapsLock as JapaneseLock, and presumably the person who suggested it to me does it too, so it might be common practice to bind it to an input method switcher. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 5:22 ` Stephen J. Turnbull @ 2010-08-06 6:21 ` Tassilo Horn 0 siblings, 0 replies; 277+ messages in thread From: Tassilo Horn @ 2010-08-06 6:21 UTC (permalink / raw) To: emacs-devel; +Cc: Óscar Fuentes, Stephen J. Turnbull, Lennart Borgman On Friday 06 August 2010 07:22:14 Stephen J. Turnbull wrote: > > Maybe using CapsLock as the default META would be good? > > Dunno. I wouldn't find that useful. Ditto. > I use CapsLock as JapaneseLock, and presumably the person who > suggested it to me does it too, so it might be common practice to bind > it to an input method switcher. I use it as additional Control key (which is pretty common IMO), and basically I don't use the left and right "real" Control keys at all, so those would be free. But the usual Alt seems more convenient to me. (And for all things window manager related, I use the Super [windows] key.) I think it is much better to configure those things globally for X instead of inside emacs. I guess, anyone who wants to press C with CapsLock wants to do that in all apps, and it's the same for Alt/Meta or sticky modifier keys... Bye, Tassilo ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 3:21 ` Stephen J. Turnbull 2010-08-06 3:25 ` Lennart Borgman @ 2010-08-06 5:09 ` Miles Bader 2010-08-06 9:02 ` Stephen J. Turnbull 2010-08-06 17:32 ` Uday S Reddy 2 siblings, 1 reply; 277+ messages in thread From: Miles Bader @ 2010-08-06 5:09 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > It's not essential, but I really appreciate having Meta on the outside > (where my little finger can press it). It's also nice in X because of > the number of window managers that willy-nilly steal Alt for their own > use. I'm a bit confused about how the alt-meta split actually happens in X, because I've found it _extremely_ hard to get any kind of consistent behavior (across systems, even those running the same OS / version, and across apps). In particular, it seems to depend on the type of keyboard you use (USB vs. PS/2), and Emacs does not recognize modifier mappings that other apps do, so I get the feeling Emacs may be using reading keyboard input at a different level than most apps (e.g., logical vs. physical or something?). I dunno. It's a mess in X generally, but it seems even more of a mess in X+Emacs... It's hard even to describe the problem well enough to come up with a real bug report... -Miles -- History, n. An account mostly false, of events mostly unimportant, which are brought about by rulers mostly knaves, and soldiers mostly fools. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 5:09 ` Miles Bader @ 2010-08-06 9:02 ` Stephen J. Turnbull 0 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-06 9:02 UTC (permalink / raw) To: Miles Bader; +Cc: Óscar Fuentes, emacs-devel Miles Bader writes: > I'm a bit confused about how the alt-meta split actually happens in > X, because I've found it _extremely_ hard to get any kind of > consistent behavior (across systems, even those running the same OS > / version, and across apps). > > In particular, it seems to depend on the type of keyboard you use (USB > vs. PS/2), and Emacs does not recognize modifier mappings that other > apps do, so I get the feeling Emacs may be using reading keyboard input > at a different level than most apps (e.g., logical vs. physical or > something?). Could be. Another possibility is simply that Emacs tries to cater to broken keyboard configurations, and (as you might expect) sometimes that fails. XEmacs will run, but bitches loudly about it (a behavior inherited from Lucid Emacs). The story is here, http://www.jwz.org/gruntle/autobogotification.html the technical details about how Meta and Alt are *defined* by X11 are here http://www.jwz.org/gruntle/autobogotification-b.html ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 3:21 ` Stephen J. Turnbull 2010-08-06 3:25 ` Lennart Borgman 2010-08-06 5:09 ` Miles Bader @ 2010-08-06 17:32 ` Uday S Reddy 2010-08-06 17:46 ` Óscar Fuentes ` (2 more replies) 2 siblings, 3 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-06 17:32 UTC (permalink / raw) To: emacs-devel Stephen J. Turnbull wrote: > > > Like Juanma, I also don't know why it is essential to use the Windows > > > key as meta. > > > > +1. But maybe I'm missing something. > > It's not essential, but I really appreciate having Meta on the outside > (where my little finger can press it). It's also nice in X because of > the number of window managers that willy-nilly steal Alt for their own > use. I agree. After having thought about for a day, I realize that it is a perfectly logical thing to map Windows keys to Meta. It is wasted keyboard real estate otherwise. Juanma, can this go on the TODO list? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 17:32 ` Uday S Reddy @ 2010-08-06 17:46 ` Óscar Fuentes 2010-08-06 18:40 ` Uday S Reddy 2010-08-06 19:13 ` Drew Adams 2010-08-06 19:04 ` Juanma Barranquero 2010-08-08 22:22 ` Chong Yidong 2 siblings, 2 replies; 277+ messages in thread From: Óscar Fuentes @ 2010-08-06 17:46 UTC (permalink / raw) To: emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > I agree. After having thought about for a day, I realize that it is a > perfectly logical thing to map Windows keys to Meta. It is wasted > keyboard real estate otherwise. > > Juanma, can this go on the TODO list? If that goes ahead, please make it easy to go back to the current configuration. Some keyboards don't have the Windows key(s) on a convenient place, if they have it at all. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 17:46 ` Óscar Fuentes @ 2010-08-06 18:40 ` Uday S Reddy 2010-08-06 19:13 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-06 18:40 UTC (permalink / raw) To: emacs-devel Óscar Fuentes wrote: > If that goes ahead, please make it easy to go back to the current > configuration. Some keyboards don't have the Windows key(s) on a > convenient place, if they have it at all. I am sure it will be controlled by an option, the same way as Alt is handled right now. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-06 17:46 ` Óscar Fuentes 2010-08-06 18:40 ` Uday S Reddy @ 2010-08-06 19:13 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Drew Adams @ 2010-08-06 19:13 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > > I agree. After having thought about for a day, I realize > > that it is a perfectly logical thing to map Windows keys to Meta. > > It is wasted keyboard real estate otherwise. > > > > Juanma, can this go on the TODO list? > > If that goes ahead, please make it easy to go back to the current > configuration. Some keyboards don't have the Windows key(s) on a > convenient place, if they have it at all. That would certainly be the _least_ that we could hope for. I have no objection to such a feature as an option, but I would not like to see it become the default for Emacs. I think the default behavior on Windows is pretty good. I think Emacs out of the box should let users use the "Windows" keys (`lwindow', `rwindow') for something other than Meta (including letting them use it in the regular MS Windows way). FWIW: For my personal use I also do this, to allow use of `M-TAB' by Emacs (as opposed to needing to use `ESC TAB'): (w32-register-hot-key [M-tab]) I'm guessing this is less well known than the possibilities provided by options `w32-alt-is-meta', `w32-pass-alt-to-system', and `w32-recognize-altgr'. Sometimes I wonder if we shouldn't provide an option for this behavior, just to help users find it easier. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 17:32 ` Uday S Reddy 2010-08-06 17:46 ` Óscar Fuentes @ 2010-08-06 19:04 ` Juanma Barranquero 2010-08-08 22:22 ` Chong Yidong 2 siblings, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-06 19:04 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel On Fri, Aug 6, 2010 at 19:32, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Juanma, can this go on the TODO list? It's not my decision. Send a wishlist bug report, and we'll see whether someone steps forward to implement it. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 17:32 ` Uday S Reddy 2010-08-06 17:46 ` Óscar Fuentes 2010-08-06 19:04 ` Juanma Barranquero @ 2010-08-08 22:22 ` Chong Yidong 2010-08-08 22:29 ` Lennart Borgman ` (3 more replies) 2 siblings, 4 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-08 22:22 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: >> It's not essential, but I really appreciate having Meta on the outside >> (where my little finger can press it). It's also nice in X because of >> the number of window managers that willy-nilly steal Alt for their own >> use. > > I agree. After having thought about for a day, I realize that it is a > perfectly logical thing to map Windows keys to Meta. It is wasted > keyboard real estate otherwise. No, this is too idiosyncratic to make it the default. Even for non-default usage, putting Emacs in charge of the Windows key seems unacceptable. This is the domain of the operating system. Doesn't the Windows world have some equivalent of `xmodmap'? That's the conceptually correct way to handle this. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 22:22 ` Chong Yidong @ 2010-08-08 22:29 ` Lennart Borgman 2010-08-08 23:06 ` David De La Harpe Golden 2010-08-08 23:09 ` Chong Yidong 2010-08-09 8:13 ` Uday S Reddy ` (2 subsequent siblings) 3 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-08 22:29 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel On Mon, Aug 9, 2010 at 12:22 AM, Chong Yidong <cyd@stupidchicken.com> wrote: > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > >>> It's not essential, but I really appreciate having Meta on the outside >>> (where my little finger can press it). It's also nice in X because of >>> the number of window managers that willy-nilly steal Alt for their own >>> use. >> >> I agree. After having thought about for a day, I realize that it is a >> perfectly logical thing to map Windows keys to Meta. It is wasted >> keyboard real estate otherwise. > > No, this is too idiosyncratic to make it the default. > > Even for non-default usage, putting Emacs in charge of the Windows key > seems unacceptable. This is the domain of the operating system. I think the Alt key is far more important. > Doesn't the Windows world have some equivalent of `xmodmap'? That's the > conceptually correct way to handle this. No really. It tries to standardize instead (and I believe it got it huge user base from that). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 22:29 ` Lennart Borgman @ 2010-08-08 23:06 ` David De La Harpe Golden 2010-08-08 23:09 ` Chong Yidong 1 sibling, 0 replies; 277+ messages in thread From: David De La Harpe Golden @ 2010-08-08 23:06 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Chong Yidong, emacs-devel Apart from anything else, on x11, the windows keys are nowadays conventionally "Super", so x11 emacs already tends to see them as, well, "Super". Xorg with a PC keyboard tends to map the windoze keys to the Super_L/Super_R modifiers. x11 emacs therefore sees them as "Super" ("s-" in emacs, as opposed to shift which is "S-"). (w32 emacs apparently calls them lwindow/rwindow and binds them to ignore) X.org maps that menu key to the right of the right windows key to "Menu", which x11 emacs considers to be "menu", bound to execute-extended-command (i.e. M-x), at least if it gets to see it (i.e. window manager or whatever hasn't already eaten it). (w32 emacs apparently calls it "apps" when it sees it and doesn't bind it to anything) [On x11, I therefore put my window manager's various keybindings on Super (they're windows keys, heh), freeing up x11 Alt for emacs' Meta. Yes, I realise doing that on w32 is far harder than on x11.] For completeness: ns emacs encounters *step-type keys, apparently interpreting them (by default) as: step-"Control" => emacs Control, step-"Alternate" => Alt -> emacs Meta, step-"Command" => emacs Super, step-"Help" => emacs Hyper. GNUstep/x11 itself can also be told which _x11_ keys to consider which *step keys with the "defaults" tool e.g. you might do NSGlobalDomain GSFirstControlKey Control_L NSGlobalDomain GSFirstCommandKey Super_L NSGlobalDomain GSFirstAlternateKey Alt_L NSGlobalDomain GSSecondHelpKey Super_R NSGlobalDomain GSSecondControlKey Control_R etc. (those are not the current out-of-box gnustep settings, they're choices that meant gnustep/x11 emacs' default mapping wound up close to x11 emacs) On a real macosx keyboard, though, physically, compared to a PC: "Control" tends to be similarly positioned to PC Control "Command" roughly where a PC has Alt. "Alternate" (well, "Option") roughly where a PC has windows keys. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 22:29 ` Lennart Borgman 2010-08-08 23:06 ` David De La Harpe Golden @ 2010-08-08 23:09 ` Chong Yidong [not found] ` <AANLkTim86uB8Yb3P9_HX2NN=RQ6svVTvXfyvUQfAJAnE@mail.gmail! .com> 2010-08-08 23:19 ` Lennart Borgman 1 sibling, 2 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-08 23:09 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > I think the Alt key is far more important. Why is it any more important than on any other platform? Practically no one uses a keyboard with separate Alt and Meta keys anymore, so it makes sense to translate the alt key to a Meta event, as we do on GNU/Linux. ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <AANLkTim86uB8Yb3P9_HX2NN=RQ6svVTvXfyvUQfAJAnE@mail.gmail! .com>]
* Re: Key bindings proposal 2010-08-08 23:09 ` Chong Yidong [not found] ` <AANLkTim86uB8Yb3P9_HX2NN=RQ6svVTvXfyvUQfAJAnE@mail.gmail! .com> @ 2010-08-08 23:19 ` Lennart Borgman 2010-08-08 23:42 ` Chong Yidong 2010-08-09 1:01 ` Juanma Barranquero 1 sibling, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-08 23:19 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel On Mon, Aug 9, 2010 at 1:09 AM, Chong Yidong <cyd@stupidchicken.com> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> I think the Alt key is far more important. > > Why is it any more important than on any other platform? Practically no > one uses a keyboard with separate Alt and Meta keys anymore, so it makes > sense to translate the alt key to a Meta event, as we do on GNU/Linux. I really think you know: - Alt-TAB is very important, at least on w32. It switches application (or rather application level window). - Alt+Letter (or Alt and then Letter) is used to open menus. The Window key is of course also important, but: - The most common use of it is to open the Start Menu. You can do that with Ctrl-Esc too, at least on w32. - Also, on other platforms Emacs commonly seem to bind the Windows key. - On other platforms it is often used ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 23:19 ` Lennart Borgman @ 2010-08-08 23:42 ` Chong Yidong [not found] ` <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9!! @mail.gmail.com> ` (2 more replies) 2010-08-09 1:01 ` Juanma Barranquero 1 sibling, 3 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-08 23:42 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > I really think you know: > > - Alt-TAB is very important, at least on w32. It switches application > (or rather application level window). > - Alt+Letter (or Alt and then Letter) is used to open menus. Again, how is this different from other platforms? ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9!! @mail.gmail.com>]
[parent not found: <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9! @mail.gmail.com>]
* Re: Key bindings proposal 2010-08-08 23:42 ` Chong Yidong [not found] ` <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9!! @mail.gmail.com> [not found] ` <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9! @mail.gmail.com> @ 2010-08-09 14:50 ` Lennart Borgman 2010-08-09 15:16 ` Uday S Reddy 2010-08-12 15:21 ` Chong Yidong 2 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-09 14:50 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel On Mon, Aug 9, 2010 at 1:42 AM, Chong Yidong <cyd@stupidchicken.com> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> I really think you know: >> >> - Alt-TAB is very important, at least on w32. It switches application >> (or rather application level window). >> - Alt+Letter (or Alt and then Letter) is used to open menus. > > Again, how is this different from other platforms? I think you know the other platforms better. But one important thing to notice is that on w32 there is one window manager (with just small variations relevant here). This means that most people on w32 expects the common standards to work, especially those above. (I.e. if they are keyboard users and I guess those interested in Emacs are that.) What is unclear to you in this respect? I have not seen anything that I would regard as seriously doubt here of what I wrote above. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-09 14:50 ` Lennart Borgman @ 2010-08-09 15:16 ` Uday S Reddy 2010-08-09 16:08 ` Drew Adams 2010-08-12 15:21 ` Chong Yidong 1 sibling, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-09 15:16 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Chong Yidong, emacs-devel Lennart Borgman writes: > >> I really think you know: > >> > >> - Alt-TAB is very important, at least on w32. It switches application > >> (or rather application level window). > >> - Alt+Letter (or Alt and then Letter) is used to open menus. > > But one important thing to notice is that on w32 there is one window > manager (with just small variations relevant here). This means that > most people on w32 expects the common standards to work, especially > those above. (I.e. if they are keyboard users and I guess those > interested in Emacs are that.) I am not sure that this is a clincher argument. The "common standards" apply equally to the windows-key, which you are proposing to give up. The point is that one has to use one kind of modifier keys (either the alt-keys or windows-keys) for the Emacs meta-key. It would be good to provide the users with a choice in this regard. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-09 15:16 ` Uday S Reddy @ 2010-08-09 16:08 ` Drew Adams 2010-08-10 7:30 ` Stephen J. Turnbull 0 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-09 16:08 UTC (permalink / raw) To: 'Uday S Reddy', 'Lennart Borgman' Cc: 'Chong Yidong', emacs-devel >> most people on w32 expects the common standards to work, especially >> those above. You privilege compatibility with Windows. It is often better to privilege compatibility with Emacs on other platforms. One of the advantages of Emacs is that it runs on multiple platforms. A related advantage is that most of its default behavior is the same across platforms. This advantage is felt most, of course, by users of more than one platform, but it is also an advantage (simplification) for doc etc. The Alt key is available on most platforms, and Emacs uses it by default for Meta. The Window key is available on PC keyboards, but its "common standard" behavior is generally MS Windows-specific. It should be a no-brainer that the Emacs default would use Alt (not the Window key) for Meta on Windows also. > The point is that one has to use one kind of modifier keys (either the > alt-keys or windows-keys) for the Emacs meta-key. It would be good to > provide the users with a choice in this regard. A choice is almost always a good thing. I support that. And I agree with you that it would be bad to change the default to this. Other things being equal(*), it is desirable to have the same defaults across multiple platforms. --- * "Other things being equal..." generally means, "IF other things are/were equal...". Yes, it is a bit misleading - it can seem to _assert_ that all other things are in fact equal. http://en.wikipedia.org/wiki/Other_things_being_equal ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-09 16:08 ` Drew Adams @ 2010-08-10 7:30 ` Stephen J. Turnbull 0 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-10 7:30 UTC (permalink / raw) To: Drew Adams Cc: 'Uday S Reddy', 'Chong Yidong', 'Lennart Borgman', emacs-devel Drew Adams writes: > Other things being equal(*), Use "ceteris paribus". Not only does it enhance the writer's image of erudition (except among economists, where it's first year undergradate required vocabulary), but it signals to real people that something really weird and counterfactual is coming next. ;-) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-09 14:50 ` Lennart Borgman 2010-08-09 15:16 ` Uday S Reddy @ 2010-08-12 15:21 ` Chong Yidong 2010-08-12 15:46 ` Andreas Schwab 2010-08-12 15:59 ` Lennart Borgman 1 sibling, 2 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-12 15:21 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: >>> - Alt-TAB is very important, at least on w32. It switches application >>> (or rather application level window). >>> - Alt+Letter (or Alt and then Letter) is used to open menus. >> >> Again, how is this different from other platforms? > > I think you know the other platforms better. > > What is unclear to you in this respect? I have not seen anything that > I would regard as seriously doubt here of what I wrote above. None of your points are Windows specific. On POSIX platforms, Alt-TAB is used commonly with to switch windows, and Alt-LETTER to open menus. But your proposed solution is myopically focused on Windows, and I have not seen a good explanation of why it should be so. > But one important thing to notice is that on w32 there is one window > manager (with just small variations relevant here). This means that > most people on w32 expects the common standards to work, especially > those above. (I.e. if they are keyboard users and I guess those > interested in Emacs are that.) Hijacking the Windows key is not exactly following the "common standards". ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 15:21 ` Chong Yidong @ 2010-08-12 15:46 ` Andreas Schwab 2010-08-12 16:13 ` Jan Djärv 2010-08-12 15:59 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: Andreas Schwab @ 2010-08-12 15:46 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, Lennart Borgman, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > On POSIX platforms, Alt-TAB is used commonly with to switch windows, > and Alt-LETTER to open menus. POSIX does not have windows and menus. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 15:46 ` Andreas Schwab @ 2010-08-12 16:13 ` Jan Djärv 0 siblings, 0 replies; 277+ messages in thread From: Jan Djärv @ 2010-08-12 16:13 UTC (permalink / raw) To: Andreas Schwab; +Cc: Uday S Reddy, Chong Yidong, Lennart Borgman, emacs-devel Andreas Schwab skrev 2010-08-12 17.46: > Chong Yidong<cyd@stupidchicken.com> writes: > >> On POSIX platforms, Alt-TAB is used commonly with to switch windows, >> and Alt-LETTER to open menus. > > POSIX does not have windows and menus. > Not now, but there was a Motif and Openlook group in POSIX. It was cancelled in 93. Also GUI usability and Ada bindings to X had working groups. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 15:21 ` Chong Yidong 2010-08-12 15:46 ` Andreas Schwab @ 2010-08-12 15:59 ` Lennart Borgman 2010-08-12 21:20 ` Juanma Barranquero 1 sibling, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-12 15:59 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel On Thu, Aug 12, 2010 at 5:21 PM, Chong Yidong <cyd@stupidchicken.com> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >>>> - Alt-TAB is very important, at least on w32. It switches application >>>> (or rather application level window). >>>> - Alt+Letter (or Alt and then Letter) is used to open menus. >>> >>> Again, how is this different from other platforms? >> >> I think you know the other platforms better. >> >> What is unclear to you in this respect? I have not seen anything that >> I would regard as seriously doubt here of what I wrote above. > > None of your points are Windows specific. On POSIX platforms, Alt-TAB > is used commonly with to switch windows, and Alt-LETTER to open menus. > But your proposed solution is myopically focused on Windows, and I have > not seen a good explanation of why it should be so. I am glad they are not Windows specific (but wonder why you say I am myopically focused on Windows). As Andreas already have pointed out POSIX does not define those things. So what I am interested in is how the different window managers handles this - and you answered that. Your answer is a repeating what others have said here before: the Alt key is commonly used by the window managers. And I think it is unfortunate that Emacs by default takes it since a keyboard user might be very used to use it the way they are used above. >> But one important thing to notice is that on w32 there is one window >> manager (with just small variations relevant here). This means that >> most people on w32 expects the common standards to work, especially >> those above. (I.e. if they are keyboard users and I guess those >> interested in Emacs are that.) > > Hijacking the Windows key is not exactly following the "common > standards". This is in open door. I have never said that. What I have said is that it seems better to use the windows key since I believe it is fair to assume it is not used that frequently by most users. (And I am quite surprised that I have to tell this once again.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 15:59 ` Lennart Borgman @ 2010-08-12 21:20 ` Juanma Barranquero 2010-08-12 21:57 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-12 21:20 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Chong Yidong, emacs-devel On Thu, Aug 12, 2010 at 17:59, Lennart Borgman <lennart.borgman@gmail.com> wrote: > What I have said is that > it seems better to use the windows key since I believe it is fair to > assume it is not used that frequently by most users. The following Windows-key combinations are reserved in one or more Windows releases: b, ctrl-b, c, d, e, f, ctrl-f, g, h, l, m, shift-m, p, r, t, u, v, f1, pause, shift, space, tab, ctrl-tab, 0-9, shift-0-9, ctrl-0-9, alt-0-9, alt-enter, home, up, down, left, right, shift-up, shift-left, shift-right, +. And, when using some programs (like OneNote, etc.): x, esc, kp-subtract, -, n, s. Many of them do quite useful things, see for example http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Keyboard_shortcuts So, in which world is the Windows key "not used that frequently"? Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 21:20 ` Juanma Barranquero @ 2010-08-12 21:57 ` Uday S Reddy 2010-08-12 22:06 ` Uday S Reddy ` (2 more replies) 0 siblings, 3 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-12 21:57 UTC (permalink / raw) To: Juanma Barranquero Cc: Uday S Reddy, Chong Yidong, Lennart Borgman, emacs-devel Juanma Barranquero writes: > Many of them do quite useful things, see for example > http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Keyboard_shortcuts Hi guys, I am not sure where this discussion is headed. Whether these applications of the windows key are "useful" or not is for the users to determine, is it not? The same web page also mentions that, Linuxen call the key the "meta" or "super" key. So, it is not unreasonable to request that we should have the option under Windows too? We are talking about providing the users with a choice between - keyboard access to Emacs's own menus, and - the fancy applications for a pair of modifier keys that Microsoft dreamt up of as justification for putting its own trademark on them. Is that choice so hard to understand? - Uday Perplexed ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 21:57 ` Uday S Reddy @ 2010-08-12 22:06 ` Uday S Reddy 2010-08-12 22:12 ` Juanma Barranquero 2010-08-13 15:37 ` Chong Yidong 2 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-12 22:06 UTC (permalink / raw) To: Uday S Reddy Cc: Juanma Barranquero, Chong Yidong, Lennart Borgman, emacs-devel Uday S Reddy writes: > Juanma Barranquero writes: > > > Many of them do quite useful things, see for example > > http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Keyboard_shortcuts > > The same web page also mentions that, Linuxen call the key the "meta" > or "super" key. Sorry, it wasn't the same web page. It was this one: http://en.wikipedia.org/wiki/Windows_key Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 21:57 ` Uday S Reddy 2010-08-12 22:06 ` Uday S Reddy @ 2010-08-12 22:12 ` Juanma Barranquero 2010-08-12 23:02 ` Lennart Borgman 2010-08-13 8:57 ` Uday S Reddy 2010-08-13 15:37 ` Chong Yidong 2 siblings, 2 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-12 22:12 UTC (permalink / raw) To: Uday S Reddy; +Cc: Chong Yidong, Lennart Borgman, emacs-devel On Thu, Aug 12, 2010 at 23:57, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Hi guys, I am not sure where this discussion is headed. Whether these > applications of the windows key are "useful" or not is for the users > to determine, is it not? Am I not a user? Can't I state that I wouldn't want Emacs to forcefully hijack the Windows key for meta? (Having it as an option is fine, though; I wouldn't set it up in a million years.) > So, it is not unreasonable to request that we should > have the option under Windows too? Nobody has argued against the *option*, I think. Me, I deny the *necessity* that Lennart posits. > We are talking about providing the users with a choice between > > - keyboard access to Emacs's own menus, and I can access Emacs' own menus quite well if I set `w32-pass-alt-to-system'. > - the fancy applications for a pair of modifier keys that Microsoft > dreamt up of as justification for putting its own trademark on them. You don't find them useful. That does not make it "fancy applications". > Is that choice so hard to understand? It is a false choice. IIUC, the trouble is using Alt with StickyKeys. If so, Lennart is invited to try and find a fix for that which does not force every Windows user to switch to "Windows is meta". > - Uday Perplexed Rhetorical [http://www.unseelie.org/rpg/question.html] Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 22:12 ` Juanma Barranquero @ 2010-08-12 23:02 ` Lennart Borgman 2010-08-12 23:11 ` Juanma Barranquero 2010-08-13 8:57 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-12 23:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Uday S Reddy, Chong Yidong, emacs-devel On Fri, Aug 13, 2010 at 12:12 AM, Juanma Barranquero <lekktu@gmail.com> wrote: > On Thu, Aug 12, 2010 at 23:57, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > >> Hi guys, I am not sure where this discussion is headed. Whether these >> applications of the windows key are "useful" or not is for the users >> to determine, is it not? > > Am I not a user? Can't I state that I wouldn't want Emacs to > forcefully hijack the Windows key for meta? (Having it as an option is > fine, though; I wouldn't set it up in a million years.) We have only been talking about having it as an option. (If that option should make it default is another question.) This is already implemented in my patched version of Emacs. (The default there is still using Alt as Emacs META since I did not want to confuse new users.) > IIUC, the trouble is using Alt with StickyKeys. If so, Lennart is > invited to try and find a fix for that which does not force every > Windows user to switch to "Windows is meta". There are several troubles, but this is a main one, yes. And it is already implemented in my patched version of Emacs. Like the other patch above it has been there for several years now. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 23:02 ` Lennart Borgman @ 2010-08-12 23:11 ` Juanma Barranquero 0 siblings, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-12 23:11 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Chong Yidong, emacs-devel On Fri, Aug 13, 2010 at 01:02, Lennart Borgman <lennart.borgman@gmail.com> wrote: > We have only been talking about having it as an option. (If that > option should make it default is another question.) No, it is the same question as long as you insist that the reason you use your keyboard changes in your fork is because they are necessary to use alt on Windows (the wording varies among threads, but that's the general idea). > This is already implemented in my patched version of Emacs. (The > default there is still using Alt as Emacs META since I did not want to > confuse new users.) Glad to hear that. > And it is already implemented in my patched version of Emacs. > > Like the other patch above it has been there for several years now. The operating word being "there", of course. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 22:12 ` Juanma Barranquero 2010-08-12 23:02 ` Lennart Borgman @ 2010-08-13 8:57 ` Uday S Reddy 2010-08-13 14:42 ` Drew Adams 2010-08-13 22:53 ` Juanma Barranquero 1 sibling, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-13 8:57 UTC (permalink / raw) To: Juanma Barranquero Cc: Uday S Reddy, Chong Yidong, Lennart Borgman, emacs-devel Juanma Barranquero writes: > Am I not a user? Can't I state that I wouldn't want Emacs to > forcefully hijack the Windows key for meta? Yes, sure. But, I think you are joining in in a subthread where Yidong has been pushing the view that treating the windows key as meta is unreasonable. On the other hand, the wikipedia page on the windows key says that it is *freqently* done. > > We are talking about providing the users with a choice between > > > > - keyboard access to Emacs's own menus, and > > I can access Emacs' own menus quite well if I set `w32-pass-alt-to-system'. We have been through this before. The current Emacs provision is sub-optimal for normal users like me, and it is unworkable for sticky-keys uses like Lennart. > > - the fancy applications for a pair of modifier keys that Microsoft > > dreamt up of as justification for putting its own trademark on them. > > You don't find them useful. That does not make it "fancy applications". Well, those of us that depend on commercial products develop antennae that can sense the difference between a marketing gimmick and a truly engineered feature. The Microsoft-branded windows keys (for which the keyboard manufacturers have to pay a royalty to Microsoft!) seem to fall in the former camp. So, the more we can violate Microsoft's designs, the better we feel. By arguing for using the windows key the Microsoft way, you are unwittingly championing the Microsoft gimmicry. > > Is that choice so hard to understand? > > It is a false choice. Is it really? The majority of the functions that have been put on the windows key can already be obtained by other means. Win = C+Esc Win+Tab = Alt+Tab Win+F1 = F1 Win+R = C+Esc R Win+F = C+Esc f Win+Pause = C+Esc R sysdm.cpl (ok, that one needed some research!) Win+L = C+Alt+Delete win+[up] = Alt+Space x and so on. Many other functions are quite infrequently used. None of them seems important enough to give up good keyboard access to Emacs's own menus. For the seasoned Emacs users, something like 90% of our work is done inside Emacs and only around 10% in Windows. So, it makes sense for us to put as many resources as possible at Emacs's disposal rather than Windows. I am afraid the logic is on Lennart's side. For better or worse, Microsoft has ended up providing us with a good pair of modifier keys. Now, let us put them to good use! > > - Uday Perplexed > > Rhetorical [http://www.unseelie.org/rpg/question.html] Ok, I plead guilty to that charge. But I have a point as well. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-13 8:57 ` Uday S Reddy @ 2010-08-13 14:42 ` Drew Adams 2010-08-13 14:57 ` Lennart Borgman 2010-08-13 16:07 ` Uday S Reddy 2010-08-13 22:53 ` Juanma Barranquero 1 sibling, 2 replies; 277+ messages in thread From: Drew Adams @ 2010-08-13 14:42 UTC (permalink / raw) To: 'Uday S Reddy', 'Juanma Barranquero' Cc: 'Chong Yidong', 'Lennart Borgman', emacs-devel > the wikipedia page on the windows key says that [treating > the windows key as meta] is *freqently* done. On what basis does Wikipedia say that? Do you believe it is true? Why? > For the seasoned Emacs users, something like 90% of our work is done > inside Emacs and only around 10% in Windows. My guess (just a guess) is that there are many, many of us Emacs users on Windows who are *UN*seasoned according to that statement. One at least: me. I use Windows applications (outside of Emacs) for most of what I do all day. Call me an Emacs newbie. Like many Windows users (a guess, based on what I see), I use neither ALT for Windows-specific features (e.g. ALT-TAB) nor the Window key for Windows-specific features. And that is the case regardless of whether I'm using Emacs. (I've used the Window key to bring up Windows Explorer - but generally only on other people's desktops when they don't have a shortcut to it.) I would even guess that most Windows users never use the ALT key in a Windows-specific way (except for CONTROL-ALT-DELETE) and never use the Window key at all. For one thing, most are not programmers (another guess), and most interact with Windows using the mouse most of the time, not the keyboard. And my guess is that _very_ few (proportionally) users of Windows use menu accelerators. That's a lot of guesses ("many", "most") on my part, admittedly. What does Wikipedia say? ;-) Of course it is not all-important what many or most Windows users do. Even if only 0.00001% of them use menu accelerators or whatever, it might still be a good idea for Emacs to support such a feature - as an _option_. Being able to use menu accelerators or use the Window key as Meta (or as Control or Super or Hyper or...) as an _optional_ behavior is one thing. AFAIK, no one has objected to that, so if that is all you are arguing about then the story should be over and done. Send a patch for consideration to provide such optional behavior. But making Emacs give up ALT as Meta by default on some particular platform would be quite another thing. I do not see any good reason for that. Other things being equal, it is good for Emacs to have the same default keys across platforms. And ALT as Meta in Emacs is as old as the hills and as common as their wildflowers. What does Wikipedia say about that? Does it tell you that using ALT as Meta "is *frequently* done" in Emacs? > So, it makes sense for us to put as many resources as possible at Emacs's > disposal rather than Windows. Which means what? That's just as much an argument for keeping the defaults the way they are, ALT for Meta and letting users bind the Window key in Emacs if they like. > I am afraid the logic is on Lennart's side. Do not be afraid. ;-) But do show the logic please, if there is any. > For better or worse, Microsoft has ended up providing us with a good > pair of modifier keys. Now, let us put them to good use! ALT as Meta key is definitely put to good use by Emacs. On all platforms. Out of the box. Always has been. You can easily move among platforms and keyboards and change nothing about how you use the ALT key. Well, on Windows you might need to first set a variable or two to prevent Windows from grabbing ALT for its own use in some cases. But other than that using ALT in Emacs is pretty transparent across platforms. If you want to argue that Emacs should by default grab ALT for Meta in all cases (including for example `(w32-register-hot-key [M-tab])', then go for it: make the argument. Personally, I probably would not object to such a change. The Window key, on the other hand, is not available for non-PC keyboards. There is no special reason to give it any default behavior in Emacs. Leave it open, for users to bind as they wish. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 14:42 ` Drew Adams @ 2010-08-13 14:57 ` Lennart Borgman 2010-08-13 16:09 ` Drew Adams 2010-08-13 16:07 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-13 14:57 UTC (permalink / raw) To: Drew Adams; +Cc: Uday S Reddy, Chong Yidong, emacs-devel, Juanma Barranquero On Fri, Aug 13, 2010 at 4:42 PM, Drew Adams <drew.adams@oracle.com> wrote: > > I would even guess that most Windows users never use the ALT key in a > Windows-specific way (except for CONTROL-ALT-DELETE) and never use the Window > key at all. For one thing, most are not programmers (another guess), and most > interact with Windows using the mouse most of the time, not the keyboard. And > my guess is that _very_ few (proportionally) users of Windows use menu > accelerators. Here is a lesson from MS on using MS Word: http://office.microsoft.com/en-us/word-help/work-with-the-keyboard-RZ006078589.aspx?section=9 It mentions explicitly Alt+Letter. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-13 14:57 ` Lennart Borgman @ 2010-08-13 16:09 ` Drew Adams 2010-08-13 16:15 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-13 16:09 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 'Uday S Reddy', 'Chong Yidong', emacs-devel, 'Juanma Barranquero' > > I would even guess that most Windows users never use the > > ALT key in a Windows-specific way (except for CONTROL-ALT-DELETE) > > and never use the Window key at all. For one thing, most are not > > programmers (another guess), and most interact with Windows using > > the mouse most of the time, not the keyboard. And > > my guess is that _very_ few (proportionally) users of > > Windows use menu accelerators. > > Here is a lesson from MS on using MS Word: > http://office.microsoft.com/en-us/word-help/ > work-with-the-keyboard-RZ006078589.aspx?section=9 > > It mentions explicitly Alt+Letter. So what? No one said that menu accelerators do not _exist_. And no one said that Microsoft has no doc describing them. I say that my guess is that the percentage of Windows users that regularly use - or even who have _ever_ tried to use - menu accelerators is very, very, _very_ small. It simply is not a large part of the global Windows experience. That's my guess. Do do guess differently? Do you guess that _most_ Windows users use menu accelerators? Or even 10% of Windows users? Or 1%? What's your guess? Do your mother, sister, cousin, neighbor, doctor, dentist, car mechanic, and grocer (who all use Windows no doubt) use Windows menu accelerators? Have they even heard of such a thing? No way. That's _my_ guess. Would they care to use accelerators if you told them about their existence and how terribly handy they are? Point them to the URL you passed along as proof of the importance. See how quickly they adopt this feature that you feel is so vital to Windows. No way. That's _my_ guess. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:09 ` Drew Adams @ 2010-08-13 16:15 ` Lennart Borgman 2010-08-13 17:40 ` David Robinow 2010-08-14 0:01 ` Drew Adams 0 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-13 16:15 UTC (permalink / raw) To: Drew Adams; +Cc: Uday S Reddy, Chong Yidong, emacs-devel, Juanma Barranquero On Fri, Aug 13, 2010 at 6:09 PM, Drew Adams <drew.adams@oracle.com> wrote: >> > I would even guess that most Windows users never use the >> > ALT key in a Windows-specific way (except for CONTROL-ALT-DELETE) >> > and never use the Window key at all. For one thing, most are not >> > programmers (another guess), and most interact with Windows using >> > the mouse most of the time, not the keyboard. And >> > my guess is that _very_ few (proportionally) users of >> > Windows use menu accelerators. >> >> Here is a lesson from MS on using MS Word: >> http://office.microsoft.com/en-us/word-help/ >> work-with-the-keyboard-RZ006078589.aspx?section=9 >> >> It mentions explicitly Alt+Letter. > > So what? No one said that menu accelerators do not _exist_. > And no one said that Microsoft has no doc describing them. This is the way MS Word users are educated. People who are mostly programmers or similar might never learn that kind of things. I do not know. But where I was working on the technical university people actually wrote a lot of text too. (And they used tools like MS Words.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:15 ` Lennart Borgman @ 2010-08-13 17:40 ` David Robinow 2010-08-14 0:01 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: David Robinow @ 2010-08-13 17:40 UTC (permalink / raw) To: emacs-devel On Fri, Aug 13, 2010 at 12:15 PM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Fri, Aug 13, 2010 at 6:09 PM, Drew Adams <drew.adams@oracle.com> wrote: >>> > I would even guess that most Windows users never use the >>> > ALT key in a Windows-specific way (except for CONTROL-ALT-DELETE) >>> > and never use the Window key at all. For one thing, most are not >>> > programmers (another guess), and most interact with Windows using >>> > the mouse most of the time, not the keyboard. And >>> > my guess is that _very_ few (proportionally) users of >>> > Windows use menu accelerators. >>> >>> Here is a lesson from MS on using MS Word: >>> http://office.microsoft.com/en-us/word-help/ >>> work-with-the-keyboard-RZ006078589.aspx?section=9 >>> >>> It mentions explicitly Alt+Letter. >> >> So what? No one said that menu accelerators do not _exist_. >> And no one said that Microsoft has no doc describing them. > > This is the way MS Word users are educated. The existence of documentation does not imply that people read it. I use Word frequently and I've never seen that doc. I just looked at a copy of the Word 2003 textbook formerly used at our local junior college (ISBN 1-4188-3911-6) and in over 600 pages I see NO MENTION of Alt+Letter usage. I simply don't believe that is the way most MS Word users are educated. I've used Windows since 3.1 and I've never used that feature (except during discussions such as this one where I've tried things just to see if they work) Menu accelerators are only useful when one's mouse is broken. > > People who are mostly programmers or similar might never learn that > kind of things. I do not know. But where I was working on the > technical university people actually wrote a lot of text too. (And > they used tools like MS Words.) Yes, many people use MS Word. That's one of the reasons Bill Gates is a multi-billionaire. Most of them don't use Alt+Letter. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-13 16:15 ` Lennart Borgman 2010-08-13 17:40 ` David Robinow @ 2010-08-14 0:01 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Drew Adams @ 2010-08-14 0:01 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 'Uday S Reddy', 'Chong Yidong', emacs-devel, 'Juanma Barranquero' > >> > I would even guess that most Windows users never use the > >> > ALT key in a Windows-specific way (except for CONTROL-ALT-DELETE) > >> > and never use the Window key at all. For one thing, most are not > >> > programmers (another guess), and most interact with Windows using > >> > the mouse most of the time, not the keyboard. And > >> > my guess is that _very_ few (proportionally) users of > >> > Windows use menu accelerators. > >> > >> Here is a lesson from MS on using MS Word: > >> http://office.microsoft.com/en-us/word-help/ > >> work-with-the-keyboard-RZ006078589.aspx?section=9 > >> > >> It mentions explicitly Alt+Letter. > > > > So what? No one said that menu accelerators do not _exist_. > > And no one said that Microsoft has no doc describing them. > > This is the way MS Word users are educated. Sorry, my friend (sincerely), but that is nonsense. 99.999999999% of Windows users have never, ever, ever, ever read that doc section, I am sure. And very, very few Windows users make use of menu accelerators. No, I have no stats to back that up. But I'm stickin to it. ;-) My impression is that you have a very narrow view of the average Windows user, even the average Windows programmer. Most do not use menu accelerators, or ALT-TABbing, or sticky keys. They just don't. Sorry. My sister, who uses Word, never heard of any of those, and she would not dream of using any of them if I told her they existed. Your sister too, no doubt. > People who are mostly programmers or similar might never learn that > kind of things. Hey, if those who are mostly programmers don't use them, AND the average point-and-click user doesn't use them either, then who are you so worried about? It wouldn't be just yourself, would it? > I do not know. But where I was working on the > technical university people actually wrote a lot of text too. (And > they used tools like MS Words.) Hey, where I work now and at other places I've worked in the past, lots of people use Word too. I've never known _any_ who use menu accelerators. I've known only a few who use ALT-TAB etc., and they were all programmers. Different people use the same tools differently. Including Emacs. That's why I support giving users such things as you've mentioned (as optional behavior). I really think the only real question is how that could be done (implementation/design). I sure cannot speak for Yidong - hell, we disagree on nearly everything (!), but I would not be surprised if he were _not_ really opposed to giving users such options. My guess is that he does not like the sound of the implementation changes it would seem to require to provide these options. Why do I think that, even though he said that he was not in favor of providing such an option? Because every time we start to get into the details of how it might be done there ensues a conversation where you say that you have already done it all - but others do not agree. They say "Where's the beef?" and you say "It's all there, look for yourself and figure it out", and 'round you all go in circles. Or else you say something like you've done it all but there are still some problems to be worked out. Do you remember how we got to discussing menu accelerators? It was I who mentioned "menus, menus, menus" in response to Uday who was saying that it is too difficult to discover commands and keys in Emacs. And later it was I who mentioned that you (Lennart) have already implemented Windows menu accelerators for Emacs - I mentioned that in the context of telling Uday that that feature exists and he can use it with La Carte. But what did you reply to my saying that? Here it is: > Yes and we were also discussing adding this to GNU/Linux but it has > not happened yet. > > A problem is of course that Emacs uses the Alt key by default as Emacs > META key. (I have a patch for this for w32 as I have said before many > times). > > There are some bugs in menuacc.el (it depends on tmm), but it works > reasonably well. I have postponed further development on it until it > is included in Emacs. Do you see? You said that menuacc.el is not fully baked and you have stopped developing it. You said you will finish it only after it is included in Emacs. And you suggested that your feature should have been added to GNU/Linux (not Emacs) but someone dropped the ball. And you brought in another topic: use of ALT as Meta by Emacs. You said, in effect, that your menu-accelerator feature depends on Emacs not using the ALT key as Meta by default. _BY DEFAULT_ no less. I hope you see the problem I'm trying to point out. You say that you have a solution, but that you won't finish it until it is merged into Emacs, and to do that Emacs has to give up its use of Alt as Meta by default. Is it any wonder that things are not clear and the feature has not been adopted as an option? I might be completely wet, but my guess is that your changes are not clear to those who could judge them (which does not include me, certainly), and they are not convinced of how these optional features could be offered. You "have a patch for this for w32", but no one seems to see the patch, or perhaps they have seen it but do not understand it. Clear that up and I'm convinced we could progress. If you have a simple solution, then I'll bet we can get the options you guys want into Emacs (as options). But if there is no such real communication about the changes to be made (implementation), then no progress will be made. You will remain convinced that no one wants the features you have to offer, and others will remain convinced that there was no reasonable and completed implementation of the feature as optional behavior. Remember that you know your implementation better than others do. If you do not master it and cannot communicate it then others will naturally lose interest. My friendly advice is to look again at the problem, finish your solution (if unfinished), and send a complete, clear solution to the list for consideration. But it needs to offer the feature in an optional way, not hard-coded/built-in or difficult to bypass. Above all, the changes need to be clear. I really think that is the problem behind the resistance you see about this. But yes, I could be wrong. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-13 14:42 ` Drew Adams 2010-08-13 14:57 ` Lennart Borgman @ 2010-08-13 16:07 ` Uday S Reddy 2010-08-13 22:34 ` Juanma Barranquero 2010-08-14 0:01 ` Drew Adams 1 sibling, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-13 16:07 UTC (permalink / raw) To: Drew Adams Cc: 'Uday S Reddy', 'Chong Yidong', emacs-devel, 'Lennart Borgman', 'Juanma Barranquero' Drew Adams writes: > > the wikipedia page on the windows key says that [treating the > > windows key as meta] is *freqently* done. > > On what basis does Wikipedia say that? Do you believe it is true? > Why? I am by no means an expert on the low-level keyboard issues. So, people can correct me if I am wrong. Alt is "hyper" and the windows key is "super". PC keyboards don't have a "meta". Therefore, the systems that want a meta-key map one of these to meta. It looks like desktops such as KDE and Gnome map the windows key as meta, and their users, who presumably contributed to the Wikipedia article, say "windows key is also known as the meta-key". They are not exactly right, but I admire their diligence in countering the Microsoft corporatization of the everyday keyboard. Such spirit seems to be sadly lacking on this mailing list :-( > I would even guess that most Windows users never use the ALT key in > a Windows-specific way (except for CONTROL-ALT-DELETE) and never use > the Window key at all. For one thing, most are not programmers > (another guess), and most interact with Windows using the mouse most > of the time, not the keyboard. And my guess is that _very_ few > (proportionally) users of Windows use menu accelerators. I think the issues of "most Windows users" are not relevant here. This is emacs-developers mailing list after all. We are only interested in Windows users that also use Emacs. And, these users can learn key bindings if they think they are useful. > Being able to use menu accelerators or use the Window key as Meta > (or as Control or Super or Hyper or...) as an _optional_ behavior is > one thing. AFAIK, no one has objected to that, so if that is all > you are arguing about then the story should be over and done. That is indeed what we are arguing about, because Yidong has said (on 8 Aug): > Even for non-default usage, putting Emacs in charge of the Windows key > seems unacceptable. This is the domain of the operating system. Both Lennart and I have clarified many times that we are not arguing about defaults. We are arguing about capabilities. Emacs, at the moment, does not have the capability to treat the windows key as meta. Lennart knows how to do it, and he can possibly be persuaded to provide a patch, but welcoming his idea a bit more warmly on this mailing list would be a good first step. > And ALT as Meta in Emacs is as old as the hills and as common as > their wildflowers. What does Wikipedia say about that? Does it > tell you that using ALT as Meta "is *frequently* done" in Emacs? Come on. Meta keys existed before Bill Gates learnt to program, and Emacs has existed long before the PC keyboards came on the scene. Treating ALT as meta on PC keyboards was a natural choice because they were free modifier keys. Nobody is faulting Emacs for having done that. But, the current position is that enough keyboards have the windows/super key and Microsoft has unlocked it on Windows, according to Lennart. And, using the windows/super key as meta provides significant advantages in enabling keyboard access to the Emacs menubar. > Do not be afraid. ;-) But do show the logic please, if there is any. I just stated it above, for the umpteenth time. The rest of your post is not relevant because it is talking about defaults, which we are not. You can read it again and note that it is irrelevant. Cheers, Uday > > > For better or worse, Microsoft has ended up providing us with a > > good pair of modifier keys. Now, let us put them to good use! > > ALT as Meta key is definitely put to good use by Emacs. On all > platforms. Out of the box. Always has been. You can easily move > among platforms and keyboards and change nothing about how you use > the ALT key. > > Well, on Windows you might need to first set a variable or two to > prevent Windows from grabbing ALT for its own use in some cases. > But other than that using ALT in Emacs is pretty transparent across > platforms. > > If you want to argue that Emacs should by default grab ALT for Meta > in all cases (including for example `(w32-register-hot-key > [M-tab])', then go for it: make the argument. Personally, I > probably would not object to such a change. > > The Window key, on the other hand, is not available for non-PC > keyboards. There is no special reason to give it any default > behavior in Emacs. Leave it open, for users to bind as they wish. > > ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:07 ` Uday S Reddy @ 2010-08-13 22:34 ` Juanma Barranquero 2010-08-14 0:01 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-13 22:34 UTC (permalink / raw) To: Uday S Reddy; +Cc: Chong Yidong, Lennart Borgman, Drew Adams, emacs-devel On Fri, Aug 13, 2010 at 18:07, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Lennart knows how to do it, and he can possibly be persuaded to > provide a patch Ha! (Oops, sorry, did I speak out loud?) Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-13 16:07 ` Uday S Reddy 2010-08-13 22:34 ` Juanma Barranquero @ 2010-08-14 0:01 ` Drew Adams 2010-08-14 9:23 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-14 0:01 UTC (permalink / raw) To: 'Uday S Reddy' Cc: 'Juanma Barranquero', 'Chong Yidong', 'Lennart Borgman', emacs-devel > Alt is "hyper" and the windows key is "super". PC keyboards don't > have a "meta". The PC keyboards I've seen do not have a Hyper key or a Super key either - no such key labels. Maybe some PC keyboards do, but the average "everyday" one does not. If you want to call the ALT key "Hyper" and the Window key "Super", feel free. In Emacs, by default we call the ALT key "Meta" (or rather we map the physical key ALT to the logical key Meta). > Therefore, the systems that want a meta-key map one of > these to meta. > > It looks like desktops such as KDE and Gnome map the > windows key as meta, and their users, who presumably contributed to > the Wikipedia article, say "windows key is also known as the > meta-key". Sounds to me more like the KDE and Gnome crowd tried to fit in with Windows and its users to some extent, by mirroring some of its use of ALT for the OS (window mgr). ;-) ALT is a very old key. Its use by Emacs as Meta is nearly as old. Use of ALT by the OS (or window mgr) to do the kinds of things it does for KDE, Gnome, and Windows is much more recent. In the old days, before the Almighty Windows, ALT was not used for such things by the OS or window mgr - at least not the ones I used back then (Control Data, Univac, IBM, VAX/VMS, various UNIXen,...). AFAIK, Windows was the one to spread window-mgr use of ALT far and wide. In this regard, KDE and Gnome are just come-lately ugly ducklings waddling to keep up with their Microsoft mom. If I had to guess (again), I'd guess that KDE & Gnome imitated (shudder!) Windows to some extent, to try to "fit in" with its user base - precisely the kind of argument we've been hearing here ("Gee Dad, everyone else is doing it!"). So to now point to KDE and Gnome as desktops in the GNU/Linux camp that also use ALT somewhat similar to how Windows uses it is a bit disingenuous. > They are not exactly right, but I admire their diligence > in countering the Microsoft corporatization of the everyday keyboard. Hm. You push for Windows-compatible behavior while spearheading the attack on MS. OK. I do too sometimes. To be clear, I have no problem with some of the positive UI ideas introduced by Windows (i.e. by MS, although often originally by Xerox and others). I've tried to add some such features to Emacs myself. But it does sound curious that you trumpet KDE/Gnome's "countering of MS" while defending their imitating Windows' use of ALT. And you have the cart before the horse. The PC keyboard does not risk _becoming_ MS-corporatized. Your "everyday keyboard" was _engendered_ by Microsoft and its partner at the time, IBM. You don't need to save the PC keyboard from MS; you need to thank or blame MS for it in the first place. The PC keyboard is the ubiquitous, everyday keyboard precisely _because_ of MS and Windows and PCs. Use of PC keyboards with anything other than MS (DOS and then Windows) is a recent and still largely marginal development, albeit welcome. > Such spirit seems to be sadly lacking on this mailing list :-( I really think you're out there on a limb sawing strong, if you think that this mailing list is lacking in "diligence in countering the Microsoft corporatization of the everyday keyboard" (or countering Microsoft tout court). You want Emacs to roll over and adapt to MS's use of ALT, but somehow the rest of us are caving in to MS? What am I missing? > > I would even guess that most Windows users never use the ALT key in > > a Windows-specific way (except for CONTROL-ALT-DELETE) and never use > > the Window key at all. For one thing, most are not programmers > > (another guess), and most interact with Windows using the mouse most > > of the time, not the keyboard. And my guess is that _very_ few > > (proportionally) users of Windows use menu accelerators. > > I think the issues of "most Windows users" are not relevant here. > This is emacs-developers mailing list after all. We are only > interested in Windows users that also use Emacs. And, these users can > learn key bindings if they think they are useful. OK, so what do we know about Windows users who are already Emacs users? What proportion of _them_ use menu accelerators or other Windows-specific uses of ALT? Do you know? Personally, I do not limit the set of potential Emacs users to those who already use it. And I do not limit it to programmers either. (I don't claim I am typical in this regard.) I see no reason why other, non-programmer users of Windows might not become Emacs users. There are some already. > > Being able to use menu accelerators or use the Window key as Meta > > (or as Control or Super or Hyper or...) as an _optional_ behavior is > > one thing. AFAIK, no one has objected to that, so if that is all > > you are arguing about then the story should be over and done. > > That is indeed what we are arguing about, because Yidong has said (on > 8 Aug): > > > Even for non-default usage, putting Emacs in charge of the > > Windows key seems unacceptable. This is the domain of the > > operating system. Then you are arguing only with Yidong. I have not seen anyone argue that Emacs should not offer such an option. On the contrary, I've seen several people who disagree with many of your points agree that there is _no_ problem in principle with Emacs offering such an option. I'm one of them. The devil might be in the details of design or implementation, however - dunno. If the implementation were trivial, then there would be no hullaballoo. Suppose that you could send in a simple Lisp minor mode that let users use Windows accelerators or use the Window key for Meta. Piece of cake. I doubt that even Yidong would object in that case (but I do not know that). But much more than that is involved apparently, and I suspect that might be where Yidong's resistance in this regard is coming from. If the ability to provide this as an option involves reworking lots of important C code that no one understands clearly, then that reworking had better be careful, correct, and worth it. > Both Lennart and I have clarified many times that we are not arguing > about defaults. We are arguing about capabilities. Emacs, at the > moment, does not have the capability to treat the windows key as > meta. Lennart knows how to do it, and he can possibly be persuaded to > provide a patch, but welcoming his idea a bit more warmly on this > mailing list would be a good first step. I, for one, do welcome Lennart's idea warmly, if the idea is to provide such a thing as an option. Just as I warmly welcome his idea of letting Emacs users take advantage of Windows menu accelerators. (I adapted my own Lisp library lacarte.el to fit that feature from his library menuacc.el many years ago.) I've said this several times now. And I really do not see _any_ opposition to such an idea. But the code providing such optional behavior needs to be clear - and truly optional. No one is going to immediately adopt a wholesale rewrite of lots of basic Emacs C code without it being clear and complete and tested, and without the pros and cons (of the implementation) being investigated closely. Above all, the behavior needs to be truly optional. With the option turned off by default, the code changes, whatever they are, need to amount to a no-op. I have not followed the implementation discussion, but from what I gathered things are not so clear. Others will have to judge that, not I. > > And ALT as Meta in Emacs is as old as the hills and as common as > > their wildflowers. What does Wikipedia say about that? Does it > > tell you that using ALT as Meta "is *frequently* done" in Emacs? > > Come on. Meta keys existed before Bill Gates learnt to program, and > Emacs has existed long before the PC keyboards came on the scene. Precisely. If by "Meta" you mean using ALT as a Meta key. Yes, that predates Bill and PCs. That was the point of the text you quoted. It is surely a lot more "*frequently* done" to use ALT than the Window key for Meta. > Treating ALT as meta on PC keyboards was a natural choice because they > were free modifier keys. Nobody is faulting Emacs for having done > that. But, the current position is that enough keyboards have the > windows/super key and Microsoft has unlocked it on Windows, according > to Lennart. And, using the windows/super key as meta provides > significant advantages in enabling keyboard access to the Emacs > menubar. Having any such key available provides significant advantages, no matter what behavior is mapped to it. I'm in favor of letting Emacs users bind the Window key to whatever they want. If it is "unlocked" then it should be easy for Emacs users to bind it to whatever they want, no? And if it is _not_ easy to do that out of the box, then I, for one, welcome code that will help users do that. Being able to bind the Window key to Meta, as one possibility, one option, can only be a positive feature - IMO at least. But the cost (e.g. implementation) has to be worth it. I do not see opposition to the _idea_ of such a feature. I do see reluctance to simply gulp down whatever brew Lennart has on tap. Again, I cannot speak to the implementation. Personally I am in favor of such an option, _other things being equal_. And that is so even though I will no doubt never use such an option myself. I like Emacs to offer everything to everyone - provided the cost is reasonable. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-14 0:01 ` Drew Adams @ 2010-08-14 9:23 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-14 9:23 UTC (permalink / raw) To: Drew Adams Cc: 'Uday S Reddy', 'Chong Yidong', emacs-devel, 'Lennart Borgman', 'Juanma Barranquero' Drew Adams writes: > The PC keyboards I've seen do not have a Hyper key or a Super key > either - no such key labels. Maybe some PC keyboards do, but the > average "everyday" one does not. > > If you want to call the ALT key "Hyper" and the Window key "Super", > feel free. In Emacs, by default we call the ALT key "Meta" (or > rather we map the physical key ALT to the logical key Meta). I am not talking about the physical labels. I am talking about the low-level key codes that get sent in to the OS. I don't know enough about low-level key codes. What I said is based on what I have seen written here and there. Perhaps that is Linux-specific. I can't say. > ALT is a very old key. Its use by Emacs as Meta is nearly as old. > Use of ALT by the OS (or window mgr) to do the kinds of things it > does for KDE, Gnome, and Windows is much more recent. > > In the old days, before the Almighty Windows, ALT was not used for > such things by the OS or window mgr - at least not the ones I used > back then (Control Data, Univac, IBM, VAX/VMS, various UNIXen,...). > AFAIK, Windows was the one to spread window-mgr use of ALT far and > wide. In this regard, KDE and Gnome are just come-lately ugly > ducklings waddling to keep up with their Microsoft mom. I didn't know about the old history of the Alt key. The IBM PC was the first time I saw them. Perhaps you can add some stuff to the Wikipedia page on the Alt key so that the rest of us can know? > > They are not exactly right, but I admire their diligence in > > countering the Microsoft corporatization of the everyday keyboard. > > Hm. You push for Windows-compatible behavior while spearheading the > attack on MS. OK. I do too sometimes. > > ... > > And you have the cart before the horse. The PC keyboard does not > risk _becoming_ MS-corporatized. Your "everyday keyboard" was > _engendered_ by Microsoft and its partner at the time, IBM. You > don't need to save the PC keyboard from MS; you need to thank or > blame MS for it in the first place. We are going off-topic here. So, I will be brief. I am not opposed to commerce. If a company makes a product that is useful to me and charges me money that I can afford, I am happy to buy it and use it. That is normal life in a capitalist society. But I am opposed to commercialization. The Windows keys were not on the IBM PC keyboard. Microsoft added them. They are good modifier keys. So, I have no problem with Microsoft adding them. My opposition is to Microsoft branding them, charging royalty to the keyboard manufacturers, and locking up the keys in Windows-specific ways so that they are *not free*. And, software freedom is what we are here about. So, it is a surprise to me that the people here don't attack this violation of freedom as vigorously as possible. The true free software people might say, "serves you right for using commercial software." But that is not right. Violation of freedom should be fought no matter what. These are normal ways for consumers in a capitalist economy to fight corporatization. Free software should ally with them. In the present instance, that means that, for people like Lennart and me who need to use the Win keys in ways that Microsoft did not intend, Emacs should provide all support possible. Asking us what proportion of Windows users actually want to use Win keys this way etc., is irrelevant. > You want Emacs to roll over and > adapt to MS's use of ALT, but somehow the rest of us are caving in > to MS? What am I missing? The Alt is not at issue because Emacs can control how the Alt key gets mapped via the standardard option settings. It is not able to do so for the Win key. Accepting that as life would amount to caving in to MS, yes. > Having any such key available provides significant advantages, no > matter what behavior is mapped to it. I'm in favor of letting Emacs > users bind the Window key to whatever they want. If it is > "unlocked" then it should be easy for Emacs users to bind it to > whatever they want, no? > > And if it is _not_ easy to do that out of the box, then I, for one, > welcome code that will help users do that. Being able to bind the > Window key to Meta, as one possibility, one option, can only be a > positive feature - IMO at least. Good. I am glad that we are on the same side! > But the cost (e.g. implementation) has to be worth it. I do not see > opposition to the _idea_ of such a feature. I do see reluctance to > simply gulp down whatever brew Lennart has on tap. Well, a good part of this thread has been spent on repeatedly asking Lennart and me, "why you do you need to map the Windows key to meta," "why is it the best possible solution," "how many people want to do things that way?" and so on. Politically, at least, these are not the right questions to ask. It is perfectly fine to say, "let us do it outside of Emacs." Then we could have focused on what needs to be done and what programs are out there that can do it, or whether we need to write new programs etc. That is the kind of stuff that matters. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 8:57 ` Uday S Reddy 2010-08-13 14:42 ` Drew Adams @ 2010-08-13 22:53 ` Juanma Barranquero 2010-08-14 7:08 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-13 22:53 UTC (permalink / raw) To: Uday S Reddy; +Cc: Chong Yidong, Lennart Borgman, emacs-devel On Fri, Aug 13, 2010 at 10:57, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Yes, sure. But, I think you are joining in in a subthread where > Yidong has been pushing the view that treating the windows key as meta > is unreasonable. No, he doesn't. He says that making that at the Emacs level is unreasonable. And I think that making this the default, or implying that it's the only sane behavior for Windows users, or necessary somehow, is unreasonable. > On the other hand, the wikipedia page on the windows key says that it is *freqently* done. On non-Windows environments. So what? > We have been through this before. The current Emacs provision is > sub-optimal for normal users like me, and it is unworkable for > sticky-keys uses like Lennart. Please, reread my e-mail. I already know that. Making Windows to be meta is much more subotimal to me. > Well, those of us that depend on commercial products develop antennae > that can sense the difference between a marketing gimmick and a truly > engineered feature. Please! What kind of argument is that? Some appeal to authority? > The Microsoft-branded windows keys (for which the > keyboard manufacturers have to pay a royalty to Microsoft!) seem to > fall in the former camp. So, the more we can violate Microsoft's > designs, the better we feel. Talk for yourself. I don't mind what company's logo is on the key, just that it is useful to me. > By arguing for using the windows key the Microsoft way, you are > unwittingly championing the Microsoft gimmicry. Even worse: by using Microsoft products I'm doing it too. As you do, if you're using Windows. > Is it really? The majority of the functions that have been put on the > windows key can already be obtained by other means. "The majority" != "all". And, C+Esc is much less convenient for me. I've never used any C+Esc shortcut because I find them hard to type, while W+key are quite natural. > None of > them seems important enough to give up good keyboard access to Emacs's > own menus. I'm glad to know you know what's important for all Windows users. > For the seasoned Emacs users, something like 90% of our work is done > inside Emacs and only around 10% in Windows. I confess I've been using Emacs daily only for thirteen years, so I'm not seasoned enough. But I certainly don't spend 90% of my time inside Emacs. > So, it makes sense for > us to put as many resources as possible at Emacs's disposal rather > than Windows. I am afraid the logic is on Lennart's side. Only if you define logic as "everyone needs the exact same things that Lennart and me need, or they are not *really* Windows users". > For better or worse, Microsoft has ended up providing us with a good > pair of modifier keys. Now, let us put them to good use! I already do. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 22:53 ` Juanma Barranquero @ 2010-08-14 7:08 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-14 7:08 UTC (permalink / raw) To: Juanma Barranquero Cc: Uday S Reddy, Chong Yidong, Lennart Borgman, emacs-devel Juanma Barranquero writes: > > Yes, sure. But, I think you are joining in in a subthread where > > Yidong has been pushing the view that treating the windows key as meta > > is unreasonable. > > No, he doesn't. He says that making that at the Emacs level is > unreasonable. Ok, that was a subtlety that I missed for while. I have no trouble using an external program to do key remapping. But what is it that you want it to do, to get the windows key act as meta? I would appreciate a clear specification. > And I think that making this the default, or implying > that it's the only sane behavior for Windows users, or necessary > somehow, is unreasonable. Sorry if I gave that impression. I was only trying to demonstrate that treating win as meta is *reasonable* (to counter Yidong's push that it was unreasonable). Come to think of it, my first PC keyboard probably didn't have the Win key or had it at some awkward place. So, I had begun to use Ctrl+Esc and never paid attention to what the Win key does. I have been perfectly happy to use Ctrl+Esc and other combinations to serve all my Windows needs. I can well imagine that other users might have come through different routes and might have different preferences. I have no problem with that, obviously. Neither does Lennart. Our only problem is that our preferred solution is not supported by Emacs. So, excuse me if I shouted a bit too loudly! Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-12 21:57 ` Uday S Reddy 2010-08-12 22:06 ` Uday S Reddy 2010-08-12 22:12 ` Juanma Barranquero @ 2010-08-13 15:37 ` Chong Yidong 2010-08-13 15:46 ` Óscar Fuentes ` (2 more replies) 2 siblings, 3 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-13 15:37 UTC (permalink / raw) To: Uday S Reddy; +Cc: Juanma Barranquero, Lennart Borgman, emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > Hi guys, I am not sure where this discussion is headed. Whether these > applications of the windows key are "useful" or not is for the users > to determine, is it not? The problem is that Lennart's proposed solution seems to be the wrong one. If you want to rebind the Windows key to a modifier key, the conceptually correct way to do it should be via a separate program, separate from Emacs. That is exactly how it is done on GNU/Linux (where conventions like Alt-TAB are commonly respected, nowadays). If there is any technical reason why this cannot be done on Windows, I have not yet seen anyone argue it. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 15:37 ` Chong Yidong @ 2010-08-13 15:46 ` Óscar Fuentes 2010-08-13 16:50 ` Chong Yidong 2010-08-13 16:01 ` Jason Rumney 2010-08-13 16:04 ` Lennart Borgman 2 siblings, 1 reply; 277+ messages in thread From: Óscar Fuentes @ 2010-08-13 15:46 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > The problem is that Lennart's proposed solution seems to be the wrong > one. If you want to rebind the Windows key to a modifier key, the > conceptually correct way to do it should be via a separate program, > separate from Emacs. That is exactly how it is done on GNU/Linux > (where conventions like Alt-TAB are commonly respected, nowadays). > > If there is any technical reason why this cannot be done on Windows, I > have not yet seen anyone argue it. It is Emacs who is behaving idiosyncratically in Windows, so the fix must come from Emacs, not from a system-wide change. Not that I have any problem with the current behavior... ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 15:46 ` Óscar Fuentes @ 2010-08-13 16:50 ` Chong Yidong 2010-08-13 20:32 ` Óscar Fuentes 2010-08-16 7:25 ` christian.lynbech 0 siblings, 2 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-13 16:50 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > It is Emacs who is behaving idiosyncratically in Windows, so the fix > must come from Emacs, not from a system-wide change. The current standard is used on all platforms: the key labelled "Alt" on the keyboard is handled internally by Emacs as Meta. If this is an idiosyncracy, it is a very simple, uniform, and consistently-applied one. I don't see a well-reasoned argument for deviating from it specifically for the Windows port, given that the de-facto desktop standards (such as the use of Alt-TAB for window switching) are identical between Windows and modern UNIX-like systems such as GNU/Linux. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:50 ` Chong Yidong @ 2010-08-13 20:32 ` Óscar Fuentes 2010-08-13 22:37 ` Juanma Barranquero ` (2 more replies) 2010-08-16 7:25 ` christian.lynbech 1 sibling, 3 replies; 277+ messages in thread From: Óscar Fuentes @ 2010-08-13 20:32 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: >> It is Emacs who is behaving idiosyncratically in Windows, so the fix >> must come from Emacs, not from a system-wide change. > > The current standard is used on all platforms: the key labelled "Alt" on > the keyboard is handled internally by Emacs as Meta. Windows users couldn't care less about what Emacs does on all the other platforms. > If this is an idiosyncracy, it is a very simple, uniform, and > consistently-applied one. I don't see a well-reasoned argument for > deviating from it specifically for the Windows port, given that the > de-facto desktop standards (such as the use of Alt-TAB for window > switching) are identical between Windows and modern UNIX-like systems > such as GNU/Linux. On standard Windows applications, if you press and release Alt, the menu is activated. Not so on KDE (most likely KDE has an option for enabling that behvior, but it is not the default.) Alt+SPC on Windows activates the window's system menu, used for moving, resizing, minimizing, closing, etc. Not so on KDE. That feature is valued by people that tend to avoid using the mouse. Possibly there are more instances. But if the "problem" affects the other platforms too, that's a good reason for allowing using the Windows key as Meta on all of them too, right? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 20:32 ` Óscar Fuentes @ 2010-08-13 22:37 ` Juanma Barranquero 2010-08-13 23:30 ` Óscar Fuentes 2010-08-14 0:00 ` Drew Adams 2010-08-14 7:48 ` Uday S Reddy 2 siblings, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-13 22:37 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Fri, Aug 13, 2010 at 22:32, Óscar Fuentes <ofv@wanadoo.es> wrote: > Windows users couldn't care less about what Emacs does on all the other > platforms. Don't try to speak for all Windows users, please. > On standard Windows applications, if you press and release Alt, the menu > is activated. Including Emacs, if you set w32-pass-alt-to-system. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 22:37 ` Juanma Barranquero @ 2010-08-13 23:30 ` Óscar Fuentes 2010-08-13 23:53 ` Juanma Barranquero 0 siblings, 1 reply; 277+ messages in thread From: Óscar Fuentes @ 2010-08-13 23:30 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > On Fri, Aug 13, 2010 at 22:32, Óscar Fuentes <ofv@wanadoo.es> wrote: > >> Windows users couldn't care less about what Emacs does on all the other >> platforms. > > Don't try to speak for all Windows users, please. Are we going the all-or-nothing route here? Again? Try explaining to someone that a tool he is supposed to use for hours every day doesn't follow his platform's standards because it supports on other platforms too. Do you think that would be an unfair response from him to say "so what? I'm working on *this* platform" >> On standard Windows applications, if you press and release Alt, the menu >> is activated. > > Including Emacs, if you set w32-pass-alt-to-system. What's the variable enabling the usual Windows behavior of Alt+SPC? Seriously, on this topic I'm happy with what Emacs does now, but this is not about my personal preferences, but about if adding an option for turning the Windows key into Meta would be appreciated by some users. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 23:30 ` Óscar Fuentes @ 2010-08-13 23:53 ` Juanma Barranquero 2010-08-14 0:21 ` Óscar Fuentes 0 siblings, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-13 23:53 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Sat, Aug 14, 2010 at 01:30, Óscar Fuentes <ofv@wanadoo.es> wrote: > Try explaining to someone that a tool he is supposed to use for hours > every day doesn't follow his platform's standards because it supports on > other platforms too. Do you use Emacs on Windows? How so? Were you able to overcome the apparently unsurmountable problem of Emacs "not following [your] platform's standards"? The amount of problem, and the lack of adaptability of Windows users, are being wildly overstated. > Seriously, on this topic I'm happy with what Emacs does now, but this is > not about my personal preferences, but about if adding an option for > turning the Windows key into Meta would be appreciated by some users. No. Nobody is against an *option*, so it's not about that. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 23:53 ` Juanma Barranquero @ 2010-08-14 0:21 ` Óscar Fuentes 2010-08-15 22:21 ` Juanma Barranquero 0 siblings, 1 reply; 277+ messages in thread From: Óscar Fuentes @ 2010-08-14 0:21 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > On Sat, Aug 14, 2010 at 01:30, Óscar Fuentes <ofv@wanadoo.es> wrote: > >> Try explaining to someone that a tool he is supposed to use for hours >> every day doesn't follow his platform's standards because it supports on >> other platforms too. > > Do you use Emacs on Windows? How so? Were you able to overcome the > apparently unsurmountable problem of Emacs "not following [your] > platform's standards"? This is not a dialogue, but something else I'm not interested on participating. [snip] ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 0:21 ` Óscar Fuentes @ 2010-08-15 22:21 ` Juanma Barranquero 0 siblings, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-15 22:21 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Sat, Aug 14, 2010 at 02:21, Óscar Fuentes <ofv@wanadoo.es> wrote: > This is not a dialogue, but something else I'm not interested on > participating. It certainly is not a dialogue if you don't answer questions. But that's OK. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-13 20:32 ` Óscar Fuentes 2010-08-13 22:37 ` Juanma Barranquero @ 2010-08-14 0:00 ` Drew Adams 2010-08-14 0:25 ` Óscar Fuentes 2010-08-14 7:48 ` Uday S Reddy 2 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-14 0:00 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > > The current standard is used on all platforms: the key > > labelled "Alt" on the keyboard is handled internally by > > Emacs as Meta. > > Windows users couldn't care less about what Emacs does on all > the other platforms. W r o n g . That is sooooo silly. Lots of people (including yours truly) use multiple platforms (including Windows) to do their work. And some of us use Emacs. FWIW, at Oracle most developers use Windows to access remote GNU/Linux boxes on farms somewhere out there in the ether. Many of them use Emacs locally (running on Windows) as well as remotely (running on GNU/Linux). Many of them also access remote files on the GNU/Linux boxes using Emacs running on Windows. I wouldn't be surprised if the same were true for developers in some other large companies. Yes, no doubt that is not representative of most Windows users. Most Windows users are not even developers. The point is that it is ridiculous to claim that "Windows users couldn't care less about what Emacs does on other platforms." You have only to look at Emacs Wiki or help-gnu-emacs@gnu.org, or google for examples of user .emacs files, to see that some people have init files that are adapted to multiple platforms. And guess what? It's _always_ been like that. Long before there was a Windows at all people used Emacs on multiple platforms. And (trust me) they do care that the default behavior be the same or at least similar on the platforms they use. Relative platform independence is an important Emacs feature. And it's not just about byte code. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 0:00 ` Drew Adams @ 2010-08-14 0:25 ` Óscar Fuentes 2010-08-14 2:05 ` Drew Adams 0 siblings, 1 reply; 277+ messages in thread From: Óscar Fuentes @ 2010-08-14 0:25 UTC (permalink / raw) To: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: >> > The current standard is used on all platforms: the key >> > labelled "Alt" on the keyboard is handled internally by >> > Emacs as Meta. >> >> Windows users couldn't care less about what Emacs does on all >> the other platforms. > > W r o n g . That is sooooo silly. > > Lots of people (including yours truly) use multiple platforms (including > Windows) to do their work. And some of us use Emacs. Please note that I was referring to "Windows users." The part that depicts them as users of other platforms too is your original addition. [snip] ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-14 0:25 ` Óscar Fuentes @ 2010-08-14 2:05 ` Drew Adams 2010-08-14 10:20 ` Jeff Clough 0 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-14 2:05 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > >> > The current standard is used on all platforms > >> > >> Windows users couldn't care less about what Emacs does on all > >> the other platforms. > > > > W r o n g . That is sooooo silly. > > > > Lots of people (including yours truly) use multiple > > platforms (including Windows) to do their work. > > And some of us use Emacs. > > Please note that I was referring to "Windows users." The part that > depicts them as users of other platforms too is your original > addition. But that's the point. The "standard is used on all platforms". Emacs is similar, if not the same, on all platforms. And that's important, including to some Emacs users. Why, you say? What do "Windows users" care about other platforms? Well one reason it is important that a common standard be used across platforms is that "Windows users" are not necessarily users of Windows _only_. When you say "Windows users" without qualification that means _all_ Windows users or Windows users as a class, Windows users in general, as others have pointed out. You seemed to be speaking for all Windows users and missing the point that having similar behavior across platforms could be useful to at least some Windows users. This might be mainly an English problem - dunno. But you can see from the reactions your assertion provoked that it was taken as a clear statement that no Windows users (or hardly any) would care about Emacs behavior on other platforms. And nothing could be farther from the truth. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-14 2:05 ` Drew Adams @ 2010-08-14 10:20 ` Jeff Clough 0 siblings, 0 replies; 277+ messages in thread From: Jeff Clough @ 2010-08-14 10:20 UTC (permalink / raw) To: emacs-devel On Fri, 2010-08-13 at 19:05 -0700, Drew Adams wrote: > > >> > The current standard is used on all platforms > > >> > > >> Windows users couldn't care less about what Emacs does on all > > >> the other platforms. > > > > > > W r o n g . That is sooooo silly. > > > > > > Lots of people (including yours truly) use multiple > > > platforms (including Windows) to do their work. > > > And some of us use Emacs. > > > > Please note that I was referring to "Windows users." The part that > > depicts them as users of other platforms too is your original > > addition. > > But that's the point. The "standard is used on all platforms". Emacs is > similar, if not the same, on all platforms. And that's important, including to > some Emacs users. > > Why, you say? What do "Windows users" care about other platforms? > > Well one reason it is important that a common standard be used across platforms > is that "Windows users" are not necessarily users of Windows _only_. Another reason is that the vast majority of third-party Emacs tutorials, wikis, how-tos, etc. aren't written by Windows users. So if it's three in the morning and you're trying to set up foo package using the customizations from someone using a *nix, the last thing you need is for things to work differently for you because you're running Windows. Jeff -- web: http://www.chaosphere.com Author of Genesys, a Free Universal Paper and Pencil RPG. http://www.chaosphere.com/genesys/ ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 20:32 ` Óscar Fuentes 2010-08-13 22:37 ` Juanma Barranquero 2010-08-14 0:00 ` Drew Adams @ 2010-08-14 7:48 ` Uday S Reddy 2010-08-14 8:18 ` Jason Rumney 2010-08-15 22:27 ` Juanma Barranquero 2 siblings, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-14 7:48 UTC (permalink / raw) To: emacs-devel On 8/13/2010 9:32 PM, Óscar Fuentes wrote: > > Windows users couldn't care less about what Emacs does on all the other > platforms. I wouldn't go that far. Emacs is a cross-platform software and it is valuable that it is so. The keyboard is a limited resource. Conflicts are likely to arise when cross-platform software is used on multiple platforms. Emacs may not be able to look seamless on each and every platform. That is life. But, you and I probably agree that allowing Win key as meta can solve many of these problems. That should be an available option on Emacs. So, if Yidong and Juanma can come back and tell us how to make that happen, we would have made some progress. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 7:48 ` Uday S Reddy @ 2010-08-14 8:18 ` Jason Rumney 2010-08-15 22:27 ` Juanma Barranquero 1 sibling, 0 replies; 277+ messages in thread From: Jason Rumney @ 2010-08-14 8:18 UTC (permalink / raw) To: emacs-devel On 14/8/2010 3:48 PM, Uday S Reddy wrote: > But, you and I probably agree that allowing Win key as meta can solve > many of these problems. That should be an available option on Emacs. > So, if Yidong and Juanma can come back and tell us how to make that > happen, we would have made some progress. Lennart has had advice on how to make such progress in the past, but for some reason this topic always seems to degenerate into an argument that puts him off following through: http://lists.gnu.org/archive/html/help-emacs-windows/2007-10/msg00018.html http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01574.html Please lets drop the arguing for and against until we see what his patch actually does. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 7:48 ` Uday S Reddy 2010-08-14 8:18 ` Jason Rumney @ 2010-08-15 22:27 ` Juanma Barranquero 1 sibling, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-15 22:27 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel On Sat, Aug 14, 2010 at 09:48, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > So, if > Yidong and Juanma can come back and tell us how to make that happen, we > would have made some progress. Sorry, but no. Lennart's the one that says that he's fixed the problem, and he's the one saying that his fix is not accepted. But the fix has not been sent to emacs-devel, or at least, if sent (a long time, as in several years, ago) the usual procedure to get such a patch accepted was not followed. So we're all waiting to see the patch again... Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:50 ` Chong Yidong 2010-08-13 20:32 ` Óscar Fuentes @ 2010-08-16 7:25 ` christian.lynbech 2010-08-16 7:37 ` Miles Bader 1 sibling, 1 reply; 277+ messages in thread From: christian.lynbech @ 2010-08-16 7:25 UTC (permalink / raw) To: Chong Yidong; +Cc: Óscar Fuentes, emacs-devel@gnu.org >>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes: Chong> The current standard is used on all platforms: the key labelled Chong> "Alt" on the keyboard is handled internally by Emacs as Meta. Is this really correct? It would appear to me (though I have admittedly not checked the source) that emacs (under X11) uses as meta whatever modifier is assigned the Meta_* keysym, at least when present (probably there is some fallback mechanism). It just so happens that the standard modifier layout in most GNU/Linux distributions associates the Meta keysym with the key labelled "Alt". I have for a long time used the windows key as my meta key and that I have realised that simply by reshuffling the modifier keysyms via xmodmap. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-16 7:25 ` christian.lynbech @ 2010-08-16 7:37 ` Miles Bader 0 siblings, 0 replies; 277+ messages in thread From: Miles Bader @ 2010-08-16 7:37 UTC (permalink / raw) To: christian.lynbech; +Cc: Óscar Fuentes, Chong Yidong, emacs-devel@gnu.org <christian.lynbech@tieto.com> writes: > Chong> The current standard is used on all platforms: the key labelled > Chong> "Alt" on the keyboard is handled internally by Emacs as Meta. > > Is this really correct? ... > I have for a long time used the windows key as my meta key and that I > have realised that simply by reshuffling the modifier keysyms via > xmodmap. I think it's impossible to make any firm statements about the issue on modern systems, there are just too many layers stepping on each others' toes, too many vague system/device-dependent details, and too much "helpful" tweaking by various parties (e.g., gnome-session). [Currently on my home system, the Alt key maps to meta in Emacs, but the "Windows" (really super) key maps to meta in most non-Emacs apps; on my work system (with identical software/OS versions), this inconsistency doesn't exist. I have no idea why...] -Miles -- Learning, n. The kind of ignorance distinguishing the studious. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 15:37 ` Chong Yidong 2010-08-13 15:46 ` Óscar Fuentes @ 2010-08-13 16:01 ` Jason Rumney 2010-08-13 22:40 ` Juanma Barranquero 2010-08-13 16:04 ` Lennart Borgman 2 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-13 16:01 UTC (permalink / raw) To: emacs-devel On 13/8/2010 11:37 PM, Chong Yidong wrote: > The problem is that Lennart's proposed solution seems to be the wrong > one. If you want to rebind the Windows key to a modifier key, the > conceptually correct way to do it should be via a separate program, > separate from Emacs. That is exactly how it is done on GNU/Linux (where > conventions like Alt-TAB are commonly respected, nowadays). > > If there is any technical reason why this cannot be done on Windows, I > have not yet seen anyone argue it. Such a program might theoretically be possible, but as far as I know it does not exist. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:01 ` Jason Rumney @ 2010-08-13 22:40 ` Juanma Barranquero 2010-08-13 22:46 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-13 22:40 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Fri, Aug 13, 2010 at 18:01, Jason Rumney <jasonr@gnu.org> wrote: > On 13/8/2010 11:37 PM, Chong Yidong wrote: >> If there is any technical reason why this cannot be done on Windows, I >> have not yet seen anyone argue it. > > Such a program might theoretically be possible, but as far as I know it does > not exist. I haven't tried it, but shouldn't AutoHotKey be theoretically able to do it? Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 22:40 ` Juanma Barranquero @ 2010-08-13 22:46 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-13 22:46 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel, Jason Rumney On Sat, Aug 14, 2010 at 12:40 AM, Juanma Barranquero <lekktu@gmail.com> wrote: > > I haven't tried it, but shouldn't AutoHotKey be theoretically able to do it? I might misremember, but I think that was not possible. That was one of the reason I added the low level keyboard hook to my patched Emacs. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 15:37 ` Chong Yidong 2010-08-13 15:46 ` Óscar Fuentes 2010-08-13 16:01 ` Jason Rumney @ 2010-08-13 16:04 ` Lennart Borgman 2010-08-13 16:53 ` Chong Yidong ` (2 more replies) 2 siblings, 3 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-13 16:04 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel, Juanma Barranquero On Fri, Aug 13, 2010 at 5:37 PM, Chong Yidong <cyd@stupidchicken.com> wrote: > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > >> Hi guys, I am not sure where this discussion is headed. Whether these >> applications of the windows key are "useful" or not is for the users >> to determine, is it not? > > The problem is that Lennart's proposed solution seems to be the wrong > one. If you want to rebind the Windows key to a modifier key, the > conceptually correct way to do it should be via a separate program, > separate from Emacs. ?? Where did you get this from? If that was the case then the "conceptually correct way to" rebind the Alt key would also be a separate program, or? Beside that it would not solve the problem that Emacs on w32 does not allow people which needs sticky keys to use it, i.e. it does not allow access for some disabled people. > That is exactly how it is done on GNU/Linux That is maybe how it is organized on GNU/Linux. That is not the way it is organized on w32. > (where conventions like Alt-TAB are commonly respected, nowadays). Might be interesting. Exactly what do you mean by "commonly respected"? > If there is any technical reason why this cannot be done on Windows, I > have not yet seen anyone argue it. ?? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:04 ` Lennart Borgman @ 2010-08-13 16:53 ` Chong Yidong 2010-08-14 0:41 ` Jason Rumney 2010-08-13 22:43 ` Juanma Barranquero 2010-08-14 0:30 ` Jason Rumney 2 siblings, 1 reply; 277+ messages in thread From: Chong Yidong @ 2010-08-13 16:53 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel, Juanma Barranquero Lennart Borgman <lennart.borgman@gmail.com> writes: > Beside that it would not solve the problem that Emacs on w32 does not > allow people which needs sticky keys to use it, i.e. it does not allow > access for some disabled people. This is an appropriate issue, and the patch to handle it, independent of the rebinding-the-Windows-key feature, would be welcome. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:53 ` Chong Yidong @ 2010-08-14 0:41 ` Jason Rumney 2010-08-14 1:24 ` Chong Yidong 2010-08-14 2:02 ` Drew Adams 0 siblings, 2 replies; 277+ messages in thread From: Jason Rumney @ 2010-08-14 0:41 UTC (permalink / raw) To: emacs-devel On 14/8/2010 12:53 AM, Chong Yidong wrote: > Lennart Borgman<lennart.borgman@gmail.com> writes: > >> Beside that it would not solve the problem that Emacs on w32 does not >> allow people which needs sticky keys to use it, i.e. it does not allow >> access for some disabled people. > This is an appropriate issue, and the patch to handle it, independent of > the rebinding-the-Windows-key feature, would be welcome. You misunderstand the purpose of Lennart's patch. The ability to rebind the windows and alt keys on w32 is already there, and has been since about 1996. Lennart's patch allows the user to forcibly reclaim keys that are being used for system wide functions, in a way that works for all keys (we already have a function that can reclaim some of those, but not Alt-Tab or some of the Windows key bindings). Lennart's patch is useful for users who continue to use the default of Alt bound to Meta as well as users who would prefer to move meta to one or both windows keys. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 0:41 ` Jason Rumney @ 2010-08-14 1:24 ` Chong Yidong 2010-08-14 2:13 ` Jason Rumney 2010-08-14 2:02 ` Drew Adams 1 sibling, 1 reply; 277+ messages in thread From: Chong Yidong @ 2010-08-14 1:24 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel Jason Rumney <jasonr@gnu.org> writes: >>> Beside that it would not solve the problem that Emacs on w32 does not >>> allow people which needs sticky keys to use it, i.e. it does not allow >>> access for some disabled people. >> This is an appropriate issue, and the patch to handle it, independent of >> the rebinding-the-Windows-key feature, would be welcome. > > You misunderstand the purpose of Lennart's patch. The ability to > rebind the windows and alt keys on w32 is already there, and has been > since about 1996. Lennart's patch allows the user to forcibly reclaim > keys that are being used for system wide functions, in a way that > works for all keys (we already have a function that can reclaim some > of those, but not Alt-Tab or some of the Windows key bindings). > Lennart's patch is useful for users who continue to use the default of > Alt bound to Meta as well as users who would prefer to move meta to > one or both windows keys. On X, Alt-TAB does not go to Emacs either; the window manager grabs it. I don't understand why it's proper for Emacs to "reclaim" the key. If it's not desireable for Alt-TAB to switch windows, the logical solution seems to be to tell the window manager to stop grabbing Alt-TAB, since it's the window manager that's at "fault". Also, I don't understand the relation between forcibly reclaiming operating system keys and the claim about sticky keys not behaving properly. Sticky keys are handled by the operating system; Emacs should not be able to tell (nor have to care) whether the `M-x' it received came from a sticky key. What am I missing? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 1:24 ` Chong Yidong @ 2010-08-14 2:13 ` Jason Rumney 0 siblings, 0 replies; 277+ messages in thread From: Jason Rumney @ 2010-08-14 2:13 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 14/8/2010 9:24 AM, Chong Yidong wrote: > On X, Alt-TAB does not go to Emacs either; the window manager grabs it. > I don't understand why it's proper for Emacs to "reclaim" the key. If > it's not desireable for Alt-TAB to switch windows, the logical solution > seems to be to tell the window manager to stop grabbing Alt-TAB, since > it's the window manager that's at "fault". That may well be the solution on X, but it is not a solution on Windows, so we have to provide solutions within Emacs. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-14 0:41 ` Jason Rumney 2010-08-14 1:24 ` Chong Yidong @ 2010-08-14 2:02 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Drew Adams @ 2010-08-14 2:02 UTC (permalink / raw) To: 'Jason Rumney', emacs-devel > we already have a function that can reclaim some of > those, but not Alt-Tab What am I missing about that? I use (w32-register-hot-key [M-tab]) and it lets me use ALT-TAB for M-TAB just fine. Did you mean something different from that? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:04 ` Lennart Borgman 2010-08-13 16:53 ` Chong Yidong @ 2010-08-13 22:43 ` Juanma Barranquero 2010-08-14 0:30 ` Jason Rumney 2 siblings, 0 replies; 277+ messages in thread From: Juanma Barranquero @ 2010-08-13 22:43 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Chong Yidong, emacs-devel On Fri, Aug 13, 2010 at 18:04, Lennart Borgman <lennart.borgman@gmail.com> wrote: > Beside that it would not solve the problem that Emacs on w32 does not > allow people which needs sticky keys to use it, i.e. it does not allow > access for some disabled people. You've been invited several times to provide a patch. There's no concerted attempt to keep this feature out of Emacs, as far as I know. Just no one has fixed it yet, except, apparently, you. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 16:04 ` Lennart Borgman 2010-08-13 16:53 ` Chong Yidong 2010-08-13 22:43 ` Juanma Barranquero @ 2010-08-14 0:30 ` Jason Rumney 2010-08-14 12:07 ` Lennart Borgman 2 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-14 0:30 UTC (permalink / raw) To: emacs-devel On 14/8/2010 12:04 AM, Lennart Borgman wrote: > Beside that it would not solve the problem that Emacs on w32 does not > allow people which needs sticky keys to use it, i.e. it does not allow > access for some disabled people. Can you please point me to the bug report where you explained this in detail. I have tried searching, and cannot find anything other than a report that the Alt key needs to be pressed twice to open the menu - which turned out to be the case for any program. As far as I can tell, sticky keys work perfectly fine with Emacs, but I don't have much experience with using them, so maybe I am missing something subtle that would prevent disabled people from using them. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 0:30 ` Jason Rumney @ 2010-08-14 12:07 ` Lennart Borgman 2010-08-14 13:56 ` Jason Rumney 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-14 12:07 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel On Sat, Aug 14, 2010 at 2:30 AM, Jason Rumney <jasonr@gnu.org> wrote: > On 14/8/2010 12:04 AM, Lennart Borgman wrote: > >> Beside that it would not solve the problem that Emacs on w32 does not >> allow people which needs sticky keys to use it, i.e. it does not allow >> access for some disabled people. > > Can you please point me to the bug report where you explained this in > detail. I have tried searching, and cannot find anything other than a > report that the Alt key needs to be pressed twice to open the menu - which > turned out to be the case for any program. As far as I can tell, sticky > keys work perfectly fine with Emacs, but I don't have much experience with > using them, so maybe I am missing something subtle that would prevent > disabled people from using them. I will try to, but can you please tell me first where you found this "pressed twice to open the menu"? Is this in a bug report, or? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 12:07 ` Lennart Borgman @ 2010-08-14 13:56 ` Jason Rumney 0 siblings, 0 replies; 277+ messages in thread From: Jason Rumney @ 2010-08-14 13:56 UTC (permalink / raw) To: Lennart Borgman; +Cc: emacs-devel On 14/8/2010 8:07 PM, Lennart Borgman wrote: > On Sat, Aug 14, 2010 at 2:30 AM, Jason Rumney<jasonr@gnu.org> wrote: >> Can you please point me to the bug report where you explained this in >> detail. I have tried searching, and cannot find anything other than a >> report that the Alt key needs to be pressed twice to open the menu - which >> turned out to be the case for any program. As far as I can tell, sticky >> keys work perfectly fine with Emacs, but I don't have much experience with >> using them, so maybe I am missing something subtle that would prevent >> disabled people from using them. > I will try to, but can you please tell me first where you found this > "pressed twice to open the menu"? Is this in a bug report, or? http://lists.gnu.org/archive/html/bug-gnu-emacs/2004-08/msg00296.html ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 23:19 ` Lennart Borgman 2010-08-08 23:42 ` Chong Yidong @ 2010-08-09 1:01 ` Juanma Barranquero 2010-08-09 8:48 ` Uday S Reddy 1 sibling, 1 reply; 277+ messages in thread From: Juanma Barranquero @ 2010-08-09 1:01 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, Chong Yidong, emacs-devel On Mon, Aug 9, 2010 at 01:19, Lennart Borgman <lennart.borgman@gmail.com> wrote: > - The most common use of it is to open the Start Menu. You can do that > with Ctrl-Esc too, at least on w32. I almost never use the Windows key to open the Start menu (strangely enough I tend to use the mouse for that). But I use it a lot for Run (W+r), Explorer (W+e), W+tab and the many Windows 7 W+cursor functions. Juanma ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-09 1:01 ` Juanma Barranquero @ 2010-08-09 8:48 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-09 8:48 UTC (permalink / raw) To: Juanma Barranquero Cc: Uday S Reddy, Chong Yidong, Lennart Borgman, emacs-devel Juanma Barranquero writes: > I almost never use the Windows key to open the Start menu (strangely > enough I tend to use the mouse for that). But I use it a lot for Run > (W+r), Explorer (W+e), W+tab and the many Windows 7 W+cursor > functions. That is nice. I never expected to be learning so much about Windows on the emacs-developers list! However, if everybody can recall the reason we got to this point, Lennart and I think that keyboard access to the Emacs menubar is important. Alt+letter is the normal mechanism on Windows to provide such keyboard access. One objection to making Alt+letter available in Emacs is that Alt is normally used as the Meta-key, which is important for Emacs use. So, those of us that find keyboard access to menubar important have to use some other key as the Meta-key. Windows logo key is the natural choice. We might have to give up the standard Windows key functionality in doing so. But we think that the other two needs, viz., (a) keyboard access to menus and (b) the Emacs meta-key functionality, take priority. Emacs doesn't have to many any decisions for us. It is just being asked to provide two options w32-lwindow-as-meta, w32-rwindow-as-meta which can be used to treat Windows keys as meta-keys. It that can be agreed, that would end this part of the discussion. (Phew!) Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 22:22 ` Chong Yidong 2010-08-08 22:29 ` Lennart Borgman @ 2010-08-09 8:13 ` Uday S Reddy 2010-08-10 7:52 ` Uday Reddy 2010-08-13 9:05 ` Uday S Reddy 3 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-09 8:13 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel Chong Yidong writes: > > I agree. After having thought about for a day, I realize that it is a > > perfectly logical thing to map Windows keys to Meta. It is wasted > > keyboard real estate otherwise. > > No, this is too idiosyncratic to make it the default. I don't think I ever said that the Windows keys should be made meta-keys by "default". I am only suggesting it as an option. Whether it is idiosyncratic, I don't know. As far as I know the only function of the Windows keys on Win32 is to invoke the start menu, which can already be done using C-Esc. I myself never use the Windows keys for anything and find them annoying because they are located at a strategic place on the keyboard, next to the Alt-keys. I end up pressing them often while trying to press an Alt-key. I have thought of disabling them many times, but I haven't invested the time to figure out how. If Lennart knows how to make them turn into Meta-keys, it seems like it is worthwhile doing it. > Doesn't the Windows world have some equivalent of `xmodmap'? That's the > conceptually correct way to handle this. I will look into that. It seems possible to map the Windows key to an Alt-key using key remapping (which can be done via Windows registry). But that might not achieve much, because Emacs will end up interpreting both sets of Alt-keys as Meta-keys. There is still work to do at the Emacs end. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 22:22 ` Chong Yidong 2010-08-08 22:29 ` Lennart Borgman 2010-08-09 8:13 ` Uday S Reddy @ 2010-08-10 7:52 ` Uday Reddy 2010-08-13 9:05 ` Uday S Reddy 3 siblings, 0 replies; 277+ messages in thread From: Uday Reddy @ 2010-08-10 7:52 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 8/8/2010 11:22 PM, Chong Yidong wrote: >> I agree. After having thought about for a day, I realize that it is a >> perfectly logical thing to map Windows keys to Meta. It is wasted >> keyboard real estate otherwise. > > No, this is too idiosyncratic to make it the default. There seems to be some amount of confusion here. Wikipedia http://en.wikipedia.org/wiki/Meta_key says that the Meta key is emulated on modern keyboards by either the Alt or Windows keys. The statement was written by "Cate" (http://en.wikipedia.org/wiki/User:Cate) and has been there since 2005. The Emacs manual says, "We refer to <Alt> as <Meta> for historical reasons" (Section 2.) Is Emacs imagining a strict connection between <Alt> and <Meta> which doesn't actually exist? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-08 22:22 ` Chong Yidong ` (2 preceding siblings ...) 2010-08-10 7:52 ` Uday Reddy @ 2010-08-13 9:05 ` Uday S Reddy 3 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-13 9:05 UTC (permalink / raw) To: Chong Yidong; +Cc: Uday S Reddy, emacs-devel Chong Yidong writes: > Even for non-default usage, putting Emacs in charge of the Windows key > seems unacceptable. This is the domain of the operating system. > > Doesn't the Windows world have some equivalent of `xmodmap'? That's the > conceptually correct way to handle this. I have been able to successfully use the Sharpkeys program http://www.randyrants.com/sharpkeys/ to remap Left windows (E0_5B) to Left Alt (00_38) Right windows (E0_5C) to Right Alt (E0_38) Works like a peach! Is there something else I can do to remap the windows keys to meta keys instead? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-03 11:56 ` Uday S Reddy 2010-08-03 14:04 ` Juanma Barranquero @ 2010-08-03 15:54 ` Stephen J. Turnbull 2010-08-04 9:52 ` Uday S Reddy 2010-08-04 12:57 ` Stefan Monnier 2 siblings, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-03 15:54 UTC (permalink / raw) To: Uday S Reddy; +Cc: 'Lennart Borgman', Drew Adams, emacs-devel Uday S Reddy writes: > When new users come to using a tool like Emacs, their first mode of > interaction is via the menubar, used with the mouse. The second might > be to use keyboard accelerators. Seems unlikely to me. If keyboard accelerators were so important, those users would all at least try XEmacs, which has integrated keyboard accelerators for a decade or so. In fact, a *lot* of effort was put into making XEmacs look and feel more familiar to the "new new user crowd" around the turn of the century: menu accelerators, sticky modifiers, tab controls, progress gauges, shifted motion extends selection, and on Windows, native dialogs for file selection, antialiased fonts, copy/cut/paste integration with the Windows clipboard, and a proper printer device.[1] But I've never seen a huge flood of new XEmacs users, and *no* new contributors, from that crowd. The new users are mostly the kind of folk who read software manuals for fun (or to pass the time when they're sitting where the sun don't shine). And the new contributors all read the manuals. > And, Emacs has to fit in. Why? > If people like Xah Lee or Lennart have to fork Emacs in order to > make it suitable to groups of users, That's not why they "have to" fork Emacs. They have to fork for other reasons, then as long as they're forked anyway, they redo the UI in their forks. BTW, you forgot David Reitter, who must fork because Aquamacs is dedicated to implementing features that make his proprietary platform (the Mac) more attractive for users than free platforms -- and such features are not allowed as a matter of Emacs policy. Nevertheless, he has over 50 credits in the Emacs ChangeLogs. Lennart has half as many. Xah Lee has *none*. Hmmm.... Footnotes: [1] I *think* these are all in 21.4, which was released in April 2001. But it's been a while since I used 21.4 regularly. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-03 15:54 ` Stephen J. Turnbull @ 2010-08-04 9:52 ` Uday S Reddy 2010-08-04 10:20 ` joakim 2010-08-04 10:54 ` Stephen J. Turnbull 0 siblings, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-04 9:52 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Uday S Reddy, Drew Adams, emacs-devel Stephen J. Turnbull writes: > Seems unlikely to me. If keyboard accelerators were so important, > those users would all at least try XEmacs, which has integrated > keyboard accelerators for a decade or so. In fact, a *lot* of effort > was put into making XEmacs look and feel more familiar to the "new new > user crowd" around the turn of the century: menu accelerators, > sticky modifiers, tab controls, progress gauges, shifted motion > extends selection, and on Windows, native dialogs for file selection, > antialiased fonts, copy/cut/paste integration with the Windows > clipboard, and a proper printer device.[1] And, believe me that all of these features were indeed quite useful to the new users. I recall now that it was XEmacs that we had set up in the labs and it was this that I had observed the students using in ways quite different from me. I had tried to get a few of the smarter ones to use the key bindings, and they tried things like C-o and C-s and gave up. If you already had keyboard accelerators of menus in 2001, well, thank you very much for it! But, it still requires extra RET key strokes to confirm selections. That is what I characterized as inefficient in my previous post, i.e., it is not good enough to serve as a substitute for key bindings. Coming back to the students, the vast majority of them switched to IDEs by the time they reached their final year. So, while we had done our bit by introducing them to Emacs, Emacs wasn't able to retain them due to its limitations. In this sense, the previous thread was right in focusing on the IDE support. > But I've never seen a huge flood of new XEmacs users, and *no* new > contributors, from that crowd. The new users are mostly the kind of > folk who read software manuals for fun (or to pass the time when > they're sitting where the sun don't shine). And the new contributors > all read the manuals. You are obviously right about that. However, I don't agree with the conclusion. The user base is still needed to motivate contributors to find it worthwhile to come forward. Mozilla and Eclipse have armies of contributors, not because they have great manuals but because they have large user bases. > > And, Emacs has to fit in. > > Why? Because, otherwise, you raise the barrier to entry so high that only a small minority of potential users will be able to get through. Cheers, Uday PS: Sorry that I haven't gotten around to replying to your other posts. But I am thinking... ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 9:52 ` Uday S Reddy @ 2010-08-04 10:20 ` joakim 2010-08-04 10:52 ` Lennart Borgman ` (2 more replies) 2010-08-04 10:54 ` Stephen J. Turnbull 1 sibling, 3 replies; 277+ messages in thread From: joakim @ 2010-08-04 10:20 UTC (permalink / raw) To: Uday S Reddy; +Cc: Stephen J. Turnbull, Drew Adams, emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > Stephen J. Turnbull writes: > >> Seems unlikely to me. If keyboard accelerators were so important, >> those users would all at least try XEmacs, which has integrated >> keyboard accelerators for a decade or so. In fact, a *lot* of effort >> was put into making XEmacs look and feel more familiar to the "new new >> user crowd" around the turn of the century: menu accelerators, >> sticky modifiers, tab controls, progress gauges, shifted motion >> extends selection, and on Windows, native dialogs for file selection, >> antialiased fonts, copy/cut/paste integration with the Windows >> clipboard, and a proper printer device.[1] > > And, believe me that all of these features were indeed quite useful to > the new users. I recall now that it was XEmacs that we had set up in > the labs and it was this that I had observed the students using in > ways quite different from me. I had tried to get a few of the smarter > ones to use the key bindings, and they tried things like C-o and C-s > and gave up. > > If you already had keyboard accelerators of menus in 2001, well, thank > you very much for it! But, it still requires extra RET key strokes to > confirm selections. That is what I characterized as inefficient in my > previous post, i.e., it is not good enough to serve as a substitute > for key bindings. I dont understand this. I normaly have menus disabled, but I enabled them now to see. In the File menu I have an entry like: "Visit new file... C-x C-f" Isn't that a "keyboard accelerator"? I note that Firefox does the same thing for this menu entry: "bookmarks/organize bookmarks ctrl+shif+o" Or do you mean there is no obvious way to traverse the menus from the keyboard? Could we then promote the use of F10 already in the menu bar text? (f10 is bound to menu-bar-open here) perhaps like the 1st line of the help menu or something: "Use F10 to start traversing menus with kbd" > > Coming back to the students, the vast majority of them switched to > IDEs by the time they reached their final year. So, while we had done > our bit by introducing them to Emacs, Emacs wasn't able to retain them > due to its limitations. In this sense, the previous thread was right > in focusing on the IDE support. > >> But I've never seen a huge flood of new XEmacs users, and *no* new >> contributors, from that crowd. The new users are mostly the kind of >> folk who read software manuals for fun (or to pass the time when >> they're sitting where the sun don't shine). And the new contributors >> all read the manuals. > > You are obviously right about that. However, I don't agree with the > conclusion. The user base is still needed to motivate contributors to > find it worthwhile to come forward. Mozilla and Eclipse have armies > of contributors, not because they have great manuals but because they > have large user bases. > >> > And, Emacs has to fit in. >> >> Why? > > Because, otherwise, you raise the barrier to entry so high that only a > small minority of potential users will be able to get through. > > Cheers, > Uday > > PS: Sorry that I haven't gotten around to replying to your other > posts. But I am thinking... > -- Joakim Verona ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 10:20 ` joakim @ 2010-08-04 10:52 ` Lennart Borgman 2010-08-04 11:11 ` joakim 2010-08-04 11:19 ` Jan Djärv 2010-08-04 11:16 ` Uday S Reddy 2010-08-04 13:15 ` Jason Rumney 2 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 10:52 UTC (permalink / raw) To: joakim; +Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, emacs-devel On Wed, Aug 4, 2010 at 12:20 PM, <joakim@verona.se> wrote: > > I dont understand this. I normaly have menus disabled, but I enabled > them now to see. In the File menu I have an entry like: > > "Visit new file... C-x C-f" > > Isn't that a "keyboard accelerator"? Yes, but it is not menu accelerators. Those are underlined chars in the menus. (At least on w32 all applications I know of have them, except Emacs.) > Or do you mean there is no obvious way to traverse the menus from the > keyboard? Could we then promote the use of F10 already in the menu bar > text? (f10 is bound to menu-bar-open here) > > perhaps like the 1st line of the help menu or something: > > "Use F10 to start traversing menus with kbd" That is not the standard way to access menus (at least not on w32). You normally use the Alt key to access them. (Here too it is important to notice that with all applications I know of on w32 you can access menus that way. Except Emacs.) Maybe it is still good to tell about f10 since most non-Emacs users are not aware of that. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 10:52 ` Lennart Borgman @ 2010-08-04 11:11 ` joakim 2010-08-04 11:25 ` Lennart Borgman 2010-08-04 11:19 ` Jan Djärv 1 sibling, 1 reply; 277+ messages in thread From: joakim @ 2010-08-04 11:11 UTC (permalink / raw) To: Lennart Borgman Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > On Wed, Aug 4, 2010 at 12:20 PM, <joakim@verona.se> wrote: >> >> I dont understand this. I normaly have menus disabled, but I enabled >> them now to see. In the File menu I have an entry like: >> >> "Visit new file... C-x C-f" >> >> Isn't that a "keyboard accelerator"? > > Yes, but it is not menu accelerators. Those are underlined chars in > the menus. (At least on w32 all applications I know of have them, > except Emacs.) But did you snip the part about how firefox does it here? Firefox does the same thing as emacs, it only uses "menu accelerators" when it doesnt provide a specific keybinding. see the "organize bookmarks" example. Anyway, I'm not expressing an opinion on the merits of the various menu systems as I never use them. I just tried to add a data point. (As a side-note I always want to try to emacsify a program rather than programify emacs, so I do understand the urge to arrive at a consistent overall environment) >> Or do you mean there is no obvious way to traverse the menus from the >> keyboard? Could we then promote the use of F10 already in the menu bar >> text? (f10 is bound to menu-bar-open here) >> >> perhaps like the 1st line of the help menu or something: >> >> "Use F10 to start traversing menus with kbd" > > That is not the standard way to access menus (at least not on w32). > You normally use the Alt key to access them. (Here too it is important > to notice that with all applications I know of on w32 you can access > menus that way. Except Emacs.) > Maybe it is still good to tell about f10 since most non-Emacs users > are not aware of that. I wasnt either. I sort of just stumbled about the keyboard to see if something activated menu traversal :) Anyway, what would you do with emacs normal use of alt then? Should alt be an emacs event in itself? Maybe this is possible already? As another related side-note I would like to experiment with modal keybindings in Emacs, to implement something like ctrl-lock functionality. That would I suppose be similar to your use-case for the alt key. -- Joakim Verona ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:11 ` joakim @ 2010-08-04 11:25 ` Lennart Borgman 2010-08-04 11:44 ` joakim 2010-08-04 13:24 ` Jason Rumney 0 siblings, 2 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 11:25 UTC (permalink / raw) To: joakim; +Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, emacs-devel On Wed, Aug 4, 2010 at 1:11 PM, <joakim@verona.se> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> On Wed, Aug 4, 2010 at 12:20 PM, <joakim@verona.se> wrote: >>> >>> I dont understand this. I normaly have menus disabled, but I enabled >>> them now to see. In the File menu I have an entry like: >>> >>> "Visit new file... C-x C-f" >>> >>> Isn't that a "keyboard accelerator"? >> >> Yes, but it is not menu accelerators. Those are underlined chars in >> the menus. (At least on w32 all applications I know of have them, >> except Emacs.) > > But did you snip the part about how firefox does it here? > > Firefox does the same thing as emacs, it only uses "menu accelerators" > when it doesnt provide a specific keybinding. No. At least on w32 it normally shows both keyboard and menu accelerators in the menus. See the "View" submenu for example. > see the "organize bookmarks" example. That is a bit special since it is a list of your bookmarks. (Also a lot of add-ons in Firefox does not add menu accelerators the way the are supposed. Some add them when they should not and others omit them when they should add them.) > (As a side-note I always want to try to emacsify a program rather than > programify emacs, so I do understand the urge to arrive at a consistent > overall environment) Is not that quite a lot more work ... ;-) >>> Or do you mean there is no obvious way to traverse the menus from the >>> keyboard? Could we then promote the use of F10 already in the menu bar >>> text? (f10 is bound to menu-bar-open here) >>> >>> perhaps like the 1st line of the help menu or something: >>> >>> "Use F10 to start traversing menus with kbd" >> >> That is not the standard way to access menus (at least not on w32). >> You normally use the Alt key to access them. (Here too it is important >> to notice that with all applications I know of on w32 you can access >> menus that way. Except Emacs.) >> Maybe it is still good to tell about f10 since most non-Emacs users >> are not aware of that. > > I wasnt either. I sort of just stumbled about the keyboard to see if > something activated menu traversal :) > > Anyway, what would you do with emacs normal use of alt then? In my patched version of Emacs on w32 you can use the left and/or right window keys as alt instead. Some people here has said that this is just as bad since that overrides the normal use of those keys. I do not agree for two reasons: - microsoft has made it possible to override those keys totally, while you can not totally override the alt key. - using the alt key is far more common than using the windows key. > Should alt be an emacs event in itself? Maybe this is possible already? See above. > As another related side-note I would like to experiment with modal keybindings > in Emacs, to implement something like ctrl-lock functionality. That > would I suppose be similar to your use-case for the alt key. Except that the window manager does not let you handle all key combinations with the Alt key. (You can not override for example Alt-Tab on w32. And that is a good thing in my opinion.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:25 ` Lennart Borgman @ 2010-08-04 11:44 ` joakim 2010-08-04 13:24 ` Jason Rumney 1 sibling, 0 replies; 277+ messages in thread From: joakim @ 2010-08-04 11:44 UTC (permalink / raw) To: Lennart Borgman Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > On Wed, Aug 4, 2010 at 1:11 PM, <joakim@verona.se> wrote: >> Lennart Borgman <lennart.borgman@gmail.com> writes: >> >>> On Wed, Aug 4, 2010 at 12:20 PM, <joakim@verona.se> wrote: >>>> >>>> I dont understand this. I normaly have menus disabled, but I enabled >>>> them now to see. In the File menu I have an entry like: >>>> >>>> "Visit new file... C-x C-f" >>>> >>>> Isn't that a "keyboard accelerator"? >>> >>> Yes, but it is not menu accelerators. Those are underlined chars in >>> the menus. (At least on w32 all applications I know of have them, >>> except Emacs.) >> >> But did you snip the part about how firefox does it here? >> >> Firefox does the same thing as emacs, it only uses "menu accelerators" >> when it doesnt provide a specific keybinding. > > No. At least on w32 it normally shows both keyboard and menu > accelerators in the menus. See the "View" submenu for example. > >> see the "organize bookmarks" example. > > That is a bit special since it is a list of your bookmarks. > > (Also a lot of add-ons in Firefox does not add menu accelerators the > way the are supposed. Some add them when they should not and others > omit them when they should add them.) > >> (As a side-note I always want to try to emacsify a program rather than >> programify emacs, so I do understand the urge to arrive at a consistent >> overall environment) > > Is not that quite a lot more work ... ;-) > >>>> Or do you mean there is no obvious way to traverse the menus from the >>>> keyboard? Could we then promote the use of F10 already in the menu bar >>>> text? (f10 is bound to menu-bar-open here) >>>> >>>> perhaps like the 1st line of the help menu or something: >>>> >>>> "Use F10 to start traversing menus with kbd" >>> >>> That is not the standard way to access menus (at least not on w32). >>> You normally use the Alt key to access them. (Here too it is important >>> to notice that with all applications I know of on w32 you can access >>> menus that way. Except Emacs.) >>> Maybe it is still good to tell about f10 since most non-Emacs users >>> are not aware of that. >> >> I wasnt either. I sort of just stumbled about the keyboard to see if >> something activated menu traversal :) >> >> Anyway, what would you do with emacs normal use of alt then? > > In my patched version of Emacs on w32 you can use the left and/or > right window keys as alt instead. > > Some people here has said that this is just as bad since that > overrides the normal use of those keys. I do not agree for two > reasons: > > - microsoft has made it possible to override those keys totally, while > you can not totally override the alt key. > - using the alt key is far more common than using the windows key. > >> Should alt be an emacs event in itself? Maybe this is possible already? > > See above. > >> As another related side-note I would like to experiment with modal keybindings >> in Emacs, to implement something like ctrl-lock functionality. That >> would I suppose be similar to your use-case for the alt key. > > Except that the window manager does not let you handle all key > combinations with the Alt key. (You can not override for example > Alt-Tab on w32. And that is a good thing in my opinion.) My particular interest is not in making Emacs fit a particular WM such as W32 or Metacity or Compiz. My interest is making Emacs be able to do things a WM does, but more, for example "m-x inkscape-set-object-fill-color". Anyway, that is stuff for another thread, so I bow out of this thread now. -- Joakim Verona ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:25 ` Lennart Borgman 2010-08-04 11:44 ` joakim @ 2010-08-04 13:24 ` Jason Rumney 2010-08-04 13:29 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-04 13:24 UTC (permalink / raw) To: Lennart Borgman Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, joakim, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > In my patched version of Emacs on w32 you can use the left and/or > right window keys as alt instead. > > Some people here has said that this is just as bad since that > overrides the normal use of those keys. I do not agree for two > reasons: > > - microsoft has made it possible to override those keys totally, while > you can not totally override the alt key. > - using the alt key is far more common than using the windows key. Your opinion differs from many people on both accounts. To override the Windows keys, you have had to use a low level keyboard hook to catch the key before the normal Windows input event handling takes place. This is required to catch about half a dozen bindings that Windows does not let you override in the officially supported way (which is used by w32-register-hot-key). OTOH, the only Alt keybinding that requires such hackery is Alt-TAB. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 13:24 ` Jason Rumney @ 2010-08-04 13:29 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 13:29 UTC (permalink / raw) To: Jason Rumney Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, joakim, emacs-devel On Wed, Aug 4, 2010 at 3:24 PM, Jason Rumney <jasonr@gnu.org> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> In my patched version of Emacs on w32 you can use the left and/or >> right window keys as alt instead. >> >> Some people here has said that this is just as bad since that >> overrides the normal use of those keys. I do not agree for two >> reasons: >> >> - microsoft has made it possible to override those keys totally, while >> you can not totally override the alt key. >> - using the alt key is far more common than using the windows key. > > Your opinion differs from many people on both accounts. I think ms agree with me on both... > To override the Windows keys, you have had to use a low level keyboard > hook to catch the key before the normal Windows input event handling > takes place. This is required to catch about half a dozen bindings that > Windows does not let you override in the officially supported way (which > is used by w32-register-hot-key). The low level keyboard hook is the only supported way as far as I know. There were other ways before, but I think ms dropped them since they were not secure. (Is not hot keys for a different situation?) > OTOH, the only Alt keybinding that requires such hackery is Alt-TAB. No. Alt-TAB can not be overrided by low level keyboard hooks on w32. That is stated in ms documentation. (I have sent links to this long ago.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 10:52 ` Lennart Borgman 2010-08-04 11:11 ` joakim @ 2010-08-04 11:19 ` Jan Djärv 2010-08-04 11:27 ` Lennart Borgman 1 sibling, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-04 11:19 UTC (permalink / raw) To: Lennart Borgman Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, joakim, emacs-devel 2010-08-04 12:52, Lennart Borgman skrev: > On Wed, Aug 4, 2010 at 12:20 PM,<joakim@verona.se> wrote: > >> Or do you mean there is no obvious way to traverse the menus from the >> keyboard? Could we then promote the use of F10 already in the menu bar >> text? (f10 is bound to menu-bar-open here) >> >> perhaps like the 1st line of the help menu or something: >> >> "Use F10 to start traversing menus with kbd" > > That is not the standard way to access menus (at least not on w32). F10 on W32 does start keyboard traversal on menus on Microsoft applications and others, and it is listed here: http://support.microsoft.com/kb/301583. How more standard does it get? The difference between for example Gnome is that Gnome opens the first menu, but W32 does not. > > Maybe it is still good to tell about f10 since most non-Emacs users > are not aware of that. If they used Gnome or W32 they should be. Don't know about KDE though. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:19 ` Jan Djärv @ 2010-08-04 11:27 ` Lennart Borgman 2010-08-04 13:27 ` Jason Rumney 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 11:27 UTC (permalink / raw) To: Jan Djärv Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, joakim, emacs-devel On Wed, Aug 4, 2010 at 1:19 PM, Jan Djärv <jan.h.d@swipnet.se> wrote: > 2010-08-04 12:52, Lennart Borgman skrev: >> >> On Wed, Aug 4, 2010 at 12:20 PM,<joakim@verona.se> wrote: > >> >>> Or do you mean there is no obvious way to traverse the menus from the >>> keyboard? Could we then promote the use of F10 already in the menu bar >>> text? (f10 is bound to menu-bar-open here) >>> >>> perhaps like the 1st line of the help menu or something: >>> >>> "Use F10 to start traversing menus with kbd" >> >> That is not the standard way to access menus (at least not on w32). > > F10 on W32 does start keyboard traversal on menus on Microsoft applications > and others, and it is listed here: http://support.microsoft.com/kb/301583. > How more standard does it get? The difference between for example Gnome is > that Gnome opens the first menu, but W32 does not. OK, I should of course have written "normal way". Most users on w32 never ever use f10 to access the menus. They use the Alt key. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:27 ` Lennart Borgman @ 2010-08-04 13:27 ` Jason Rumney 2010-08-04 13:45 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-04 13:27 UTC (permalink / raw) To: Lennart Borgman Cc: Uday S Reddy, joakim, emacs-devel, Stephen J. Turnbull, Jan Djärv, Drew Adams Lennart Borgman <lennart.borgman@gmail.com> writes: > OK, I should of course have written "normal way". Most users on w32 > never ever use f10 to access the menus. They use the Alt key. Have you polled them? Most users on w32 that I've met only ever use the mouse. But that is just anecdotal evidence, and I wouldn't pretend to guess what proportion of those who use the keyboard use F10 vs Alt vs the Ctrl shortcuts. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 13:27 ` Jason Rumney @ 2010-08-04 13:45 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 13:45 UTC (permalink / raw) To: Jason Rumney Cc: Uday S Reddy, joakim, emacs-devel, Stephen J. Turnbull, Jan Djärv, Drew Adams On Wed, Aug 4, 2010 at 3:27 PM, Jason Rumney <jasonr@gnu.org> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> OK, I should of course have written "normal way". Most users on w32 >> never ever use f10 to access the menus. They use the Alt key. > > Have you polled them? No, of course not. > Most users on w32 that I've met only ever use the mouse. But that is > just anecdotal evidence, and I wouldn't pretend to guess what proportion > of those who use the keyboard use F10 vs Alt vs the Ctrl shortcuts. Yes, but keyboard users might prefer Alt since that is easier to reach than f10. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 10:20 ` joakim 2010-08-04 10:52 ` Lennart Borgman @ 2010-08-04 11:16 ` Uday S Reddy 2010-08-04 11:28 ` Andreas Schwab 2010-08-04 13:53 ` Stephen J. Turnbull 2010-08-04 13:15 ` Jason Rumney 2 siblings, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-04 11:16 UTC (permalink / raw) To: joakim; +Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, emacs-devel joakim@verona.se writes: > I dont understand this. I normaly have menus disabled, but I enabled > them now to see. In the File menu I have an entry like: > > "Visit new file... C-x C-f" > > Isn't that a "keyboard accelerator"? No, that is what I have been calling a "key binding". The "keyboard acceleration" (Stephen's term) is what you get by menu-bar-open. (Sorry, I didn't realize that it was bound to <F10>. I had disabled <F10> for some reason.) So, "<F10> f v" gets you to find file, and you don't need to remember C-x C-f. There, "f" is for "File" and "v" is for "Visit...". The problem I am pointing out is that using the first letter of the menu titles/entries is kind of a "poor man's keyboard acceleration". It breaks whenever there are other titles and entries beginning with the same letter. Then the user has to repeat the key stroke to get to the right entry and hit RET to confirm a selection. Lennart's menu accelerators, which are standard on Windows applications, provide designated key strokes as the access points for each menu title and entry. In the Firefox file menu, for instance, you will find: N underlined in New Window C+N T underlined in New Tab C+T The developers chose different keys as the access points for these two menu items so that there is no conflict between. If Gnu Emacs were to do the same menu, there would be conflict. I made a mistake in my previous response to Stephen, it seems. XEmacs does provide menu accelerators and it probably did it since 2001. So, the infrastructure has been there. However, the menus don't seem to have been designed all that carefully to avoid conflicts. (I got fooled because the examples that I tried all had conflicts.) When menus are designed carefully to avoid conflict, keyboard accelerators become competitive with key bindings. Then one doesn't need to remember key bindings any more. That can make a BIG difference. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:16 ` Uday S Reddy @ 2010-08-04 11:28 ` Andreas Schwab 2010-08-04 11:36 ` Uday S Reddy 2010-08-04 13:53 ` Stephen J. Turnbull 1 sibling, 1 reply; 277+ messages in thread From: Andreas Schwab @ 2010-08-04 11:28 UTC (permalink / raw) To: Uday S Reddy; +Cc: Stephen J. Turnbull, Drew Adams, joakim, emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > When menus are designed carefully to avoid conflict, keyboard > accelerators become competitive with key bindings. Then one doesn't > need to remember key bindings any more. So you have to remember menu entries. Big deal. Key bindings don't change with the text in the menu entries, and are customizable. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:28 ` Andreas Schwab @ 2010-08-04 11:36 ` Uday S Reddy 2010-08-04 12:03 ` Andreas Schwab 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-04 11:36 UTC (permalink / raw) To: Andreas Schwab Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, joakim, emacs-devel Andreas Schwab writes: > So you have to remember menu entries. Big deal. Key bindings don't > change with the text in the menu entries, and are customizable. That is exactly the kind of resistance that people are complaining about. It may not be a big deal for you, but it might be for others. Further, I don't think the argument has validity. You don't have to "remember" the menu entries. You can see them! At least in Emacs, menubars are just as customizable as key bindings are. Or, did I get it wrong? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:36 ` Uday S Reddy @ 2010-08-04 12:03 ` Andreas Schwab 2010-08-04 12:09 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 277+ messages in thread From: Andreas Schwab @ 2010-08-04 12:03 UTC (permalink / raw) To: Uday S Reddy; +Cc: Stephen J. Turnbull, Drew Adams, joakim, emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > Further, I don't think the argument has validity. You don't have to > "remember" the menu entries. You can see them! You have to remember where to search, and do search for them. And if you change the language you are screwed. What a stupid concept. > At least in Emacs, menubars are just as customizable as key bindings > are. Or, did I get it wrong? In Emacs you have key bindings and M-x, no need for menus. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 12:03 ` Andreas Schwab @ 2010-08-04 12:09 ` Lennart Borgman 2010-08-04 12:13 ` Andreas Schwab 2010-08-04 12:33 ` Uday S Reddy 2010-08-04 14:06 ` Stephen J. Turnbull 2 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 12:09 UTC (permalink / raw) To: Andreas Schwab Cc: Uday S Reddy, Stephen J. Turnbull, joakim, Drew Adams, emacs-devel On Wed, Aug 4, 2010 at 2:03 PM, Andreas Schwab <schwab@linux-m68k.org> wrote: > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > >> Further, I don't think the argument has validity. You don't have to >> "remember" the menu entries. You can see them! > > You have to remember where to search, and do search for them. And if > you change the language you are screwed. What a stupid concept. When someone says "stupid" I always get interested. What have that person got wrong? There is always a reason. Look for that. A lot of users thinks the current behavior in other applications is good and wants it. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 12:09 ` Lennart Borgman @ 2010-08-04 12:13 ` Andreas Schwab 2010-08-04 12:17 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Andreas Schwab @ 2010-08-04 12:13 UTC (permalink / raw) To: Lennart Borgman Cc: Uday S Reddy, Stephen J. Turnbull, joakim, Drew Adams, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > There is always a reason. Look for that. A lot of users thinks the > current behavior in other applications is good and wants it. They only know what they are offered. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 12:13 ` Andreas Schwab @ 2010-08-04 12:17 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 12:17 UTC (permalink / raw) To: Andreas Schwab Cc: Uday S Reddy, Stephen J. Turnbull, joakim, Drew Adams, emacs-devel On Wed, Aug 4, 2010 at 2:13 PM, Andreas Schwab <schwab@linux-m68k.org> wrote: > Lennart Borgman <lennart.borgman@gmail.com> writes: > >> There is always a reason. Look for that. A lot of users thinks the >> current behavior in other applications is good and wants it. > > They only know what they are offered. That does not mean that they do not have a good reason to like it. And isn't there research behind this? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 12:03 ` Andreas Schwab 2010-08-04 12:09 ` Lennart Borgman @ 2010-08-04 12:33 ` Uday S Reddy 2010-08-04 16:19 ` Tom 2010-08-04 14:06 ` Stephen J. Turnbull 2 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-04 12:33 UTC (permalink / raw) To: Andreas Schwab Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, joakim, emacs-devel Andreas Schwab writes: > You have to remember where to search, and do search for them. And if > you change the language you are screwed. What a stupid concept. People seem good at doing that kind of search. Yes, I agree that menus have to be designed for each language. That is a drag. I wonder why people use different languages '-). > In Emacs you have key bindings and M-x, no need for menus. Yes, that is one "language". Nobody denies that! Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 12:33 ` Uday S Reddy @ 2010-08-04 16:19 ` Tom 2010-08-04 17:38 ` Stuart Hacking 2010-08-05 2:28 ` Chong Yidong 0 siblings, 2 replies; 277+ messages in thread From: Tom @ 2010-08-04 16:19 UTC (permalink / raw) To: emacs-devel Uday S Reddy <u.s.reddy <at> cs.bham.ac.uk> writes: > > > In Emacs you have key bindings and M-x, no need for menus. > > Yes, that is one "language". Nobody denies that! > Which brings the question: is Emacs only targeted to English-speaking users? Internationalization is a natural feature of modern software. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 16:19 ` Tom @ 2010-08-04 17:38 ` Stuart Hacking 2010-08-05 2:39 ` Stephen J. Turnbull 2010-08-05 2:28 ` Chong Yidong 1 sibling, 1 reply; 277+ messages in thread From: Stuart Hacking @ 2010-08-04 17:38 UTC (permalink / raw) To: Tom; +Cc: emacs-devel On 4 Aug 2010, at 17:19, Tom wrote: > Uday S Reddy <u.s.reddy <at> cs.bham.ac.uk> writes: >> >>> In Emacs you have key bindings and M-x, no need for menus. >> >> Yes, that is one "language". Nobody denies that! >> > > Which brings the question: is Emacs only targeted to English-speaking > users? Internationalization is a natural feature of modern software. > > > Just a few thoughts: Won't we encounter problems due to much of Emacs' UI being closely tied to the underlying source code? Even in software that is localised, the source code is usually in English. Emacs goes a step further by having much documentation written inline with the code. A lot of the emacs documentation comes from source code doc-strings, command names, arguments. As I see it, we could at best hope for partial localisation. It would be a large effort to achieve 100%. Tasks (and issues): * Translate Info Files There's a lot of this type of documentation for the manuals, but translating it wouldn't impact functionality. * Translate function documentation Documentation strings are inline with the actual code. Thus, translation would mean either duplicating all the libraries (no), separating the documentation from the code (no), or keeping the English documentation with the code, but translating it and implementing a build process that will do the compile time substitution? * Translate the function names Probably not even necessary. * Translate the menu items and other UI strings Are any of these generated from function names? For inline strings, perhaps they could be extracted - but would this make it harder to read the code? Perhaps the same suggestion as the inline documentation applies? (leaving the english, but implementing a string substitution process) I think there would be not insignificant changes to the build process and possibly some re-architecturing where string management is concerned. Is there a big demand for localisation? --Stuart ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 17:38 ` Stuart Hacking @ 2010-08-05 2:39 ` Stephen J. Turnbull 2010-08-05 8:16 ` Stuart Hacking 2010-08-05 8:34 ` Andreas Schwab 0 siblings, 2 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-05 2:39 UTC (permalink / raw) To: Stuart Hacking; +Cc: Tom, emacs-devel Stuart Hacking writes: > On 4 Aug 2010, at 17:19, Tom wrote: > > Which brings the question: is Emacs only targeted to English-speaking > > users? Internationalization is a natural feature of modern software. No, it's not "natural". Look at Wikipedia, which grows "naturally" -- and with separation of language at the top level. Localization, ie, compartmentalization, is easy and natural. But the infrastructure needs to be internationalized, which is unnatural and a lot of work. Fortunately most of that work can be done incrementally. > Just a few thoughts: > > Won't we encounter problems due to much of Emacs' UI being closely > tied to the underlying source code? Yes. But UI internationalization is a solved problem. There are some Emacs-specific problems such as "Russian Ctrl-X" (on a Cyrillic keyboard, the user doesn't think of the key as "X" -- is C-x defined by the row/column position on the keyboard, or by the label on the key?) But these are basically at the level of inconvenience (even to the Russian users, according to what I've read). The real problems are in getting LISP to be internationalized, ie, integrating string-handling with gettext. Should concat look up strings? Should the LISP interpreter do it when passing args? etc. That is a fairly delicate design problem. > Even in software that is localised, the source code is usually in > English. Emacs goes a step further by having much documentation > written inline with the code. > > A lot of the emacs documentation comes from source code > doc-strings, command names, arguments. As I see it, we could at > best hope for partial localisation. It would be a large effort to > achieve 100%. Docstrings are a solved problem, by gettext. Even translating them is a solved problem, there are several projects which will help, and it can be done incrementally. Ditto Info files and the like. > I think there would be not insignificant changes to the build > process and possibly some re-architecturing where string management > is concerned. Is there a big demand for localisation? I don't think either the build process or string storage is a big issue. There may be technical issues in the latter due to string compaction in garbage collection, but they're probably pretty straighforward. Yes, there is a big demand for localization. Most Japanese and Chinese programmers speak English very poorly, and read it only with a fair amount of effort. Even a surprisingly large number of Indians have some trouble with English. If Uday Reddy is right that many users means many recruits, well, there are probably 50 million potential users Emacs could reach with better localization. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 2:39 ` Stephen J. Turnbull @ 2010-08-05 8:16 ` Stuart Hacking 2010-08-05 8:34 ` Andreas Schwab 1 sibling, 0 replies; 277+ messages in thread From: Stuart Hacking @ 2010-08-05 8:16 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Tom, emacs-devel On 5 August 2010 03:39, Stephen J. Turnbull <stephen@xemacs.org> wrote: > Yes. But UI internationalization is a solved problem. > > Docstrings are a solved problem, by gettext. Even translating them is > a solved problem, there are several projects which will help, and it > can be done incrementally. > > Ditto Info files and the like. > I wasn't aware of this, thanks for the reading suggestions. :) > Yes, there is a big demand for localization. Most Japanese and > Chinese programmers speak English very poorly, and read it only with a > fair amount of effort. Even a surprisingly large number of Indians > have some trouble with English. If Uday Reddy is right that many > users means many recruits, well, there are probably 50 million > potential users Emacs could reach with better localization. > I'd say that makes it more than worthwhile. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 2:39 ` Stephen J. Turnbull 2010-08-05 8:16 ` Stuart Hacking @ 2010-08-05 8:34 ` Andreas Schwab 2010-08-05 11:55 ` Stephen J. Turnbull 1 sibling, 1 reply; 277+ messages in thread From: Andreas Schwab @ 2010-08-05 8:34 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Stuart Hacking, Tom, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > The real problems are in getting LISP to be internationalized, ie, > integrating string-handling with gettext. Should concat look up > strings? Should the LISP interpreter do it when passing args? etc. Of course not. Strings are to be translated when they are presented to the user, which is a high level concept. Translatable strings must be explicitly marked. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 8:34 ` Andreas Schwab @ 2010-08-05 11:55 ` Stephen J. Turnbull 2010-08-05 12:20 ` Andreas Schwab 0 siblings, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-05 11:55 UTC (permalink / raw) To: Andreas Schwab; +Cc: Stuart Hacking, Tom, emacs-devel Andreas Schwab writes: > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > The real problems are in getting LISP to be internationalized, ie, > > integrating string-handling with gettext. Should concat look up > > strings? Should the LISP interpreter do it when passing args? etc. > > Of course not. Strings are to be translated when they are presented to > the user, which is a high level concept. Translatable strings must be > explicitly marked. Marked, yes. That's the way gettext works from the programmer's standpoint. In C, that translates to a function call. Cheap. Function calls are not so cheap in LISP, though, nor is allocating strings. And while you perhaps might be happy with code like (defun parental-warning (dependents) (format (gettext "It's %s %s; do you know where your %s are?") (format-time-string "%I") ; URK URK URK! is this right? ; not everybody uses Arabic numerals! (gettext (format-time-string "%p")) ; or is this f-t-s's job? (gettext dependents))) I sure hope Emacs can do better. Eg, it might make sense to have either the interpreter or certain subrs call gettext on marked strings (where the marking is done by the LISP reader on literals). Or it might make sense to have *un*marked strings automatically translated in those contexts. And "high-level"? Maybe, maybe not. In some important cases it may make sense to assemble a large variable string from many pieces. It is not at all obvious to me that passing all strings to top level, where they are translated then concatenated, is always possible, let alone always a sane way to organize a program. P.S. (defsubst _ (s) (gettext s)) doesn't cut it, except as a last resort. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 11:55 ` Stephen J. Turnbull @ 2010-08-05 12:20 ` Andreas Schwab 2010-08-05 12:37 ` Stephen J. Turnbull 0 siblings, 1 reply; 277+ messages in thread From: Andreas Schwab @ 2010-08-05 12:20 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Stuart Hacking, Tom, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > In some important cases it may make sense to assemble a large variable > string from many pieces. Not if you want to be i18n friendly. > It is not at all obvious to me that passing all strings to top level, > where they are translated then concatenated, is always possible Almost never (unless the parts are independent, full sentences). Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 12:20 ` Andreas Schwab @ 2010-08-05 12:37 ` Stephen J. Turnbull 2010-08-05 12:47 ` Andreas Schwab 0 siblings, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-05 12:37 UTC (permalink / raw) To: Andreas Schwab; +Cc: Stuart Hacking, Tom, emacs-devel Andreas Schwab writes: > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > > In some important cases it may make sense to assemble a large variable > > string from many pieces. > > Not if you want to be i18n friendly. Friends are as friends do. "I18N" is a computer program, it should dance to *my* tune, not vice versa. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 12:37 ` Stephen J. Turnbull @ 2010-08-05 12:47 ` Andreas Schwab 0 siblings, 0 replies; 277+ messages in thread From: Andreas Schwab @ 2010-08-05 12:47 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Stuart Hacking, Tom, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Friends are as friends do. "I18N" is a computer program, it should > dance to *my* tune, not vice versa. i18n is about natural languages, not programming languages. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 16:19 ` Tom 2010-08-04 17:38 ` Stuart Hacking @ 2010-08-05 2:28 ` Chong Yidong 2010-08-05 3:14 ` Stephen J. Turnbull 2010-08-05 14:01 ` Richard Stallman 1 sibling, 2 replies; 277+ messages in thread From: Chong Yidong @ 2010-08-05 2:28 UTC (permalink / raw) To: Tom; +Cc: emacs-devel Tom <levelhalom@gmail.com> writes: > Which brings the question: is Emacs only targeted to English-speaking > users? Internationalization is a natural feature of modern software. It's impractical to internationalize the docstrings; there's too much. Internationalizing the menu-bar is doable. We could have a set of packages on elpa.gnu.org, each consisting of an elisp file that changes the strings in menu-bar-*-menu to a different language. Contributions welcome. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 2:28 ` Chong Yidong @ 2010-08-05 3:14 ` Stephen J. Turnbull 2010-08-05 7:46 ` Uday S Reddy 2010-08-05 14:01 ` Richard Stallman 1 sibling, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-05 3:14 UTC (permalink / raw) To: Chong Yidong; +Cc: Tom, emacs-devel Chong Yidong writes: > It's impractical to internationalize the docstrings; there's too much. No no no! Internationalizing the documentation is enthusiasm generating; it brings in new contributors who feel they're not able to do anything else. Label the incomplete state "Emacs's Cathedral of the Sagrada Familia" and it might even get registered as a world treasure. :-) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 3:14 ` Stephen J. Turnbull @ 2010-08-05 7:46 ` Uday S Reddy 2010-08-05 15:17 ` David Kastrup 2010-08-06 3:12 ` Stephen J. Turnbull 0 siblings, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-05 7:46 UTC (permalink / raw) To: emacs-devel On 8/5/2010 4:14 AM, Stephen J. Turnbull wrote: > No no no! Internationalizing the documentation is enthusiasm > generating; it brings in new contributors who feel they're not able to > do anything else. Good idea. But, how will the translations be kept uptodate? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 7:46 ` Uday S Reddy @ 2010-08-05 15:17 ` David Kastrup 2010-08-06 3:12 ` Stephen J. Turnbull 1 sibling, 0 replies; 277+ messages in thread From: David Kastrup @ 2010-08-05 15:17 UTC (permalink / raw) To: emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > On 8/5/2010 4:14 AM, Stephen J. Turnbull wrote: > >> No no no! Internationalizing the documentation is enthusiasm >> generating; it brings in new contributors who feel they're not able to >> do anything else. > > Good idea. But, how will the translations be kept uptodate? Prefixing them with a comment indicating the corresponding commit/line pair of the source. An automated process picks up all translation that have gotten out of date, sees whether it suffices to update the comment (since the line has not changed), and commits the string to the translation task list otherwise. -- David Kastrup ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 7:46 ` Uday S Reddy 2010-08-05 15:17 ` David Kastrup @ 2010-08-06 3:12 ` Stephen J. Turnbull 2010-08-06 5:54 ` Jan Djärv 1 sibling, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-06 3:12 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Uday S Reddy writes: > On 8/5/2010 4:14 AM, Stephen J. Turnbull wrote: > > > No no no! Internationalizing the documentation is enthusiasm > > generating; it brings in new contributors who feel they're not able to > > do anything else. > > Good idea. But, how will the translations be kept uptodate? That's the whole point. On the technical side, there are tools for identifying changes in the translatables. On the manpower side, just for the ones I'm familiar with, there are whole organizations of translators at Debian and Ubuntu who volunteer to do these things, and probably at GNOME and KDE and others. When Emacs goes into prerelease freeze, one of the things you freeze is the translatable content. Then you tell the translators that they can work without fear that their translations will be obsoleted before release. There also must be thousands of Emacs users who are uncomfortable contributing code, but if there was a serious effort on I18N would consider translating to their own language an important and fulfilling task. Maintaining the sense of fulfilment requires proper respect from the developers (cf. the description of the release cycle above, plus as RMS imples some help from developers on where the priorities are so the translators can be confident their work is important). Even if their primary interest was translating, such folks are more likely to convert to Emacs developers (typically via a patch to po-mode, you see?) than other users, since Emacs is a tool they use in translation (remember, they're volunteers so there's some reason they *want* to work on Emacs; it's a good bet they're already users). I haven't been in close touch with the translator community for years, but I believe that emacs/po-mode is still one of the most popular tools for them (although web-based tools have been gaining ground rapidly). Emacs will probably not be fully translated until machine translation becomes acceptable. But that's no reason to give up in advance. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 3:12 ` Stephen J. Turnbull @ 2010-08-06 5:54 ` Jan Djärv 2010-08-06 6:20 ` Stephen J. Turnbull 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-06 5:54 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Uday S Reddy, emacs-devel Stephen J. Turnbull skrev 2010-08-06 05.12: > > On the manpower side, just for the ones I'm familiar with, there are > whole organizations of translators at Debian and Ubuntu who volunteer > to do these things, and probably at GNOME and KDE and others. Not to forget GNU itself: http://translationproject.org/html/welcome.html Buth the size of the translation project matters. Larger packages tend to be less often translated than smaller. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-06 5:54 ` Jan Djärv @ 2010-08-06 6:20 ` Stephen J. Turnbull 0 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-06 6:20 UTC (permalink / raw) To: Jan Djärv; +Cc: Uday S Reddy, emacs-devel Jan Djärv writes: > Stephen J. Turnbull skrev 2010-08-06 05.12: > > On the manpower side, just for the ones I'm familiar with, there are > > whole organizations of translators at Debian and Ubuntu who volunteer > > to do these things, and probably at GNOME and KDE and others. > > Not to forget GNU itself: > > http://translationproject.org/html/welcome.html Crap, I had GNU in there, along with a bunch of off-thread-topic stuff, and edited it all out. :-( Thanks for the correction. :-) > Buth the size of the translation project matters. Larger packages > tend to be less often translated than smaller. That's an important point. That's another reason why it's important to prioritize, to make the immediate task feel smaller and do-able. Another way to address the size issue: With some judicious negotiation among stakeholders, the various packages (which are bite-size by comparison) could take turns asking for help from the translation project(s). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 2:28 ` Chong Yidong 2010-08-05 3:14 ` Stephen J. Turnbull @ 2010-08-05 14:01 ` Richard Stallman 2010-08-05 14:55 ` Eli Zaretskii 1 sibling, 1 reply; 277+ messages in thread From: Richard Stallman @ 2010-08-05 14:01 UTC (permalink / raw) To: Chong Yidong; +Cc: levelhalom, emacs-devel It's impractical to internationalize the docstrings; there's too much. Internationalizing the menu-bar is doable. It would be a lot of work, but that need not be an obstacle, because it doesn't need to be complete to be useful. If a team of translators adopts sensible priorities for which doc strings to work on first, their work could be useful even if they have covered only 1% of the doc strings. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-05 14:01 ` Richard Stallman @ 2010-08-05 14:55 ` Eli Zaretskii 0 siblings, 0 replies; 277+ messages in thread From: Eli Zaretskii @ 2010-08-05 14:55 UTC (permalink / raw) To: levelhalom; +Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > Date: Thu, 05 Aug 2010 10:01:21 -0400 > Cc: levelhalom@gmail.com, emacs-devel@gnu.org > > It's impractical to internationalize the docstrings; there's too much. > Internationalizing the menu-bar is doable. > > It would be a lot of work, but that need not be an obstacle, because > it doesn't need to be complete to be useful. If a team of translators > adopts sensible priorities for which doc strings to work on first, > their work could be useful even if they have covered only 1% of the > doc strings. I agree. But some initial design is necessary, because the issues are subtle, but non-trivial. This was discussed a few times in the past, see, for example the following two large threads: http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01464.html http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01525.html http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg00945.html http://lists.gnu.org/archive/html/emacs-devel/2001-12/msg00200.html ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 12:03 ` Andreas Schwab 2010-08-04 12:09 ` Lennart Borgman 2010-08-04 12:33 ` Uday S Reddy @ 2010-08-04 14:06 ` Stephen J. Turnbull 2 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-04 14:06 UTC (permalink / raw) To: Andreas Schwab; +Cc: Uday S Reddy, joakim, Drew Adams, emacs-devel Andreas Schwab writes: > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > > > Further, I don't think the argument has validity. You don't have to > > "remember" the menu entries. You can see them! > > You have to remember where to search, and do search for them. And if > you change the language you are screwed. What a stupid concept. If you're depending on muscle memory, indeed. But as George Carlin put it, "They ask me what I think of the dope problem. I think we definitely have too many dopes!" There are dope-y users, or, more precisely, users who (think they) have better use for time and brain cells (or even peripheral ganglia aka muscle memory) than memorizing Emacs keystrokes. I think those users should be served. Where I differ from Uday is that it is my considered opinion (subject to change given good evidence, but I don't expect to encounter such :-) that there's no particular reason for *Emacsen* to do so. It happens that Ben Wing disagreed with me and put in many hours to implement accelerators and reorganize the menus, so (IMO) I not only won the argument (it didn't bring more developer or that many new users), but got a nice feature for XEmacs, too. Without spending my own time on it! :-) Maybe Uday will do the same for Emacs. :-) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 11:16 ` Uday S Reddy 2010-08-04 11:28 ` Andreas Schwab @ 2010-08-04 13:53 ` Stephen J. Turnbull 1 sibling, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-04 13:53 UTC (permalink / raw) To: Uday S Reddy; +Cc: Drew Adams, joakim, emacs-devel Uday S Reddy writes: > I made a mistake in my previous response to Stephen, it seems. XEmacs > does provide menu accelerators and it probably did it since 2001. So, > the infrastructure has been there. However, the menus don't seem to > have been designed all that carefully to avoid conflicts. (I got > fooled because the examples that I tried all had conflicts.) That's possibly true in XEmacs 21.4 (then, and now). I think Ben's big push on the menus was later, and probably only made it into 21.5. Anyway, in 21.5 I don't see any conflicts. I think if there are conflicts, it starts randomly assigning accelerators. (Well, not entirely randomly; it uses numbers, which normally are not used that way.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 10:20 ` joakim 2010-08-04 10:52 ` Lennart Borgman 2010-08-04 11:16 ` Uday S Reddy @ 2010-08-04 13:15 ` Jason Rumney 2 siblings, 0 replies; 277+ messages in thread From: Jason Rumney @ 2010-08-04 13:15 UTC (permalink / raw) To: joakim; +Cc: Uday S Reddy, Stephen J. Turnbull, Drew Adams, emacs-devel joakim@verona.se writes: > > I dont understand this. I normaly have menus disabled, but I enabled > them now to see. In the File menu I have an entry like: > > "Visit new file... C-x C-f" > > Isn't that a "keyboard accelerator"? I note that Firefox does the same > thing for this menu entry: > > "bookmarks/organize bookmarks ctrl+shif+o" The Bookmarks menu is not a good example, as it doesn't have accelerators, but if you look at the File menu in Firefox for example, you'll see that many of the commands in there have a letter underlined, in addition to the global keybinding that is printed to the right. Some people prefer navigating the menu with Alt-F N for New Window instead of Ctrl-N, as the underlined letter for each step is always visible (you have to open the File menu to see the Ctrl-N, by which time you have lost the advantage of the shorter key sequence). Although Emacs supports menu navigation with F10, you then have to use the arrow keys, which is cumbersome. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-04 9:52 ` Uday S Reddy 2010-08-04 10:20 ` joakim @ 2010-08-04 10:54 ` Stephen J. Turnbull 2010-08-04 11:25 ` Uday S Reddy 2010-08-04 15:21 ` Óscar Fuentes 1 sibling, 2 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-04 10:54 UTC (permalink / raw) To: Uday S Reddy; +Cc: Drew Adams, emacs-devel Uday S Reddy writes: > If you already had keyboard accelerators of menus in 2001, well, thank > you very much for it! But, it still requires extra RET key strokes to > confirm selections. I'm not sure what extra RET key strokes you're talking about. In XEmacs, you hold down the appropriate modifier with a menubar accelerator key. This pulls down that menu. Then you navigate to the desired item by pressing the appropriate item accelerators, which take effect immediately, either popping a submenu or running a command. Of course if it's something like find-file which takes a string input, you'll need to terminate the string with RET. But other than key order, it's no different from the ordinary keymap[1] (except for being a lot slower for me :-). Maybe you're just using the wrong Emacs for your purposes. :-) > Coming back to the students, the vast majority of them switched to > IDEs by the time they reached their final year. So, while we had done > our bit by introducing them to Emacs, Emacs wasn't able to retain them > due to its limitations. In this sense, the previous thread was right > in focusing on the IDE support. I don't understand "in this sense." As Bill Clinton didn't say, "It's the apps, stupid." IDE is *really* important to Java programmers as I understand it because of restrictions of the language. WYSIWYG and multimedia content is really important to non-programmers. Emacs provides neither very well, and CEDET, while very nice, is unlikely to ever catch up to Eclipse. Multimedia is pretty much hopeless for the forseeable future, too. > The user base is still needed to motivate contributors to find it > worthwhile to come forward. Mozilla and Eclipse have armies of > contributors, not because they have great manuals but because they > have large user bases. That's the "post hoc" fallacy. IMO, Eclipse has armies of contributors because programming in Java sucks, and Eclipse is the best available way to make it suck less (certified by Big Blue, no less). And Mozillla? Yes, when you have hundreds of millions of users, even an 0.00001% annual user-to-developer conversion rate is enough to produce plenty of cannon fodder. But there's no way Emacs can compete with Mozilla in terms of sheer numbers of users, unless it becomes a browser. And I don't see that happening. > > > And, Emacs has to fit in. > > > > Why? > > Because, otherwise, you raise the barrier to entry so high that only a > small minority of potential users will be able to get through. If it's the minority of users who will become contributors, that's a big win. :-) Footnotes: [1] There is a known XEmacs weirdness that the use of the modifier is restricted to the initial pulldown menu. Items and submenus *must* be selected with an *unmodified* key. This is stupid, of course. ;-) Maybe that's the problem you're thinking of? ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-04 10:54 ` Stephen J. Turnbull @ 2010-08-04 11:25 ` Uday S Reddy 2010-08-04 14:25 ` Stephen J. Turnbull 2010-08-04 15:21 ` Óscar Fuentes 1 sibling, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-04 11:25 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Uday S Reddy, Drew Adams, emacs-devel Stephen J. Turnbull writes: > I'm not sure what extra RET key strokes you're talking about. In > XEmacs, you hold down the appropriate modifier with a menubar > accelerator key. This pulls down that menu. As I mentioned in my previous message, I got fooled because the examples I tried all had conflicts. I went to a dired buffer and tried m to get to Cmds, but it conflicted with Mark s to get to Subdir, but it conflicted with Sort l to get to Look, but it conflicted with "Load emacs" Then I generalized, wrongly! But 3 conflicts in the titles of a single menubar is rather much, I think. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-04 11:25 ` Uday S Reddy @ 2010-08-04 14:25 ` Stephen J. Turnbull 0 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-04 14:25 UTC (permalink / raw) To: Uday S Reddy; +Cc: Drew Adams, emacs-devel Uday S Reddy writes: > As I mentioned in my previous message, I got fooled because the > examples I tried all had conflicts. > > I went to a dired buffer and tried [...] Aha. I see what's happening here; that's stunningly bad, or at least unfortunate, design. It's now issue725, and offtopic for this list. Reply-To set to xemacs-beta. (Not that I expect any, but just in case.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 10:54 ` Stephen J. Turnbull 2010-08-04 11:25 ` Uday S Reddy @ 2010-08-04 15:21 ` Óscar Fuentes 2010-08-04 15:45 ` joakim 1 sibling, 1 reply; 277+ messages in thread From: Óscar Fuentes @ 2010-08-04 15:21 UTC (permalink / raw) To: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: [snip] > IDE is *really* important to Java programmers as I understand it > because of restrictions of the language. No. IDEs are becoming more and more important for developers because they are improving productivity through smart completion, refactoring support, live checks, tight integration with other tools (debuggers, analyzers of various sorts) etc. Java/Eclipse was one of the first to get there, because the language is specially amenable to that sort of features and has lots of money backing it, but others are following suit. [snip] > Emacs provides neither very well, and CEDET, while very nice, is > unlikely to ever catch up to Eclipse. This is not necessarily so. As the author of CEDET explained a few hours ago, the package can interface with external tools for providing all sorts of information. Build an open interface to Eclipse internals (maybe there is already one?) and you have all the potential of Eclipse in Emacs. Once achieved that, you only need to do the UI work (which is not trivial, but certainly doable.) [snip] ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-04 15:21 ` Óscar Fuentes @ 2010-08-04 15:45 ` joakim 0 siblings, 0 replies; 277+ messages in thread From: joakim @ 2010-08-04 15:45 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > [snip] > >> IDE is *really* important to Java programmers as I understand it >> because of restrictions of the language. > > No. IDEs are becoming more and more important for developers because > they are improving productivity through smart completion, refactoring > support, live checks, tight integration with other tools (debuggers, > analyzers of various sorts) etc. Java/Eclipse was one of the first to > get there, because the language is specially amenable to that sort of > features and has lots of money backing it, but others are following > suit. > > [snip] > >> Emacs provides neither very well, and CEDET, while very nice, is >> unlikely to ever catch up to Eclipse. > > This is not necessarily so. As the author of CEDET explained a few hours > ago, the package can interface with external tools for providing all > sorts of information. Build an open interface to Eclipse internals > (maybe there is already one?) and you have all the potential of Eclipse > in Emacs. Once achieved that, you only need to do the UI work (which is > not trivial, but certainly doable.) There is lots of library type functionality for this sort of thing in Java. Some of it is used in the JDE. The JDE already uses Cedet. An similar aproach I worked on a bit was this: - Make EDE realice a pom.xml is a Maven project file - Hook up Cedet to the Maven via Clojure EDE is a project support facility in Cedet. Maven is a project dependency and build tool facility for Java. Clojure is a lisp-like interpreter on top of Java. The thing I wanted to achieve was: - user downloads emacs - installs "java-maven-cedet-adaptor.el" (or whatever) from elpa - opens a random src file in his existing java project shared with eclipse developers also using maven - experiences the bliss of instant working completion and tag navigation in Emacs, thus stunning eclipse users, otherwise accustomed to Emacs users mumbling and pretending completion and navigation is only for n00bs. It is entirely doable and not so far off. > [snip] > -- Joakim Verona ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 11:56 ` Uday S Reddy 2010-08-03 14:04 ` Juanma Barranquero 2010-08-03 15:54 ` Stephen J. Turnbull @ 2010-08-04 12:57 ` Stefan Monnier 2 siblings, 0 replies; 277+ messages in thread From: Stefan Monnier @ 2010-08-04 12:57 UTC (permalink / raw) To: Uday S Reddy; +Cc: 'Lennart Borgman', Drew Adams, emacs-devel > Menu navigation by keys is actually the best form of interaction for Regardless or whether that's the case, I fully agree that it is a feature we're sorely lacking (IIUC it works on w32 if you separate Alt from Meta, or something like it). Stefan ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-31 10:04 ` Uday S Reddy 2010-07-31 14:07 ` Alan Mackenzie 2010-07-31 18:17 ` Drew Adams @ 2010-08-02 9:42 ` Stuart Hacking 2010-08-02 10:58 ` Uday S Reddy 2010-08-02 10:12 ` Tassilo Horn 3 siblings, 1 reply; 277+ messages in thread From: Stuart Hacking @ 2010-08-02 9:42 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel On 31 July 2010 11:04, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > > [snip] > > My idea was why can't one type something like "M-x isearch" to get this > function, instead of "M-x dired-do-isearch" which is too long-winded and > "M-s a C-s" which is too twisted and unmemorable? This requires a new > concept for Emacs, bindable command names that can vary across modes. To me, this sounds a lot like personal preference. I already have an emacs-lisp file full of global and mode specific keybindings and another with some convenience defaliases. These make sense for the way I work, but I'm sure they would be completely inappropriate for certain other users. Is your suggestion to automatically alias functions by the current major mode? (by, for example, removing the prefix? (dired-do-isearch -> isearch)) Or, do you want a simple method of aliasing commands across modes? How would this work? (define-multi-alias 'isearch ('dired-mode 'dired-do-isearch) ... ... (t 'isearch)) > (Stephen Turnbull is going to say that you can already get its effect > through some other means. That is all well and good. The discussion right > now is really about how to set up an architecture that is functional for the > users. Not everything whose effect can be achieved by other means becomes > part of the architecture unless we use it appropriately!) the 'architecture' that I use is a combination of `defalias', `add-hook', and `define-key' in my personal init files. Am I doing something wrong? > > [snip] > > Cheers, > Uday Best regards, --Stuart ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 9:42 ` Stuart Hacking @ 2010-08-02 10:58 ` Uday S Reddy 2010-08-02 11:17 ` Stuart Hacking 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-02 10:58 UTC (permalink / raw) To: Stuart Hacking; +Cc: Uday S Reddy, emacs-devel Stuart Hacking writes: > To me, this sounds a lot like personal preference. I already have an > emacs-lisp file full of global and mode specific keybindings and > another with some convenience defaliases. These make sense for the way > I work, but I'm sure they would be completely inappropriate for > certain other users. Excellent. The only "personal" thing I see about it is that you might have picked aliases based on personal preference. But there is no reason why the concept of giving such aliases is personal. That is a generally useful idea. > Is your suggestion to automatically alias functions by the current > major mode? (by, for example, removing the prefix? (dired-do-isearch > -> isearch)) Indeed, that is one part of the suggestion. The part 2 of the suggestion is to allow key bindings for such aliases, which would then be widely applicable across several modes. > Or, do you want a simple method of aliasing commands across modes? How > would this work? > > (define-multi-alias 'isearch > ('dired-mode 'dired-do-isearch) > ... > ... > (t 'isearch)) Do you mean you already have such an aliasing scheme? I suppose one can dispatch on the major mode. That is neat! It is not a general solution, of course, since it is based on a closed world assumption about what modes one needs to deal with. But it is a good starting point. > the 'architecture' that I use is a combination of `defalias', > `add-hook', and `define-key' in my personal init files. Am I doing > something wrong? So, I suppose you will let dired-mode do all its self-righteous key bindings and then use a hook to overwrite all of them with your own key bindings? I think I am beginning to like this software-as-the-enemy principle! Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 10:58 ` Uday S Reddy @ 2010-08-02 11:17 ` Stuart Hacking 2010-08-02 11:58 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: Stuart Hacking @ 2010-08-02 11:17 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel On 2 August 2010 11:58, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Stuart Hacking writes: > >> To me, this sounds a lot like personal preference. I already have an >> emacs-lisp file full of global and mode specific keybindings and >> another with some convenience defaliases. These make sense for the way >> I work, but I'm sure they would be completely inappropriate for >> certain other users. > > Excellent. The only "personal" thing I see about it is that you might > have picked aliases based on personal preference. But there is no > reason why the concept of giving such aliases is personal. That is a > generally useful idea. Then Emacs already provides this feature, right? If I don't like a keybinding or command name I can modify/alias them. Furthermore, I can do this only for a specific mode. > So, I suppose you will let dired-mode do all its self-righteous key > bindings and then use a hook to overwrite all of them with your own > key bindings? I think I am beginning to like this > software-as-the-enemy principle! Emacs has a set of default keybindings which can be modified to suit the taste of the user. Where is the issue here? (Some software that I use will not let me redefine key bindings at all.) Is the solution to distribute a version of emacs with no keybindings set? :) --Stuart ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 11:17 ` Stuart Hacking @ 2010-08-02 11:58 ` Uday S Reddy 2010-08-03 3:03 ` Stephen J. Turnbull 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-02 11:58 UTC (permalink / raw) To: Stuart Hacking; +Cc: Uday S Reddy, emacs-devel Stuart Hacking writes: > Emacs has a set of default keybindings which can be modified to suit > the taste of the user. Where is the issue here? (Some software that I > use will not let me redefine key bindings at all.) > > Is the solution to distribute a version of emacs with no keybindings set? :) Ok, so, you don't believe in the software-as-the-enemy principle? Sorry for attributing it to you. If I were to use your scheme to set up Emacs in the flexible way, I would need to define an entire range of generic aliases like you did for "isearch" in your message. Then I need to overwrite pretty much *all* the key bindings that the modes do with my own bindings so that the keys are bound to these generic aliases. Such an idea wouldn't have occured to me normally, because I really imagine the software to be a friend. So, if it doesn't help me, I would get annoyed instead of thinkings of ways to defeat it. But the latter can work too, as you have demonstrated. Do I want to distribute emacs with no key bindings at all? No, not at all. All I am saying is that Emacs, which calls itself the "customizable extensible editor," should accommodate the users that like its way of doing things as well as the users who want to do things differently. Making life a peach for the followers but really difficult for the dissenters doesn't quite fit the bill. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 11:58 ` Uday S Reddy @ 2010-08-03 3:03 ` Stephen J. Turnbull 0 siblings, 0 replies; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-03 3:03 UTC (permalink / raw) To: Uday S Reddy; +Cc: Stuart Hacking, emacs-devel Uday S Reddy writes: > Making life a peach for the followers but really difficult for the > dissenters doesn't quite fit the bill. I'm sorry, but you are wrong. Nobody *made* life difficult for dissenters; it just *is* difficult. True, the Emacs developers *chose* the relatively easy task of finding one path through a dense maze (and even that has proved not so easy). But to make life easy for the dissenters is analogous to enumerating all the paths through that maze. Your dissenters demand a solution to a very difficult task; Emacs doesn't make it hard for them, quite the contrary probably Emacs is the only system which makes it possible to solve this problem in a reasonable amount of work. Other systems that I know of provide at best the equivalents of `global-set-key' and `(setq global-map full-keymap)'. (You're welcome to point me at exceptions if you can, of course, but all the systems I know of are limited in that way.) We have agreed that it is possible, using defun and [remap], to do what you propose in a loadable LISP library. It's going to be a lot of work, though, so I suggest you and other advocates get started. Note that, once you've defined a few score core actions (the total number of useful actions could easily run into the hundreds, but two or three score, if judiciously chosen, is probably a good start) and made note of the keymaps where they are used, it will be very easy to make the system more robust and maintainable by making the internal changes you and others have advocated. But there is *zero* benefit doing things in the reverse order. The defun ... [remap] pattern will be sufficiently robust for use in development of the system, just as advice.el is sufficiently robust for development purposes. A few minutes fiddling with a couple special-purpose functions or macros or advice (eg, of `define-key') will allow you to express the defun ... [remap] pattern concisely, and all of the action definitions will then be usable if and when the internal changes are made. Any experimentation with the defun ... [remap] pattern that needs to be done would have to be done anyway, in the development of an [action] pseudo-command. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-31 10:04 ` Uday S Reddy ` (2 preceding siblings ...) 2010-08-02 9:42 ` Stuart Hacking @ 2010-08-02 10:12 ` Tassilo Horn 2010-08-02 11:24 ` Uday S Reddy 3 siblings, 1 reply; 277+ messages in thread From: Tassilo Horn @ 2010-08-02 10:12 UTC (permalink / raw) To: emacs-devel; +Cc: Uday S Reddy On Saturday 31 July 2010 12:04:50 Uday S Reddy wrote: > My idea was why can't one type something like "M-x isearch" to get > this function, instead of "M-x dired-do-isearch" which is too > long-winded and "M-s a C-s" which is too twisted and unmemorable? I don't know if that's a good idea. Sounds a bit too DWIMish to me. What do I do if I want to use normal isearch although there is a mode-specific isearch implementation? What I could think of would be the introduction of a namespace concept. So all basic commands would be declared in the global namespace, and each mode could have it's own namespace: (defun dired:isearch (...) ...) Emacs then could then have a buffer local `namespace' variable per major-mode (or a list (major minor1 minor2...)?), so that M-x isearch in dired-mode would actually call dired:isearch. To get the global function, you could do M-x :isearch. But such a concept would somehow be orthogonal to [remap ...]. If there's `dired:isearch', I'd expect that `C-s' invokes `dired:isearch' in dired-mode without having to explicitly remap... Just audibly thinking... Tassilo ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-02 10:12 ` Tassilo Horn @ 2010-08-02 11:24 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-02 11:24 UTC (permalink / raw) To: Tassilo Horn; +Cc: Uday S Reddy, emacs-devel Tassilo Horn writes: > > My idea was why can't one type something like "M-x isearch" to get > > this function, instead of "M-x dired-do-isearch" which is too > > long-winded and "M-s a C-s" which is too twisted and unmemorable? > > I don't know if that's a good idea. Sounds a bit too DWIMish to me. > What do I do if I want to use normal isearch although there is a > mode-specific isearch implementation? Sorry, I was just giving "M-x isearch" just to illustrate the number of key presses required. It could be "M-y isearch" for all we care. Note that this "isearch" is different from a function called "isearch". It is in a different name space. > Emacs then could then have a buffer local `namespace' variable per > major-mode (or a list (major minor1 minor2...)?), so that M-x isearch in > dired-mode would actually call dired:isearch. To get the global > function, you could do M-x :isearch. Thank you. A scheme like that would feel so 21st century! > But such a concept would somehow be orthogonal to [remap ...]. If > there's `dired:isearch', I'd expect that `C-s' invokes `dired:isearch' > in dired-mode without having to explicitly remap... Yes, it is orthogonal to the [remap...] idea. I think we really wouldn't want dired to remap `isearch-forward' to `dired:isearch', because `isearch-forward' is quite useful in a dired buffer. The user can do such remapping for himself if he/she wants that. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-07-31 7:16 ` Mathias Dahl 2010-07-31 10:04 ` Uday S Reddy @ 2010-08-23 13:45 ` Juri Linkov 2010-08-23 14:14 ` Thierry Volpiatto ` (3 more replies) 1 sibling, 4 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-23 13:45 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel > function has to be on a key or people won't use it. > And the key combinations keep getting weirder and weirder. > Like M-s a C-s to do an isearch! Well, we have 4 basic input trees for input sequences and usually are trying to add a command to all of them: 1. Command names for M-x. An input sequence comprises of characters of the command name, and completion helps making the input sequence shorter. This have to be taken into account when designing a scheme for command names (using an unique command name prefix, etc.) To improve this type of input, we could try adding dwim completions for M-x. For instance, like the `calc-execute-extended-command' command basically does the same as `execute-extended-command' but prefills the minibuffer's input with the `calc-' prefix: M-x calc- Similarly e.g. in Dired, M-x could guess the `dired-' prefix for Dired commands, so you could just add `isearch' to run `dired-isearch-filenames'. For more convenience, this could also behave like completions in text fields in web browsers and push the most likely completions combined with more frequent items from the input history to the top of the completions list. 2. Menus. In a menu-driven program with menu accelerators using Alt+Letter in a sequence like `M-s a C-s' selects an action from the main menu. So if we had a separate top-level menu "_S_earch" then using the menu accelerator key `M-s' would open the Search menu. Then the next key `a' will select a submenu with the menu accelerator `a', and the final key `C-s' will run a command bound to the menu item. If the last key is RET, it will select the first menu item. 3. Key sequences of input events. You seem to suggest that we have to refrain from binding each and every command to a key sequence since it duplicates two other input types above. I tend to agree provided that M-x completions are as short as possible and the menu structure is well-thought-out (balanced breadth and depth, e.g. to reduce the length of the overlong File menu, print-related items could be moved into a submenu with the "_P_rint" menu accelerator, etc.) 4. Toolbar (a flat menu with icons). All in all, is it a conclusion we are leaning towards: 1. All commands should have a name designed for M-x completions. 2. Most commands should be presented in the main menu. 3. Few basic commands should be bound to a key sequence. 4. Some of most frequently used command should be added to the toolbar. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 13:45 ` Juri Linkov @ 2010-08-23 14:14 ` Thierry Volpiatto 2010-08-23 20:56 ` Juri Linkov 2010-08-23 14:39 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 1 reply; 277+ messages in thread From: Thierry Volpiatto @ 2010-08-23 14:14 UTC (permalink / raw) To: emacs-devel Hi Juri, Juri Linkov <juri@jurta.org> writes: >> function has to be on a key or people won't use it. >> And the key combinations keep getting weirder and weirder. >> Like M-s a C-s to do an isearch! > > Well, we have 4 basic input trees for input sequences > and usually are trying to add a command to all of them: > > 1. Command names for M-x. An input sequence comprises of characters > of the command name, and completion helps making the input sequence shorter. > This have to be taken into account when designing a scheme for command > names (using an unique command name prefix, etc.) > > To improve this type of input, we could try adding dwim completions > for M-x. For instance, like the `calc-execute-extended-command' command > basically does the same as `execute-extended-command' but prefills the > minibuffer's input with the `calc-' prefix: > > M-x calc- If you use anything, you have to try anything-M-x (<f5-a> M-x) that give you history (easy to use, no need to know M-p/n) and describe commands under point with C-z (without quitting M-x). > Similarly e.g. in Dired, M-x could guess the `dired-' prefix > for Dired commands, so you could just add `isearch' to run > `dired-isearch-filenames'. If you know that something is called isearch in emacs. ;-) > For more convenience, this could also behave like completions > in text fields in web browsers and push the most likely completions > combined with more frequent items from the input history > to the top of the completions list. That what does anything-M-x. > 2. Menus. In a menu-driven program with menu accelerators > using Alt+Letter in a sequence like `M-s a C-s' selects > an action from the main menu. > > So if we had a separate top-level menu "_S_earch" then using the menu > accelerator key `M-s' would open the Search menu. Then the next key `a' > will select a submenu with the menu accelerator `a', and the final key > `C-s' will run a command bound to the menu item. If the last key is RET, > it will select the first menu item. > > 3. Key sequences of input events. > > You seem to suggest that we have to refrain from binding each and every > command to a key sequence since it duplicates two other input types above. > > I tend to agree provided that M-x completions are as short as possible > and the menu structure is well-thought-out (balanced breadth and depth, > e.g. to reduce the length of the overlong File menu, print-related items > could be moved into a submenu with the "_P_rint" menu accelerator, etc.) > > 4. Toolbar (a flat menu with icons). > > All in all, is it a conclusion we are leaning towards: > > 1. All commands should have a name designed for M-x completions. > 2. Most commands should be presented in the main menu. > 3. Few basic commands should be bound to a key sequence. > 4. Some of most frequently used command should be added to the toolbar. > > -- Thierry Volpiatto Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 14:14 ` Thierry Volpiatto @ 2010-08-23 20:56 ` Juri Linkov 2010-08-23 21:15 ` Thierry Volpiatto 0 siblings, 1 reply; 277+ messages in thread From: Juri Linkov @ 2010-08-23 20:56 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > If you use anything, you have to try anything-M-x (<f5-a> M-x) that give > you history (easy to use, no need to know M-p/n) and describe commands > under point with C-z (without quitting M-x). I tried anything, but it does nothing. anything-M-x displays an empty list. TAB displays the message "Nothing is selected". C-z displays the message "No candidates". Do you have an idea what is wrong? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 20:56 ` Juri Linkov @ 2010-08-23 21:15 ` Thierry Volpiatto 2010-08-23 22:36 ` Drew Adams 0 siblings, 1 reply; 277+ messages in thread From: Thierry Volpiatto @ 2010-08-23 21:15 UTC (permalink / raw) To: emacs-devel Juri Linkov <juri@jurta.org> writes: >> If you use anything, you have to try anything-M-x (<f5-a> M-x) that give >> you history (easy to use, no need to know M-p/n) and describe commands >> under point with C-z (without quitting M-x). > > I tried anything, but it does nothing. > > anything-M-x displays an empty list. TAB displays the message > "Nothing is selected". C-z displays the message "No candidates". > Do you have an idea what is wrong? Nothing is wrong, start typing commands say dired-, after exactly two characters typed (i.e "di") you will see completion. choose a command in list and run it with RET, C-z to describe it. When you have run command it is added in extended-command-history. Next time you run anything-M-x, you will see your command appearing in a buffer with header "Emacs commands history". NOTE: There is no TAB menu in this command as it use anything-comp-read, an "anything" completing-read that have a sole action like completing-read (Two indeed with the possibility of a persistent action i.e C-z). -- Thierry Volpiatto Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-23 21:15 ` Thierry Volpiatto @ 2010-08-23 22:36 ` Drew Adams 2010-08-24 13:55 ` Juri Linkov 0 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-23 22:36 UTC (permalink / raw) To: 'Thierry Volpiatto', emacs-devel > > I tried anything, but it does nothing. > > Do you have an idea what is wrong? > > Nothing is wrong, start typing commands say dired-, after exactly two > characters typed (i.e "di") you will see completion. > choose a command in list and run it with RET, C-z to describe it. > > When you have run command it is added in extended-command-history. > Next time you run anything-M-x, you will see your command appearing in > a buffer with header "Emacs commands history". FWIW, nearly the same with Icicles. But `dir' instead of `di', since there are also non-Dired command names (e.g. `diary', `diff') that start with `di'. And `C-M-RET' instead of `C-z' for candidate help. And just `M-x', not `anything-M-x'. And normal access to the history (as well as access using completion). I made the point that the solution to the problem Juri described is not to rename the commands but to use better completion (e.g. substring, regexp, pcomplete, fuzzy,...). That's the point. It does not matter how you get better completion. I mentioned that even vanilla Emacs now offers completion other than prefix completion - one need *not* use Icicles or Anything (or Ido, for that matter) to invoke a command whose names matches somewhere other than the prefix. (However, Icicles (and probably Anything, by now) also offers progressive completion, which lets you match multiple patterns (e.g. substrings) without regard to order.) The main point is that commands should *not* be named only on the basis of facilitating prefix completion. Instead, if you want to improve completion matching, then use non-prefix matching. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 22:36 ` Drew Adams @ 2010-08-24 13:55 ` Juri Linkov 2010-08-24 15:20 ` Thierry Volpiatto 2010-08-24 16:38 ` Drew Adams 0 siblings, 2 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-24 13:55 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, 'Thierry Volpiatto' > And normal access to the history (as well as access using completion). Any reason why this is still not available in vanilla Emacs? > I made the point that the solution to the problem Juri described is > not to rename the commands but to use better completion > (e.g. substring, regexp, pcomplete, fuzzy,...). That's the point. > It does not matter how you get better completion. Yes, better completion is what we need. This includes pushing more likely completions to the top of the list. But it seems in anything-M-x the sorting order of completions is random (at least, I can't deduce any logic behind the order of its completions). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-24 13:55 ` Juri Linkov @ 2010-08-24 15:20 ` Thierry Volpiatto 2010-08-24 16:38 ` Drew Adams 1 sibling, 0 replies; 277+ messages in thread From: Thierry Volpiatto @ 2010-08-24 15:20 UTC (permalink / raw) To: Juri Linkov; +Cc: Drew Adams, emacs-devel Juri Linkov <juri@jurta.org> writes: >> And normal access to the history (as well as access using completion). > > Any reason why this is still not available in vanilla Emacs? > >> I made the point that the solution to the problem Juri described is >> not to rename the commands but to use better completion >> (e.g. substring, regexp, pcomplete, fuzzy,...). That's the point. >> It does not matter how you get better completion. > > Yes, better completion is what we need. This includes pushing > more likely completions to the top of the list. But it seems > in anything-M-x the sorting order of completions is random > (at least, I can't deduce any logic behind the order of its completions). No sorting is done in anything-M-x, i think it's not really useful, as as soon you type some characters, all commands starting with these characters go on top of list. Regexp are accepted also, and if you have anything-match plugin enabled, multi regexp completion is available (just enter a space in anything pattern). OTOH, last command used is always pushed on top of history, that mean all recents commands are on top of list (doublons and not bounded commands are removed). -- Thierry Volpiatto Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-24 13:55 ` Juri Linkov 2010-08-24 15:20 ` Thierry Volpiatto @ 2010-08-24 16:38 ` Drew Adams 2010-08-25 13:47 ` Juri Linkov 1 sibling, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-24 16:38 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: emacs-devel, 'Thierry Volpiatto' > > And normal access to the history (as well as access using > > completion). > > Any reason why this is still not available in vanilla Emacs? Why _what_ is not in vanilla Emacs - (a) Icicles or (b) the addition of previous command inputs to the command history or (c) the ability to complete against history items? You know the answer for (a). (b) _is_ of course available in vanilla Emacs. Icicles just extends vanilla minibuffer input, so it maintains this vanilla property. `Anything' might be a different story - dunno. For (c), the answer is that no one has bothered to add the feature to vanilla Emacs. Note: Completion against the history list has this advantage over cycling and searching it (`M-p', `M-r'): the age of the input retrieved is irrelevant. [FWIW - (c) is provided by Icicles in 3 different ways: c1. During minibuffer input anytime (not necessarily input with completion), you can use `M-o' to insert a previous input from the input history using completion (recursive minibuffer). This is on-demand history completion. I've suggested in the past that vanilla Emacs do likewise. IIRC, at one point you or someone else proposed simply adding previous inputs to the completion-candidate set. That is misguided, IMO - the two sets should be kept separate. But completion can be allowed independently against both sets - even during the same input interaction. c2. During completion, you can use `M-h' to filter the current set of completion candidates, limiting it to past inputs. c3. During completion, you can use `M-pause' to filter the (raw/initial) domain of completion candidates, limiting it to past inputs. (c2) and (c3) differ in that Icicles lets you progressively filter the set of candidates or even replace it by a saved set. (b2) acts on the current set of candidates; (c3) acts on the domain of candidates defined by the command.] [FWIW2 - Icicles has additional history-list features, any of which could serve as food for thought for vanilla Emacs. Two simple examples: (1) highlight the previous inputs in *Completions* (optionally: `C-pause' toggles it during completion); (2) sort the candidates on demand (e.g. putting previous inputs first). http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements] > > I made the point that the solution to the problem Juri described is > > not to rename the commands but to use better completion > > (e.g. substring, regexp, pcomplete, fuzzy,...). That's the point. > > It does not matter how you get better completion. > > Yes, better completion is what we need. This includes pushing > more likely completions to the top of the list. Be careful, please. What the program considers "more likely" might not correspond to what some user considers more likely in a given context. This kind of thing should be under user control. DWIM should always be considered at best only a stupid guess. It should be subjected to user control - preferably runtime, on-the-fly control. Only in that context can DWIM be useful and not just an annoyance. Programs can sometimes help by being smart, but users still know best. It would be a mistake, IMO, to systematically place previous inputs at the beginning of the *Completions* list. Of course, vanilla Emacs does not let you cycle among candidates, so their order is irrelevant except in terms of what user sees (in *Completions*). Even so, it is a bad idea to impose an order such as chronological (previous use). Alphabetical order has the advantage of making it easy to find a name (think of an index in a book). [In Icicles, users can sort completion candidates on the fly in many ways, the possible sort orders being dependent on the context (and under user control).] > But it seems in anything-M-x the sorting order of completions is > randome (at least, I can't deduce any logic behind the order of its > completions). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-24 16:38 ` Drew Adams @ 2010-08-25 13:47 ` Juri Linkov 0 siblings, 0 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-25 13:47 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, 'Thierry Volpiatto' > Why _what_ is not in vanilla Emacs - (a) Icicles or (b) the addition of previous > command inputs to the command history or (c) the ability to complete against > history items? (c) > For (c), the answer is that no one has bothered to add the feature to vanilla > Emacs. Note: Completion against the history list has this advantage over cycling > and searching it (`M-p', `M-r'): the age of the input retrieved is irrelevant. > > c1. During minibuffer input anytime (not necessarily input with completion), you > can use `M-o' to insert a previous input from the input history using completion > (recursive minibuffer). This is on-demand history completion. I think `M-h' is a better key since it has obvious mnemonics: h = history. > IIRC, at one point you or someone else proposed simply adding previous inputs to > the completion-candidate set. That is misguided, IMO - the two sets should be > kept separate. But completion can be allowed independently against both sets - > even during the same input interaction. Some web browsers combine previous input (sorted alphabetically or by frequency) with suggestions in the same list. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-23 13:45 ` Juri Linkov 2010-08-23 14:14 ` Thierry Volpiatto @ 2010-08-23 14:39 ` Drew Adams 2010-08-23 20:45 ` Juri Linkov ` (2 more replies) 2010-08-23 17:10 ` Andreas Schwab 2010-08-27 8:18 ` Uday S Reddy 3 siblings, 3 replies; 277+ messages in thread From: Drew Adams @ 2010-08-23 14:39 UTC (permalink / raw) To: 'Juri Linkov', 'Uday S Reddy'; +Cc: emacs-devel > 1. Command names for M-x. An input sequence comprises of characters > of the command name, and completion helps making the input > sequence shorter. This have to be taken into account when > designing a scheme for command names (using an unique command > name prefix, etc.) > > To improve this type of input, we could try adding dwim completions > for M-x. For instance, like the > `calc-execute-extended-command' command > basically does the same as `execute-extended-command' but prefills the > minibuffer's input with the `calc-' prefix: M-x calc- > > Similarly e.g. in Dired, M-x could guess the `dired-' prefix > for Dired commands, so you could just add `isearch' to run > `dired-isearch-filenames'. Please don't. There are lots of 3rd-party extensions to Dired (etc.) whose commands do not start with the prefix `dired-'. Typically, they start with the 3rd-party library prefix. Likewise, for personal user commands that are useful in Dired (etc.). There is no problem getting completion to filter only to a given prefix or substring or whatever, even in vanilla Emacs (e.g. using completion styles). Hard-coding prefix matching for the current mode is truly misguided. > So if we had a separate top-level menu "_S_earch" I've long argued for such a top-level menu. I've used a `Search' menubar menu for decades. There is lots of stuff on other menus that really belongs on `Search', and it's helpful for it to be top level. If people are worried about menu space, then move something like `Options' back under `Help' or `File' (it was originally under `Help'). This is a useful change independently of the reason you gave (use of menu accelerators). > 4. Toolbar (a flat menu with icons). If changes are to be envisioned for the tool bar, they should be along lines already suggested previously: allow for multiple actions, popup menu, etc. per icon (e.g. via modifier keys). The only things particular about a tool bar should be (1) icons, (2) immediate, single action by clicking. Emacs provides a deep, rich user experience with multiple levels of interaction. Emacs tool bars could be made richer and more useful while retaining their simplicity for novice use. There is no reason to limit Emacs tool bars to what are available in some other apps. And even some other apps have tool-bar icons that allow more complex interaction. > All in all, is it a conclusion we are leaning towards: > > 1. All commands should have a name designed for M-x completions. > 2. Most commands should be presented in the main menu. > 3. Few basic commands should be bound to a key sequence. > 4. Some of most frequently used command should be added to the toolbar. That is definitely not a conclusion (4 conclusions) that I am leaning toward. #1: Naming a command can take completion into account to some degree, but that should be only a minor consideration. There are other things important about command names (discoverability, naming patterns for the library, relation to other commands,...). #2: A command should be put on a menu only when it is helpful to provide it with menu access and organization (e.g. discoverability, association with similar commands). It makes no sense to say that "most" commands should or should not be on menus, let alone the "main menu" (whatever that might be). #3 is particularly off the wall. (Though it's unclear what you might mean by "basic commands".) Having a command bound by default does not prevent anyone from rebinding it to a different key. It is true that many commands need not be bound by default, but it is also true that many are not bound by default. There is no problem here that needs to be solved. #4: Some should. Some should not. This is a vacuous conclusion. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 14:39 ` Drew Adams @ 2010-08-23 20:45 ` Juri Linkov 2010-08-24 13:50 ` Juri Linkov 2010-08-27 8:56 ` Uday S Reddy 2 siblings, 0 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-23 20:45 UTC (permalink / raw) To: Drew Adams; +Cc: 'Uday S Reddy', emacs-devel >> So if we had a separate top-level menu "_S_earch" > > I've long argued for such a top-level menu. I've used a `Search' > menubar menu for decades. There is lots of stuff on other menus that > really belongs on `Search', and it's helpful for it to be top level. > If people are worried about menu space, then move something like > `Options' back under `Help' or `File' (it was originally under `Help'). In most programs `Options' (or `Preferences') is just one menu item under `Edit' or `Tools'. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 14:39 ` Drew Adams 2010-08-23 20:45 ` Juri Linkov @ 2010-08-24 13:50 ` Juri Linkov 2010-08-24 16:34 ` Drew Adams 2010-08-27 8:56 ` Uday S Reddy 2 siblings, 1 reply; 277+ messages in thread From: Juri Linkov @ 2010-08-24 13:50 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel > This is a useful change independently of the reason you gave > (use of menu accelerators). But what are technical difficulties of implementing menu accelerators? IIUC, Gtk and Windows already support menu accelerators, and they will also improve navigation in tmm-menubar (that currently assigns quite random accelerators). So for instance, in Gimp you can open a file by typing `<f10> f o'. And in Emacs it will be possible to do exactly the same in Gtk, Windows, xterm and non-toolkit versions (using tmm). ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-24 13:50 ` Juri Linkov @ 2010-08-24 16:34 ` Drew Adams 2010-08-25 13:48 ` Juri Linkov 0 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-24 16:34 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: emacs-devel > > This is a useful change independently of the reason you gave > > (use of menu accelerators). > > But what are technical difficulties of implementing menu accelerators? I have no idea. But apparently Lennart has more or less succeeded for Windows, and Stephen mentioned that XEmacs added accelerators long ago. > IIUC, Gtk and Windows already support menu accelerators, > and they will also improve navigation in tmm-menubar > (that currently assigns quite random accelerators). [With La Carte what you type directly reflects the menu names themselves: you complete against a menu path (with substring etc. matching, if you use Icicles or Ido etc.). There is nothing arbitrary about what you type. This helps you learn and remember the menu organization. You can drill down the menu hierarchy progressively, as in TMM (but with meaningful input) or you can match your menu target directly.] > So for instance, in Gimp you can open a file by typing `<f10> f o'. > And in Emacs it will be possible to do exactly the same > in Gtk, Windows, xterm and non-toolkit versions (using tmm). I have nothing against Emacs supporting menu accelerators. That should be clear from previous posts. [And La Carte already handles (Lennart's implementation of) accelerators.] I was simply agreeing with you that `Search' could and perhaps should be a top-level menu. And that is so whether or not Emacs supports menu accelerators. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-24 16:34 ` Drew Adams @ 2010-08-25 13:48 ` Juri Linkov 2010-08-25 15:07 ` Drew Adams 2010-08-25 16:34 ` Stephen J. Turnbull 0 siblings, 2 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-25 13:48 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel >> But what are technical difficulties of implementing menu accelerators? > > I have no idea. But apparently Lennart has more or less succeeded for Windows, > and Stephen mentioned that XEmacs added accelerators long ago. Does XEmacs bind a key (or key sequences) to access the top-level menu? I mean something like <f10> or Alt-F (for File menu)? >> IIUC, Gtk and Windows already support menu accelerators, >> and they will also improve navigation in tmm-menubar >> (that currently assigns quite random accelerators). > > [With La Carte what you type directly reflects the menu names themselves: you > complete against a menu path (with substring etc. matching, if you use Icicles > or Ido etc.). There is nothing arbitrary about what you type. This helps you > learn and remember the menu organization. You can drill down the menu hierarchy > progressively, as in TMM (but with meaningful input) or you can match your menu > target directly.] Tmm is for menu navigation, and La Carte is for menu completion. I think they both are useful. >> So for instance, in Gimp you can open a file by typing `<f10> f o'. >> And in Emacs it will be possible to do exactly the same >> in Gtk, Windows, xterm and non-toolkit versions (using tmm). > > I have nothing against Emacs supporting menu accelerators. That should be clear > from previous posts. Then who is against Emacs supporting menu accelerators? :-) ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-25 13:48 ` Juri Linkov @ 2010-08-25 15:07 ` Drew Adams 2010-08-26 23:22 ` Juri Linkov 2010-08-25 16:34 ` Stephen J. Turnbull 1 sibling, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-25 15:07 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: emacs-devel > >> But what are technical difficulties of implementing menu > >> accelerators? > > > > I have no idea. But apparently Lennart has more or less > > succeeded for Windows, and Stephen mentioned that XEmacs > > added accelerators long ago. > > Does XEmacs bind a key (or key sequences) to access the > top-level menu? I mean something like <f10> or Alt-F > (for File menu)? No idea. Maybe Stephen can help you here. > >> IIUC, Gtk and Windows already support menu accelerators, > >> and they will also improve navigation in tmm-menubar > >> (that currently assigns quite random accelerators). > > > > [With La Carte what you type directly reflects the menu > > names themselves: you complete against a menu path (with > > substring etc. matching, if you use Icicles or Ido etc.). > > > > There is nothing arbitrary about what you type. This helps you > > learn and remember the menu organization. You can drill > > down the menu hierarchy progressively, as in TMM (but with > > meaningful input) or you can match your menu target directly.] > > Tmm is for menu navigation, and La Carte is for menu completion. > I think they both are useful. Nope. La Carte is particularly helpful for menu _navigation_, especially if used together with Icicles (or Ido or...). If to navigate means to get around, to orient yourself, to see both the trees and the forest, to see where you are and where you can go and how to get there, then La Carte beats TMM everytime for navigation. You can see all or any part of the menu tree. You can change the scope of your view of the tree incrementally (on the fly). And what you see are the actual menu names and menu-item names - there is no artificial legend/key/map to refer to, nothing to learn or forget. You might call such a legend "accelerators". And so they can be, but they require an indirection and learning, at least at first. And "at first" is always "now" for at least some parts of the tree (no one is intimately familiar with the entire tree). Even if some simple accelerator-naming rules are used, there is still some learning and some level of arbitrariness to the map/code. Simple analogy: Imagine that `C-x C-f' did not use the actual file and directory names, but required you to use a TMM-like UI where you drilled down from the root each time using single-key codes (~menu accelerators). Is that a better UI for navigation? I don't think so. To further improve navigation, add to the usual `C-x C-f' (using file names) the ability to match also directory names (anywhere along the path) and match using more powerful patterns (multiple substrings or regexps). That's analogous to La Carte (+ Icicles or Ido or... for the fancy matching). Anyway, Uday's point was about menu accelerators, and my reply was that Emacs has them (XEmacs, Lennart/Windows) or could have them. And I support it doing so. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-25 15:07 ` Drew Adams @ 2010-08-26 23:22 ` Juri Linkov 2010-08-27 12:10 ` Jason Rumney 0 siblings, 1 reply; 277+ messages in thread From: Juri Linkov @ 2010-08-26 23:22 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel > Simple analogy: Imagine that `C-x C-f' did not use the actual file and > directory names, but required you to use a TMM-like UI where you > drilled down from the root each time using single-key codes (~menu > accelerators). Is that a better UI for navigation? Tmm is a good alternative to binding every command to a key sequence. When you remember where the command is located in the menu tree, you can run it by typing its menu accelerators (either in the graphical menu or in text-based tmm menu) with fewer key strokes than with completion. For instance, currently to run `gnus', I need to type `M-x gnus RET' - 7 keys. With menu accelerators, the key sequence will be more than twice shorter - `<f10> t g' ("Tools -> Gnus" menu) - 3 keys. (And with enabled top-level menu accelerators also 3 keys - `M-t g'.) > Anyway, Uday's point was about menu accelerators, and my reply was > that Emacs has them (XEmacs, Lennart/Windows) or could have them. > And I support it doing so. IIUC, Windows defines menu accelerators by prepending "~" in front of the accelerator character in the menu label, Gtk - by prepending "_". These two are incompatible with each other. A common Emacs way would be to define a new underlined face and put it on the accelerator character. Then menu accelerators will appear underlined automatically in tmm (but not in Gtk and Windows). Or more consistent with Emacs menu definitions would be to use a menu property like `:key-sequence' and `:keys', e.g. `key-accel': (define-key menu-bar-file-menu [write-file] `(menu-item ,(purecopy "Save As...") write-file :key-accel "A" :help ,(purecopy "Write current buffer to another file"))) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-26 23:22 ` Juri Linkov @ 2010-08-27 12:10 ` Jason Rumney 2010-08-27 22:38 ` Juri Linkov 0 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-27 12:10 UTC (permalink / raw) To: emacs-devel On 27/8/2010 7:22 AM, Juri Linkov wrote: > IIUC, Windows defines menu accelerators by prepending "~" in front of > the accelerator character in the menu label, Gtk - by prepending "_". > These two are incompatible with each other. > > A common Emacs way would be to define a new underlined face and put it > on the accelerator character. Then menu accelerators will appear > underlined automatically in tmm (but not in Gtk and Windows). > > Or more consistent with Emacs menu definitions would be > to use a menu property like `:key-sequence' and `:keys', > e.g. `key-accel': IIRC, last time we discussed this, we decided that the latter approach would be best. We also considered adopting the GTK approach and replacing _ with ~ on windows (and whatever is appropriate on Mac), but that leaves lucid and text menus needing to remove the character all the time. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 12:10 ` Jason Rumney @ 2010-08-27 22:38 ` Juri Linkov 2010-08-28 0:01 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-27 22:38 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel >> Or more consistent with Emacs menu definitions would be >> to use a menu property like `:key-sequence' and `:keys', >> e.g. `key-accel': > > IIRC, last time we discussed this, we decided that the latter approach > would be best. We also considered adopting the GTK approach and replacing > _ with ~ on windows (and whatever is appropriate on Mac), but that leaves > lucid and text menus needing to remove the character all the time. It seems I missed this decision in this overlong thread. What would be a good scheme for values of `key-accel'? It could either specify the absolute position of the accelerator in the menu label string (an integer value like `:key-accel 6'), or the accelerator itself as a character (like `:key-accel ?A'). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 22:38 ` Juri Linkov @ 2010-08-28 0:01 ` Stefan Monnier 2010-08-28 7:28 ` Eli Zaretskii 2010-08-28 9:25 ` Jan Djärv 2010-08-28 1:02 ` Jason Rumney 2010-08-28 9:20 ` Jan Djärv 2 siblings, 2 replies; 277+ messages in thread From: Stefan Monnier @ 2010-08-28 0:01 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel, Jason Rumney >> IIRC, last time we discussed this, we decided that the latter approach >> would be best. We also considered adopting the GTK approach and replacing >> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves >> lucid and text menus needing to remove the character all the time. > It seems I missed this decision in this overlong thread. So have I. > What would be a good scheme for values of `key-accel'? > It could either specify the absolute position of the accelerator > in the menu label string (an integer value like `:key-accel 6'), > or the accelerator itself as a character (like `:key-accel ?A'). Neither sounds good when you think of a possible future addition of gettext. Stefan ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 0:01 ` Stefan Monnier @ 2010-08-28 7:28 ` Eli Zaretskii 2010-08-30 14:37 ` Stefan Monnier 2010-08-28 9:25 ` Jan Djärv 1 sibling, 1 reply; 277+ messages in thread From: Eli Zaretskii @ 2010-08-28 7:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: juri, jasonr, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sat, 28 Aug 2010 02:01:52 +0200 > Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org> > > > What would be a good scheme for values of `key-accel'? > > It could either specify the absolute position of the accelerator > > in the menu label string (an integer value like `:key-accel 6'), > > or the accelerator itself as a character (like `:key-accel ?A'). > > Neither sounds good when you think of a possible future addition > of gettext. Yes, I agree. We need to design a scheme that could support translatable menu items. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 7:28 ` Eli Zaretskii @ 2010-08-30 14:37 ` Stefan Monnier 2010-08-30 15:34 ` Drew Adams 0 siblings, 1 reply; 277+ messages in thread From: Stefan Monnier @ 2010-08-30 14:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, jasonr, emacs-devel >> Neither sounds good when you think of a possible future addition >> of gettext. > Yes, I agree. We need to design a scheme that could support > translatable menu items. That basically implies that it has to be part of the text (and not as a text-property). So the scheme using an underscore or some such char seems to be the way to go. I see two questions left open: 1- which char to use (I'd favor _ since it's what's used in the Free toolkit I happen to know). 2- how to deal with breaking backward compatibility (e.g. menus which currently include _). Stefan ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-30 14:37 ` Stefan Monnier @ 2010-08-30 15:34 ` Drew Adams 2010-08-30 15:39 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 277+ messages in thread From: Drew Adams @ 2010-08-30 15:34 UTC (permalink / raw) To: 'Stefan Monnier', 'Eli Zaretskii' Cc: juri, emacs-devel, jasonr > That basically implies that it has to be part of the text (and not as > a text-property). So the scheme using an underscore or some such char > seems to be the way to go. > I see two questions left open: > 1- which char to use (I'd favor _ since it's what's used in the Free > toolkit I happen to know). > 2- how to deal with breaking backward compatibility (e.g. menus which > currently include _). Not really to weigh in here. And I have not been following this with much attention or interest... Just a reminder that dynamically generated menus can contain nearly anything. A buffer name used as a menu item could easily contain `_', as could a function, class, etc. name used as an Imenu menu item. Always treating `_' in a name as an accelerator indicator would be quite limiting and bug-/error-prone, I expect. Typically for this kind of thing (treating a char as special sometimes but not always) some char escaping/unescaping mechanism is used. Jan D. mentioned that `_' could escape an underscore (it does in Gtk+) so that `__' (2 of them) inhibits acting as an accelerator indication. But then there needs to be an unambigous way to specify an underscore itself as an accelerator char. Perhaps `___' (3 or them) could (be made to) do that. How does Gtk+ deal with this? In any case, this stuff needs to be well thought out before going ahead. I'm glad (and surprised) to see that you are concerned about backward compatibility here. ;-) I doubt there is a good way to respect that, however, if the menu-item text itself is changed. (But I also agree about the limitations of using a text property instead of a char.) If a menu item contains an underscore and there was no intention of indicating an accelerator, then there is little or nothing to be done - modulo some way to test the intention (e.g. version of the code that creates the menu item). I see no good way to both (a) respect `_' in old code as _not_ meaning anything special and (b) make `_' (together with an appropriate escape feature) indicate an accelerator. 3rd-party code will just have to adjust, providing two sets of menu items: one that works in old Emacs versions (no accelerator indication) and one that works in new versions. Ugh. And code that dynamically generates menu items would need to be adapted to always DTRT. Ugh. It is also true that introducing a new keyword would complicate code that parses menu items (or keymaps generally). ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-30 15:34 ` Drew Adams @ 2010-08-30 15:39 ` Lennart Borgman 2010-08-30 15:53 ` Drew Adams 2010-08-30 15:54 ` Andreas Schwab 2010-08-30 21:39 ` Davis Herring 2 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-30 15:39 UTC (permalink / raw) To: Drew Adams; +Cc: juri, Eli Zaretskii, jasonr, Stefan Monnier, emacs-devel On Mon, Aug 30, 2010 at 5:34 PM, Drew Adams <drew.adams@oracle.com> wrote: > > 3rd-party code will just have to adjust, providing two sets of menu items: one > that works in old Emacs versions (no accelerator indication) and one that works > in new versions. Ugh. And code that dynamically generates menu items would > need to be adapted to always DTRT. Ugh. Can't this be handled something like this: - Provide a function in Emacs, say `menu-escape-underscore', that does escaping of underscore so that it is shown as an underscore. - Test for the presence of this function in external libraries. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-30 15:39 ` Lennart Borgman @ 2010-08-30 15:53 ` Drew Adams 2010-08-30 16:06 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Drew Adams @ 2010-08-30 15:53 UTC (permalink / raw) To: 'Lennart Borgman' Cc: juri, 'Eli Zaretskii', jasonr, 'Stefan Monnier', emacs-devel > > 3rd-party code will just have to adjust, providing two sets > > of menu items: one that works in old Emacs versions (no > > accelerator indication) and one that works in new versions. > > Ugh. And code that dynamically generates menu items would > > need to be adapted to always DTRT. Ugh. > > Can't this be handled something like this: > > - Provide a function in Emacs, say `menu-escape-underscore', that does > escaping of underscore so that it is shown as an underscore. > > - Test for the presence of this function in external libraries. The point is that legacy 3rd-party code makes no provision for anything. It simply includes `_' as an ordinary character. Either the 3rd-party code must change to recognize Emacs's different treatment in different versions or the new Emacs behavior will treat `_' differently from what was intended. If you mean that new Emacs would use (fboundp 'menu-escape-underscore) and then handle the menu accordingly, that might make new Emacs DTRT with old 3rd-party code. But it would not solve the reverse problem of old Emacs versions handling code that creates menus that expect the new treatment. Maybe there is a good, simple solution, but I don't see it yet. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-30 15:53 ` Drew Adams @ 2010-08-30 16:06 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-30 16:06 UTC (permalink / raw) To: Drew Adams; +Cc: juri, Eli Zaretskii, jasonr, Stefan Monnier, emacs-devel On Mon, Aug 30, 2010 at 5:53 PM, Drew Adams <drew.adams@oracle.com> wrote: >> > 3rd-party code will just have to adjust, providing two sets >> > of menu items: one that works in old Emacs versions (no >> > accelerator indication) and one that works in new versions. >> > Ugh. And code that dynamically generates menu items would >> > need to be adapted to always DTRT. Ugh. >> >> Can't this be handled something like this: >> >> - Provide a function in Emacs, say `menu-escape-underscore', that does >> escaping of underscore so that it is shown as an underscore. >> >> - Test for the presence of this function in external libraries. > > The point is that legacy 3rd-party code makes no provision for anything. It > simply includes `_' as an ordinary character. Either the 3rd-party code must > change to recognize Emacs's different treatment in different versions or the new > Emacs behavior will treat `_' differently from what was intended. > > If you mean that new Emacs would use (fboundp 'menu-escape-underscore) and then > handle the menu accordingly, that might make new Emacs DTRT with old 3rd-party > code. But it would not solve the reverse problem of old Emacs versions handling > code that creates menus that expect the new treatment. No, I meant that 3rd party code must check for this. So yes, third party code must change, but it is a simple change, something like (when (fboundp 'menu-escape-underscore) (setq my-menu-txt (menu-escape-underscore my-menu-txt))) > Maybe there is a good, simple solution, but I don't see it yet. > > ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-30 15:34 ` Drew Adams 2010-08-30 15:39 ` Lennart Borgman @ 2010-08-30 15:54 ` Andreas Schwab 2010-08-30 21:39 ` Davis Herring 2 siblings, 0 replies; 277+ messages in thread From: Andreas Schwab @ 2010-08-30 15:54 UTC (permalink / raw) To: Drew Adams Cc: juri, 'Eli Zaretskii', jasonr, 'Stefan Monnier', emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > But then there needs to be an unambigous way to specify an underscore > itself as an accelerator char. I don't think so. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-30 15:34 ` Drew Adams 2010-08-30 15:39 ` Lennart Borgman 2010-08-30 15:54 ` Andreas Schwab @ 2010-08-30 21:39 ` Davis Herring 2010-08-31 5:49 ` Jan Djärv 2 siblings, 1 reply; 277+ messages in thread From: Davis Herring @ 2010-08-30 21:39 UTC (permalink / raw) To: Drew Adams Cc: juri, 'Eli Zaretskii', jasonr, 'Stefan Monnier', emacs-devel > But then there needs to be an unambigous way to specify an underscore > itself as an accelerator char. Perhaps `___' (3 or them) could (be > made to) do that. "___" (with any following character) is already a literal underscore and an accelerator-prefix, so that doesn't work. You'd have to have "__U" be a literal underscore and "__A" be an accelerator underscore (leaving all other "__?" patterns undefined for future expansion). Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-30 21:39 ` Davis Herring @ 2010-08-31 5:49 ` Jan Djärv 2010-08-31 9:54 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-31 5:49 UTC (permalink / raw) To: herring Cc: emacs-devel, juri, 'Stefan Monnier', 'Eli Zaretskii', jasonr, Drew Adams Davis Herring skrev 2010-08-30 23.39: >> But then there needs to be an unambigous way to specify an underscore >> itself as an accelerator char. Perhaps `___' (3 or them) could (be >> made to) do that. > > "___" (with any following character) is already a literal underscore and > an accelerator-prefix, so that doesn't work. You'd have to have "__U" be > a literal underscore and "__A" be an accelerator underscore (leaving all > other "__?" patterns undefined for future expansion). > Given that Gtk+ has had this limitation for years (_ can not be an accelerator) and nobody complained, I don't think it is anything but a theoretical problem. Anybody got a concrete example of an Emacs menu that could have _ as accelerator? Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-31 5:49 ` Jan Djärv @ 2010-08-31 9:54 ` Lennart Borgman 2010-08-31 12:14 ` Jan Djärv 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-31 9:54 UTC (permalink / raw) To: Jan Djärv Cc: juri, jasonr, Stefan Monnier, Eli Zaretskii, emacs-devel, Drew Adams On Tue, Aug 31, 2010 at 7:49 AM, Jan Djärv <jan.h.d@swipnet.se> wrote: > > Given that Gtk+ has had this limitation for years (_ can not be an > accelerator) and nobody complained, I don't think it is anything but a > theoretical problem. Anybody got a concrete example of an Emacs menu that > could have _ as accelerator? Drew had examples and I suggested a solution to him in this thread. Please see our messages here. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-31 9:54 ` Lennart Borgman @ 2010-08-31 12:14 ` Jan Djärv 2010-08-31 21:25 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-31 12:14 UTC (permalink / raw) To: Lennart Borgman Cc: juri, jasonr, Stefan Monnier, Eli Zaretskii, emacs-devel, Drew Adams Lennart Borgman skrev 2010-08-31 11.54: > On Tue, Aug 31, 2010 at 7:49 AM, Jan Djärv<jan.h.d@swipnet.se> wrote: >> >> Given that Gtk+ has had this limitation for years (_ can not be an >> accelerator) and nobody complained, I don't think it is anything but a >> theoretical problem. Anybody got a concrete example of an Emacs menu that >> could have _ as accelerator? > > Drew had examples and I suggested a solution to him in this thread. > Please see our messages here. I don't understand. How can you suggest a solution on how to make underscore an accelerator when Gtk+ doesn't even support that? Or are you talking of another specific toolkit/port? Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-31 12:14 ` Jan Djärv @ 2010-08-31 21:25 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-31 21:25 UTC (permalink / raw) To: Jan Djärv Cc: juri, jasonr, Stefan Monnier, Eli Zaretskii, emacs-devel, Drew Adams On Tue, Aug 31, 2010 at 2:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote: > > > Lennart Borgman skrev 2010-08-31 11.54: >> >> On Tue, Aug 31, 2010 at 7:49 AM, Jan Djärv<jan.h.d@swipnet.se> wrote: >>> >>> Given that Gtk+ has had this limitation for years (_ can not be an >>> accelerator) and nobody complained, I don't think it is anything but a >>> theoretical problem. Anybody got a concrete example of an Emacs menu >>> that >>> could have _ as accelerator? >> >> Drew had examples and I suggested a solution to him in this thread. >> Please see our messages here. > > I don't understand. How can you suggest a solution on how to make > underscore an accelerator when Gtk+ doesn't even support that? Or are you > talking of another specific toolkit/port? Sorry, my bad. I misread your question. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 0:01 ` Stefan Monnier 2010-08-28 7:28 ` Eli Zaretskii @ 2010-08-28 9:25 ` Jan Djärv 1 sibling, 0 replies; 277+ messages in thread From: Jan Djärv @ 2010-08-28 9:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juri Linkov, Jason Rumney, emacs-devel Stefan Monnier skrev 2010-08-28 02.01: >>> IIRC, last time we discussed this, we decided that the latter approach >>> would be best. We also considered adopting the GTK approach and replacing >>> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves >>> lucid and text menus needing to remove the character all the time. > >> It seems I missed this decision in this overlong thread. > > So have I. > >> What would be a good scheme for values of `key-accel'? >> It could either specify the absolute position of the accelerator >> in the menu label string (an integer value like `:key-accel 6'), >> or the accelerator itself as a character (like `:key-accel ?A'). > > Neither sounds good when you think of a possible future addition > of gettext. > I know that strings for translations in Gtk+ programs include the _ for marking the accelerator, so translators have to choose a new one in their languages. But I don't think this is something to worry about now, as we don't even have plans for including gettext yet. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 22:38 ` Juri Linkov 2010-08-28 0:01 ` Stefan Monnier @ 2010-08-28 1:02 ` Jason Rumney 2010-08-28 9:20 ` Jan Djärv 2 siblings, 0 replies; 277+ messages in thread From: Jason Rumney @ 2010-08-28 1:02 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel On 28/8/2010 6:38 AM, Juri Linkov wrote: >> IIRC, last time we discussed this, we decided that the latter approach >> would be best. We also considered adopting the GTK approach and replacing >> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves >> lucid and text menus needing to remove the character all the time. > It seems I missed this decision in this overlong thread. It seems there has been a more recent thread. I was thinking of a thread from several years ago. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 22:38 ` Juri Linkov 2010-08-28 0:01 ` Stefan Monnier 2010-08-28 1:02 ` Jason Rumney @ 2010-08-28 9:20 ` Jan Djärv 2010-08-28 9:23 ` Jason Rumney 2 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-28 9:20 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel, Jason Rumney Juri Linkov skrev 2010-08-28 00.38: > > What would be a good scheme for values of `key-accel'? > It could either specify the absolute position of the accelerator > in the menu label string (an integer value like `:key-accel 6'), > or the accelerator itself as a character (like `:key-accel ?A'). Why no just a text property on the character in question? Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 9:20 ` Jan Djärv @ 2010-08-28 9:23 ` Jason Rumney 2010-08-28 9:41 ` Jan Djärv 0 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-28 9:23 UTC (permalink / raw) To: Jan Djärv; +Cc: Juri Linkov, emacs-devel Jan Djärv <jan.h.d@swipnet.se> writes: > Juri Linkov skrev 2010-08-28 00.38: > >> >> What would be a good scheme for values of `key-accel'? >> It could either specify the absolute position of the accelerator >> in the menu label string (an integer value like `:key-accel 6'), >> or the accelerator itself as a character (like `:key-accel ?A'). > > Why no just a text property on the character in question? Defining menus is already complex enough as it is. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 9:23 ` Jason Rumney @ 2010-08-28 9:41 ` Jan Djärv 2010-08-28 10:13 ` Jason Rumney 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-28 9:41 UTC (permalink / raw) To: Jason Rumney; +Cc: Juri Linkov, emacs-devel Jason Rumney skrev 2010-08-28 11.23: > Jan Djärv<jan.h.d@swipnet.se> writes: > >> Juri Linkov skrev 2010-08-28 00.38: >> >>> >>> What would be a good scheme for values of `key-accel'? >>> It could either specify the absolute position of the accelerator >>> in the menu label string (an integer value like `:key-accel 6'), >>> or the accelerator itself as a character (like `:key-accel ?A'). >> >> Why no just a text property on the character in question? > > Defining menus is already complex enough as it is. > Sure, but putting in stuff like :key-accel makes translation harder and you have to add lisp and C code to handle it. Text properties exist now. It is trivial to make a function that takes for example "_File" and turns this into a string with "File" and a text property on F. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 9:41 ` Jan Djärv @ 2010-08-28 10:13 ` Jason Rumney 2010-08-28 10:58 ` Jan Djärv 0 siblings, 1 reply; 277+ messages in thread From: Jason Rumney @ 2010-08-28 10:13 UTC (permalink / raw) To: Jan Djärv; +Cc: Juri Linkov, emacs-devel On 28/8/2010 5:41 PM, Jan Djärv wrote: > Sure, but putting in stuff like :key-accel makes translation harder > and you have to add lisp and C code to handle it. Text properties > exist now. > > It is trivial to make a function that takes for example "_File" and > turns this into a string with "File" and a text property on F. It's not significantly more difficult than a function that replaces both the menu text and the :key-accel (or :mnemonic to use the GTK and Motif name rather than the MS Windows one) property given the menu item that is being translated and the translation string as above. The interface should be what is easy for the users of the function, not what is slightly easier for the person who implements the feature. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 10:13 ` Jason Rumney @ 2010-08-28 10:58 ` Jan Djärv 2010-08-28 23:16 ` Juri Linkov 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-28 10:58 UTC (permalink / raw) To: Jason Rumney; +Cc: Juri Linkov, emacs-devel Jason Rumney skrev 2010-08-28 12.13: > On 28/8/2010 5:41 PM, Jan Djärv wrote: > >> Sure, but putting in stuff like :key-accel makes translation harder and you >> have to add lisp and C code to handle it. Text properties exist now. >> >> It is trivial to make a function that takes for example "_File" and turns >> this into a string with "File" and a text property on F. > > It's not significantly more difficult than a function that replaces both the > menu text and the :key-accel (or :mnemonic to use the GTK and Motif name > rather than the MS Windows one) property given the menu item that is being > translated and the translation string as above. > > The interface should be what is easy for the users of the function, not what > is slightly easier for the person who implements the feature. > Agreed. But it is a fundamentally bad design to keep information in two places. Take this: (define-key menu-bar-file-menu [exit-emacs] `(menu-item ,(purecopy "Quit") save-buffers-kill-terminal :key-accel "Q" :help ,(purecopy "Save unsaved buffers, then exit"))) Information in two places. You may think it is not a big deal, but Motif uses a similar scheme (a property that is the number of the acceleration character). People has to update in two places. When changing menu text mistakes will be made and :key-accel will be wrong. I seen this happen in Motif apps, it will happen here also. Keeping the accelerator indication in the string itself: (define-key menu-bar-file-menu [exit-emacs] `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal :help ,(purecopy "Save unsaved buffers, then exit"))) almost guarantees that bad things won't happen. This is without any translation. That is a separate matter. For example, how are you going to present the first case to a translator that uses gettext? He only sees "Quit" and does not know where the accelerator is or that there should be one. Gettext collects it strings automatically from sources such as .el files and does not know about :key-accel. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 10:58 ` Jan Djärv @ 2010-08-28 23:16 ` Juri Linkov 2010-08-29 7:46 ` Jan Djärv 0 siblings, 1 reply; 277+ messages in thread From: Juri Linkov @ 2010-08-28 23:16 UTC (permalink / raw) To: Jan Djärv; +Cc: emacs-devel, Jason Rumney > Keeping the accelerator indication in the string itself: > (define-key menu-bar-file-menu [exit-emacs] > `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal > :help ,(purecopy "Save unsaved buffers, then exit"))) Does this scheme allow to escape underscores (when _ should be part of the menu item but not as an accelerator)? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-28 23:16 ` Juri Linkov @ 2010-08-29 7:46 ` Jan Djärv 2010-08-29 11:58 ` David Kastrup 0 siblings, 1 reply; 277+ messages in thread From: Jan Djärv @ 2010-08-29 7:46 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel@gnu.org, Jason Rumney 29 aug 2010 kl. 01:16 skrev Juri Linkov <juri@jurta.org>: >> Keeping the accelerator indication in the string itself: >> (define-key menu-bar-file-menu [exit-emacs] >> `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal >> :help ,(purecopy "Save unsaved buffers, then exit"))) > > Does this scheme allow to escape underscores (when _ should be part of > the menu item but not as an accelerator)? Two underscores in a row translates to one in Gtk+. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-29 7:46 ` Jan Djärv @ 2010-08-29 11:58 ` David Kastrup 2010-08-29 12:24 ` Jan Djärv 0 siblings, 1 reply; 277+ messages in thread From: David Kastrup @ 2010-08-29 11:58 UTC (permalink / raw) To: emacs-devel Jan Djärv <jan.h.d@swipnet.se> writes: > 29 aug 2010 kl. 01:16 skrev Juri Linkov <juri@jurta.org>: > >>> Keeping the accelerator indication in the string itself: >>> (define-key menu-bar-file-menu [exit-emacs] >>> `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal >>> :help ,(purecopy "Save unsaved buffers, then exit"))) >> >> Does this scheme allow to escape underscores (when _ should be part of >> the menu item but not as an accelerator)? > > Two underscores in a row translates to one in Gtk+. In "___Ola", is the accelerator ?_ or ?O ? -- David Kastrup ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-29 11:58 ` David Kastrup @ 2010-08-29 12:24 ` Jan Djärv 0 siblings, 0 replies; 277+ messages in thread From: Jan Djärv @ 2010-08-29 12:24 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel David Kastrup skrev 2010-08-29 13.58: > Jan Djärv<jan.h.d@swipnet.se> writes: > >> 29 aug 2010 kl. 01:16 skrev Juri Linkov<juri@jurta.org>: >> >>>> Keeping the accelerator indication in the string itself: >>>> (define-key menu-bar-file-menu [exit-emacs] >>>> `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal >>>> :help ,(purecopy "Save unsaved buffers, then exit"))) >>> >>> Does this scheme allow to escape underscores (when _ should be part of >>> the menu item but not as an accelerator)? >> >> Two underscores in a row translates to one in Gtk+. > > In "___Ola", is the accelerator ?_ or ?O ? It is ?O. AFAIK, it isn't possible to make _ an accelerator, i.e parse three underscores as _ + __. It is always taken to be __ + _. Jan D. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-25 13:48 ` Juri Linkov 2010-08-25 15:07 ` Drew Adams @ 2010-08-25 16:34 ` Stephen J. Turnbull 2010-08-26 23:23 ` Juri Linkov 1 sibling, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-25 16:34 UTC (permalink / raw) To: Juri Linkov; +Cc: Drew Adams, emacs-devel Juri Linkov writes: > Does XEmacs bind a key (or key sequences) to access the top-level > menu? I mean something like <f10> or Alt-F (for File menu)? Yes. The actual behavior depends on two customizable variables. `menu-accelerator-enabled' Whether menu accelerator keys can cause the menubar to become active. If `menu-force' or `menu-fallback', then menu accelerator keys can be used to activate the top level menu. Once the menubar becomes active, the accelerator keys can be used regardless of the value of this variable. menu-force is used to indicate that the menu accelerator key takes precedence over bindings in the current keymap(s). menu-fallback means that bindings in the current keymap take precedence over menu accelerator keys. Thus a top level menu with an accelerator of "T" would be activated on a keypress of Meta-t if menu-accelerator-enabled is menu-force. However, if menu-accelerator-enabled is menu-fallback, then Meta-t will not activate the menubar and will instead run the function transpose-words, to which it is normally bound. This variable is normally nil. The other is `mswindows-alt-by-itself-activates-menu' Controls whether pressing and releasing the Alt key activates the menubar. This applies only if no intervening key was pressed. See also `menu-accelerator-enabled', which is probably the behavior you actually want. Default is t. This is available only on MS Windows. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-25 16:34 ` Stephen J. Turnbull @ 2010-08-26 23:23 ` Juri Linkov 2010-08-27 0:17 ` Miles Bader 0 siblings, 1 reply; 277+ messages in thread From: Juri Linkov @ 2010-08-26 23:23 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Drew Adams, emacs-devel > > Does XEmacs bind a key (or key sequences) to access the top-level > > menu? I mean something like <f10> or Alt-F (for File menu)? > > Yes. The actual behavior depends on two customizable variables. > > `menu-accelerator-enabled' > > Whether menu accelerator keys can cause the menubar to become > active. If `menu-force' or `menu-fallback', then menu accelerator > keys can be used to activate the top level menu. Once the menubar > becomes active, the accelerator keys can be used regardless of the > value of this variable. Thanks for the information. Shouldn't this be part of CUA mode? If the CUA standard defines this functionality then probably it should be enabled with CUA mode. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-26 23:23 ` Juri Linkov @ 2010-08-27 0:17 ` Miles Bader 2010-08-27 22:38 ` Juri Linkov 0 siblings, 1 reply; 277+ messages in thread From: Miles Bader @ 2010-08-27 0:17 UTC (permalink / raw) To: emacs-devel Juri Linkov <juri@jurta.org> writes: > Shouldn't this be part of CUA mode? If the CUA standard defines this > functionality then probably it should be enabled with CUA mode. I think CUA-mode is already way too overloaded and bloated with random functionality. To the extent it's possible, it seems far better to have an independent mode. -Miles -- "Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join." -- Anon. British Officer in WW I ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 0:17 ` Miles Bader @ 2010-08-27 22:38 ` Juri Linkov 0 siblings, 0 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-27 22:38 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel >> Shouldn't this be part of CUA mode? If the CUA standard defines this >> functionality then probably it should be enabled with CUA mode. > > I think CUA-mode is already way too overloaded and bloated with random > functionality. And there are no CUA-mode parts that could be shared - there is no delay between key presses (like cua-prefix-override-inhibit-delay), and activating the top-level doesn't depend on the region being active (like in CUA). The only idea that could be taken from CUA-mode is using the SHIFT key to override the menu activation. Actually, this is what Gnome Terminal already does when "Enable menu access keys" is enabled: - M-b moves backward one word (since there is no menu with the accelerator "B"); - M-f activates the top-level File menu; - S-M-f moves forward one word. The same could be implemented in Emacs (not by default, of course). > To the extent it's possible, it seems far better to have > an independent mode. A mode or a variable? XEmacs just goes with a customizable variable `menu-accelerator-enabled'. ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-23 14:39 ` Drew Adams 2010-08-23 20:45 ` Juri Linkov 2010-08-24 13:50 ` Juri Linkov @ 2010-08-27 8:56 ` Uday S Reddy 2 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-27 8:56 UTC (permalink / raw) To: Drew Adams; +Cc: 'Juri Linkov', 'Uday S Reddy', emacs-devel Drew Adams writes: > #3 is particularly off the wall. (Though it's unclear what you might > mean by "basic commands".) Having a command bound by default does > not prevent anyone from rebinding it to a different key. It is true > that many commands need not be bound by default, but it is also true > that many are not bound by default. There is no problem here that > needs to be solved. Here is a philosophy that one might take. We will bind a few crucial functions to keys because we think they are absolutely essential. Then we will make available a whole bunch of other functions and a whole bunch of free keys, so that you can bind them as they suit you. "Less is more" with this philosophy. The fewer keys you bind, the more free keys you give to the user. Let me give you a concrete instance of the problem I spent some thought on during the last couple of weeks. VM has traditionally had a key binding of `k' to kill-subject, i.e., kill all messages with the same subject as the current one. Most people have used it to kill message threads, because threading didn't work very reliably in the old days, and so, we went by subject. Now, I have improved threading and it works reliably. So, I raised the idea "can we rebind `k' to kill-thread instead of kill-subject?" The answer is, "oh, well, not quite." I can bet that 90% of the users 90% of the time will use kill-thread instead of kill-subject. But I can't simply disregard the remaining 10%. If the old key binding is left alone, then the users will just habitually type `k' and never discover that there is a better function now. If there had not been a built-in key binding for k = kill-subject, and it was merely a suggestion for users to do the binding themselves, I could now simply change the suggestion and let the users suit themselves. Those users who really need kill-subject will keep the old binding and the others will switch over. The whac-a-mole problem is better solved at the usr end than at our end. As a developer, I don't feel possessive about key bindings. I am quite happy to give the users a blank slate and let them do their own key bindings. It is my software that I put my value in. If the key bindings get in the way of my users deriving the best value out of my software, then what purpose has been served? Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 13:45 ` Juri Linkov 2010-08-23 14:14 ` Thierry Volpiatto 2010-08-23 14:39 ` Drew Adams @ 2010-08-23 17:10 ` Andreas Schwab 2010-08-27 8:18 ` Uday S Reddy 3 siblings, 0 replies; 277+ messages in thread From: Andreas Schwab @ 2010-08-23 17:10 UTC (permalink / raw) To: Juri Linkov; +Cc: Uday S Reddy, emacs-devel Juri Linkov <juri@jurta.org> writes: > Similarly e.g. in Dired, M-x could guess the `dired-' prefix > for Dired commands, so you could just add `isearch' to run > `dired-isearch-filenames'. That's definitely not DWIM. Just because I happen to visit a dired buffer does not mean that I want to execute a command starting with "dired-". In fact, most commands associated with the current buffer's major mode are usually on a key, so the command I want to execute with M-x is more likely _not_ associated with that mode. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-23 13:45 ` Juri Linkov ` (2 preceding siblings ...) 2010-08-23 17:10 ` Andreas Schwab @ 2010-08-27 8:18 ` Uday S Reddy 2010-08-27 22:34 ` Juri Linkov 3 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-27 8:18 UTC (permalink / raw) To: Juri Linkov; +Cc: Uday S Reddy, emacs-devel Juri Linkov writes: > All in all, is it a conclusion we are leaning towards: > > 1. All commands should have a name designed for M-x completions. > 2. Most commands should be presented in the main menu. > 3. Few basic commands should be bound to a key sequence. > 4. Some of most frequently used command should be added to the toolbar. Dear Juri, Thanks for an excellent summary and putting the life back into this thread! A couple of amendments. My proposal for > 1. All commands should have a name designed for M-x completions. wasn't actually that M-x should be extended or modified. Rather, a prefix key like M-x (say, M-z for argument's sake) would be used for invoking mode-specific "command names". Each mode would bind such command names to actual elisp functions, and this allows us to reuse the command names in each mode. So `M-z isearch' can provide isearch through files in dired, isearch through buffers in buf-menu, isearch through messages in Rmail or Gnus or VM, etc. Similarly, you might have commands `M-z next', `M-z previous', `M-z view', `M-z other-window', `M-z mark', `M-z delete', `M-z undelete', `M-z execute' and so on. The key idea is that command names form a *new namespace*, created explicitly for providing efficient user interaction. In addition, my idea also includes: 1a. key bindings can be made to "command names". This allows the user to create a personal keymap like n for M-z next p for M-z previous v for M-z view o for M-z other-window m for M-z mark d for M-z delete u for M-z undelete x for M-z execute ... and install it in every mode where it might make sense. This would save work for configuration and re-skinning. Note that Stephen Turnbull countered by saying that a lot of this can already be achieved using the existing elisp technology. I am not entirely convinced, but those suggestions need to be explored. Regarding: > 2. Most commands should be presented in the main menu. I don't have a firm view on this. There is also a case for having simple menus that are not intimidating. But, I think one can probably have the cake and eat it too in this case. It is easy enough to install different menus depending on the user's preference. A beginner might start with simple menus, and graduate to bigger ones when he/she wants more. Regarding the contentious issue: > 3. Few basic commands should be bound to a key sequence. we will probably need to continue debating it. "Less is more" only if the users can turn it into "more". If the users have a good technology for making their own key bindings, then Emacs can ship with fewer and fewer built-in key bindings. Or, you can at least detach the majority of key bindings from standard Emacs and make them customization packages. I will be going offline for a few weeks. I will catch up after I get back. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 8:18 ` Uday S Reddy @ 2010-08-27 22:34 ` Juri Linkov 2010-08-27 23:12 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: Juri Linkov @ 2010-08-27 22:34 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel > Dear Juri, Thanks for an excellent summary and putting the life back > into this thread! Since you brought up the key binding `M-s a C-s' (added by yours truly) as an example of the obsession with key bindings, I feel responsible for your criticism :-) > Rather, a prefix key like M-x (say, M-z for argument's sake) would be > used for invoking mode-specific "command names". Each mode would bind > such command names to actual elisp functions, and this allows us to > reuse the command names in each mode. I see, we have mode-specific menus and mode-specific key bindings, but not mode-specific command names for the M-x namespace. Maybe it should be not just mode-specific but also context-dependent in a broader sense. Some programs provide <S-f10> to pop up a context menu. So Emacs could provide a separate context menu and corresponding command namespace and key prefixes. ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 22:34 ` Juri Linkov @ 2010-08-27 23:12 ` Lennart Borgman 2010-08-28 23:27 ` Juri Linkov 0 siblings, 1 reply; 277+ messages in thread From: Lennart Borgman @ 2010-08-27 23:12 UTC (permalink / raw) To: Juri Linkov; +Cc: Uday S Reddy, emacs-devel On Sat, Aug 28, 2010 at 12:34 AM, Juri Linkov <juri@jurta.org> wrote: > > Maybe it should be not just mode-specific but also context-dependent > in a broader sense. Some programs provide <S-f10> to pop up a context > menu. So Emacs could provide a separate context menu and corresponding > command namespace and key prefixes. I tried to implement something like that in appmenu.el in nXhtml. (It has changed quite a few times.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-27 23:12 ` Lennart Borgman @ 2010-08-28 23:27 ` Juri Linkov 0 siblings, 0 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-28 23:27 UTC (permalink / raw) To: Lennart Borgman; +Cc: Uday S Reddy, emacs-devel >> Maybe it should be not just mode-specific but also context-dependent >> in a broader sense. Some programs provide <S-f10> to pop up a context >> menu. So Emacs could provide a separate context menu and corresponding >> command namespace and key prefixes. > > I tried to implement something like that in appmenu.el in nXhtml. (It > has changed quite a few times.) You construct menu items from doc-strings, but much simpler would be to use normal menu definitions at point (provided that modes will put them there). ^ permalink raw reply [flat|nested] 277+ messages in thread
* coding guidelines? (was Re: Key bindings proposal) 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier ` (2 preceding siblings ...) 2010-07-29 15:28 ` Uday S Reddy @ 2010-07-30 2:04 ` Joe Brenner 2010-07-30 8:33 ` Andreas Schwab 2010-07-30 9:32 ` Stephen J. Turnbull 3 siblings, 2 replies; 277+ messages in thread From: Joe Brenner @ 2010-07-30 2:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: > Using `remap' is one way to express such an intention. > I would welcome patches that try to make intentions more clear > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the > place) and have myself replaced bindings to TAB and to M-q many times by > settings of indent-line-function and fill-paragraph-functions. Rather than hardcoding "C-c", what are we supposed to do? Are these guidelines documented anywhere? (The elisp manual is full of examples where "C-c" is hardcoded.) ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: coding guidelines? (was Re: Key bindings proposal) 2010-07-30 2:04 ` coding guidelines? (was Re: Key bindings proposal) Joe Brenner @ 2010-07-30 8:33 ` Andreas Schwab 2010-07-30 9:32 ` Stephen J. Turnbull 1 sibling, 0 replies; 277+ messages in thread From: Andreas Schwab @ 2010-07-30 8:33 UTC (permalink / raw) To: Joe Brenner; +Cc: Stefan Monnier, emacs-devel Joe Brenner <doom@kzsu.stanford.edu> writes: > Rather than hardcoding "C-c", what are we supposed to do? mode-specific-map Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 277+ messages in thread
* coding guidelines? (was Re: Key bindings proposal) 2010-07-30 2:04 ` coding guidelines? (was Re: Key bindings proposal) Joe Brenner 2010-07-30 8:33 ` Andreas Schwab @ 2010-07-30 9:32 ` Stephen J. Turnbull 2010-07-31 19:19 ` Joe Brenner 1 sibling, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-07-30 9:32 UTC (permalink / raw) To: Joe Brenner; +Cc: Stefan Monnier, emacs-devel Joe Brenner writes: > > I would welcome patches that try to make intentions more clear > > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the > Rather than hardcoding "C-c", what are we supposed to do? Create a separate map and bind it to a single prefix key sequence. Usually the prefix sequence should also be configurable. From footnote.el: ;;;###autoload (defvar footnote-prefix [(control ?c) ?!] "*When not using message mode, the prefix to bind in `mode-specific-map'") ;;;###autoload (defvar footnote-mode-map nil "Keymap used for footnote minor mode.") ;; Set up our keys ;;;###autoload (unless footnote-mode-map (setq footnote-mode-map (make-sparse-keymap)) (define-key footnote-mode-map "a" 'Footnote-add-footnote) (define-key footnote-mode-map "b" 'Footnote-back-to-message) (define-key footnote-mode-map "c" 'Footnote-cycle-style) (define-key footnote-mode-map "d" 'Footnote-delete-footnote) (define-key footnote-mode-map "g" 'Footnote-goto-footnote) (define-key footnote-mode-map "r" 'Footnote-renumber-footnotes) (define-key footnote-mode-map "s" 'Footnote-set-style)) ;;;###autoload (define-key global-map footnote-prefix footnote-mode-map) That's not quite verbatim; there's some additional weirdness about footnote-minor-mode-map that I don't really understand. > > Are these guidelines documented anywhere? > > (The elisp manual is full of examples where "C-c" is hardcoded.) > ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: coding guidelines? (was Re: Key bindings proposal) 2010-07-30 9:32 ` Stephen J. Turnbull @ 2010-07-31 19:19 ` Joe Brenner 2010-07-31 19:45 ` Joe Brenner 0 siblings, 1 reply; 277+ messages in thread From: Joe Brenner @ 2010-07-31 19:19 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Stefan Monnier, emacs-devel Stephen J. Turnbull <stephen@xemacs.org> wrote: > Joe Brenner writes: > > > I would welcome patches that try to make intentions more clear > > > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the > > > Rather than hardcoding "C-c", what are we supposed to do? > > Create a separate map and bind it to a single prefix key sequence. > Usually the prefix sequence should also be configurable. From > footnote.el: > > ;;;###autoload > (defvar footnote-prefix [(control ?c) ?!] > "*When not using message mode, the prefix to bind in `mode-specific-map'") > > ;;;###autoload > (defvar footnote-mode-map nil > "Keymap used for footnote minor mode.") > > ;; Set up our keys > ;;;###autoload > (unless footnote-mode-map > (setq footnote-mode-map (make-sparse-keymap)) > (define-key footnote-mode-map "a" 'Footnote-add-footnote) > (define-key footnote-mode-map "b" 'Footnote-back-to-message) > (define-key footnote-mode-map "c" 'Footnote-cycle-style) > (define-key footnote-mode-map "d" 'Footnote-delete-footnote) > (define-key footnote-mode-map "g" 'Footnote-goto-footnote) > (define-key footnote-mode-map "r" 'Footnote-renumber-footnotes) > (define-key footnote-mode-map "s" 'Footnote-set-style)) > > ;;;###autoload > (define-key global-map footnote-prefix footnote-mode-map) > > That's not quite verbatim; there's some additional weirdness about > footnote-minor-mode-map that I don't really understand. This is pretty good (and much better than the hacks I was trying to get a customizeable prefix key), but this puts the new bindings in the global keymap. I think what's going on in footnote.el is that they wanted the new bindings in it's own map which is associated with a new minor mode. That approach makes a little more sense to me (for my immediate problem, anyway), but I'm a little puzzled that the minor mode bindings don't go away when you shut off the minor mode. Do I need to do something in an after mode hook to cleanup? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: coding guidelines? (was Re: Key bindings proposal) 2010-07-31 19:19 ` Joe Brenner @ 2010-07-31 19:45 ` Joe Brenner 0 siblings, 0 replies; 277+ messages in thread From: Joe Brenner @ 2010-07-31 19:45 UTC (permalink / raw) Cc: Stephen J. Turnbull, Stefan Monnier, emacs-devel Joe Brenner <doom@kzsu.stanford.edu> wrote: > I think what's going on in footnote.el is that they wanted the new > bindings in it's own map which is associated with a new minor mode. > > That approach makes a little more sense to me (for my immediate problem, > anyway), but I'm a little puzzled that the minor mode bindings don't go > away when you shut off the minor mode. Oops, spoke too soon. I had some cruft in my code that was causing that problem. Sorry. ^ permalink raw reply [flat|nested] 277+ messages in thread
* 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; 277+ 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] 277+ 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; 277+ 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] 277+ 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; 277+ 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] 277+ 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; 277+ 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] 277+ messages in thread
* RE: Key bindings proposal @ 2010-08-03 20:10 MON KEY 2010-08-03 22:19 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: MON KEY @ 2010-08-03 20:10 UTC (permalink / raw) To: u.s.reddy; +Cc: emacs-devel On Tue, 3 Aug 2010 12:56, Uday Reddy wrote: ,---- | When new users come to using a tool like Emacs, their first mode of | interaction is via the menubar, used with the mouse. The second might | be to use keyboard accelerators. `---- As a relevantly recent adoptee of Emacs (circa Winter 2007) I'm compelled to respond. What you say in the above two sentences is true of my experience coming to Emacs. The rest of what you say below is well off the mark w/re my experience. ,---- | Only after they have settled down to using the tool would they begin | to learn some of its key bindings. `---- This does not reflect my experience at all. I read through the tutorial which got me "settled down" in a reasonable time frame and in a reasonable manner. ,---- | And, they will learn them selectively based on the frequency of use | and what they care about. `---- Obv. but this is true of most learning experiences/curves. So what? Maybe someone should author emacs-vulcan-mind-meld.el then learning Emacs will no longer be a selective process. (: ,---- | They almost definitely won't start by reading the manual. Whatever | we might think about it, that is not the way the world works `---- Nearly the first thing I did after reading the tutorial was to _print_ a copy of that big damned Emacs manual wit a 2up landscape orientation. I bound it with some white-glue. Then I read it on the ride to and from work. It quickly became quite dog-eared. Indeed, I once became quite irate once after Stefan politely suggested I RTFM after asking a question on this group re: regexp escaping b/c I _had_ read the manual (though obv. reading about a thing is sometimes mutually exclusive of understanding the thing). ,---- | They will look up the manual when they are stuck on something or | want to learn about some particular feature. If the manual dwells on | the fundamentals too much, it will get in the way. `---- This is a ridiculous assertion. After a few years of Emacs use I still use/refer to the manual constantly. Moreover, I become _annoyed_ when the manual glosses over a fundamental. Frequently my own user experience has been that until I achieve a clear grasp of an Emacs fundamental I am unable to dispense w/ frequent reference to the manual. When the manual discusses a fundamental at length I consider this an _Emacs_ feature that is quite often (i.e. almost always) lacking w/ other software. As a case in point, I read the following portion of the elisp manual on more than one occasion without understanding at all what its author was "getting at" though I did retain an impression that it was somehow important/fundamental: (info "(elisp)Not Intervals") I can recall quite distinctly the moment I finally "got" the implications of this section. My current impression is that the section is a couched lesson in mathematical correctness w/re software. I doubt very seriously most software documentation includes such passages in their manuals though i would bet that its developers would benefit from an opportunity to reflect upon such things.... -- /s_P\ ^ permalink raw reply [flat|nested] 277+ messages in thread
* RE: Key bindings proposal 2010-08-03 20:10 MON KEY @ 2010-08-03 22:19 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-03 22:19 UTC (permalink / raw) To: MON KEY; +Cc: u.s.reddy, emacs-devel MON KEY writes: > As a relevantly recent adoptee of Emacs (circa Winter 2007) I'm > compelled to respond. > > What you say in the above two sentences is true of my experience > coming to Emacs. > > The rest of what you say below is well off the mark w/re my experience. Thank you for sharing your experience with us. You are obviously the kind of model new user that we would all love to have! But, I am not sure how much you can generalize from your own example. The narrative I gave was based on observing large groups of students over several years as a University Professor. If you have knowledge of representative samples of users and their behavior was different from what I narrated, then please by all means counter me. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal @ 2010-08-03 20:39 MON KEY 2010-08-04 0:11 ` Lennart Borgman 0 siblings, 1 reply; 277+ messages in thread From: MON KEY @ 2010-08-03 20:39 UTC (permalink / raw) To: emacs-devel On Tue, 3 Aug 2010 17:02, Lennart Borgman wrote: ,---- | The problem is that it is very hard to get them accepted. Thousands of | users using them without trouble does not seem enough. `---- FWIW I finally stopped using your patched version when the bugs I was seeing did not appear in like instances of Emacs proper or on other free OSs. I resisted abondoning the pathed Emacs until it became clear that problems would not be solved in a manner that allowed me to transparently access/deploy my Emacsen across multiple versions, OSs, etc. The good news is extended use of Lennarts patched Emacs finally convinced me that MS can never be fully integrated w/ Emacs and motivated me switch to a free OS despite the migration pains converting workplace machines. IOW having abandoned the only piece of software that made w32 bearable freed me to leave it. Thanks Lennart! -- /s_P\ ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-03 20:39 MON KEY @ 2010-08-04 0:11 ` Lennart Borgman 0 siblings, 0 replies; 277+ messages in thread From: Lennart Borgman @ 2010-08-04 0:11 UTC (permalink / raw) To: MON KEY; +Cc: emacs-devel On Tue, Aug 3, 2010 at 10:39 PM, MON KEY <monkey@sandpframing.com> wrote: > On Tue, 3 Aug 2010 17:02, Lennart Borgman wrote: > ,---- > | The problem is that it is very hard to get them accepted. Thousands of > | users using them without trouble does not seem enough. > `---- > > FWIW I finally stopped using your patched version when the bugs I was > seeing did not appear in like instances of Emacs proper or on other > free OSs. I resisted abondoning the pathed Emacs until it became > clear that problems would not be solved in a manner that allowed me to > transparently access/deploy my Emacsen across multiple versions, OSs, > etc. What bug was that? ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <0LflI2-1PHZPs2uvS-00oe0Z@mx.perfora.net>]
* Re: Key bindings proposal [not found] <0LflI2-1PHZPs2uvS-00oe0Z@mx.perfora.net> @ 2010-08-13 10:21 ` Xah Lee 0 siblings, 0 replies; 277+ messages in thread From: Xah Lee @ 2010-08-13 10:21 UTC (permalink / raw) To: emacs-devel Lennart Borgman wrote: > We have only been talking about having it as an option. (If that > option should make it default is another question.) > This is already implemented in my patched version of Emacs. (The > default there is still using Alt as Emacs META since I did not want to > confuse new users.) hi all, i just like to voice support for the ability to set Win key as Meta as a option, and the ability to have Windows system wide keyboard access to menu mechanism also work while in emacs. I know Lennart has put huge amount of work to code this, and i feel his emacs distribution, and Carbon Emacs and Aquamacs Emacs has helped emacs spread by a lot outside of GNU/Linux. I've been using them for the past 6 years, am really indebted to them (and FSF too). Xah ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal @ 2010-08-13 11:32 grischka 2010-08-13 12:49 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: grischka @ 2010-08-13 11:32 UTC (permalink / raw) To: u.s.reddy; +Cc: emacs-devel > So, the more we can violate Microsoft's designs, the better we feel. It might make you feel better if you can violate their design by decision and creativity. However just violating a design by lack of creativity or inability to make decisions wont make you feel better I'm sure. On the topic, I'd recommend to leave the Windows keys alone and instead try to get rid of as many Alt-letter bindings as possible to free them for menu access. If then you want to keep say Alt-x, it just means you can't have a menu with X... which seems okay. --- grischka ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 11:32 grischka @ 2010-08-13 12:49 ` Uday S Reddy 2010-08-13 20:24 ` grischka 0 siblings, 1 reply; 277+ messages in thread From: Uday S Reddy @ 2010-08-13 12:49 UTC (permalink / raw) To: grischka; +Cc: u.s.reddy, emacs-devel grischka writes: > > So, the more we can violate Microsoft's designs, the better we feel. > > It might make you feel better if you can violate their design by decision > and creativity. However just violating a design by lack of creativity or > inability to make decisions wont make you feel better I'm sure. I have no idea what you are talking about. The idea of having several sets of modifier keys is a long established design. See this page for example http://en.wikipedia.org/wiki/Space-cadet_keyboard > On the topic, I'd recommend to leave the Windows keys alone and instead > try to get rid of as many Alt-letter bindings as possible to free them for > menu access. If then you want to keep say Alt-x, it just means you can't > have a menu with X... which seems okay. You haven't stated any reason why you want to leave the Windows key alone. And, in particular, why you want everybody else to leave their windows key alone? Alt is being used by Emacs as meta. (Not necessary, but pretty much forced because Emacs doesn't provide any workable alternative.) So there is no way to "get rid of Alt-letter bindings". I am not sure you understand what this discussion is about. Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 12:49 ` Uday S Reddy @ 2010-08-13 20:24 ` grischka 2010-08-14 6:37 ` Uday S Reddy 0 siblings, 1 reply; 277+ messages in thread From: grischka @ 2010-08-13 20:24 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Uday S Reddy wrote: > See this page for example > > http://en.wikipedia.org/wiki/Space-cadet_keyboard > And in how is that relevant to future key binding design? > You haven't stated any reason why you want to leave the Windows key > alone. And, in particular, why you want everybody else to leave their > windows key alone? All I want is emacs to leave my windows key alone. But I'd also want proper menu accelerators via Alt+Letter. You see? > Alt is being used by Emacs as meta. (Not necessary, but pretty much > forced because Emacs doesn't provide any workable alternative.) So > there is no way to "get rid of Alt-letter bindings". Why not? Surely it is possible. > I am not sure you understand what this discussion is about. About how to make scrambled eggs without breaking them? --- grischka > > Uday > ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-13 20:24 ` grischka @ 2010-08-14 6:37 ` Uday S Reddy 2010-08-14 7:59 ` Stephen J. Turnbull 2010-08-23 13:45 ` Juri Linkov 0 siblings, 2 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-14 6:37 UTC (permalink / raw) To: grischka; +Cc: Uday S Reddy, emacs-devel grischka writes: > > I am not sure you understand what this discussion is about. > > About how to make scrambled eggs without breaking them? Fortunately, you can still do it. Sort of. There are two eggs, and you only want to scramble one of them. The problem is that one of the eggs has the the Microsoft logo on it, and people are afraid to break it. Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 6:37 ` Uday S Reddy @ 2010-08-14 7:59 ` Stephen J. Turnbull 2010-08-14 9:39 ` Uday S Reddy 2010-08-23 13:45 ` Juri Linkov 1 sibling, 1 reply; 277+ messages in thread From: Stephen J. Turnbull @ 2010-08-14 7:59 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel Uday S Reddy writes: > The problem is that one of the eggs has the the Microsoft logo on > it, and people are afraid to break it. That's a silly and unproductive claim. Yidong has opposed even providing the option, but I don't understand his logic. Everybody else is in favor of providing the option. They're not afraid of breaking an egg labeled Microsoft, not even Yidong. It seems to be that the real development problem here is that we don't have a reviewable patch. Lennart wants to dump his whole branch on the mainline because he doesn't have time to sort things out. The core devs are uninterested in doing the reviewing of a whole branch with many features in it, some of them not particularly desirable it would seem. The solution is obvious: some third party with an interest in getting this feature into Emacs should 1. Check that Lennart wants to contribute it partially, and is willing to/already has signed papers for it. 2. Get Lennart's version, test that it does what the third party thinks it should do. 3. Dive into the source and tease out a diff that isolates that feature. 4. Submit the patch and push it through the process. If you get to 4, I bet Yidong will change his mind enough to at least review the patch. OTOH, if nobody wants to do that, the whole discussion is moot, isn't it? ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 7:59 ` Stephen J. Turnbull @ 2010-08-14 9:39 ` Uday S Reddy 0 siblings, 0 replies; 277+ messages in thread From: Uday S Reddy @ 2010-08-14 9:39 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Uday S Reddy, emacs-devel Stephen J. Turnbull writes: > Uday S Reddy writes: > > > The problem is that one of the eggs has the the Microsoft logo on > > it, and people are afraid to break it. > > That's a silly and unproductive claim. Sorry everybody. That was a joke. I forgot to put a smiley on it. Don't take offence please! Cheers, Uday ^ permalink raw reply [flat|nested] 277+ messages in thread
* Re: Key bindings proposal 2010-08-14 6:37 ` Uday S Reddy 2010-08-14 7:59 ` Stephen J. Turnbull @ 2010-08-23 13:45 ` Juri Linkov 1 sibling, 0 replies; 277+ messages in thread From: Juri Linkov @ 2010-08-23 13:45 UTC (permalink / raw) To: Uday S Reddy; +Cc: emacs-devel > There are two eggs, and you only want to scramble one of them. > > The problem is that one of the eggs has the the Microsoft logo on it, > and people are afraid to break it. This is not a problem for me because I pasted the GNU sticker over the Microsoft logo on my keyboard :-) ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <0LpLKf-1PMJpV3jOf-00eqos@mx.perfora.net>]
* Re: Key bindings proposal [not found] <0LpLKf-1PMJpV3jOf-00eqos@mx.perfora.net> @ 2010-08-13 17:40 ` Xah Lee 0 siblings, 0 replies; 277+ messages in thread From: Xah Lee @ 2010-08-13 17:40 UTC (permalink / raw) To: emacs-devel Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes: > Hi guys, I am not sure where this discussion is headed. Whether these > applications of the windows key are "useful" or not is for the users > to determine, is it not? Chong Yidong wrote: > The problem is that Lennart's proposed solution seems to be the wrong > one. If you want to rebind the Windows key to a modifier key, the > conceptually correct way to do it should be via a separate program, > separate from Emacs. That is exactly how it is done on GNU/Linux (where > conventions like Alt-TAB are commonly respected, nowadays). > > If there is any technical reason why this cannot be done on Windows, I > have not yet seen anyone argue it. Emacs on Mac all allow either Cmd or Opt to be Meta though. doesn't matter which choice, they step on the OS's function. Cmd is Mac's primary modifier (e.g. copy is Cmd+c, open is Cmd+o), and Opt is for inserting special chars (e.g. like AltGr). same can be said on Windows. Both Alt and Win key have OS purposes. doesn't matter which key emacs uses a meta by default on either Mac or Windows, they intrude the OS keys. Doesn't make sense to me to say setting Win key as Meta is not stepping on OS operation while setting it to Win is. (personally i prefer Alt as Meta on Windows and i don't agree with Lennart or Uday that Alt is more critical than Win in Windows. I think they are both rather important, and i use both heavily on Windows outside of emacs. Win key in general is for system-wide operation, and Microsoft in last few years has more and more emphazied that key's importance thru Windows Vista and now Windows 7. Alt is importance because it provides a system wide method to access any app's menu by pressing key sequences. Quite efficient and is commonly used by power users (e.g. programers).) Overall, i don't think there's any conclusive argument whether by default Alt or Win should be Meta, but providing this choice to user i think is critical for emacs. Xah ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <0LuegS-1Osh2D2A3E-00zozI@mx.perfora.net>]
* Re: Key bindings proposal [not found] <0LuegS-1Osh2D2A3E-00zozI@mx.perfora.net> @ 2010-08-14 0:14 ` Xah Lee 0 siblings, 0 replies; 277+ messages in thread From: Xah Lee @ 2010-08-14 0:14 UTC (permalink / raw) To: emacs-devel > On Fri, Aug 13, 2010 at 18:01, Jason Rumney <jasonr@gnu.org> wrote: > >> Â On 13/8/2010 11:37 PM, Chong Yidong wrote: > >>> If there is any technical reason why this cannot be done on Windows, I >>> have not yet seen anyone argue it. >> >> Such a program might theoretically be possible, but as far as I know it does >> not exist. > > I haven't tried it, but shouldn't AutoHotKey be theoretically able to do it? Lennart Borgman wrote: > I might misremember, but I think that was not possible. That was one > of the reason I added the low level keyboard hook to my patched Emacs. i researched this about 3 months ago, and in one of the doc page, it stated no. (can't find the page at the moment, but i should be able to find it if anyone needs) here's what i've written on my AutoHotkey tutorial: «the “Win+L” (lock computer) and “Win+U” (easy access center) cannot be disabled.» http://xahlee.org/mswin/autohotkey_examples.html it was quoted or rephrased from one of the page in the official doc. (i myself didn't need/want to disable it) basically, it's easy to completely disable the Win key. Can be done with IntelliType that is bundled with every Microsoft keyboards, thru a GUI. but there are certain Win+key combinations that's hard or impossible. See e.g. http://www.autohotkey.com/forum/viewtopic.php?p=345326 btw, same situation with Mac. Certain Opt+key and/or Cmd+key are hard to disable. Xah ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <0MKXcd-1OjFjG3Si7-001yF5@mx.perfora.net>]
* Re: Key bindings proposal [not found] <0MKXcd-1OjFjG3Si7-001yF5@mx.perfora.net> @ 2010-08-14 0:18 ` Xah Lee 0 siblings, 0 replies; 277+ messages in thread From: Xah Lee @ 2010-08-14 0:18 UTC (permalink / raw) To: emacs-devel Drew Adams wrote: > > > It mentions explicitly Alt+Letter. > So what? No one said that menu accelerators do not _exist_. > And no one said that Microsoft has no doc describing them. > I say that my guess is that the percentage of Windows users that regularly use - > or even who have _ever_ tried to use - menu accelerators is very, very, _very_ > small. It simply is not a large part of the global Windows experience. That's > my guess. > Do do guess differently? Do you guess that _most_ Windows users use menu > accelerators? Or even 10% of Windows users? Or 1%? What's your guess? > Do your mother, sister, cousin, neighbor, doctor, dentist, car mechanic, and > grocer (who all use Windows no doubt) use Windows menu accelerators? Have they > even heard of such a thing? > No way. That's _my_ guess. > Would they care to use accelerators if you told them about their existence and > how terribly handy they are? Point them to the URL you passed along as proof of > the importance. See how quickly they adopt this feature that you feel is so > vital to Windows. > No way. That's _my_ guess. Windows's mechanism for accessing menu is pretty old, starting from mid 1990s or earlier. my guess is that most programers use it, and extensively. when i first started to use Windows in a company in 1998, i learned it and use it extensively. I haven't used Windows from about 2002 to 2008, but in 2009 i switched from Mac to Windows as my main machine. I still use the Alt as a efficient way to operate applications. for example, one trick is that Alt+Space brings out the generic window menu, then you can press c to close the window, or other letter to max or min the window. So, typically if i want to close a window, i press Alt+Space c, in any application. That's faster than Alt+F4 because F4 is far up. Same for minimizing the window. And it works system wide. likewise, in Explorer (aka a folder on desktop), i can quickly press Alt v d to change to listing view. Alt v m to change to thumbnail view. and likewise many other operations in diverse applications. For emacs, it is a different beast so i don't use the Alt way to access emacs's menu (after all emacs doesn't really rely on putting commands to menus.). But the point here is that the Alt key on Windows is quite old and very clean and efficient keyboarding system, and i suspect is still heavily used by programers on Windows today. i think the original design is that it allows people to operate the computer wholly without owning a mouse. (at the time mouse is still a novelty from Apple) If i recall correctly, it was well praised. It was so for Windows in 1990s, and i can still operate Windows completely today with just keyboard, reasonably effective (without turning on mousing keys on the number keypad; and without considering 3D apps or drawing apps etc that really requires mousing.) though, Lennart's and Uday argue that Alt key under Windows is more important than the Win key. This i'm not sure. In last few years, i think Microsoft has de-emphasized the importance of the Alt key, and put more emphasize on the Win key. Because the Win key got new logo design with their new keyboards, and there are more shortcuts assigned to it in Vista and more in 7. By default, Windows Vista has the underscore in the menu names turned off. I recall reading that it's because few people use the Alt key today and the underscore in menu names is a eyesore (because average users is happy to use the mouse to pull menus, and the underscore confuses them). in general, the Win key's function is for system wide OS management such as app launch/switch, logging out, system sleep. While Alt is for system wide control of menus by keyboard for each app. There are common exceptions of course. e.g. many games will disable Win key when they are running. Because, in gaming situation, user don't usually want to do any system mangement tasks, and the accidental hitting of Win key is a problem. Likewise, many specialized apps will have different use of Alt key. e.g. In Second Life (a 3D app), Alt is to control camera used in conjunction of mouse. In Blender (3D app), Alt also has specialized purposes. just some input from my experience. Xah ^ permalink raw reply [flat|nested] 277+ messages in thread
[parent not found: <0LyWQo-1Ovn6v30nm-01699h@mx.perfora.net>]
* RE: Key bindings proposal [not found] <0LyWQo-1Ovn6v30nm-01699h@mx.perfora.net> @ 2010-08-14 15:19 ` Xah Lee 0 siblings, 0 replies; 277+ messages in thread From: Xah Lee @ 2010-08-14 15:19 UTC (permalink / raw) To: emacs-devel Uday wrote: > But I am opposed to commercialization. The Windows keys were not on > the IBM PC keyboard. Microsoft added them. They are good modifier > keys. So, I have no problem with Microsoft adding them. My > opposition is to Microsoft branding them, charging royalty to the > keyboard manufacturers, and locking up the keys in Windows-specific > ways so that they are *not free*. And, software freedom is what we > are here about. So, it is a surprise to me that the people here don't > attack this violation of freedom as vigorously as possible. not sure this is true, Uday. Microsoft is also a keyboard manufacture, starting in mid or early 1990s. i don't know the history of how the Win key/logo got so wide spread, but once they made their logo into their own keyboards, and if other keyboard makers want to use them, certainly they are subject to licensing. Apple always has a Apple logo on their keyboards on the Cmd key, only about 3 years ago it's officially removed. Those who make 3rd party Apple keyboard are subject to licensing fee too, am sure, and probably also a royalty. thinking about this... i think FSF might make a keyboard where the Win/Cmd key is a GNU logo. Actually i think that's a good idea because the Win logo key on keyboard is a commonly heard complaint from GNU/linux programers. Actually i think this is quite a doable market... Several kbd makers started to have a cult following due to the fact they sell kbds without the win logo, e.g. Daz, Happy Hacking, and are frequently buzzed about in programing forums and in gadget review sites. (Google recently ban'd MS's OS for their employees (google announced it from their blog, and subsequently reported all over by news agencies). Allegedly, they allow just linux and mac. (if any doesnt know, Google is probably the largest user of GNU/linux in the world, not just as servers, and they are making their own OS based on GNU/linux called Chrome OS) I'd say such a kbd would be popular fairly quickly, especially if FSF takes the initiative to create them.) (PS the Win key and Apple key both send the same keycode am pretty sure. This is because you can plug in a PC keyboard to Mac, or Apple kbd to PC, and the Win/Apple key functions without any special driver.) sorry for the diversion... thinking about putting the gnu head as a logo on the key... it'll needs to be a streamline version, perhaps a silhouette of the gnu head. (am a aficionado of logo artwork and computer keyboards, have written perhaps 50 articles on them.) Xah ^ permalink raw reply [flat|nested] 277+ messages in thread
end of thread, other threads:[~2010-08-31 21:25 UTC | newest] Thread overview: 277+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-26 22:01 Key bindings proposal [Was: Emacs learning curve] Uday S Reddy 2010-07-27 3:17 ` Stephen J. Turnbull 2010-07-27 10:32 ` Key bindings proposal Stefan Monnier 2010-07-27 11:30 ` Eric M. Ludlam 2010-07-27 11:32 ` Stephen J. Turnbull 2010-07-27 12:03 ` Stefan Monnier 2010-07-27 16:41 ` Uday S Reddy 2010-07-27 23:32 ` Miles Bader 2010-07-29 14:05 ` Stefan Monnier 2010-07-27 16:41 ` Stephen J. Turnbull 2010-07-27 17:52 ` Uday S Reddy 2010-07-28 5:57 ` Stephen J. Turnbull 2010-07-28 18:32 ` Uday S Reddy 2010-07-29 5:47 ` Stephen J. Turnbull 2010-07-29 15:28 ` Uday S Reddy 2010-07-29 16:05 ` Andreas Röhler 2010-07-31 7:16 ` Mathias Dahl 2010-07-31 10:04 ` Uday S Reddy 2010-07-31 14:07 ` Alan Mackenzie 2010-07-31 18:17 ` Drew Adams 2010-08-02 14:59 ` Uday S Reddy 2010-08-02 17:59 ` Drew Adams 2010-08-02 18:10 ` Lennart Borgman 2010-08-03 9:45 ` Jan Djärv 2010-08-03 10:02 ` Lennart Borgman 2010-08-03 2:09 ` Stephen J. Turnbull 2010-08-03 11:56 ` Uday S Reddy 2010-08-03 14:04 ` Juanma Barranquero 2010-08-03 15:02 ` Lennart Borgman 2010-08-03 15:16 ` Juanma Barranquero 2010-08-03 15:54 ` Lennart Borgman 2010-08-03 15:18 ` David Kastrup 2010-08-03 15:51 ` Lennart Borgman 2010-08-03 15:58 ` no forking relation (was: Key bindings proposal) Drew Adams 2010-08-05 8:39 ` Key bindings proposal Uday S Reddy 2010-08-05 9:22 ` Juanma Barranquero 2010-08-05 11:00 ` Lennart Borgman 2010-08-05 11:24 ` Juanma Barranquero 2010-08-05 12:16 ` Lennart Borgman 2010-08-05 13:59 ` Uday S Reddy 2010-08-05 14:07 ` Lennart Borgman 2010-08-05 13:10 ` Uday S Reddy 2010-08-05 13:13 ` Juanma Barranquero 2010-08-05 13:22 ` Lennart Borgman 2010-08-05 13:48 ` Uday S Reddy 2010-08-05 14:01 ` Lennart Borgman 2010-08-05 14:01 ` Lennart Borgman 2010-08-05 17:08 ` Uday S Reddy [not found] ` <19546.51009.703000.960158@gargle.gargle.HOWL> 2010-08-05 14:18 ` Lennart Borgman 2010-08-06 0:50 ` Jason Rumney 2010-08-06 1:28 ` Lennart Borgman 2010-08-06 1:35 ` Jason Rumney 2010-08-06 1:41 ` Lennart Borgman 2010-08-06 1:58 ` Lennart Borgman 2010-08-06 2:16 ` Óscar Fuentes 2010-08-06 2:38 ` Lennart Borgman 2010-08-06 2:34 ` Lennart Borgman 2010-08-06 2:55 ` Lennart Borgman 2010-08-06 3:11 ` Lennart Borgman 2010-08-06 6:05 ` Jason Rumney 2010-08-06 15:07 ` Lennart Borgman 2010-08-06 15:29 ` Lennart Borgman 2010-08-05 20:33 ` Óscar Fuentes 2010-08-05 21:26 ` Uday S Reddy 2010-08-05 22:55 ` Lennart Borgman 2010-08-06 0:05 ` Drew Adams 2010-08-06 7:46 ` Eli Zaretskii 2010-08-06 3:21 ` Stephen J. Turnbull 2010-08-06 3:25 ` Lennart Borgman 2010-08-06 5:22 ` Stephen J. Turnbull 2010-08-06 6:21 ` Tassilo Horn 2010-08-06 5:09 ` Miles Bader 2010-08-06 9:02 ` Stephen J. Turnbull 2010-08-06 17:32 ` Uday S Reddy 2010-08-06 17:46 ` Óscar Fuentes 2010-08-06 18:40 ` Uday S Reddy 2010-08-06 19:13 ` Drew Adams 2010-08-06 19:04 ` Juanma Barranquero 2010-08-08 22:22 ` Chong Yidong 2010-08-08 22:29 ` Lennart Borgman 2010-08-08 23:06 ` David De La Harpe Golden 2010-08-08 23:09 ` Chong Yidong [not found] ` <AANLkTim86uB8Yb3P9_HX2NN=RQ6svVTvXfyvUQfAJAnE@mail.gmail! .com> 2010-08-08 23:19 ` Lennart Borgman 2010-08-08 23:42 ` Chong Yidong [not found] ` <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9!! @mail.gmail.com> [not found] ` <AANLkTikRWNmYsEqJX7ccPFGsBobNLkeYRY+1BvnBDOt9! @mail.gmail.com> 2010-08-09 14:50 ` Lennart Borgman 2010-08-09 15:16 ` Uday S Reddy 2010-08-09 16:08 ` Drew Adams 2010-08-10 7:30 ` Stephen J. Turnbull 2010-08-12 15:21 ` Chong Yidong 2010-08-12 15:46 ` Andreas Schwab 2010-08-12 16:13 ` Jan Djärv 2010-08-12 15:59 ` Lennart Borgman 2010-08-12 21:20 ` Juanma Barranquero 2010-08-12 21:57 ` Uday S Reddy 2010-08-12 22:06 ` Uday S Reddy 2010-08-12 22:12 ` Juanma Barranquero 2010-08-12 23:02 ` Lennart Borgman 2010-08-12 23:11 ` Juanma Barranquero 2010-08-13 8:57 ` Uday S Reddy 2010-08-13 14:42 ` Drew Adams 2010-08-13 14:57 ` Lennart Borgman 2010-08-13 16:09 ` Drew Adams 2010-08-13 16:15 ` Lennart Borgman 2010-08-13 17:40 ` David Robinow 2010-08-14 0:01 ` Drew Adams 2010-08-13 16:07 ` Uday S Reddy 2010-08-13 22:34 ` Juanma Barranquero 2010-08-14 0:01 ` Drew Adams 2010-08-14 9:23 ` Uday S Reddy 2010-08-13 22:53 ` Juanma Barranquero 2010-08-14 7:08 ` Uday S Reddy 2010-08-13 15:37 ` Chong Yidong 2010-08-13 15:46 ` Óscar Fuentes 2010-08-13 16:50 ` Chong Yidong 2010-08-13 20:32 ` Óscar Fuentes 2010-08-13 22:37 ` Juanma Barranquero 2010-08-13 23:30 ` Óscar Fuentes 2010-08-13 23:53 ` Juanma Barranquero 2010-08-14 0:21 ` Óscar Fuentes 2010-08-15 22:21 ` Juanma Barranquero 2010-08-14 0:00 ` Drew Adams 2010-08-14 0:25 ` Óscar Fuentes 2010-08-14 2:05 ` Drew Adams 2010-08-14 10:20 ` Jeff Clough 2010-08-14 7:48 ` Uday S Reddy 2010-08-14 8:18 ` Jason Rumney 2010-08-15 22:27 ` Juanma Barranquero 2010-08-16 7:25 ` christian.lynbech 2010-08-16 7:37 ` Miles Bader 2010-08-13 16:01 ` Jason Rumney 2010-08-13 22:40 ` Juanma Barranquero 2010-08-13 22:46 ` Lennart Borgman 2010-08-13 16:04 ` Lennart Borgman 2010-08-13 16:53 ` Chong Yidong 2010-08-14 0:41 ` Jason Rumney 2010-08-14 1:24 ` Chong Yidong 2010-08-14 2:13 ` Jason Rumney 2010-08-14 2:02 ` Drew Adams 2010-08-13 22:43 ` Juanma Barranquero 2010-08-14 0:30 ` Jason Rumney 2010-08-14 12:07 ` Lennart Borgman 2010-08-14 13:56 ` Jason Rumney 2010-08-09 1:01 ` Juanma Barranquero 2010-08-09 8:48 ` Uday S Reddy 2010-08-09 8:13 ` Uday S Reddy 2010-08-10 7:52 ` Uday Reddy 2010-08-13 9:05 ` Uday S Reddy 2010-08-03 15:54 ` Stephen J. Turnbull 2010-08-04 9:52 ` Uday S Reddy 2010-08-04 10:20 ` joakim 2010-08-04 10:52 ` Lennart Borgman 2010-08-04 11:11 ` joakim 2010-08-04 11:25 ` Lennart Borgman 2010-08-04 11:44 ` joakim 2010-08-04 13:24 ` Jason Rumney 2010-08-04 13:29 ` Lennart Borgman 2010-08-04 11:19 ` Jan Djärv 2010-08-04 11:27 ` Lennart Borgman 2010-08-04 13:27 ` Jason Rumney 2010-08-04 13:45 ` Lennart Borgman 2010-08-04 11:16 ` Uday S Reddy 2010-08-04 11:28 ` Andreas Schwab 2010-08-04 11:36 ` Uday S Reddy 2010-08-04 12:03 ` Andreas Schwab 2010-08-04 12:09 ` Lennart Borgman 2010-08-04 12:13 ` Andreas Schwab 2010-08-04 12:17 ` Lennart Borgman 2010-08-04 12:33 ` Uday S Reddy 2010-08-04 16:19 ` Tom 2010-08-04 17:38 ` Stuart Hacking 2010-08-05 2:39 ` Stephen J. Turnbull 2010-08-05 8:16 ` Stuart Hacking 2010-08-05 8:34 ` Andreas Schwab 2010-08-05 11:55 ` Stephen J. Turnbull 2010-08-05 12:20 ` Andreas Schwab 2010-08-05 12:37 ` Stephen J. Turnbull 2010-08-05 12:47 ` Andreas Schwab 2010-08-05 2:28 ` Chong Yidong 2010-08-05 3:14 ` Stephen J. Turnbull 2010-08-05 7:46 ` Uday S Reddy 2010-08-05 15:17 ` David Kastrup 2010-08-06 3:12 ` Stephen J. Turnbull 2010-08-06 5:54 ` Jan Djärv 2010-08-06 6:20 ` Stephen J. Turnbull 2010-08-05 14:01 ` Richard Stallman 2010-08-05 14:55 ` Eli Zaretskii 2010-08-04 14:06 ` Stephen J. Turnbull 2010-08-04 13:53 ` Stephen J. Turnbull 2010-08-04 13:15 ` Jason Rumney 2010-08-04 10:54 ` Stephen J. Turnbull 2010-08-04 11:25 ` Uday S Reddy 2010-08-04 14:25 ` Stephen J. Turnbull 2010-08-04 15:21 ` Óscar Fuentes 2010-08-04 15:45 ` joakim 2010-08-04 12:57 ` Stefan Monnier 2010-08-02 9:42 ` Stuart Hacking 2010-08-02 10:58 ` Uday S Reddy 2010-08-02 11:17 ` Stuart Hacking 2010-08-02 11:58 ` Uday S Reddy 2010-08-03 3:03 ` Stephen J. Turnbull 2010-08-02 10:12 ` Tassilo Horn 2010-08-02 11:24 ` Uday S Reddy 2010-08-23 13:45 ` Juri Linkov 2010-08-23 14:14 ` Thierry Volpiatto 2010-08-23 20:56 ` Juri Linkov 2010-08-23 21:15 ` Thierry Volpiatto 2010-08-23 22:36 ` Drew Adams 2010-08-24 13:55 ` Juri Linkov 2010-08-24 15:20 ` Thierry Volpiatto 2010-08-24 16:38 ` Drew Adams 2010-08-25 13:47 ` Juri Linkov 2010-08-23 14:39 ` Drew Adams 2010-08-23 20:45 ` Juri Linkov 2010-08-24 13:50 ` Juri Linkov 2010-08-24 16:34 ` Drew Adams 2010-08-25 13:48 ` Juri Linkov 2010-08-25 15:07 ` Drew Adams 2010-08-26 23:22 ` Juri Linkov 2010-08-27 12:10 ` Jason Rumney 2010-08-27 22:38 ` Juri Linkov 2010-08-28 0:01 ` Stefan Monnier 2010-08-28 7:28 ` Eli Zaretskii 2010-08-30 14:37 ` Stefan Monnier 2010-08-30 15:34 ` Drew Adams 2010-08-30 15:39 ` Lennart Borgman 2010-08-30 15:53 ` Drew Adams 2010-08-30 16:06 ` Lennart Borgman 2010-08-30 15:54 ` Andreas Schwab 2010-08-30 21:39 ` Davis Herring 2010-08-31 5:49 ` Jan Djärv 2010-08-31 9:54 ` Lennart Borgman 2010-08-31 12:14 ` Jan Djärv 2010-08-31 21:25 ` Lennart Borgman 2010-08-28 9:25 ` Jan Djärv 2010-08-28 1:02 ` Jason Rumney 2010-08-28 9:20 ` Jan Djärv 2010-08-28 9:23 ` Jason Rumney 2010-08-28 9:41 ` Jan Djärv 2010-08-28 10:13 ` Jason Rumney 2010-08-28 10:58 ` Jan Djärv 2010-08-28 23:16 ` Juri Linkov 2010-08-29 7:46 ` Jan Djärv 2010-08-29 11:58 ` David Kastrup 2010-08-29 12:24 ` Jan Djärv 2010-08-25 16:34 ` Stephen J. Turnbull 2010-08-26 23:23 ` Juri Linkov 2010-08-27 0:17 ` Miles Bader 2010-08-27 22:38 ` Juri Linkov 2010-08-27 8:56 ` Uday S Reddy 2010-08-23 17:10 ` Andreas Schwab 2010-08-27 8:18 ` Uday S Reddy 2010-08-27 22:34 ` Juri Linkov 2010-08-27 23:12 ` Lennart Borgman 2010-08-28 23:27 ` Juri Linkov 2010-07-30 2:04 ` coding guidelines? (was Re: Key bindings proposal) Joe Brenner 2010-07-30 8:33 ` Andreas Schwab 2010-07-30 9:32 ` Stephen J. Turnbull 2010-07-31 19:19 ` Joe Brenner 2010-07-31 19:45 ` Joe Brenner -- strict thread matches above, loose matches on Subject: below -- 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 2010-08-03 20:10 MON KEY 2010-08-03 22:19 ` Uday S Reddy 2010-08-03 20:39 MON KEY 2010-08-04 0:11 ` Lennart Borgman [not found] <0LflI2-1PHZPs2uvS-00oe0Z@mx.perfora.net> 2010-08-13 10:21 ` Xah Lee 2010-08-13 11:32 grischka 2010-08-13 12:49 ` Uday S Reddy 2010-08-13 20:24 ` grischka 2010-08-14 6:37 ` Uday S Reddy 2010-08-14 7:59 ` Stephen J. Turnbull 2010-08-14 9:39 ` Uday S Reddy 2010-08-23 13:45 ` Juri Linkov [not found] <0LpLKf-1PMJpV3jOf-00eqos@mx.perfora.net> 2010-08-13 17:40 ` Xah Lee [not found] <0LuegS-1Osh2D2A3E-00zozI@mx.perfora.net> 2010-08-14 0:14 ` Xah Lee [not found] <0MKXcd-1OjFjG3Si7-001yF5@mx.perfora.net> 2010-08-14 0:18 ` Xah Lee [not found] <0LyWQo-1Ovn6v30nm-01699h@mx.perfora.net> 2010-08-14 15:19 ` Xah Lee
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.