Feature request: system wide .XCompose

[Pixelfck]

Description

A system wide (as opposed to per user) .XCompose file. For example /etc/.XCompose.

This would allow for the typical triplet of lookup paths:

• vendor-provided ones in /usr/share/X11/xkb](/usr/share/X11/locale/\[locale\]/Compose),
• system-specific ones in /etc/.XCompose, and
• user-specific ones in ~/.XCompose¹.

Rationale for the inclusion in this project

Right now, there is the vendor supplied (and locale dependent) Compose file, and a per-user .XCompose file to overwrite or extend the vendor one, but there is no method to deploy an .XCompose file for the whole system, which would make the same compose sequences available to all users on the same system.

---

¹ see also: https://xkbcommon.org/doc/current/group__compose.html#ga69376b0303c6ac0c17468e0c215a872e for a more detailed description.

[wismill]

Thank you for your interest! What is your use case? Wouldn’t be better to have a mechanism to extend /usr/share/X11/locale/locale.dir?

[Pixelfck]

Our use case is that we want to roll out a 'custom' .XCompose throughout all machines in our organization. The 'custom' compositions are nothing more than the standard in our county, but not supported by default, because we use the US keyboard layout, and that has too many confusing compositions defined.

I guess it is the same reason why the typical triplet of lookup paths came into existence in the first place: it works well, give a nice granularity, and came to be the common method of doing things for that reason. In our specific case, we would like to just deploy the .XCompose at installation time, for each machine.

Our users don't care about all this, they just want a computer that works. The keyboard is one of the most important interfaces between the user's intention, and the outcome on screen. If the keyboard does not do what they expect, the keyboard, and by extension the computer is 'wrong' or 'does not work'.

[wismill]

Our use case is that we want to roll out a 'custom' .XCompose throughout all machines in our organization. The 'custom' compositions are nothing more than the standard in our county, but not supported by default,

What locale do you use? I understand that it is not currently supported by the system Compose files. What country/language is to be supported?

because we use the US keyboard layout, and that has too many confusing compositions defined.

The basic US layout does not have dead keys. Are you sure it is not a variant? How do you use the Compose file?

Our users don't care about all this, they just want a computer that works. The keyboard is one of the most important interfaces between the user's intention, and the outcome on screen. If the keyboard does not do what they expect, the keyboard, and by extension the computer is 'wrong' or 'does not work'.

Could you provide some examples of “the keyboard does not do what they expect”?

[Pixelfck]

What locale do you use? I understand that it is not currently supported by the system Compose files. What country/language is to be supported?

We are based in the Netherlands. The US and US International keyboard layouts are the standard layout used in the Netherlands (yes, there is a Dutch keyboard layout out there, I don't think I've seen one in the last 30 years).

The basic US layout does not have dead keys. Are you sure it is not a variant? How do you use the Compose file?

We use the en_US.UTF-8 keyboard locale, along with Microsoft Windows US International layout defined as a 'custom' xkb layout. This 'custom' layout is very close to the US, intl., with dead keys layout, but has some minor differences.

The problem we are running into (and my college Ana has also opened an issue about this) is that the en_US.UTF-8 locale has 5000+ compositions defined. Many of those interfere with what our users expect, up to the point that we have now deployed a temporary "Windows US International layout, without dead keys" custom layout, as an intermediate solution.

We have also made a custom .XCompose that defines the compositions needed/expected by the "Windows US International layout" layout. We would like to deploy this organization wide, while still allowing some of the more tech literate colleagues (who have been allowed to use Linux for some time now) to use their own personal .XCompose composition combinations, if they feel like it.

Could you provide some examples of “the keyboard does not do what they expect”?

• I've turns into Iǘe
• "" turns into ¨
• "H turns into Ḧ

etc. etc.

[mahkoh]

You can accomplish this with $XCOMPOSEFILE and /etc/environment.

[Pixelfck]

May I ask what the reason is for not wanting to support the, very common, triplet of lookup paths?

[mahkoh]

I only told you how to solve your problem. I am not implying anything else.

[Pixelfck]

I only told you how to solve your problem. I am not implying anything else.

I appreciate your pointer to a solution!

I also realize that my question came out rather blunt. I asked the question because it would help me explain the current situation, and the need for a workaround to my team. I did not want to imply anything else.

