The installation of im-config breaks the keyboard configuration:
accented characters no longer work, etc.

Note: This package is automatically installed via dependencies
(ibus, needed by Zoom).

again. My configuration by xkbcomp is just ignored.

Running xkbcomp manually after logging in seems to be taken into
account, but
  * currently running applications don't always take into account the
    new settings;
  * I don't want to fix the configuration manually each time I log in.

Something else...
[...]
[...]

Note that I don't use GNOME or any other desktop environment.
I just use fvwm as my window manager.

There is nothing, while when I don't have im-config installed, I get

zira:~> setxkbmap -print
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+gb+inet(evdev)"     };
        xkb_geometry  { include "pc(pc105)"     };
};

Hi Vincent,

I see one thing which looks suspicious: You have set the LC_ALL
environment variable to C. LC_ALL is not supposed to be set permanently.
Ever. Especially not to C, which disables UTF-8 encoding.

What's the contents of your /etc/default/locale file?

With that said, im-config can be disabled if you don't need it. To do
that you can use the "Input Method Configuration" GUI and select "none".
The command line equivalent is:

im-config -n none

Rgds,
Gunnar Hjalmarsson

Hi Gunnar,

Well, I don't have that in my settings, though there may still be
some old scripts around that does this, but only inside the script,
of course.

#  File generated by update-locale
#LANG="en_US.UTF-8"
LANGUAGE="en_US:en"

And in my shell:

zira:~> locale
LANG=POSIX
LANGUAGE=
LC_CTYPE=C.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=en_DK.utf8
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

And if I run "/usr/share/bug/im-config 3> /dev/stdout" manually,
I get:

[...]
=== locale output ===
LANG=POSIX
LANGUAGE=
LC_CTYPE=C.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=en_DK.utf8
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
[...]

But reportbug still gives LC_ALL=C.

Thanks, that works. But the default should not modify the user's
settings.

BTW, reportbug still gives an empty "setxkbmap -print", but the output
is actually sent to the terminal instead of being redirected to the
file... Obviously, there is a missing ">&3" for this line in
"/usr/share/bug/im-config":

[...]
    if [ -x /usr/bin/setxkbmap ]; then
        echo "=== setxkbmap -print ===" >&3
        /usr/bin/setxkbmap -print
        echo >&3
    fi
[...]

Well, the purpose of im-config is to launch and configure an input
method framework if present, and having it do so by default is
considered important.

I see. Possibly we should add a "unset LC_ALL" to /usr/share/bug/im-config.

But as regards your actual locale configuration, I'm still not convinced
that it's sensible, since LANG is unset.

Can you please replace

#LANG="en_US.UTF-8"

with

LANG="C.UTF-8"

and then re-enable im-config:

im-config -n REMOVE

and reboot.

Does ibus/im-config still mess up your keyboard configuration?

Yes, that's indeed a typo. Thanks for mentioning it.

Hello,

2021년 5월 15일 (토) 오후 8:21, Gunnar Hjalmarsson <gunnarhj@debian.org>님이 작성:

Actually LC_ALL=C is set by reportbug and it's an intended
behavior; see /usr/share/doc/reportbug/README.developers.gz

Now I can see

dbus-update-activation-environment: setting LANG=C.UTF-8

in the .xsession-errors file.

Yes, still the same issue.

But if I add "sleep 3" in my .xsession file before executing xkbcomp,
then the issue disappears. There seems to be a race condition.

Hi Changwoo,

Yeah, that's what I came to suspect. Thanks for pointing at the relevant
documentation.

But due to that, the "locale output" section in /usr/share/bug/im-config
isn't so useful. Previously I mentioned the idea to add "unset LC_ALL"
in the script. Or should we better drop the "locale output" section?

Quoting from /usr/share/doc/reportbug/README.developers.gz:

"Part of reportbug "System Information" section of a bug template,
already contains the locale information, no need for your bugscript to
re-discover that information again."

/ Gunnar

Yeah.. Wondering if the explanation can be that ~/.xsession is sourced
before the launch of ibus-daemon has been completed.

@Changwoo, do you have any theory on this?

