U+2384 "COMPOSITION SYMBOL" unnecessarily affects text layout

[IBBoard]

Which distribution and version?:
openSUSE Tumbleweed

Which desktop environment and version?:
Gnome 3.30

Which session type?:
X11

Which application and version?:
All (gEdit, Geany, Tilda, Firefox, Thunderbird, Corebird)

IBus version?:
1.5.19

Issue description:
Since 1.5.19, when using the compose key then it shows the keys you've typed, prefixed with "⎄" (U+2384 "COMPOSITION SYMBOL"). Showing what you've typed is helpful, but the composition character a) unnecessarily moves things to the right and b) sometimes affects the entire text position.

This looks like it might be because of #1935, which (as I understand it) introduced the pre-edit text for compose combinations. The composition symbol seems unnecessary when the pre-edit content is already underlined.

I've tried to change this myself, but I've not been able to work out how to patch my own builds (I've put in logging and not even seen any output, so I'm clearly missing something somewhere!)

Steps to reproduce:

1. Press multi-key then "a"
2. "⎄a" appears, text may move
3. Press "'" (apostrophe)
4. "⎄a" disappears, "a" moves left and becomes "á"

Text:

Start composing:

(Difference)

Finish composing:

Can you reproduce your problem when you restart ibus-daemon? (yes / no):
Yes

