XCompose and X.org config files -- customizing, defining priority

ErikAnderson3 commented 5 years ago

In past versions of WinCompose, the text config files for the XCompose and X.org multikey sequences were located in C:\Program Files\WinCompose\res. That no longer seems to be the case -- some time since January 2016 (when I last customised my XCompose file and backed up the default one), it seems that these config files might now be included in the WinCompose build, and are no longer available on the filesystem.

XCompose contains numerous poorly-planned legacy combinations that conflict with common sense, consistency, and the X.org combinations. I reported on this to the Gnome project ten years ago (https://bugzilla.gnome.org/show_bug.cgi?id=557420#c30), and they explained that the error was caused by upstream XCompose.

The specific combos affecting me right now are lower-case <a> and <o> with multikey <minus>. These should produce ā (a+macron) and ō (o+macron), similar to <minus> plus the other three vowels, but XCompose instead defines these (today) as ª (feminine ordinal) and º (masculine ordinal).

In WinCompose, I can only achieve ā and ō if I go into Options and disable Use sequences from the XCompose project. When I do this, the correct sequences from the X.org configuration take precedence. However, if I do this, I also lose the ability to type things like ↑, which are defined in XCompose but have no definition in X.org.

FWIW, the change in behavior only appeared when I upgraded from WinCompose version 0.8.2 to 0.9.0. Prior to that, I had a customized XCompose config file that removed the inconsistent multikey definitions for ª and º, and things worked just fine. The WinCompose 0.9.0 installer seems to have removed my customized XCompose config file and the X.org config file, leaving behind the Xcompose.txt.BAK file I'd created in January 2016.

Suggestions:

Do not embed the X.org and Xcompose configuration files in the app, but instead leave them available on the filesystem as in the past.
I feel somewhat strongly that this is the best approach, as it leaves everything transparently accessible to the user. (Perhaps betraying my Linux background. :) )
Alternatively, make it possible to specify whether X.org or XCompose takes precedence.
If the two have conflicting settings, it would be ideal to be able to configure which one has priority.
In the WinCompose Options UI, X.org is above XCompose, so intuitively, I'd expect the X.org settings to take precedence. However, it turns out that XCompose takes precedence instead.

As it is, I have to go into Options and toggle things on and off again in order to be able to type all the characters I need. While functional, this is terribly inefficient.

goodger commented 5 years ago

+1 to this issue. It would be great to define rules for priority/precedence. IMO user-defined sequences should take priority over any others.

In my specific use case, I have sequences set up for the Japanese hiragana & katakana characters, e.g.: <Multi_key> <k> <k> <a> : "カ" U30ab # Katakana letter KA

Unfortunately, this (and many others, like katakana KI, KU, KE, KO, etc.) conflicts with the built-in sequence: <Multi_key> <k> <k> : "ĸ" # : LATIN SMALL LETTER KRA

I have no use for "kra" and would like to disable it in favor of my user-defined sequences.

ErikAnderson3 commented 3 years ago

Migrated to a new laptop. Due to corporate policy, I cannot use the installed version, so I have the portable version of WinCompose 0.9.4. Looks like this problem is still extant --

Xorg and XCompose sequence lists are apparently hard-coded now and not external text resources that can be edited by users.
XCompose sequences appear to take priority -- over both Xorg sequences and the user-defined sequences. This is sub-optimal, as the XCompose sequences are buggy and inconsistent (as described above and in the much-older linked Gnome bug thread).
There is no apparent way for users to specify a different priority, and, counter-intuitively, the user-defined sequences are ignored if they conflict with an existing XCompose sequence (unsure about collisions with Xorg sequences).