Indeed, since reportbug modifies the locales, it should provide the
relevant information. However, this may currently be incomplete:
nothing about LC_ALL, which is precisely what is modified by reportbug.

It doesn't output everything that is set. For instance, I use
LC_TIME=en_DK.utf8, and reportbug doesn't output it. However,
this setting is still available.

That is just a consequence of the fact that LC_ALL is set.

I pushed this commit:

https://salsa.debian.org/input-method-team/im-config/-/commit/47941de4

So, Vincent, this bug report has resulted in a tiny improvement at least. ;)

As regards the main topic I don't think it's really an im-config
specific issue. im-config is run as an Xsession script, and possibly
your setup with fvwm and an xkbcomp call in ~/.xsession is a rather
special combo where things happen in the wrong order. Fortunately you
were able to figure out the sleep() workaround.

Keeping the bug open for now to see if more users experience the same issue.

Rgds,
Gunnar Hjalmarsson

I don't think that this is a special combo, at least when not used
a desktop environment like GNOME. You can see other users doing the
same thing:

https://superuser.com/questions/644521/linux-mint-mate-use-xkbcomp-to-load-a-keyboard-layout-on-startup
https://askubuntu.com/questions/437584/xkbcomp-command-at-startup-using-xinitrc

If the user has a .xsession file, that's what it is for.

This was just for testing, but it is not an acceptable workaround,
slowing down the startup, without any guarantee under machine load.
It is up to im-config to do its own synchronization before going on;
that would be sufficient in my case, but...

I'm also wondering whether there could be clashes with other software
provided by Debian, for instance, possibly tigervnc-standalone-server,
which provides /etc/X11/Xtigervnc-session, running setxkbmap before
executing /etc/X11/Xsession.

Note also that the Xsession(5) man page even documents things that
could clash with im-config:

       Here is an example of how one might write a script, named
       40custom_load-xmodmap, to invoke xmodmap(1):

       SYSMODMAP="/etc/X11/Xmodmap"
       USRMODMAP="$HOME/.Xmodmap"

       if [ -x /usr/bin/X11/xmodmap ]; then
           if [ -f "$SYSMODMAP" ]; then
               xmodmap "$SYSMODMAP"
           fi
       fi

       if [ -x /usr/bin/X11/xmodmap ]; then
           if [ -f "$USRMODMAP" ]; then
               xmodmap "$USRMODMAP"
           fi
       fi

(xkbcomp is just the equivalent of xmodmap, with more possibilities
and not breaking some default features).

If the user needs to do something special, this must be documented
in this man page.

Unfortunately, I suspect that most users won't report issues.
Moreover, I suppose that users who have their own settings
normally don't use (and don't need) im-config. Here, it was
installed just via dependencies. So, breakage could occur at
any time when installing an application.

I see in the Mint example that they use sleep() to make it work without
mentioning ibus or im-config. ;) That speaks for this being a general
Xsession issue, which you happened to hit via ibus/im-config.

Possibly a better option is to put the xkbcomp() call in a .desktop file
in ~/.config/autostart.

If you put it within parentheses as in the Mint example (i.e. start a
separate sub process), it won't slow down or jeopardize the whole startup.

I think it's too much to ask from a simple Xsession plugin such as
im-config that it should be responsible for preventing any kind of
possible conflicts.

/ Gunnar

No, this is because Mate is a desktop environment, and DEs typically
have their own config at their levels. I recall that I do *not* use
a desktop environment.

This seems specific to desktop environments.

This will trigger another race condition since the keyboard must be
set up before X applications start (otherwise not all settings are
taken into account). Not a solution.

Then it should not be started by default. If it is so important,
desktop environments could depend on it and enable it on their
side.

If you run "apt rdepends ibus" on a Debian system you see that basically
only input method packages depend on ibus. (gnome-shell recommends it,
which is a special case.) But the output is free of random applications
which depend on ibus.

Well, not in your case, since you installed zoom. I can't tell why they
made zoom depend on ibus, but I'm pretty sure it's a rare exception.

So whatever you think about it, your case is special. ibus was installed
for you even if you didn't really ask for it, and since it pulled
im-config, ibus is configured and launched automatically by default. On
top of that you have an advanced keyboard configuration using an xkbcomp
call in ~/.xsession, and somehow those things don't play well together.

