Re: [emacs-bidi] Control-key binding while typing (for example) Hebrew

[Larry Denenberg]

Eli Zaretskii <address@hidden> 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
address@hidden
http://larry.denenberg.com/