Eli Zaretskii <[email protected]> wrote: >I'm saying that Emacs doesn't know the number of the key (5 in your >example) that produces t. All it knows is that the character t was >sent by the keyboard. Which key number produced it is never >considered. > >Now, if you are saying that the key marked with ALEF on the Dvorak >keyboard is not the same key that is marked with t, then I understand >why it doesn't work for you. Is this what you are saying?
A very confusing discussion. I can't resist adding to the confusion by explaining Amit's problem in a different way (I entirely agree with his analysis) and also bringing up a different approach to the problem. First, everyone agrees on this: An input method just translates characters to other characters. It doesn't know anything about where the character come from, and in particular can't see the keyboard. All the trouble (and confusion) arises because input methods must decide what to do based on *assumptions* about where characters come from, which means assumptions about the keyboard layout. Suppose we're writing a Hebrew input method. What do we do when we receive a "t"? That is, into what Hebrew character should we translate the "t"? We want to translate it into the character that a Hebrew typer expects when he presses the key that transmits a "t". But which key is that? That is, which key produces a "t"? Assuming a standard keyboard, a "t" is produced by a key in the middle of the top row. On a Hebrew keyboard, that key should produce alef. So we map "t" to alef, right? But this is true only on a standard keyboard. If the user has a Dvorak keyboard, the key that produces "t" is near the right of the middle row. On a Hebrew keyboard, that key should produce lamed. So should our Hebrew input method map "t" to alef or to lamed? There is no way to tell without knowing which keyboard the user is using. Said another way: We need two Hebrew input methods, one for each keyboard. So, to Eli: Yes, that's what he's saying. If you have a keyboard where the keys are marked with both the standard Hebrew layout and the Dvorak layout, the key marked "t" is NOT also marked "alef". We've been assuming that the Dvorak user has a physical Dvorak keyboard. But the conclusion is the same even if the computer is "simulating" Dvorak by translating the QWERTY keyboard layout into Dvorak. That translation is done *before* Emacs sees any characters. It's not the case that Emacs translates some characters and "lets the rest pass through to [the] operating system's normal keystroke handler". Translations in the operating system (or in X) happen first. Now we get to the point where I don't fully understand Amit's problem. Let me start by explaining my own situation and proposed solution. I'm working on a Mac, so to switch to Hebrew I tell the *Macintosh* (not Emacs) to switch to Hebrew. The Mac has many built-in input methods including a couple for Hebrew. Doing this at the level of the Mac switches me to Hebrew throughout the system, not just for Emacs---I switch in the same way when I want to type a Hebrew word into the Google search box of my browser. This means that, in Emacs, I don't need an input method at all. The OS is already translating everything for me. Emacs gets Hebrew letters just as though I had a keyboard that directly generated them. However, I do have the following problem: Suppose I switch the Mac to Hebrew and type control-B in Emacs. The Mac quite properly translates this into control-bet, because bet is on the key marked "B" (I'm using a Hebrew-for-QWERTY-typers layout). Then of course Emacs says that control-bet is not bound to anything, which is not what I want. I want to move backward one character, just as though I were not in Hebrew. (Although of course "backward" means "right", but that's irrelevant.) One solution, which I assume is easy, is to make an input method that translates control-bet back to control-B and similarly for other keys. But this is not a good answer because it means that switching to Hebrew takes two steps: Switch the Mac OS to Hebrew, then switch Emacs to the new compensating input method. If I switch the Mac to Hebrew while browsing, I don't want to have switch Emacs when---perhaps much later---I move from the browser to Emacs. My planned solution is to do a bunch of keyboard bindings along the lines of "(global-set-key control-bet 'backward-char)". These bindings can stay in effect globally and permanently, since control-bet isn't needed for anything else. It's not completely trivial to do this; for example, control-kaph (which is produced by control-X) needs a whole keymap rather than just a binding. But the resulting solution should be very good. I haven't started yet, so if anyone has already done it or has comments or suggestions I'd be very grateful for them. Now back to Amit: Are you switching your whole computer to Dvorak at the X level? In that case I would have thought that the Emacs Hebrew input method is totally broken, not just for control keys. Or are you switching the whole machine to Hebrew? In that case I think you might be better off with a solution via permanent key bindings rather than a new input method, for reasons explained above. Let me add my appreciation for the latest round of bidi work, which I just found after years of waiting for it. I know it was an enormous effort and the results are outstanding. Apologies for the length of the post. I didn't have time to shorten it. /Larry Denenberg [email protected] http://larry.denenberg.com/ _______________________________________________ emacs-bidi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-bidi