[wismill]

What locale do you use? I understand that it is not currently supported by the system Compose files. What country/language is to be supported?

We are based in the Netherlands. The US and US International keyboard layouts are the standard layout used in the Netherlands (yes, there is a Dutch keyboard layout out there, I don't think I've seen one in the last 30 years).

The basic US layout does not have dead keys. Are you sure it is not a variant? How do you use the Compose file?

We use the en_US.UTF-8 keyboard locale, along with Microsoft Windows US International layout defined as a 'custom' xkb layout. This 'custom' layout is very close to the US, intl., with dead keys layout, but has some minor differences.

Are these differences specific to your organization or would it be worth to have it included in the system layouts?

The problem we are running into (and my college Ana has also opened an issue about this) is that the en_US.UTF-8 locale has 5000+ compositions defined. Many of those interfere with what our users expect, up to the point that we have now deployed a temporary "Windows US International layout, without dead keys" custom layout, as an intermediate solution.

We have also made a custom .XCompose that defines the compositions needed/expected by the "Windows US International layout" layout. We would like to deploy this organization wide, while still allowing some of the more tech literate colleagues (who have been allowed to use Linux for some time now) to use their own personal .XCompose composition combinations, if they feel like it.

Could you provide some examples of “the keyboard does not do what they expect”?

* `I've` turns into `Iǘe`

* `""` turns into `¨`

* `"H` turns into `Ḧ`

etc. etc.

On Windows, typing dead key ' (hack for acute) + v gives you 'v only because the IM actually fails to find an entry and default to display both charactera: dead key and letter v. On Linux the default is to usually cancel the typing if no entry is found¹. But here there are entries defined and you get the “unexpected” result.

But the thing is that users are not typing ' nor " but ◌́ and ◌̈, which are respectively the acute and diaeresis diacritics marks, not quotes.

How much of the dead keys do you and your users really use from the “US, intl., with dead keys”? It may simply not be the relevant layout.

Do you know this alternative?

Footnotes

1. ultimately, it’s up to the input method. ↩

[Pixelfck]

Are these differences specific to your organization or would it be worth to have it included in the system layouts?

These differences are not specific to our organization. They are a 1:1 re-implementation of Microsoft keyboard layout KLID: 00020409 / kbdusx.

I personally think that having this keyboard layout included in the system layouts would be a good thing, as it would help transition (Dutch, but apparently it is also used by Spanish speaking US users) users from Windows to Linux.

On Windows, typing dead key ' (hack for acute) + v gives you 'v only because the IM actually fails to find an entry and default to display both charactera: dead key and letter v. On Linux the default is to usually cancel the typing if no entry is found1. (...)

Yes, we noticed the difference in implementation. On Linux, non-defined compositions are 'swallowed' on Windows, they print both glyphs separately. One is not necessarily better than the other, it is just a different implementation choice.

To remedy this behavior, we have specified all possible combination in our .XCompose file, so that no combination is ever undefined. (see: gistfile1.txt)

How much of the dead keys do you and your users really use from the “US, intl., with dead keys”? It may simply not be the relevant layout.

From the feedback we received: more frequently than I expected. We are research institute, with people working on a wide variety of subjects. Working with different languages is a common occurrence for the research staff, support staff mostly works in English, Dutch, German, and French (and less frequently Spanish).

Do you know this alternative?

Yes, we looked into all options. The US (Intl., with AltGr dead keys) keyboard layout is less compatible with the Windows version than US, intl., with dead keys.

[mahkoh]

I personally think that having this keyboard layout included in the system layouts would be a good thing, as it would help transition

XKB and XCompose are unrelated except insofar that XCompose takes keysyms generated by XKB as input, just like most other applications working with keyboard input. Nor does XCompose have a concept of layouts that you can easily switch between. The used compose file is a function of the locale.

[Pixelfck]

(...) The used compose file is a function of the locale.

This is the key issue. There are 12 keyboard layouts for English (US), and there is only 1 set of compose combinations (with 5000+ combinations defined). The only method to change those compose combinations, is on a per user overwrite/append basis.

I would say that in an ideal situation, I would be able to specify which compose combinations to use, for each keyboard layout, irrespective of locale, because the if I choose a US, intl., with dead keys keyboard, I would expect it to behave the same whether I'm in the US, the UK, Finland, Japan or Vietnam. Right now, this is (I believe) not the case.