The im-config behavior is based on the assumption that if you install an
input method framework such as ibus or fcitx, you want to use it. It's a
reasonable assumption and it makes it easier for input method users.

Actually im-config checks the XDG_CURRENT_DESKTOP environment variable,
and theoretically it wouldn't be very difficult to disable it by default
if that variable is unset/empty. But personally I would not like to see
such a change. The interest of input method users carries greater weight
IMO.

Maybe somebody comes up with a clever solution which makes everybody
happy. Short of such a solution and for now, please just disable or
remove im-config and move on.

Gunnar,

Thank you for very accurate assessment of the situation.

I can confirm this situation here too.  It didn't bother me since I was
using ibus.

At least, zoom should have used RECOMMENDS and user should have avoided
to install ibus.

Yah

For wayland based applications, they can't use XKB thing.  That's why
ibus included such XKB functionality now to support European language
on Wayland. At the same time you need to configure ibus for such
special features.  Gnome Tweaks can do it.  So theoretically, using
dconf, you should be able to set the same effect even with ibus.  But
the best approach is not to install ibus if you want pure classic X
based desktop.  If zoom depends on ibus and if you can live without
ibus, create fake ibus package with equives.  This may be cleanest
solution for non-free package creating problem.

It seems that one cannot report a bug to Zoom without a Zoom account.
So I've just tweeted them about the issue:
https://twitter.com/vinc17/status/1396199397428432902

The ibus dependency in the zoom .deb file is getting annoying. Besides
this bug there is <https://bugs.debian.org/1004363>, and the other day I
noticed this case:

https://github.com/mike-fabian/ibus-typing-booster/issues/107#issuecomment-1089262983

So I made an own attempt to get in touch with the zoom developers:

https://devforum.zoom.us/t/annoying-ibus-dependency-in-zoom-deb-files/67293

My attempt has been wasted time so far. If somebody else wants to chime
in, please feel free. I have given up.

Classic X environment supports to enter non-ASCII (latin) characters via XKB input
and some people still want to use this via this old setting method.

Bug was filed by an annoyed user who lost access to functionalities offered by his
old fashioned XKB input setting.  This happened because ZOOM (this package is
external to Debian) provides its DEB package with its "Depends" listing ibus.

It is reasonable for ZOOM to support Chinese and Japanese input and list ibus as
dependency.  (XKB can't support Chinese nor Japanese input)

ibus merely recommends im-config for easy set-up but this fact pulls in im-config as
its default behavior.

im-config is a glue layer code to support keyboard input with focus to use modern
mothods (such as ibus).  im-config's default behavior is to use ibus (reasonable
default choice).

ibus can (I think) offer XKB equivalent input functionality if configured correctly.
I don't use such feature so I can't explain with confidence.  Here are some
references which might help.
*
https://superuser.com/questions/1637594/how-to-pass-xkb-options-to-ibus-and-use-them-with-m17n-engines
(2021)
* https://vas.neocities.org/custom_keyboard_layout_xkb_ibus.html (2020)
* https://askubuntu.com/questions/1139936/ubuntu-mate-disable-xkb-and-use-ibus (2019)
* https://askubuntu.com/questions/1077683/ibus-xkb-engine-layouts-dont-work (2018)
* https://wiki.archlinux.org/title/IBus#Troubleshooting

(If I recall correctly, ibus-xkb code has been merged into ibus.  ibus should offer
this XKB input functionality by now.)

Also for im-config, im-config can be configured not to use ibus by running this
command:

    im-config -n none

and reboot.

For both ibus and im-config, the desirable user experience can be provided by proper
user configuration.

So there is no bug on im-config's parts.  (Besides, you can remove im-config too
since it is only recommended.)

I consider this bug report as wishlist bug for the default of im-config.

With the above assessment, I mark this as wontfix and leave this here to help ZOOM
user :-)

(Please note GNOME forces to use ibus even when you disable or remove im-config.)

Regards,

Osamu

im-config can be disabled to avoid breaking the keyboard input using XKB input (ZOOM
user)

thanks

