Spurious characters on compose sequence input.

[munizao]

trafficstars

Using tomboy-ng version 0.31a on Linux Mint 20 Ulyana.

When I type in characters using a compose sequence, extra spurious characters are inserted. For example, when I type: [compose] n ~ I get: ñ (That's a 000E character before the 'ñ', if that doesn't come through.) The extra character comes when I type the n, then the 'ñ' is input as normal when I type the '~'. When I type: [compose] x x I get: × (Those are two 0018 characters before the '×' if they don't come through. Or maybe 001B, what I see is a box with that in it, but there aren't enough pixels to tell an 8 from a B.) In this case, I get the first spurious character when I type the first x, and the second spurious character and the correct character together when I type the second x.

[davidbannon]

Compose Sequence ? I was under the impression that the underlying editor control I use, kMemo cannot do key compose at all ?? If its trying to and fails, maybe its a fixable bug ? Sorry, not a process I am familiar with, here in Australia, we are a terrible mono-culture, quite rare to use those characters except for scientific writing.

Will look into it ...

Davo

[munizao]

Sorry, I didn't consider the possibility the problem would be upstream. I just installed Lazarus and KControls, and created a new project with a KMemo, and I can verify that I get exactly the same behavior there. Well, that's too bad. I was looking for a suitable replacement for Tomboy, and I don't particularly like the direction GNote has taken, but this is a dealbreaker for me. I use compose sequences quite a lot.

I just submitted an issue on KControls.

[davidbannon]

yes, I understand it is important. I had been thinking of providing a way to 'insert' such character, once in the text they work fine, I have been copying and pasting them into notes to test its UTF8 robustness ! But interested in what you are saying about a "compose sequence", is that the "hold down shift-ctrl and type 'u' then hex code" trick ? I get no response, if you get a 'bad' response, that surprises me and maybe is a glimmer of hope ...

Worth looking into anyway. My plan was some keyboard shortcut, perhaps Ctrl-Shift-U ? And then a popup that lets you either type in that same sequence or click a "frequently used list".

Surprisingly, you are the first to ask for that capability, so I have not prioritized it !

Davo

[munizao]

No. In Linux generally you can set up one of your keys on your keyboard to be a [compose] key in the keyboard settings. I use my right Windows key, but there are other options. Once that's set up, there are pretty easy mnemonics for accented characters and a bunch of other unicode characters. You press the compose key, then press 'n', then press '~' (you can do the last two in either order) and an 'ñ' comes out. I'm rather partial to the feature, as I have an 'ñ' in my name, but am a native English speaker and don't want to use a Spanish keyboard layout. Also, occasionally I use some of the math characters that you can get this way, and French, Spanish, or German words as appropriate, and I want to get them right.

I do miss the "hold down shift-ctrl and type 'u' then hex code" thing working like it used to, but I gather that that's down to the powers that be stopping using gtk's native input methods, and using input methods that work on a different level, which does have the advantage that you can specify an input method to use and have it work in multiple toolkits. I believe I'm using the default XIM input method, if that matters.

[davidbannon]

OK, you are right in several respects here Muñizao (note the spelling!). Firstly, like you, I much prefer the old, shift-Ctrl uXX model, I guess thats just because I know the codes. Secondly, yep, I have configured my system to use a Compose key, Shift-RWin and sure enough, it almost works in tomboy-ng. In fact some char do work but most have a low byte char inserted in front of them. And it sure should not be there. Its going to take some serious debugging to find where that extra byte is coming from, so I cannot hold up this release to find it. Sorry. After I this release, I will visit it again, maybe its fixable, the KMemo author accepts bug fixes but is not too interested in just bug reports. Whats puzzelling is that people using non-English keyboards are not experiencing this problem, I would have expected the keyboard input is delivered in the same way ??
If I cannot fix this, I will implement a somewhat more obtrusive model with a popup dialog. But I don't like going out on my own ... Davo

[munizao]

Here's the bug I filed on KControls: https://github.com/kryslt/KControls/issues/31 As you can see, the maintainer found that it's a bug in the Lazarus Component Library, not in KControls. So I filed this bug on on Lazarus LCL: https://bugs.freepascal.org/view.php?id=38454 It really looks like it's something that needs to get fixed at that level. I wouldn't bother to make a workaround. I wouldn't expect non-English keyboards to have any problems. That's all handled by the XKB layer, before things get to the input method layer. Although the input method layer is doing the right thing here, it's just that LCL appears to be intercepting keystrokes that happen during a compose sequence and deciding to do something extra with them.

[davidbannon]

Hmm, to my surprise, I do think that is the case. I should have tried a bit earlier but in the Qt5 version of tomboy-ng, the problem does not exist ! So, that does point pretty cleanly to LCL's gtk2 implementation.

I will follow that up, but, as I said, not for the 0.32 release !

(will add it to know issues....)

I will reopen this ticket to remind me to track the LCL problem.

Thanks Davo

[davidbannon]

Hmm, seems I did not re-open it ! Try again....

[davidbannon]

munizao, while the lazarus bug report did provoke some interest and I have added a clear demo of how to reproduce the problem even without KMemo, I don't see it getting fixed in the near future. I spent some time trying to follow how it works without making any progress.

I suggest you consider using the Qt5 version of tomboy-ng, it works nicely ...

Davo

[davidbannon]

Hmm, I see not progress on the Lazarus front towards fixing this bug. Given that tomboy-ng now has a 'special character' tool, the compose key works fine with Qt5 and it does not work on many of the other mainstream apps, I suggest we consider this bug a "no issue". I personally use the Qt5 version myself and the next release will have all native dialogs (unlike now where its a bit hit and miss). David

[davidbannon]

OK, noting new version at https://github.com/tomboy-notes/tomboy-ng/wiki/Download_Release includes a far more mature Qt5 version, and gtk2 support in most distros is at least "under threat" I think we won's see an upstream fix. Please just use the Qt5 version !

So closing this issue, thanks for your report.

Davo