Bug#988540: im-config: breaks the keyboard configuration

[Vincent Lefevre]

Something else...

On 2021-05-15 11:49:50 +0200, Vincent Lefevre wrote:
> === /etc/default/im-config ==
[...]
> # List of desktop systems which starts ibus if available
> # Applicable desktops are excluded for applying IM_CONFIG_PREFERRED_RULE
> DESKTOP_SETUP_IBUS="GNOME"
[...]

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

> === setxkbmap -print ===
>

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)" };
};

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre]

On 2021-05-15 11:49:50 +0200, Vincent Lefevre wrote:

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

I forgot to say: this happens only after logging out and logging in
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.

[Vincent Lefevre]

Hi Gunnar,

On 2021-05-15 13:11:04 +0200, Gunnar Hjalmarsson wrote:
> 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.

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.

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

# 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.

> 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

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
[...]

[Gunnar Hjalmarsson]

On 2021-05-15 14:27, Vincent Lefevre wrote:
>> 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
>
> Thanks, that works. But the default should not modify the user's
> settings.

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.

> But reportbug still gives LC_ALL=C

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.

>> What's the contents of your /etc/default/locale file?
>
> # File generated by update-locale
> #LANG="en_US.UTF-8"
> LANGUAGE="en_US:en"

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?

> 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
> [...]

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

[Changwoo Ryu]

Hello,

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

>
> 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.

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

[Vincent Lefevre]

On 2021-05-15 16:07:46 +0200, Gunnar Hjalmarsson wrote:
> > > What's the contents of your /etc/default/locale file?
> >
> > # File generated by update-locale
> > #LANG="en_US.UTF-8"
> > LANGUAGE="en_US:en"
>
> 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.

Now I can see

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

in the .xsession-errors file.

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

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.

[Gunnar Hjalmarsson]

On 2021-05-15 17:20, Vincent Lefevre wrote:
> On 2021-05-15 16:07:46 +0200, Gunnar Hjalmarsson wrote:
>>>> What's the contents of your /etc/default/locale file?
>>>
>>> # File generated by update-locale
>>> #LANG="en_US.UTF-8"
>>> LANGUAGE="en_US:en"
>>
>> 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.
>
> Now I can see
>
> dbus-update-activation-environment: setting LANG=C.UTF-8
>
> in the .xsession-errors file.
>
>> Does ibus/im-config still mess up your keyboard configuration?
>
> 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.

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?

[Gunnar Hjalmarsson]

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

[Vincent Lefevre]

On 2021-05-15 17:54:39 +0200, Gunnar Hjalmarsson wrote:
> 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."

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.

[Gunnar Hjalmarsson]

On 2021-05-15 18:55, Vincent Lefevre wrote:
> 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.

[Gunnar Hjalmarsson]

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

[Vincent Lefevre]

On 2021-05-17 01:25:32 +0200, Gunnar Hjalmarsson wrote:
> 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.

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.

> Fortunately you were able to figure out the sleep() workaround.

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.

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

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.

[Gunnar Hjalmarsson]

On 2021-05-17 10:10, Vincent Lefevre wrote:
> 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

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.

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

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

>> Fortunately you were able to figure out the sleep() workaround.
>
> This was just for testing, but it is not an acceptable workaround,
> slowing down the startup, without any guarantee under machine load.

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.

> It is up to im-config to do its own synchronization before going on;
> that would be sufficient in my case, but...

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

[Vincent Lefevre]

On 2021-05-17 21:11:16 +0200, Gunnar Hjalmarsson wrote:
> On 2021-05-17 10:10, Vincent Lefevre wrote:
> > 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
>
> 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.

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.

> > If the user has a .xsession file, that's what it is for.
>
> Possibly a better option is to put the xkbcomp() call in a .desktop file in
> ~/.config/autostart.

This seems specific to desktop environments.

> > > Fortunately you were able to figure out the sleep() workaround.
> >
> > This was just for testing, but it is not an acceptable workaround,
> > slowing down the startup, without any guarantee under machine load.
>
> 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.

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.

> > It is up to im-config to do its own synchronization before going on;
> > that would be sufficient in my case, but...
>
> 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.

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.

[Gunnar Hjalmarsson]

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.

--
Regards,
Gunnar Hjalmarsson

[Osamu Aoki]

Gunnar,

Thank you for very accurate assessment of the situation.

On Tue, 2021-05-18 at 00:22 +0200, Gunnar Hjalmarsson wrote:
> On 2021-05-17 22:19, Vincent Lefevre wrote:
> > On 2021-05-17 21:11:16 +0200, Gunnar Hjalmarsson wrote:
> > > 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.
> >
> > 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.

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.

> 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.

Yah

> 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.

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.

[Vincent Lefevre]