Given the enormous amount of work that would be required to change this, across all the different bit of software that make up the various stacks that rely on the current design choices, I don't expect this to change anytime soon (it would still be a good idea, but that's discussion is not part of this issue).

So, given that we are stuck with a compose file as a function of the locale, we need an option to deploy our own set of compose combinations. Hence my feature request for a system wide .XCompose (for example (/etc/.XCompose), so the standard vendor/system/user stack of configurations would be supported.

_{(I would argue that it would be even better if we could also somehow make custom (variant?) compose combinations available through packages, system distributions or some other means, but again, that is not a discussion for this issue.)}

[wismill]

if I choose a US, intl., with dead keys keyboard, I would expect it to behave the same whether I'm in the US, the UK, Finland, Japan or Vietnam. Right now, this is (I believe) not the case.

Most locales are based on the en_US Compose file, so the locale will probably not impact your use case.

(...) The used compose file is a function of the locale.

This is the key issue. There are 12 keyboard layouts for English (US), and there is only 1 set of compose combinations (with 5000+ combinations defined).

The issue is that the Microsoft layout is peculiar: it features a failed dead key sequence into a way to type characters. Linux is not Windows and as such there is not always 1:1 feature mapping. You focused on ◌́ + v, but for example Windows does not support ◌́ + s = ś while Linux does, which is useful to type e.g. Polish, but disallow you to type “it’s” using the dead key. So the Linux layout is more international than the Windows one.

Also you mentioned some staff uses French, so I am curious if they are not bothered to have to type e.g. “c’est” without using the dead key, which would give “cést” otherwise.

In fact nobody should ever use ' or " apart in programming languages, CLI, configuration files and some niche use cases. The correct typographical characters are ’ and “”, which are available on the AltGr layer (see the layout).

Now, if we focus on compatibility with Windows, we should probably introduce dedicated dead keys ' and " for this layout and probably create a “Windows-compatible” variant.

---

Back on topic: since @mahkoh already wrote above a workaround for your issue, I would rather focus on the following:

(I would argue that it would be even better if we could also somehow make custom (variant?) compose combinations available through packages, system distributions or some other means, but again, that is not a discussion for this issue.)

I create #896 for further discussion.

[Pixelfck]

The issue is that the Microsoft layout is peculiar: it features a failed dead key sequence into a way to type characters. Linux is not Windows and as such there is not always 1:1 feature mapping. You focused on ◌́ + v, but for example Windows does not support ◌́ + s = ś while Linux does, which is useful to type e.g. Polish, but disallow you to type “it’s” using the dead key. So the Linux layout is more international than the Windows one.

This is why, in my opinion, it would be most helpful if multiple sets of composition combinations would somehow be possible. Preferably they could be defined or selected on a per keyboard layout basis.

Also you mentioned some staff uses French, so I am curious if they are not bothered to have to type e.g. “c’est” without using the dead key, which would give “cést” otherwise.

People are comfortable with what they are used to. They are not bothered by this, because this is what they have used for years, and what everybody around them uses. It may not be the optimal keyboard configuration for their use case, but that is irrelevant, because this is what they are used to, and it works for them.

In fact nobody should ever use ' or " apart in programming languages, CLI, configuration files and some niche use cases. The correct typographical characters are ’ and “”, which are available on the AltGr layer (see the layout).

It is not up to me to say what people should or should not use :-)

Now, if we focus on compatibility with Windows, we should probably introduce dedicated dead keys ' and " for this layout and probably create a “Windows-compatible” variant.

Reading back, I think I should have made it clearer that, for me, this is the main point: we have a whole lot of users who are about to switch from Windows (which they have been using all their lives), to Linux. My goal is to make sure this transition will cause a minimal a disruption to their daily workflow as possible. The most reported issue¹ from our pilot groups boils down to this keyboard issue.

There also seems to be a wider wave of not only individuals, but also organizations transitioning to Linux. Having a Windows-compatible keyboard variant would help making the transition easier for new users. So I agree that a Windows-compatible variant would be a good idea.

I create #896 for further discussion.

Great!

---

^{¹ there are of course more issues, but most of those are more specific, and related to what someone does, while everybody used the keyboard.}