[Xposed Framework Modules] Roughy:
2.2.2 [ 26.05.2019 ] - Compatibility & Punctuation ( Stable: 7.3.0.21 Beta: 7.3.1.17 )

Changes in 2.2.2

Fixed

- Compatibility targeting 7.3.1.17 ( Fixing everything prediction related )

Changed

- Option to disable auto-removal of space before punctuation.

- Option to disable auto-space when inserting predicitons

The Xposed Installer app does not appear to be refreshing properly and may not list the latest version.

Please download it directly from the Xposed Repository below using a browser.

Download:

Exi for Swiftkey on Xposed module repository

Notes:

You said no more features, why are you adding features!

More than once I have announced that I won't be adding any new features, but I still sometimes do when I have to push a compatibility update anyway.

In this case, the existing punctuation stuff ( disable auto-space after punctuation ) relies on copy-pasting a rather large config file directly from Swiftkey, which hadn't been updated in a while. This was primarily an excuse to do that, and I figured I might as well add any related features while I was already digging around in it.

HAVING SAID THAT

Do not remove space before punctuation [MENTION=3484543]paarkhi[/MENTION] [MENTION=923693]usernome[/MENTION]

Along with disable-autospace-after-punctuation, this is implemented by basically commenting out a line of text in a file that defines the various punctuation rules, and loading it instead of the original.

This particular behavior has troubled me in the past, so I figured it was a decent idea to be able to disable it.

Turns out removing this behavior isn't a particularly good idea though, as unless you end typing of a word by inserting punctuation instead of selecting a prediction or hitting space, you end up with... a space before your punctuation.

That is, of course, exactly what it's supposed to do but you know... it gets annoying, and I think this is a terrible idea, and I'm tempted to not keep it around.

Argue why it should remain, or how to improve it, keeping in mind that the punctuation rules cannot( or should nor ) be reloaded while you are actively typing, so exempting it from this behavior immediately after inserting a prediction, for instance, or not really an option.

Do not insert space after predictions [MENTION=5560080]cFendez[/MENTION]

I figured this was going to be simple.

It turns out you can mostly implement this just by commenting out another line of the punctuation config, but that leaves you with no space even when you insert a prediction by hitting the space bar.

So not so simple after all.

Luckily we keep track of what prediction was selected, and are also given some information to lets us know how it was selected.

In short, when a prediction is selected from the predictions bar, we keep a reference to it. We hook a method on all predictions that tells Swiftkey what kind of separating character it should use ( a space ), and return an empty string if it matches the prediction reference we stored earlier.

This is complicated a bit by there being multiple different prediction type classes, and some just wrap other instances, so you have to keep track of both the candidate and the candidate it wraps.

But in any case, it works, and probably doesn't mess up Swiftkey's learning stuff.

Compatibility

Everything prediction related broke. Why?

Ideally we don't want any of our inserted predictions to be ellipsized, so they are displayed "as very long text" instead of "as very lo...".

Unfortunately it seems Swiftkey has completely removed the bit of logic that keeps track of this, and disabling this behavior is no longer possible, at least not as super-duper easily as it was before.

Exi has a system that tries to avoid doing anything that might break stuff, and as part of this is will disable a hook if certain requirements are not met. In this case the set-should-ellipsize method had vanished, and it considered that to be a catastrophic failure.

We would've been fine without it of course, but it happened to sit in a stack of 10 or so other methods that would justify removing the hook, and I evidently couldn't be bothered to add a separate category for it.