On 2021-05-22 13:46:50 +0900, Osamu Aoki wrote:
> At least, zoom should have used RECOMMENDS and user should have avoided
> to install ibus.

I would even say "Suggests:", so that ibus isn't installed by default.

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

[Gunnar Hjalmarsson]

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

[Gunnar Hjalmarsson]

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

--
Gunnar

[Osamu Aoki]

Control: tags -1 wontfix
Control: severity -1 wishlist
Control: retitle -1 im-config: breaks the keyboard input using XKB input (ZOOM user)
Control: summary -1 0
thanks

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

[Osamu Aoki]

Control: summary -1 0

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

thanks

[Vincent Lefevre]

On 2022-05-21 00:05:09 +0900, Osamu Aoki wrote:
> 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.

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...

> 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)

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.

> 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.)

Thanks for the information.

> Also for im-config, im-config can be configured not to use ibus by
> running this command:
>
> im-config -n none
>
> and reboot.

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.

> 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.

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

> (Besides, you can remove im-config too since it is only
> recommended.)

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

[Osamu Aoki]

Hi,

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>
...
> > 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)
>
> 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.

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)

> 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.

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 ;-)

> > 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.
>
> IMHO, the user's .xsession file shouldn't be run before im-config has
> loaded its configuration.

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

[Gunnar Hjalmarsson]

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.

--
Gunnar

[Osamu Aoki]

Hi,

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

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

[Vincent Lefevre]

Hi,

On 2022-05-21 11:16:53 +0900, Osamu Aoki wrote:
> > If multiple Debian users reach out to them, they *might* act after all.
>
> Done with strong words.

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

> 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.

Yes, that would be great.

[Osamu Aoki]

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

[Vincent Lefevre]

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.

[Osamu Aoki]

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.)

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>

....

> 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.

Hmmm... gnome-terminal may be bloated but we can use other lighter terminal programs.

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

[Vincent Lefevre]

On 2022-05-22 21:59:35 +0900, Osamu Aoki wrote:
> 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 use XKB specifically to enter non-ASCII characters: accented
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).

> > -----Original Message-----
> > From: Vincent Lefevre <vin...@vinc17.net>
>
> ....
>
> > 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.
>
> Hmmm... gnome-terminal may be bloated but we can use other lighter
> terminal programs.

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

> I don't have any issue displaying English/French/Chinese/Japanese/...
> So I am curious why you are struggling with font and 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

[Osamu Aoki]

Hi,

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>
...
> On 2022-05-22 21:59:35 +0900, Osamu Aoki wrote:
> > 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 use XKB specifically to enter non-ASCII characters: accented
> 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).

This bug affects xterm, and rxvt which use XIM. In this, the upstream Takao Fujiwara
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.

> > > -----Original Message-----
> > > From: Vincent Lefevre <vin...@vinc17.net>
> >
> > ....
> >
> > > 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.
> >
> > Hmmm... gnome-terminal may be bloated but we can use other lighter
> > terminal programs.
>
> I've tried xfce4-terminal and lxterminal and they have the same issues
> as gnome-terminal.
>
> > I don't have any issue displaying English/French/Chinese/Japanese/...
> > So I am curious why you are struggling with font and terminal.
>
> For xterm, this is due to a change in libfreetype6
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866960

I recall seeing such problem before.

> (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.

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
>

[Vincent Lefevre]

On 2022-05-23 06:23:58 +0900, Osamu Aoki wrote:
> 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

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).

[Osamu Aoki]

Hi,

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

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>

> To: Osamu Aoki <os...@debian.org>
> Cc: Gunnar Hjalmarsson <gunn...@debian.org>, 988...@bugs.debian.org, brian m.
> carlson <san...@crustytoothpaste.net>
> Subject: Re: Bug#988540: im-config: breaks the keyboard configuration
> Date: Mon, 23 May 2022 00:54:45 +0200
>
> On 2022-05-23 06:23:58 +0900, Osamu Aoki wrote:
> > 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
>
> So, if I understand correctly, users may no longer be able to use xterm
> when ibus is installed.

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

> 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).
>

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

[Osamu Aoki]

Hi,

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

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

[Osamu Aoki]

Hi,

> -----Original Message-----
> From: Osamu Aoki <os...@debian.org>

...

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

I thought about this issue over combination of pure-X GUI and ibus for non-terminal
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

[Vincent Lefevre]

On 2022-05-23 11:49:21 +0900, Osamu Aoki wrote:
> Users may no longer be able to use xterm **reliably for some
> non-ASCII inputs** when ibus is **activated**.

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.

[Osamu Aoki]

Hi,

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>
> To: Osamu Aoki <os...@debian.org>
> Cc: Gunnar Hjalmarsson <gunn...@debian.org>, 988...@bugs.debian.org, brian m.
> carlson <san...@crustytoothpaste.net>
> Subject: Re: Bug#988540: im-config: breaks the keyboard configuration

