Feedback

[cldwalker]

Hi @rundis. This is great work so far! I'm happy we're moving in a direction that reuses the showHints addon. I haven't had a chance to read most of the code or all of the readme but some initial feedback:

• What versions of the codemirror addons are we using? Is it possible if we upgrade those that the flickering goes away or if we use the latest CodeMirror (I'm still working on getting us to use the latest)? Is the flickering present on a raw demo that uses the same options as we do?
• Not having dealt with the auto-complete API much in plugins, are there some painful examples of the API you'd recommend? I see the Clojure plugin autocomplete but I don't have trouble understanding it.
• I see that we're using a fair amount of core.async. I'm uneasy about this as I don't consider it a light dependency and this plugin would be pulled into core LT. I have doubts if our BOT framework and core.async are compatible in the long run and wonder if we'll confuse ourselves and plugin authors about when to implement functionality with BOT and when to add more go-loops. If we want to use core.async, we should probably plan for what role the library will have in LT. Also, since this would be in core, we would be locking all plugins that want to use core.async to use the version that ships with LT. I still need to read the code more to understand if it's possible to not use core.async
• Is the issue with anyword-hints that map-b[TAB] autocompletes to words starting with 'b' instead of map-b? I wonder as with flickering if this would be resolved with using the latest addon version. I find anywords somewhat useful since our cljs autocompletion is not so great

I'll add more comments once I get around to reading and using the code more. Thanks for leading this effort!

[rundis]

Tx @cldwalker

1. I'm using the latest and greatest showHints addon, but maybe a CodeMirror update helps with the flickering. There's a lot of debounce/requestAnimationFrame kind of logic in showHint that I haven't wrapped my head around
2. It might be that I'm just slow, and it's a while since last I tried to debug how it works (debug async... not easy). I think it's especially the token input param got me baffled. I'm sure there were a few other things too, but I can dig deeper into memory lane to substantiate later if need be. If we decide to think new, It seems a little bit wasted, but perhaps it will bring valuable insights.
3. I'm with you on the concerns about core.async. It's quite neat, especially the timeout solution. But maybe we should follow suit with Atom and use promises. Maybe there is an simple solution alternative waiting to be discovered (, but a collection of callbacks isn't one of them). I guess my mindset is a bit at odds with the BOT when it comes to the liberal use of objects and state. I must admit I'm skewed by working with Elm and ClojureScript/React and unidirectional data flows. If we find a nice fairly easy to reason about solution using the BOT for what it's worth, I'm not going to insist on core.async or promises.
4. Yeah. It's about whether to enforce one true token definition per editor(.tag) or allow different providers to have a difference of opinion on what constitutes a token.

I'm not too worried about enforcing one version of core-async for plugins, but if it messes with peoples clojure/clojurescript projects then it's a big no go. Adding dependencies much be done with great care, that's for sure :-)

I'll admit my views are coloured by the investment already, so a new pair of eyes and new ideas can only be beneficial !