I am not sure this is a "bug", however it is an inconvenience which other XCompose parsers do not seem to have.

CONTEXT

I like emdashes— a lot. My custom XCompose contains a custom sequence:

<Multi_key> <minus> <minus>: "—" # mcc's emdash

This is because all standard Compose files, including the /usr locale one on my system, contain

<Multi_key> <minus> <minus> <minus>     : "—"   U2014 # EM DASH

And that's too many minuses for me— I'd prefer two.

TLDR

In my testing, in programs based on xkbcommon, the three-minus emdash code always overrides the two-minus emdash code; if anywhere my custom XCompose includes a file containing the three-minus emdash, then there appears to be no way to get an xkbcommon program to accept the two-minus emdash. This differs from the behavior of non-xkbcommon programs.

"REPRO"

I am on Ubuntu 23.10. My way of testing xkbcommon is I run the "Editor" example program from the Iced repo. With Rust 1.73.0 I check out that repo and run (cd examples/editor && cargo run). The way I know this is using libxkbcommon is if there are errors in the custom XCompose it is libxkbcommon that prints an error. I don't know of a better/less Rusty way of testing libxkbcommon.

When I run this editor program, it does not recognize my <minus> <minus> emdash code. I also cannot get it to recognize any other code that is a prefix of another, for example I can't make a <Multi_key> <parenleft> <parenright> due to the existence in usr locale Compose of <Multi_key> <parenleft> <parenright> <parenright>: "🄯" U1F12F # COPYLEFT SYMBOL. It doesn't matter where in the file I place it, before or after the include "%L". Leaving out include "%L" entirely, of course, means my <minus> <minus> emdash code works.

This behavior must be a conscious choice, because it is documented. See "Conflicting Sequences" here.

This behavior differs from that of other Compose implementations I have tested. Testing with WinCompose for Windows, or on Ubuntu: any ibus (GNOME) application; Firefox, which I think is using ibus; or Google Chrome (which has its own internal Compose implementation) in X or XWayland— in all of these, my custom <minus> <minus> code is able to take priority. I don't know exactly what rule is being followed, but I notice all those other programs load sequences from the system Compose file even if no include "%L" is included, implying those programs are bending over backward to honor user intent even if intent is unclear or the file is "incorrect".

I am not aware of any "controlling" documentation indicating whether it is xkbcommon or the other apps which are correct— IE I'm not aware if any body sets a standard for XCompose. The "XCompose" man page on my system says nothing about conflict resolution and doesn't indicate any way to forcibly "forget" a sequence that has already been registered.

EXPECTED BEHAVIOR

I would expect that XCompose would offer some practical way for me to register my <minus> <minus> sequence. Currently, the only way to do this is to not include system Compose (obviously undesirable), or to make a copy of system XCompose, delete the emdash code, and include that (possible, but undesirable because it means I will not pick up new sequences on future OS updates).

(I think my personal expectation would have been that later sequences override earlier ones, but I don't know if I can defend this.)

Although the documented xkbcommon behavior is well-reasoned, it excludes a reasonable user case because it means the system XCompose (which the user cannot easily control) can prevent the user from being able to program certain sequences.