Well, I didn't know that XKB was old fashioned (I started to use it
in 2011, as a migration from xmodmap). I may consider to move to ibus
if there are no drawbacks (and with some hope that long-standing XKB
related bugs disappear). That said...

I doubt that support for Chinese and Japanese input is specific to
Zoom. The dependency should rather be at a higher level in such a
case (the desktop environment?). But since the issue is in the Zoom
package, not provided by Debian, nothing can be done here concerning
this point.

Thanks for the information.

OK. But note that an important part of the issue was that it took me
some time to figure out what was going on: I could notice the breakage
only after logging in again one week later, and I didn't know that this
was related to ibus and im-config (which I had never heard of before,
and I probably forgot that they had been installed). The fact that
I didn't get a warning or an error message in the first place is not
nice, leaving the user in the dark.

IMHO, the user's .xsession file shouldn't be run before im-config has
loaded its configuration.

But this doesn't solve the problem that one doesn't know what's going
on (see above).

Hi,
...

I agree.  There was no need to set "Depends" to "ibus" by ZOOM.  (The best option is
"No mention" and the 2nd best option is "Recommends:".)

On default desktop Debian install, GNOME recommends "ibus" via gnome-shell.  So there
is no need to force pulling in "ibus".  "ibus" is normally installed.

(I was a bit surprised to see "ibus" instead of an alternative input method framework
"fcitx" here.  As I remember, Zoom was started by chinese ex-patriots in USA and used
some servers in China to service ZOOM.  This raised security concern during the
initial COVID-19 crisis.  Although the upstream authors of both programs seem to have
Chinese name, generally fcitx is more popular with Chinese speaking people.  I don't
know if ZOOM has issue with fcitx)

We can't create random monkey patch to warn user.  I am afraid it will be complicated
and unmaintainable.

This is somewhat like some European language user sometimes still insists to have
Latin1 encoding instead of UTF-8.  (Or sysvinit instead of systemd).  Transition is
always painful.

Of course, if I get a clean set of code as a patch, I will merge it.  Scanning user's
home directory is messy task I am not so keen to pursue.

What I suggest is write up best practice of XKB input transition to ibus in a page
wiki.debian.org.  Then create wishlist bug report to ibus asking to add pointer to
the wiki page mentioned in README.Debian.  You can be the best person to do this ;-)

Without im-config, people used the user's .xsession to set up input method.  im-
config honor such setting by checking some environment variables.  If there is such a
marker variable for XKB, we can disable ibus if someone write patch.

Osamu

The right fix is to make Zoom drop the dependency on ibus. Any feedback
here on my attempt to do that?

https://devforum.zoom.us/t/annoying-ibus-dependency-in-zoom-deb-files/67293

Was I not clear enough, or not patient enough?

If multiple Debian users reach out to them, they *might* act after all.

Hi,

Done with strong words.

Aside from unjustified listing of "ibus" in "Depends:" in ZOOM, Vincent has a point.

Need to support user moving from bare XKB setting to ibus's setting.  This side of
needs need to be documented since there are many outdated tips for XKB.

Regards,

Osamu

Hi,

One year ago, I tweeted to Zoom about that, IIRC because I had not found
a way to report a bug:

https://twitter.com/vinc17/status/1396199397428432902

Yes, that would be great.

Hi,


I have updated https://wiki.debian.org/Keyboard.

(debian-reference was updated in 2020-2021, I think.)

These should give clearer view on XKB/input method situation.

If you find errors, please feel free to correct them.

Regards,

Osamu

