On Sun, Jun 27, 2010 at 10:55 PM, Amit Ramon <[email protected]> wrote:

> Eli Zaretskii <[email protected]> [2010-06-26 19:55 +0300]:
>
>
>> Could you and Larry please look for an option of the X keyboard driver
>> to leave the Ctrl- and Alt-modified keys untranslated?  This would
>> eliminate at least some of the issue.  At least with commands like
>> incremental search, it would be very inconvenient to have to switch
>> the language between C-s and the string, especially since switching
>> the language could produce an input event on some platforms, which
>> will exit the I-search.
>>
>
> I started to look at it. So far it seems that under X it is (at least
> to some extent) the responsibility of an application to take care of
> handling modified keys. I'll try to look further into it, and will
> post here any findings. Perhaps this is a question to the Emacs
> developers.
>
>
Just to avoid duplication of threads, I should mention that my conclusion
(also not final) was the same:

On Sun, Jun 27, 2010 at 6:30 AM, Amit Aronovitch <[email protected]>
 wrote:

> From a brief check, on Linux with X,  with Hebrew and English
> layouts, situation seems to be like that:
>
> 1) On the basic X level (I used xev to test) there is a "state" (binary
> flags, indicate e.g. if ctrl was held, and also the "group" i.e. if we are
> in Hebrew or English mode), keycode (a number, which is the same for "א" and
> "t"), and an "XLookupString" which is the same (14) for both "ctrl-t" and
> "ctrl-א" (but does differentiate between them if ctrl is not held). xev
>  also reports "keysym" which is the unicode point for "t" in both cases
> (ctrl-t and ctrl-א), but is the unicode point for א if control is not
> pressed.
> 2) In gtk (a higher level interface), there is "gdk_keyval_name", which is
> either "א" or "t" according to the current layout (language mode). Whether
> or not ctrl was down is determined by the mask GDK_CONTROL_MASK in the state
> of the event.
>
>  Note that at both levels there is no specific code for "ctrl-א". Whatever
> it is that emacs sees is either generated by some higher level function that
> I am not aware of, or generated within emacs itself. Probably we should look
> it up in the code.
>

This should probably appear in the gtk- or X- specific parts of emacs.
Allocating a few free hours for diving into unfamiliar code might take a few
weeks in my case, so I'll be happy if someone else does that in the
meantime.

   (the other) Amit
_______________________________________________
emacs-bidi mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-bidi

Reply via email to