triggering change events when setText

[miguelalarcos]

I would like to listen to change events of inputs of this autocomplete package.

[mizzao]

Hi @miguelalarcos,

I don't have time to maintain this project anymore, so I gave you commit access to make any changes you'd like, including merging in other PRs and deciding which features are important to include. It would be nice to follow the style used by the rest of the code and figure out a way to test some of the front-end features, if possible.

If you give me your Meteor developer username, I can give you permission to publish new versions of the package as well.

[miguelalarcos]

Hi @mizzao,

I'm not very good at coding in Coffee-script, so I'm not sure about committing. Anyway, if I decide to change some code of your package (I have to say that it's the only one that follows Meteor reactive paradigm) I will try to do my best.

My Meteor developer username is miguelalarcos. The same about publishing your package.

Thanks.

[mizzao]

Hey @miguelalarcos - if you'd like to convert the whole package to vanilla Javascript (or ES6), feel free! I'm in favor of that; just test before you publish (the demo app can handle most of it). Coffeescript was my preferred flavor when I wrote it, but I think it's much better for general contributions to use Javascript.

Added you as an Atmosphere collaborator. I usually use the following simple procedure for publishing, although you can do what works for you:

• [ ] Pick an appropriate incremented version number v0.x.y (e.g. 0.4.0 becomes 0.4.1 or 0.5.0 depending on how much changed)
• [ ] Update the History.md file to reflect all changes that will be in the new version. If you've been keeping it up to date (and it appears you have), this just involves inserting the above version number below vNEXT.
• [ ] Update this version number in package.js.
• [ ] git commit (but don't push yet).
• [ ] Try meteor publish
• [ ] If everything worked, git tag v0.x.y and push the tag (git push origin v0.x.y; this allows others to find the code for this version) and merge into master and push that too. (If you aren't rebasing the feature branch you may want to merge first before publishing)
• [ ] If publishing didn't work, you can fix things, amend the commit as necessary, then tag and push after verifying that it went through.

Thanks so much for your help!