XCompose: How to disable default compose sequences?

Ask Fedora
, ,
1

Hi,

I’m a heavy user of the Compose key and have a custom ~/.XCompose file defining many compose sequences.

man xcompose says:

Compose files can use an “include” instruction. This allows local modifications to be made to existing compose files without including all of the content directly. For example, the system’s iso8859-1 compose file can be included with a line like this:

 include "%S/iso8859-1/Compose"

There are several substitutions that can be made in the file name of the include instruction:

%H expands to the user’s home directory (the $HOME environment variable)

%L expands to the name of the locale specific Compose file (i.e., “/usr/share/X11/locale//Compose”)
%S expands to the name of the system directory for Compose files (i.e., “/usr/share/X11/locale”)

For example, you can include in your compose file the default Compose file by using:

include "%L"

and then rewrite only the few rules that you need to change. New compose rules can be added, and previous ones replaced.

In practice, however, I’m finding that even when I have no include line, the default compose sequences do get used.

  • Is this expected?
  • How do I disable them? (The motivation is creating a personal compose file that I can carry across computers without worrying about the system’s locale.)

I’m on Fedora 39, in the default flavor (with GNOME).

2

Are you using Wayland? libxkbcommon follows the behavior implied by that man page and stops at the first XCompose file found.

IBus also reads those files, and it also seems to follow that convention. ibus-typing-booster originally did not, but that’s been fixed: Don’t include the system compose files unconditionally if a user compose file exists. · Issue #170 · mike-fabian/ibus-typing-booster · GitHub

3

I’m using… whatever is the default on Fedora 39. I’ve had little success trying to understand what the exact state of X11 is and what is or is not using XWayland.

All I know is

$ echo $XDG_SESSION_TYPE
wayland

Well, that’s not the behavior I’m experiencing. Is this the library I should be reporting a bug to?

4

My concern is that multiple things seem to load XCompose files, so there could be something else, maybe another part of IBus.

Can you try installing weston and logging into the ‘Weston’ session? In that minimal environment, libxkbcommon should be the only thing used. What happens there?

5

How do I make the compose key work under Weston? I tried it and figured out I needed this ~/.config/weston.ini file:

[keyboard]
keymap_layout=fr
keymap_options=compose:ralt

to get my usual layout and enable the right Alt key as a compose key, but that compose key didn’t really work. The normal function of the key was inhibited, but it wasn’t printing any compose sequence either (whether defined in my custom file or predefined).

6

Hmm, I’ve just tried keymap_options=compose:menu (with a querty layout), and it works here. <Compose> . . produces …, and after creating an empty ~/.XCompose and restarting the session, it doesn’t anymore.

7

Oh, that’s curious. I can reproduce the same thing: when I remove ~/.XCompose, the compose key does start working, with the default bindings. When I add back ~/.XCompose, with my custom bindings and no include directory, the default bindings go away but the custom bindings don’t work.

(BTW, is there an easier way to exit Weston than kill -9 $(pgrep weston | head -1)?)

8

Also, when I add an include directory to that XCompose file, the default sequences start working on Weston, but the custom sequences still don’t work.

9

Cross-posted on Where to report a bug with XCompose files? - Platform - GNOME Discourse

10

I’ve asked a (somewhat more general) question here: x11 - Understanding the keyboard input stack on desktop Linux, esp. compose keys - Unix & Linux Stack Exchange