Do you see any errors when you run ibus-daemon with the verbose option?:
No (I don't actually get any output)

Can you reproduce your problem with a new user account instead of the current your account? (yes / no):
TBC

[fujiwarat]

The key "⎄" expresses Multi_key. The feature let invisible characters visible.
If you press Backspace for "⎄a", "a" is deleted. and press Backspace again, Multi_key is also deleted.
So is it necessary?

[fujiwarat]

CC'ing @ariasuni

[IBBoard]

The feature is generally useful overall, but I think some aspects of the implementation are a bit confusing.

• Most people won't know what the Unicode "Composition Symbol" is, and because you can't select it then it's hard to find out what it is (I only got it when I "broke" pre-edit mode by taking a screenshot of Firefox while it was showing and it left both characters as editable text)
• In some situations (mainly Gnome Terminal) the trailing part of the symbol doesn't render correctly, making it even harder to recognise
• The symbol doesn't seem to appear consistently:
  • If I press Multi-key then nothing appears - there's no change of state and no indication that I'm in a special mode, so the Composition Symbol doesn't visibly do anything here (unlike Ctrl+e/Ctrl+u)
  • If I press Multi-key then a letter, number or some symbols then the Composition Symbol and the character appear at the same time
  • If I press Multi-key then some symbols (possibly ones that start emoji?) then the symbol doesn't appear and neither does the Composition Symbol
  • If I press Multi-key twice (for some of my XCompose shortcuts) then nothing appears
  • If I press Multi-key twice and then a character that matches but is also a prefix match for a longer string then I get the exact match as the composed form in pre-edit text but no Composition Symbol
  • If I do the above and then type more characters to get the other characters then I don't see the extra characters until I get the right string and there is no Composition Symbol
  • If I press Multi-key twice and then type the next character and there is only one match then the pre-composed character is typed and I never get pre-edit text (e.g. "Multi Multi P" types "Π")
• Deleting characters isn't consistent - "Multi Multi a" doesn't delete the pre-edit text until I hit backspace four times!

As the XCompose/Multi-key approach is for fixed combinations defined in a config then it feels like a better match to an Anthy-style input with no pre-edit prefix but just an underlined "pre-edit" text showing all typed symbols.

[Edit] I've just found that "Multi o" doesn't show the Composition Symbol, so it isn't reliably "all letters and numbers". I believe this is because I've got a "o_0" emoji shortcut and emoji results are the only consistent thing that I've seen for shortcuts using a single Multi_key to not use pre-edit.

[ariasuni]

As the XCompose/Multi-key approach is for fixed combinations defined in a config then it feels like a better match to an Anthy-style input with no pre-edit prefix but just an underlined "pre-edit" text showing all typed symbols.

This is funny because I started thinking about it and went to the same conclusion, then saw your comment.

Yeah, it’s probably easier to understand this way/less weird, and also simple to enough to think of it as a good solution.

[fujiwarat]

OK, there is a bug not to update the preedit with custom compose file.
I fixed it with fujiwarat@f13a85d

[IBBoard]

Now I'm back to the old behaviour (no pre-edit text) and a warning from ibus-daemon of:

(process:14131): IBUS-WARNING **: 20:02:07.320: Not found alternative character of compose key 0xFF20

I use the right Windows key as my Compose key, if that makes a difference.

[fujiwarat]

(process:14131): IBUS-WARNING **: 20:02:07.320: Not found alternative character of compose key 0xFF20

I cannot reproduce your problem with the latest ibus.

[IBBoard]

Sorry, I took that patch and applied it to 1.5.19. I'm trying to rebuild and test compose-tentative now.

[Edit] Sorry, I've been fighting the build process a bit and ran out of time tonight. I'm going to have to try and test this on Friday evening (GMT). It looks like that warning was my fault, though.

[IBBoard]

I've had an unexpected chance to test the code. fujiwarat/ibus@f13a85d seems to give me the same behaviour as before, though - most letters show the Composition symbol and pre-edit text, punctuation/"accent" symbols (like quote for umlaut, apostrophe and backtick for grave and acute, full stop for dot, comma for cidilla) show the Composition symbol and pre-edit text, other symbols (exclamation mark, brackets, etc) don't show any pre-edit text and don't write anything until a perfect match, BUT some numbers and letters (which start my custom XCompose) don't show pre-edit text (e.g. "Multi 8 o" for 😨 or "Multi B A" for 𝔸)

I'm actually wondering whether it's not specific character types (such as emoji output) but still a problem with my custom XCompose vs the system one?

[fujiwarat]

other symbols (exclamation mark, brackets, etc) don't show any pre-edit text

Can you give example steps to reproduce it with detail?

BUT some numbers and letters (which start my custom XCompose) don't show pre-edit text (e.g. "Multi 8 o" for fearful or "Multi B A" for 𝔸)

I think those cases show pre-edit. If you type Muti_key, "⎄" is shown as pre-edit and if type "8", "⎄8" is shown as pre-edit and if type "o", 😨 is matched only and output. "Multi B A" is the same behavior.

[IBBoard]

I'm using this XCompose: https://dev.ibboard.co.uk/repos/other/linux/file/3552d0014202/XCompose

• "Multi . ." shows "⎄." then …
• "Multi B A" shows nothing until it shows 𝔸
• "Multi ' a" shows "⎄'" then á
• "Multi a '" shows "⎄a" then á
• "Multi 8 o" shows nothing until it shows 😨
• "Multi 1" shows "⎄1" (but I don't know what matches, so I can't test further)
• "Multi A A" shows nothing until it shows ∀
• "Multi c o o" shows nothing until it shows ℃
• "Multi i '" shows nothing until it shows í
• "Multi Multi a t o m" shows nothing until after the "a", at which point it shows α in pre-edit until I type the last three characters and it shows ⚛
• "Multi : )" shows nothing until it shows 🙂
• "Multi / \" shows nothing until it shows ∧

I'll keep testing and debugging at my end in case it's something that I've done/not properly restarted/etc (although I've rebooted several times, so it should be restart issues!)

[Edit] Okay, that seems to work if I do a local build and adjust LD_LIBRARY_PATH etc, but it wasn't working for the custom build that I had on the Open Build Service (there was a point that I couldn't build it locally)

I still think it would be better if it was more Anthy-like and didn't have the ⎄ symbol in normal usage, but I don't know what the solution would be to indicate "Multi Multi" shortcuts.

[IBBoard]

Okay, I've managed to test it properly now and it seems to work. I'm consistently seeing the composition character and what I type across all of the examples in my last comment. I think I did something stupid with my OBS build.

The only problem I've found (which might be a separate issue rather than part of this change) is that you can't use backspace to go back and insert an earlier match with fewer characters. For example:

• XCompose has "Multi Multi a" as α and "Multi Multi a t o m" as ⚛
• Type "Multi Multi", you get "⎄⎄" as pre-edit text
• Type "a", you get "α" as pre-edit text
• Type "t" to start "atom" and you get "⎄⎄at" as pre-edit text
• Press backspace and you get "⎄⎄a" as pre-edit text
• Press space or enter and the pre-edit text disappears. I now can't type α without cancelling the pre-edit and starting again or deleting the "a" (leaving "⎄⎄") and retyping it.

Happy to report it as a separate issue if it's not directly related to this change (which looks simple enough that it shouldn't have triggered it).

Thanks!

[IBBoard]

In case anyone is interested, I've posted my custom behaviour patch to remove the Composition Symbol from the start.

https://gist.github.com/IBBoard/ec1c040763f91fd4620678d6c909be0c

Behaviour is:

• No composition symbols show at the start (even for "Multi Multi")
• Composition symbols will (should!) still show in the middle
• Backspace that leaves just Multi keys left cancels the pre-edit (because they're hidden, so it gets confusing to do the existing "delete the Multi" behaviour)
• Everything else acts as normal

It's not perfect, because you can't differentiate "Multi" from "Multi Multi", but I prefer it to seeing "⎄" all the time (and having it move my text in several situations). I only use the Multi key and none of the other "dead" keys, though, so I don't know what impact it would have on anyone who uses them.

[fujiwarat]

"Multi B A" shows nothing until it shows 𝔸

I think When you type "Multi B", "⎄B" is shown. The preedit also is shown correctly in other test cases.

"Multi 1" shows "⎄1" (but I don't know what matches, so I can't test further)

When you type "Multi_key 1 2", "½" is output, which is loaded from /usr/share/X11/locale/en_US.UTF-8/Compose

I think I did something stupid with my OBS build.

OK, I hope the preedit is shown in your box.

The only problem I've found (which might be a separate issue rather than part of this change) is that you can't use backspace to go back and insert an earlier match with fewer characters. For example:

Thank you for reporting it.
I fixed it in https://github.com/fujiwarat/ibus/commits/compose-tentative

https://gist.github.com/IBBoard/ec1c040763f91fd4620678d6c909be0c

Currently I'm still not sure hiding "⎄" is so useful. Probably I need more feedback later.

[IBBoard]

All of those problems of things not showing are fixed now. It was my fault - I managed to make builds without the right patches included.

Thanks for pointing out the completion for "Multi 1" - I hadn't thought of that one!

I'll check the update and report back.

As for my "don't show ⎄", I know the behaviour isn't perfect because your current input status isn't clear, but IMO the "show ⎄" is also confusing. Ctrl+Shift+e and Ctrl+Shift+u have context for why they have an "e" or "u" prefix in pre-edit, but I don't expect 99.99% of users to know what the "⎄" symbol is! Hopefully other people can give their opinions and feedback.

[fujiwarat]

Ctrl+Shift+e and Ctrl+Shift+u have context for why they have an "e" or "u" prefix in pre-edit

While you refer ibus-anthy several times, I'd clarify the difference.
When you type Ctrl-j or Zenkaku_Hankaku, ibus-anthy switches the input modes and you can enable the preedit mode in a mode. Once you enable the preedit mode, the mode is not disabled until you type Ctrl-j or Zenkaku_Hankaku. And then the mode would be very visible for users.
On the other hand, when you enable a mode of Unicode code point, emoji or compose typing, the mode will be stopped once you hit and output the target character.
Also Typing Multi_key does not enable the compose mode only but also it's the first character of the compose sequence. Showing the Multi_key clears the current mode is the compose.

because your current input status isn't clear

So I don't think the status is not clear at the moment.

The start key is not Multi_key only but also dead_grave or dead_acute or else and the feature enables to show the invisible characters with the alternative characters so that users know which are typed.

I don't expect 99.99% of users to know what the "⎄" symbol is!

I'm also not sure which character is the best for Multi_key but regarding to #1935, the character is used for Multi_key in Mac OS and I think using it makes sense now.
I'm fine to think which character is the best later.
However even if users didn't know about "⎄", I think they could know it expresses Multi_key after they typed some kind of compose keys likes you.
I'd ask if any distributions can install any fonts which include "⎄" by the default desktop packages.

If you don't find any other issues at the moment, I will integrate the patches in the compose-tentative branch to master.

[IBBoard]

While you refer ibus-anthy several times, I'd clarify the difference.
When you type Ctrl-j or Zenkaku_Hankaku, ibus-anthy switches the input modes and you can enable the preedit mode in a mode. Once you enable the preedit mode, the mode is not disabled until you type Ctrl-j or Zenkaku_Hankaku. And then the mode would be very visible for users.
On the other hand, when you enable a mode of Unicode code point, emoji or compose typing, the mode will be stopped once you hit and output the target character.

I must admit that I'm not hugely familiar with Anthy. I was just basing it on the impression that I got from various videos of how it works. Some of the initial "not enough like Anthy" was probably due to the bug that you fixed.

Also Typing Multi_key does not enable the compose mode only but also it's the first character of the compose sequence. Showing the Multi_key clears the current mode is the compose.
…
The start key is not Multi_key only but also dead_grave or dead_acute or else and the feature enables to show the invisible characters with the alternative characters so that users know which are typed.

I did think about that side of it. As an English user with a standard UK keyboard then I'm only familiar with the Multi_key for composition. I imagined there would be some oddities that I hadn't accounted for, which is why I just posted my custom patch for others to use if they chose to rather than suggesting it as a pull request or anything.

because your current input status isn't clear

So I don't think the status is not clear at the moment.

I'd agree that the status is clear after the fix to make the behaviour correct and consistent, but the presentation of the characters due to that status is unfamiliar. I guess part of what I'm questioning is whether that's enough of a problem, or whether users of composition sequences are already considered "power users" who can accept a rarely known character.

I'd ask if any distributions can install any fonts which include "⎄" by the default desktop packages.

I think part of the original problem is that while I have that font, it's not the same font (because it's such an uncommon character) and so everything shifts. The odd thing is that I'm using Noto Sans, which should have REALLY good font coverage.

I'm going to try building and testing the latest update now. Thanks.

[IBBoard]

Just to confirm that the α/⚛ example that I posted seems to work now - I can happily "Multi Multi a" and then hit "t" and backspace over and over and it swaps between "α" and "at" in pre-edit mode.

Thanks!

[fujiwarat]

I can happily "Multi Multi a" and then hit "t" and backspace over and over and it swaps between "α" and "at" in pre-edit mode.

I updated https://github.com/fujiwarat/ibus/commits/compose-tentative
The first Backspace clears the tentative match and the next Backspace delete the last character of the preedit sequence.

[IBBoard]

I've not been able to test this yet, but isn't this going to get us back to a "How do I press backspace and get back to 'α' without deleting the 'a' and re-typing it" situation?

[Edit] I can see how this makes sense in some ways, but I'm not entirely convinced that the behaviour is always clear.

• Multi Multi a → α
• t → ⎄⎄at
• Backspace → α

Clear enough so far, but then:

• Backspace → ⎄⎄a

From here, I can't get back to "α" without either deleting and re-typing "a" or typing and deleting a character from a longer match (like "t"). But if I get the character wrong at this point and type something that isn't in a sequence before I backspace again then it cancels the entire pre-edit (which may or may not be desired behaviour anyway, but that's a separate question).

IMO, the previous behaviour is more consistent to work with.

[fujiwarat]

Seems I didn't get your request yesterday and I reverted the last commit; https://github.com/fujiwarat/ibus/commits/compose-tentative

Do you have no other issues?

[IBBoard]

No, that seems to work now. Thanks!

[fujiwarat]

The preedit fix is integrated in master.
Thank you for the report and test.

[fujiwarat]

I'd close this issue with some feedback.