You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to be able to specify a deletion style that performs in the same way as TokenCompleteTextView.TokenDeletionStyle.Clear but also includes the most recently completed token which would normally follow partial completion rules.
Do you mean that you want all but the most recently completed token to use .Clear and have the most recently completed token get replace by the completion text for that token instead of being cleared? If you have not started typing anything new and hit the delete key immediately after completing a token and .Clear is set, this should happen on most platforms. I haven't figured out exactly which platforms work this way.
Ah, I see. So the underlying inconsistent behavior is something provided by the system library. I'm not sure where the behavior comes from, though I'd be happy to add a fix if it's not too much of a hack. I'd prefer not to add this to the library if it's likely to make it less stable.
Yes I agree that the trade off would not be worth it if it were to affect the stability, allowing the user to modify the last created token by not clearing the whole thing (in the case of a spelling error) makes sense, but I've found the behaviour to be occasionally inconsistent and I think it makes sense to have a clear rule that affects everything the same way and define a combination rule differently.
Could you tie into TokenSpanWatcher.onSpanChanged() or onSpanRemoved() to clean up the autocomplete text? I haven't tested it but something along the lines of this may work.
public void onSpanChanged(Spannable text, Object what, int ostart, int oend, int nstart, int nend) {
if (oend > nend && text instanceof SpannableStringBuilder) {
SpannableStringBuilder builder = ((SpannableStringBuilder)text);
Object[] spans = content.getSpans(nstart, nend);
for (Object span: spans) {
builder.removeSpan(span);
}
}
}
After some time fussing with this behavior, it seems pretty clear that there's not a good way to make any of the token deletion behaviors work reliably, and the system behavior is highly dependent on keyboard implementation and OS version, so I'm unfortunately removing any behavior around specifying how deletion behavior works and marking these kinds of issues as won't fix.
Activity
mgod commentedon May 26, 2016
Do you mean that you want all but the most recently completed token to use .Clear and have the most recently completed token get replace by the completion text for that token instead of being cleared? If you have not started typing anything new and hit the delete key immediately after completing a token and .Clear is set, this should happen on most platforms. I haven't figured out exactly which platforms work this way.
ashdavies commentedon May 26, 2016
No I mean a blanket clear rule, all tokens react the same way including the most recently completed token
mgod commentedon May 27, 2016
Ah, I see. So the underlying inconsistent behavior is something provided by the system library. I'm not sure where the behavior comes from, though I'd be happy to add a fix if it's not too much of a hack. I'd prefer not to add this to the library if it's likely to make it less stable.
ashdavies commentedon May 30, 2016
Yes I agree that the trade off would not be worth it if it were to affect the stability, allowing the user to modify the last created token by not clearing the whole thing (in the case of a spelling error) makes sense, but I've found the behaviour to be occasionally inconsistent and I think it makes sense to have a clear rule that affects everything the same way and define a combination rule differently.
JM-Agrimap commentedon Jun 16, 2016
Could you tie into TokenSpanWatcher.onSpanChanged() or onSpanRemoved() to clean up the autocomplete text? I haven't tested it but something along the lines of this may work.
mgod commentedon Jan 28, 2018
After some time fussing with this behavior, it seems pretty clear that there's not a good way to make any of the token deletion behaviors work reliably, and the system behavior is highly dependent on keyboard implementation and OS version, so I'm unfortunately removing any behavior around specifying how deletion behavior works and marking these kinds of issues as won't fix.