bugvile, a vi-compatible text editor - Bugs: bug #23894, XIM doesn't work anymore in 9.7 /...

 
 

bug #23894: XIM doesn't work anymore in 9.7 / x11

Submitter:  None
Submitted:  Sun 20 Jul 2008 06:44:54 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 28 Jul 2008 10:50:38 AM UTC, comment #12: 

Yesss! Just saw and tried the 9.7c patch: now it works !
Thanks.

Anonymous
Sat 26 Jul 2008 12:29:50 AM UTC, comment #11: 

yes - when I was adding the resources, it seemed that they
were only defined for Athena, so I wasn't sure if there were
some other dependencies on that.  Adding the #define's for
the resource names, I see that I can compile/run xvile with
XIM and no Athena.  So I added that to my current changes.

(At the moment I'm modifying the which-keywords and related
stuff to put a hyperlink so I can view the corresponding
file - will put out 9.7c right after that's done).

Thomas Dickey <dickey>
Group administrator
Fri 25 Jul 2008 07:14:58 AM UTC, comment #10: 

Nope.  Sorry, this patch doesn't work for me.

Meanwhile, I documented myself a bit after seeing xev output.

XFilterEvent and XmbLookupString seem to be a new way I didn't know of to get composed keys out of X events.  Additionally all the necessary stuff seems already implemented in x11.c.

Except it seems disabled by
x11.c:115: #define OPT_INPUT_METHOD (OPT_LOCALE && ATHENA_WIDGETS)
(because I build and use the pure Xlib version, not Athena)
when 9.6l directly uses OPT_LOCALE instead of OPT_INPUT_METHOD.

But key composition and XIM/XFilterEvent/XmbLookupString are Xlib stuff;  Why then was it restricted to Athena in vile !?
Looks like the origin of the problem lies here...

Anonymous
Thu 24 Jul 2008 11:23:52 PM UTC, comment #9: 

Here's the fix - remove one line.  It looks the same in
the trace:

diff -u -b -r1.311 x11.c
--- x11.c       2008/05/09 00:21:34     1.311
+++ x11.c       2008/07/24 23:13:51
@@ -3686,7 +3686,6 @@
     cur_win->win = XtWindow(cur_win->screen);
 
 #if OPT_INPUT_METHOD
-    if (cur_win->open_im)
        init_xlocale();
     if (okCTYPE2(vl_wide_enc)) {
        term.encoding = enc_UTF8;

Thomas Dickey <dickey>
Group administrator
Wed 23 Jul 2008 10:51:41 PM UTC, comment #8: 

Thanks - the detail about not holding compose down I seem to
recall, but had forgotten.  With 9.6l I can see some of the
compose sequences (it's easy enough to remember the accents
on vowels), and don't see that in 9.6m.  My settings are
    Option "XkbRules"   "xorg"
    Option "XkbModel"   "pc104"
    Option "XkbLayout"  "us"

Thomas Dickey <dickey>
Group administrator
Wed 23 Jul 2008 07:04:54 AM UTC, comment #7: 

Ok, I see what you missed... we're getting closer to it :)
(Sorry it's gonna be long)

First, I don't use any input-method program.  My dead keys and key composition rules are those from standard Xorg keyboard layout.

More precisely, my layout is:
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "fr"

But I think you don't have to switch to this layout for testing.  Dead keys are specific to it, but the same composition rules should be available in any layout (except where disabled).

I don't think locale is important either; It should matter to vile for file-encoding purpose, but not to Xorg's keyboard driver.

Now, to the "composition" thing.

Composing keys is the act of successively typing the compose-sequence-start key followed by 2 or more other keys. (each typing is press-release, you must not hold the compose key while typing other keys, like you would do with Alt Ctrl or Shift)

On my layout, Multi_key is mapped to keycode 109 which is originally Control_R (french keyboard).  Additionally this key need not be mapped as a modifier, thus I also do:
  echo "remove control = Multi_key" | xmodmap -

Then I can do the following sample combinations:
Multi_key ' e -> é
Multi_key ' E -> É
Multi_key o e -> œ
Multi_key : - -> ÷
Multi_key - n -> ñ
Multi_key / o -> ø
Multi_key - , -> ¬
(and many more)

What you did looks like some form of simple mode shift, like Alt-q (which is mapped to another symbol on my layout).  This is confirmed by my keysymdef.h which tells 0xffe9 is Alt_L.  This works in all xvile versions so far, but this is definitely not key composition...

I tried to build with --with-trace too but then didn't understood what's going on in xvile 9.6l or 9.7, since it looks like mashing keycodes somewhat.

Maybe it's more clear with xev (though what it does doesn't look like XIM -- I'm lost):

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319396824, (12,-179), root:(1229,664),
    state 0x10, keycode 109 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: True

KeyRelease event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319396888, (12,-179), root:(1229,664),
    state 0x14, keycode 109 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes:

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319397224, (12,-179), root:(1229,664),
    state 0x10, keycode 13 (keysym 0x27, apostrophe), same_screen YES,
    XLookupString gives 1 bytes: (27) "'"
    XmbLookupString gives 1 bytes: (27) "'"
    XFilterEvent returns: True

KeyRelease event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319397304, (12,-179), root:(1229,664),
    state 0x10, keycode 13 (keysym 0x27, apostrophe), same_screen YES,
    XLookupString gives 1 bytes: (27) "'"

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319397608, (12,-179), root:(1229,664),
    state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
    XLookupString gives 1 bytes: (65) "e"
    XmbLookupString gives 1 bytes: (65) "e"
    XFilterEvent returns: True

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319397608, (12,-179), root:(1229,664),
    state 0x10, keycode 0 (keysym 0xe9, eacute), same_screen YES,
    XKeysymToKeycode returns keycode: 11
    XLookupString gives 0 bytes:
    XmbLookupString gives 1 bytes: (e9) "é"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1319397688, (12,-179), root:(1229,664),
    state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
    XLookupString gives 1 bytes: (65) "e"

The case of dead keys is different because the compose-sequence-start key doesn't have to be typed, it's something like:
^ e -> ê (^ is a key by itself on french keyboard)

In xev this gives:

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1320900072, (865,339), root:(866,390),
    state 0x10, keycode 34 (keysym 0xfe52, dead_circumflex), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: True

KeyRelease event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1320900136, (865,339), root:(866,390),
    state 0x10, keycode 34 (keysym 0xfe52, dead_circumflex), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1320900376, (865,339), root:(866,390),
    state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
    XLookupString gives 1 bytes: (65) "e"
    XmbLookupString gives 1 bytes: (65) "e"
    XFilterEvent returns: True

KeyPress event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1320900376, (865,339), root:(866,390),
    state 0x10, keycode 0 (keysym 0xea, ecircumflex), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 1 bytes: (ea) "ê"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x4a00001,
    root 0x45, subw 0x0, time 1320900440, (865,339), root:(866,390),
    state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
    XLookupString gives 1 bytes: (65) "e"

Anonymous
Tue 22 Jul 2008 11:03:13 PM UTC, comment #6: 

Which input-method program are you using?
(and how is it setup, what's the hot-key, etc).
If I can set up the same program, I should be able
to find the problem.

Thomas Dickey <dickey>
Group administrator
Tue 22 Jul 2008 10:59:32 PM UTC, comment #5: 

Let's see if we are talking about the same thing.
I looked to see what key would be used for Compose,
and that seems to be the Multi_Key - so xmodmap to
use my right-alt key:
    keycode 113 = Multi_key
which happens to give the same result (for me) as
my left-alt key.  If I type (either) alt-key in combination
with the alphabetic characters for instance, that gives the
same result as with xterm - the Latin-1 codes:

qwerty
ñ÷åòôù

That's done by xterm's program logic.  xvile is doing something
analogous.  Configuring --with-trace, and running it with UTF-8
locale en_US.UTF-8 and an empty .vilerc (to make a short trace),
I see for the alt-q this chunk (in the Trace.out file):

| called {{ x_key_press(0xFFE9) =  ()
| | return }}
| called {{ x_key_press(0x  71) = q (Mod1)
| | modifier 0
| | ADD-CHAR 0xf1
| | return }}
| mapped/getc:ñ (0xf1)
| kcod2prc(0xf1) ->M-q
| tgetc(unquoted) = M-q

Now that my attention is drawn to it, the conversion between
71 (hex) and 0xf1 is done by this chunk in x11.c:

        if (num == 1 && (ev->xkey.state & Mod1Mask)) 
            buffer[0] |= HIGHBIT;

which has "always" been there (since 1996), and does not use XIM.

However - you're seeing a difference.  It may be that your
system has an input-method application available, and that
xvile is not working properly with it.  If that's the problem
then setting xvile's openIm resource to false would prevent it
from using that code.  That is perhaps not the right solution
since up to 9.6l, it always attempted to open XIM.  The trace
from 9.6m shows the XIM as it's opened (I didn't have a trace
in the 9.6l code for this):

| called {{ init_xlocale: 
  inputMethod:@im=kinput2
  preeditType:Root
| | looking for style 'Root'
| | input_style 0x408
| | return }}
| return }} 1

Thomas Dickey <dickey>
Group administrator
Tue 22 Jul 2008 06:57:41 AM UTC, comment #4: 

Do you mean you can make key compositions in xvile without using XIM in application code ? I'm puzzled too...

From what I can recall from my (long ago) Xlib programming, key events should report keycodes;  They can be translated to keysyms directly but then key compositions can't be made (this is what x11 vile 9.7 does IIRC);  XIM was the known standard way to maintain application-side context from successive key events, so that keysyms resulting from compositions could be generated.

So maybe your Xorg server directly generates composed keysyms ? but it would look like a violation of the X11 protocol... (i.e. different behaviour than other X servers)

On my etch, "Xorg -version" reports 7.1.1, while the package is version 1:7.1.0-19.  Do you have similar Xorg version at hand to try ? or non-Xorg servers ? (I don't)

Anonymous
Tue 22 Jul 2008 12:25:24 AM UTC, comment #3: 

I'm puzzled: on my Debian/testing, the 9.6l and current
versions appear to handle compose key the same (though
there's something odd about compose+q that I'm looking
at now).  XIM (I thought) is distinct from compose,
since XIM is a protocol for an external input method,
while compose/dead keys depend on the keyboard configuration
only.  Just to check, I tried with/without the XIM
resources set.

Thomas Dickey <dickey>
Group administrator
Mon 21 Jul 2008 11:04:28 AM UTC, comment #2: 

I built the 9.6l you pointed me at... it works fine: dead and compose keys are taken into account.

Anonymous
Sun 20 Jul 2008 11:17:49 PM UTC, comment #1: 

From the change-log, looks as if I last touched that in
9.6m (20080508), with the input-method stuff.  Can you
check the 9.6l source?  (I'll put a tarball in ftp://invisible-island.net/temp ).  Thanks...

Thomas Dickey <dickey>
Group administrator
Sun 20 Jul 2008 06:44:54 AM UTC, original submission:  

Hi,

In this version of xvile, dead keys and compose don't work.  All keys are input as plain (direct) characters.

I just upgraded from 9.6 to 9.7.  I built the x11 driver variant with:
--prefix=/usr --enable-echo --enable-plugins --disable-filters --with-screen=x11 --with-locale --with-iconv

The very same build options do work fine on 9.6.

My locale is fr_FR.UTF-8 (on Debian GNU/Linux "etch" x86 32-bit, if that matters).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dickey (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-09-09 dickey StatusNone Fixed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code