Issues with quail.el

[Amit Ramon]

I believe I found some bugs in quail.el that occurs when the keyboard
layout is set to a layout that is different from the standard
"quail-keyboard-layout-standard". I'd like to try and fix them myself,
and I have some questions.

First issue

Assume that the keyboard layout is set to "atari-german" and that the
input method is "Hebrew". When I type C-h I (thus invoking
"describe-input-method"), the drawing of the keyboard layout is
incorrect. The keys that appear in the shifted level, which should be,
in this input method, similar to those in the standard layout, are
actually taken from the current keyboard layout.

For example, the Hebrew letter TET is on the (standard) y key, and
pressing this key together with shift when Hebrew input method is
active should produce Y. This works fine when typing, but in the map
drawn by "describe-input-method" the letter that appears on this key
in the shifted state is Z, which is what this key does in
"atari-german" layout. There are some other keys not in the right
place - all those that in "atari-german" have a meaning that is
different than the one in the standard layout.

Second issue

The "quail-show-key" function should describe the keys need to be
pressed in order to produce the character at point. When the input
method is Hebrew and the keyboard layout is not the standard, this
functions fails to find the keys for a Hebrew letter that sits on a
key that its meaning in the current keyboard layout is different from
its meaning in the standard layout.

For example, if the keyboard layout is "atari-german", invoking
"quail-show-key" for the Hebrew letter TET produce the message "TET
can't be input by the current input method".

This is because the key on which TET sits is Y in the standard layout
but Z in "atari-german".

Questions and Comments

For the first issue, the problem is with the "quail-insert-kbd-layout"
function. In its first part this functions generate a list of
characters to be drawn, based in the input method. It walks along the
characters of the keyboard layout, try to translate each using
"quail-map" to obtain the input method character. If translation is
not found for a specific key, its value is taken from the *current
layout* given as an argument to the function. This, as far as I
understand, is an error - input methods are based on the standard
keyboard layout, or in other words, they are based on a fixed known
physical layout. Thus, if a certain input method omits specifying a
translation for a key, it expects that the "default" value will be
taken - i.e., the value from the standard layout.

I'd appreciate an advice here - if I'm right about this, it's an easy
fix.

I also have a more general question. This function takes an argument
which is a keyboard layout, and is used in quail exactly in two
places: one for drawing the layout of an input method (this is what I
was referring to so far), and the other is for drawing the layout of a
*keyboard layout*.

The first thing the function does is to translate the given layout to
the standard one, if "(quail-kbd-layout)" is t.  I don't really
understand why this is needed - if input methods are based on the
standard layout, it seems to me that the "quail-insert-kbd-layout"
function don't need to receive a keyboard layout as an argument at
all. It should work directly with the standard layout and generate the
drawing from it (and that would solve the issue I raised).

So what is the situation in which the given keyboard layout should not
be translated back to the standard layout? If this is for drawing a
keyboard layout (not for an input method), then I would suggest to
break this function down to two separate functions.

I would appreciate your input about it.

For the second issue, I believe the problem is with the
"quail-find-key" function. This function takes a character and try to
back-translate it using quail's "decode-map". However, it seems the
"decode-map" is always based on the standard keyboard layout, no
matter what is the currently set layout. Thus, when the current layout
is not the standard, this function will fail for some characters.

I tried to fix it in a simple way - I take the key(s) returned from
the "decode-map", and translate them from the current layout to the
standard layout (a function for the other direction exists, I had to
write a new one). This seem to work.

However, as seen from the code, the decoding can return either a
string or a different type of object (cons maybe?). I'm not sure in
which cases a non-string type is returned and how to handle it.

With your help, I'd be happy to try and write a fix.

Thanks, and sorry for the length of this mail...

Amit