Yeah I don't think we did (or would have) experienced anything like that.
I suspect there is a combination of factors as to why it didn't work 100% correctly in our case. Not least the fact that such a tool is actually a fair bit more complicated when you're dealing with a
But, of course, we have always had a decent autocomplete system, the one we had in 2.0 is not dissimilar to the one we have in XF 1.5. It just didn't scale well to other applications. It only supported the @ symbol to trigger it and there was actually two nearly identical sets of code; one to handle a normal input and one to handle the editor.
That's why At.js appealed because it had all of this already built in and was actually really flexible out of the box.
We might well have forked it and fixed it ourselves (because it also became unmaintained shortly after we started using it
) but luckily refactoring our existing code and building all of the additional flexibility in and deduplicating the bits that were duplicated went well and ultimately makes the most sense so... 
I suspect there is a combination of factors as to why it didn't work 100% correctly in our case. Not least the fact that such a tool is actually a fair bit more complicated when you're dealing with a
contenteditable
rather than a traditional input.But, of course, we have always had a decent autocomplete system, the one we had in 2.0 is not dissimilar to the one we have in XF 1.5. It just didn't scale well to other applications. It only supported the @ symbol to trigger it and there was actually two nearly identical sets of code; one to handle a normal input and one to handle the editor.
That's why At.js appealed because it had all of this already built in and was actually really flexible out of the box.
We might well have forked it and fixed it ourselves (because it also became unmaintained shortly after we started using it

