[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hi,

> -----Original Message-----
> From: Vincent Lefevre <vincent@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 <vincent@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
> 


Reply to: