Derek.Beatty@UNH.CS.CMU.EDU (09/20/89)
I'm running 18.54.1 under X11R3 (not DECwindows) on a pmax running Mach. When I hit ESC then type M-0 (that's a zero not an Oh), I get the 'Eval: ' prompt in the minibuffer. In other words, the zero of my meta-zero is discarded. I think this is wrong, because when I type ESC then M-0 it's because I'm already confused: I thought I was in incremental search and terminated it with ESC then typed M-0 in preparation for C-L to scroll point to the top of the window. Emacs shouldn't add to my confusion by silently discarding a key that I really pressed. Perhaps it should keep the zero so that I have some chance of realizing what I've done without resorting to C-H l. Or perhaps ESC M-<anything> should signal an error and ring the bell. Silently throwing away the user's keystrokes is never right. -- Derek Beatty
jbw@bucsf.bu.edu (Joe Wells) (09/22/89)
In article <13066.622227723@COSMOS.VLSI.CS.CMU.EDU> Derek.Beatty@UNH.CS.CMU.EDU writes: When I hit ESC then type M-0 (that's a zero not an Oh), I get the 'Eval: ' prompt in the minibuffer. In other words, the zero of my meta-zero is discarded. I think this is wrong, because when I type ESC then M-0 it's because I'm already confused: I thought I was in incremental search and terminated it with ESC then typed M-0 in preparation for C-L to scroll point to the top of the window. Emacs shouldn't add to my confusion by silently discarding a key that I really pressed. Perhaps it should keep the zero so that I have some chance of realizing what I've done without resorting to C-H l. Or perhaps ESC M-<anything> should signal an error and ring the bell. Silently throwing away the user's keystrokes is never right. The patch I am including should fix the behaviour you noticed. However, there may be a good reason why this wasn't done before. If someone knows of such a reason, perhaps they could post it. I haven't tried this myself because I don't want to make the sysadmins angry ... recompiling Emacs takes a lot of space. -- Joe Wells <jbw@bucsf.bu.edu> jbw%bucsf.bu.edu@bu-it.bu.edu ...!harvard!bu-cs!bucsf!jbw ---------------------------------------------------------------------- *** /usr14/gnu/dist-18.55/src/keyboard.c Mon Sep 4 03:46:20 1989 --- keyboard.c Thu Sep 21 19:37:20 1989 *************** *** 1403,1408 **** } keys_prompt = 0; return i; } --- 1403,1410 ---- } keys_prompt = 0; + if (nextc >= 0) + unread_command_char = nextc; return i; }
jbw@bucsf.bu.edu (Joe Wells) (09/25/89)
In article <38641@bu-cs.BU.EDU> jbw@bucsf.bu.edu (Joe Wells) writes: [Suggested change to Emacs deleted] This was in reference to the behaviour of Emacs when ESC M-0 is pressed, using a real meta key. The original complainant, Derek Beatty had suggested that Emacs should behave as if ESC ESC 0 had been typed, instead of discarding the 0. At first I agreed, and I proposed a patch to make Emacs behave that way. Then RMS sent me a letter saying he thought that behaviour would be less than useful. After considering this, I agreed. Instead, I propose that Emacs should neither engage in its current behaviour, nor in the behaviour I proposed earlier. I think ESC M-0 should not invoke the keybinding of ESC ESC at all. Instead, keybindings that end with ESC (the value of meta-prefix-character) should require an exact match with the ESC key, and should not match a meta-prefix. Thus, ESC M-0 would be undefined and would result in no action. I am including a patch that I believe would do this. -- Joe Wells <jbw@bucsf.bu.edu> jbw%bucsf.bu.edu@bu-it.bu.edu ...!harvard!bu-cs!bucsf!jbw ---------------------------------------------------------------------- *** /usr14/gnu/dist-18.55/src/keyboard.c Mon Sep 4 03:46:20 1989 --- keyboard.c Sun Sep 24 17:16:42 1989 *************** *** 1400,1405 **** --- 1400,1408 ---- else nextglobal = Qnil; } + /* Both definitions are terminal (not keymaps). */ + /* Were they reached by meta_prefix_char without consuming nextc? */ + else if (nextc >= 0) read_key_sequence_cmd = Qnil; } keys_prompt = 0;