En fait, j'ai court-circuité une explication dans le journal. De la même manière que GTK quand aucune méthode d'entrée n'est spécifiée, IBus n'utilise pas XIM mais sa propre méthode d'entrée quand le mode de saisie par mots n'est pas activé. Du coup, IBus souffre des mêmes limitations et ne prend pas en compte la configuration des entrées X.org. Pas de « $HOME/.XCompose » avec IBus, et ses tables de compositions ne sont pas synchronisées avec X.org, d'où l'intérêt du greffon IBus XKBC (lien dans le journal) qui devrait résoudre ce problème.
Du coup, par défaut, j'ai le choix entre le confort de mes combinaisons de touches via la composition de X, ou la possibilité de saisir des caractères mathématiques par mots LaTeX. Comme je n'utilise que des langues à alphabets courts et pas de chinois ou de japonais, je préfère bénéficier par défaut de mes réglages de composition que de la saisie par mots. Évidemment, avant que je découvre ces problèmes j'utilisais IBus en permanence (et c'est ce que doivent faire tous les utilisateurs de GTK qui n'ont jamais vu les limites du mode de saisie par défaut).
[^] # Re: SCIM vs IBus
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 3.
Du coup, par défaut, j'ai le choix entre le confort de mes combinaisons de touches via la composition de X, ou la possibilité de saisir des caractères mathématiques par mots LaTeX. Comme je n'utilise que des langues à alphabets courts et pas de chinois ou de japonais, je préfère bénéficier par défaut de mes réglages de composition que de la saisie par mots. Évidemment, avant que je découvre ces problèmes j'utilisais IBus en permanence (et c'est ce que doivent faire tous les utilisateurs de GTK qui n'ont jamais vu les limites du mode de saisie par défaut).