I can read that xterm uses XIM mechanism and XIM mechanism is buggy. :(
I use mostly xterm (actually a patched version). The other terminals
have font and mouse-wheel handling issues.

Hi,

I also have updated around XIM bugs with more subdued tone.  As long as you type
ASCII characters only, you may not hit bugs (I hope.)

....

I don't have any issue displaying English/French/Chinese/Japanese/...  So I am
curious why you are struggling with font and terminal.

Are you using UTF-8 locale?  Even if you want to use text file encoded in Latin-1
mostly, it will be better to set up system as UTF-8 and use editor functionality to
access Latin-1 encoded files.

My terminal uses:

Backspace key generates ASCII DEL
Delete key generates ESCAPE sequence
Encoding Unicode -- UTF-8
Ambiguous width characters: narrow
Custom font: Hack Nerd Font

Regards,

Osamu

characters (either with a direct mapping to the Unicode character
or via a dead key), Greek letters (via a dead key) and math symbols
(either with a direct mapping to the Unicode character or via the
compose key). But at the end, I always get a single Unicode character
(I do not need to handle combinations of Unicode characters).

These where things that one could mostly do for years, even before XKB
(e.g. with xmodmap), though xmodmap had additional limitations with
some keys.

It seems that the issues mentioned in

https://bugzilla.redhat.com/show_bug.cgi?id=2013610

concern input methods that are not possible with XKB (at least I'm
not aware of).

I've tried xfce4-terminal and lxterminal and they have the same issues
as gnome-terminal.

For xterm, this is due to a change in libfreetype6

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866960

(I've patched xterm, but this is rather ugly because this depends
very much on the font and its size, and I finally think that this
should become a preference). I'm not sure whether this is the same
cause for the other terminals, because the libfreetype6 developers
recommend to use the unrounded metrics, which xterm doesn't do. In
xfce4-terminal, allowing the vertical cell spacing in the terminal
preferences to be slightly less than 1 might solve the issue if
this is supported internally.

Concerning the mouse wheel (bug reported for gnome-terminal):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921537

and this cannot be disabled (ditto with xfce4-terminal at least):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921537#60

Hi,
...
mention on 2021-10-26 03:24:40 UTC that there are 2 possible solutions both of which
seems to cause difficult transition.  His tone for XIM has been very negative.  He
mentions old bug from 2015 such as:

https://github.com/ibus/ibus/issues/1713

In this, he is filing bug to X and it seems still open (or moved to other site?)
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/34

Anyway, XIM is dead end for some foreseeable future.  My conclusion is "don't use
XIM" as backend of ibus. https://wiki.debian.org/Keyboard#Input_method_and_XIM

FYI: im-config currently sets up to run "ibus-daemon --xim" with
IBUS_ENABLE_SYNC_MODE=0

Anyway, seeing discussion like https://github.com/ibus/ibus/issues/1713 make me
wonder to add functionality to stop running "ibus-daemon --xim" or change
IBUS_ENABLE_SYNC_MODE value to accommodate conflicting user needs.  For now, I am
avoiding to create complicated mess by not adding extra functionalities.

I recall seeing such problem before.

I am not annoyed by this problem now under gnome-terminal nor the problem of mouse.  

Let's keep these issues out of this discussion.

Osamu

So, if I understand correctly, users may no longer be able to use xterm
when ibus is installed.

After some search, I've found

https://vas.neocities.org/custom_keyboard_layout_xkb_ibus.html

"This guide will help you create a custom keyboard layout in xkb and
configure ibus to play along nicely."

But this is very unclear (and perhaps wrong for other users).

Hi,

After reading your message, I have revised text around
https://wiki.debian.org/Keyboard#Input_method_and_XIM

Users may no longer be able to use xterm **reliably for some non-ASCII inputs** when
ibus is **activated**.

That's an extreme customization.  There are many ways to get to the goal.

For most people, ibus supports XKB functionality defined by xkb-options with ibus's
internal mechanism.  As long as you use gnome-terminal etc.  (not for xterm nor rxvt)
to get keyboard input, ibus supports xkb-options based substitution smoothly.

I hope my updates
around https://wiki.debian.org/Keyboard#Multi-language_keyboard_configuration_strategy
make it clear.

Regards,

Osamu

Hi,

I thought that some flexible table based fully custom input may be available using
either ibus-table or ibus-m18n with some user data. (This is my vague idea without
proof.)

Then looking at Debian repository, I found ibus-keyman package which supports over
2000 data from https://keyman.com/ (SIL) using  and keyman package.

This looks interesting for Greek/German like combination.  (Not for "Full Japanese
input with Kanji"  ... just hiragana-only)

Osamu

Hi,

...
programs.  gitk (TK based) and emacs-lucid (X, lucid based) may be popular program in
this category.  I updated contents on them:
https://wiki.debian.org/Keyboard#Input_method_and_XIM

FYI: Next upload of debian-reference will list ibus-keyman

Regards,

Osamu

I'm wondering what you mean by that. I recall that:

1. If im-config is run after my XKB settings, then my keyboard
   configuration is broken (probably overridden by im-config's
   own settings). This means that ibus is activated, right?

2. If after that, I apply my XKB settings again, then things work
   as usual (even for xterm), possibly except for applications
   that are currently running (in particular xterm, but this is
   not related to ibus, as this is an issue I reported in 2012:
   bug 661295). So, if ibus is activated (see (1)), this would
   mean that it shouldn't affect xterm, even for most non-ASCII
   inputs (I recall that I use accented letters, possibly via
   dead keys, and math symbols: xterm is receiving the Unicode
   character correctly, so I wonder why it would depend on the
   code point).

Or did you mean that if I want to remap the keyboard with ibus
instead of XKB, then it would not work with xterm[*]?

[*] in case of testing, bug 661295 needs to be taken into account,
i.e. one should test by starting xterm after any config change.

Hi,

Yes.  (To be precise, your XKB settings are *ignored*.  Since keyboard inputs goes
through ibus to reach xterm. ibus is not run under your XKB settings nor under its
influence.  I guess this is the situation but I haven't investigated exact
situation.)

ibus activation may be by the default setting of im-config or by the Desktop
environment such as recent GNOME.

To be honest, I don't want to create nor deal such a complicated situation.

If you want to use classic XKB setting, just don't activate ibus.  (or don't install
ibus.)

I don't know what do you mean by code point.

You make it sounds total breakage.  problem was rare.

Some particular keyboard inputs may cause problem but mostly functional for keyboard
-> ibus -> XIM -> xterm path.  If you re-read my updated page, I describe this subtle
situation carefully.  Please read https://wiki.debian.org/Keyboard . Especially, I
address your concern at
https://wiki.debian.org/Keyboard#Multi-language_keyboard_configuration_strategy

XIM bug for ibus seems to impact particular combination of input sequences anyway.

No no no... let's not create unmanageable system.

Osamu

This is incorrect. XKB settings are ignored when running im-config,
but they are not ignored by changing them with xkbcomp after that.

I recall that I do not use any desktop environment. But im-config
provides /etc/X11/Xsession.d/70im-config_launch, which is sourced
automatically when one logs in, and there is *no way* for the end
user to disable it. The user's $HOME/.xsessionrc file is sourced
before 70im-config_launch, so that this could be a way to let the
user choose (if properly documented), e.g. via setting or not some
shell variable. However, "im-config -n none" may be sufficient.

If "im-config -n none" has the effect that ibus is not activated,
this is fine. Otherwise, there would be issues on multiuser machines,
where ibus and im-config may be installed for users who need them.

Unicode code point. This is how XKB maps the keyboard, with
translations from a key code to a Unicode character (given
by some name or in hexadecimal). For instance, I have:

[...]
    key <AC01> { [ a, A, ae, AE ] };
    key <AC02> { [ s, S, ssharp, U2211 ] };
    key <AC03> { [ d, D, dagger, downarrow ] };
    key <AC04> { [ f, F, U2500, U2502 ] };
    key <AC05> { [ g, G, U250C, U251C ] };
    key <AC06> { [ h, H, U2510, U2524 ] };
    key <AC07> { [ j, J, U2514, U252C ] };
    key <AC08> { [ k, K, U2518, U2534 ] };
    key <AC09> { [ l, L, sterling, U253C ] };
[...]

This is not satisfactory. What do you mean by "pass processed data"
for XIM clients? i.e. what kind of data? And why non-ASCII?

BTW, do you have an example of bug for something that works with XKB
but not with XIM?

What is described under "There have been frequent and persistent bugs
around this combination as discussed in Red Hat Bugzilla – Bug 2013610."
is off-topic, because such input methods are not possible with XKB.

But if some applications start to support ibus only because XKB is
obsolete, "im-config -n none" is not a long-term solution.

??? I'm just saying that if you want to test the behavior and see
that xterm doesn't work, you must not blindly deduce that this is
a bug in XIM or whatever, because xterm or libx11 has its own bugs
and you may actually see that.

Hi,

Your message made me to look into subtle points on Xsession etc.  Thanks.

In order for me to track what I did/do with im-config, I added new section.

https://wiki.debian.org/Keyboard#Overview_of_keyboard_input

The environment in which im-config runs is complicated.

Let me ask a few questions and answer (with easy points first):
...

What do you mean?  Just hand written shell to start X?  Or you start X server from
Linux virtual console manually?

im-config only supports xdm/gdm3/sddm/lightdm/lxdm/wdm... like starting of GUI
environment.

Also, are you running classic X server or xwayland under wayland?  These are
important factor how system responds.

70im-config_launch will end-up running /usr/share/im-config/data/78_none.rc. This is
empty file and do nothing.

This is explained in GUI dialog (if you used GUI) by /usr/share/im-
config/data/78_none.conf.

Yes.  So we agree to be fine.

Since I don't know exactly what is happening on your system and I know the upstream
has been aware of timing involved race condition bug, I am not surprised you are
getting somewhat deterministic results.  (If you are interested, please read the
upstream bug mentioned in detail and test it like upstream.)  Bugs around this XIM
thing is around for last 10 years or so if you trace the older bugs.  That's why I
say to stay out.

https://bugzilla.redhat.com/show_bug.cgi?id=2013610

TBH, I never read X source around this part.  So I don't know.
But guessing from upstream bug reports and my previous read of bug reports, some
special sequence key code is the source of the problem.  The reordering of keyboard
input by the X server seems to be the issue.  (Per upstream in multiple occasions)

Hmmm... XKB is X keyboard extension.  This is X's internal code (skipping kernel
processing of keyboard events) to process key events.  X server sends resulting data
to application program using XIM when input method isn't used.  XIM is some kind of
inter-process communication via pipe.  That's my vague understanding.  I may be wrong
in details.  I updated https://wiki.debian.org/Keyboard as much to reduce confusion.

The upstream has been complaining messy situation over the use of XIM for deadkey or
something similar.  His code on bug report is test code to emulate incidents.  So I
think it is pertinent.  (Anyway, I don't understand all the glory of this
complication and I admit this is my best effort.  If you have full understanding of
the situation, please propose explicit correction texts.)

Long term solution is not to use X keyboard Extension (XKB)  (especially in
combination with ibus is bad idea).  We are moving to Wayland and xwayland doesn't
process Xsession intentionally with reasons.  So the use of input method is the
future.

https://wiki.debian.org/Wayland#Xresources_won.27t_load

I am not going to argue how to get xkbcomp to work while ibus is active.  I clarified
it by stating not to mix.  That's not the future.

Regards,

Osamu

Oops


Let me correct.  I mean non-deterministic.

Osamu

I normally use the lightdm display manager to start X (or in case of
breakage, I start X from a Linux virtual console with "startx"). This
has the effect to run my .xsession script. After some settings, it
starts my window manager FVWM2 (actually a wrapper to handle ssh-agent),
from which applications are run. FVWM2 is just a window manager, not a
desktop environment.

When installed, im-config is started by default via the Xsession
mechanism (which is used at least when one doesn't have a desktop
environment).

A classic X server. I also often use remote X applications (for
which there are no issues with my XKB settings, but I don't know
about ibus / im-config, in particular if it relies on environment
variables that are not passed via SSH).

IIRC, when I tried it, I didn't use the GUI.

If you mean this bug, the user is trying to do things that are not
possible with XKB. So I'm not surprised that there may be issues
in such a case.

This has nothing to do with non-ASCII. Perhaps there might be issues
with things like dead keys or the compose key (as a sequence of keys
is involved) if ibus does something unexpected by the X server. But
this is orthogonal to the character set.

If you mean Red Hat Bugzilla – Bug 2013610:
  * In the first video, the user apparently uses a method to
    automatically output a space after a period and complains
    that they are reversed. But that's 2 characters instead of
    one, i.e. this is not possible with XKB settings (or
    something unusual I'm not aware of). So, off-topic.
  * In the second video, one can see some kind of prediction.
    Again, this is not possible with XKB. So, off-topic.