(I'm not sure if the way the user-defined sequences get ignored is a new bug, or if this is part of the same overall issue -- please advise if I should create a separate ticket for that.)

ErikAnderson3 commented 3 years ago

Downloaded WinCompose-NoInstall-0.9.6. Thank you for the update!

Checking the new version, it looks like the \rules\DefaultUserSequences.txt file isn't ever loaded.

I opened the Debug window and tried disabling the XCompose rules and re-enabling. I see a lot of Debug output about loading various settings files, but \rules\DefaultUserSequences.txt isn't one of them. Is this intentional?

I confirmed that changes to the \rules\DefaultUserSequences.txt file are not reflected in app behavior. Meanwhile, changes to \rules\WinCompose.txt are reflected in app behavior. This file is shown as "Loading" in the Debug window.

→ Consequently, I think my previous post on Nov 2 was incorrect. It's not that the user-defined sequences are ignored if there's a conflict -- they aren't loaded at all.

Here's a screenshot from 0.9.4, showing what gets loaded after the XCompose config. Behavior and debug output in this case is identical for 0.9.6. \rules\DefaultUserSequences.txt is missing from the list.

@samhocevar , could you check?

samhocevar commented 3 years ago

That is the intended behaviour. DefaultUserSequences.txt is just a template file and is copied to %USERPROFILE%/.XCompose.txt if it doesn’t exist when you click in the sequences window to edit user sequences. Modifying files shipped with WinCompose is not supported and these files will be reverted or may be ignored in later releases.

I know this is caused by missing features allowing to change priorities between sequences, and I’m sorry that it takes me a lot of time to implement them properly.

ErikAnderson3 commented 2 years ago

It's been a while. Ran into something that appears to be related.

Version

Using version 0.9.6.
⇒ I will update to the latest version and re-test when I have time.

Problem

Emoji definitions in the user's custom .XCompose file are ignored.

Steps to reproduce

Update your C:\Users\[USERNAME]\.XCompose file, as accessed from WinCompose's Sequences dialog and clicking the Edit button. Add the following definition line:

<Multi_key> <Multi_key> <s> <t> <a> <r> <t> : "🛫" U1F6EB # Obsidian Tasks "start date" -- if starting before due date

Save the text file. Open the WinCompose Debug window. Click the Reload button in the Sequences dialog. Confirm in the Debug window that this .XCompose file loads. Confirm also that the Debug window output shows where conflicts where encountered, but does not show anything about the newly-entered key sequence:

In any screen with a text field, type <Multi_key> <Multi_key> <s> <t> <a> <r> <t>. Observe that this just causes the word start to appear, instead of the expected 🛫 emoji.

Workaround

I discovered that I had to add emoji sequences to the [WINCOMPOSE DIRECTORY]\rules\Emoji.txt file instead.

This is difficult to maintain, since this is not the expected location for a user's own custom files. Also, I suspect that this file is probably overwritten when updating the app.

Ideas

I suspect that WinCompose loads the user's custom .XCompose with some kind of logic at work that excludes the emoji codepoint ranges. This is unexpected behavior -- the application's own UI directs the user to edit their .XCompose file to enter user-defined key sequences. Any valid key sequence should be allowed -- or to put it another way, no valid key sequence should be ignored.

Suggestions

Any valid key sequence defined in the user's .XCompose file should be accepted. If this sequence collides with an existing previously loaded sequence, the new sequence should override (overriding appears to be the behavior in 0.9.6, so that's good).

The Debug window should output something when loading and discarding any invalid content in a resource file (not just the user's .XCompose file but also in the other resources in the \rules\ directory). It is unexpected that WinCompose would load a user's .XCompose file, and just ignore the user's rules without saying anything.

chtenb commented 1 year ago

What seems to work for me, as a workaround, is to paste all definitions in a single custom file, and based on the order conflicts are resolved the way I want.

ErikAnderson3 commented 1 year ago

What seems to work for me, as a workaround, is to paste all definitions in a single custom file, and based on the order conflicts are resolved the way I want.

@chtenb -- what's the filename and directory for your all-in-one definition file?

chtenb commented 1 year ago

On linux it's ~/.XCompose, on windows using WinCompose it's %UserProfile%\.XCompose

My current file can be found here btw: https://github.com/chtenb/dotfiles/blob/master/.XCompose I use it for writing math mainly, so the order and custom bindings included are to accomodate that.

samhocevar / wincompose