> Date: Tue, 24 May 2022 12:54:54 +0200
>
> On 2022-05-23 11:49:21 +0900, Osamu Aoki wrote:
> > Users may no longer be able to use xterm **reliably for some
> > non-ASCII inputs** when ibus is **activated**.
>
> 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?

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.

> 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).

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.)

> 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).

I don't know what do you mean by 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[*]?

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.

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

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

Osamu

[Vincent Lefevre]

On 2022-05-24 22:54:01 +0900, Osamu Aoki wrote:
> > > Users may no longer be able to use xterm **reliably for some
> > > non-ASCII inputs** when ibus is **activated**.
> >
> > 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?
>
> 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.)

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

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

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 you want to use classic XKB setting, just don't activate ibus.
> (or don't install ibus.)

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.

> > 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).
>
> I don't know what do you mean by code point.

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 ] };
[...]

> 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 .

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.

> Especially, I
> address your concern at
> https://wiki.debian.org/Keyboard#Multi-language_keyboard_configuration_strategy

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

> XIM bug for ibus seems to impact particular combination of input sequences anyway.
>
> > [*] in case of testing, bug 661295 needs to be taken into account,
> > i.e. one should test by starting xterm after any config change.
>
> No no no... let's not create unmanageable system.

??? 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.

[Osamu Aoki]

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):

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>

...
> > ibus activation may be by the default setting of im-config or by the
> > Desktop environment such as recent GNOME.
>
> I recall that I do not use any desktop environment. 

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.

> 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.

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.

> > If you want to use classic XKB setting, just don't activate ibus.
> > (or don't install ibus.)
>
> 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.

Yes. So we agree to be fine.

> > > 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).
> >
> > I don't know what do you mean by code point.
>
> 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 ] };
> [...]

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

> > 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 .
>
> 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?
>

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)

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

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.

> 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.

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.)

> > Especially, I
> > address your concern at
> > https://wiki.debian.org/Keyboard#Multi-language_keyboard_configuration_strategy
>
> But if some applications start to support ibus only because XKB is
> obsolete, "im-config -n none" is not a long-term solution.

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

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>

> ...
> > 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.)
>
> This is incorrect. XKB settings are ignored when running im-config,
> but they are not ignored by changing them with xkbcomp after that.

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

[Osamu Aoki]

Oops


Let me correct. I mean non-deterministic.

> 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 **non**-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
>

Osamu

[Vincent Lefevre]

On 2022-05-25 15:54:13 +0900, Osamu Aoki wrote:
> > I recall that I do not use any desktop environment. 
>
> What do you mean? Just hand written shell to start X? Or you start X
> server from Linux virtual console manually?

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.

> im-config only supports xdm/gdm3/sddm/lightdm/lxdm/wdm... like
> starting of GUI 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).

> Also, are you running classic X server or xwayland under wayland?

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).

> > [...] However, "im-config -n none" may be sufficient.

>
> 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.

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.

> > > 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 .
> >
> > 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?
>
> 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)

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.

> > 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.
>
> 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.)

Do you have the bug report?

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.

[Osamu Aoki]

Hi,

Maybe I used too strong word to describe XIM + ibus combination situation.
But I still feel unsafe to do so.

Please note I am not saying use of xterm under pure X environment (without ibus) with
xmodmap to be unsafe nor buggy. That's fine good old system.

> -----Original Message-----
> From: Vincent Lefevre <vin...@vinc17.net>
...

> 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.
....
> 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).

I see. You are in good old X environment.
ibus runs on your computer running ssh client. So it works.

> > > [...] However, "im-config -n none" may be sufficient.

> .>
> >..

> This is explained in GUI dialog (if you used GUI) by /usr/share/im-
> > config/data/78_none.conf.
>
> IIRC, when I tried it, I didn't use the GUI.

OK. But that is what happens. Hmmm manpage needs to be updated to explain "none".

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

...

> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2013610
>
> 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.

True. This recent bug may not affect such simple input. (Korean phonetic input had
issue previously but we applied workaround: IBUS_ENABLE_SYNC_MODE=0)

Anyway, its not safe playing with data path which has been hit by many bugs. I have
no interest in compiling list of previous bugs but I have bad memory around this data
path.

Let's look at practical aspect.

You want to run pure X Window based system without input method framework (ibus) but
use xmodmap to take care character table and XIM to send keyboard generated data to
your application. We now have answer for your needs.

1. Keep away from GNOME since it forces you to install and activate ibus.
2. Don't install ibus nor fcitx5.
3. If ibus is installed for any reason, disable it with "im-config -n none".

Regards,

Osamu