Thank you; It does explain things -- somewhat. On Fri, 2007-08-24 at 15:12 -0700, Alan M. Evans wrote: > It sounds to me as though you are laboring under the false assumption > that pressing <Enter> invokes some special system call, and that, for > example, pressing <A> or <Spacebar> does not. Is this what you're > thinking? > Yes and no. Understood that all keys produce a keycode. My question -- as you have answered -- was what happens with that keycode after it was produced. Obviously, I one or two (or more) things can happen. > Over-simplifying: > > Pressing any key simply produces a keycode. The system first looks and > decides it has nothing to do with the <Enter> keycode, so it passes the > keycode on to the next entity that might be interested in a key press. > > For simplicity, lets say that the next guy is the Window Manager. The > Window Manager examines the keycode and decides that it doesn't know how > to handle this key, so it passes the keycode on to the next entity that > might be interested in a key press. This is a little too anthropomorphic for me; but I get the idea and it isn't the key part of the question. > > We'll call the next entity the Focused Program. And here's where it gets > interesting. The Focused Program receives the keycode and handles it by > whatever context exists in the program. If the Focused Program is xterm > or gnome-terminal or such then it does as you've described. The main part of your answer is that each program somewhere in its programming has a function() or whatever on how the program will respond to various keycodes. I understand how this works for key intesive programs like emacs. But you are saying that this equally applicable to all programs. That I could, if I wanted change the function of RET by changing the keymap a particular application uses. It is just that the use of RET is fairly well standardized. If I have understood you properly, all this makes sense. > > If the Focused Program has a Focused Widget (a text entry or menu or > whatever) then it will likely pass the keycode on to the routines that > handle events for that Widget, so that the Widget becomes the context > for how the key is handled. > > No magic. All keys are handled the same way. (With some special > consideration for combination keys like <shift> or <ctrl>.) > If all of this is obvious to you then I've clearly misunderstood what > you're having trouble understanding. If so, sorry, move along... The mechanics you have explained is obvious to me and therefore understandable. I suppose, I had assumed, (incorrectly), that because the RET key was so rudimentary and used right from the beginning of a computer session it was predefined somewhere in init or the kernel; that changing its function, for example, was next to impossible because in some way it was unlike other keys. Thank you for the clarification. I came at this question by originally wondering how pushing RET actually issued some command to fire up, start, begin, execute the named program on the command line and where that command or function resided. I knew somewhere an exec or fork command had to be involved. It is obvious to me that if the focus as you outlined falls on the shell then the shell interprets the RET as a a fork or whatever command. -- Regards Bill
