request handler not called for (

[basarat]

This is blocking me using it for function signatures : TypeStrong/atom-typescript#23

[basarat]

Basically if I am at

And press (. The following is the state of the UI:

And requestHandler was not called. I can trigger it explicitly using ctrl+shift+space (as normal).

[joefitzgerald]

Hey @basarat you should join the Gitter room: https://gitter.im/atom-community/autocomplete-plus. Your work overlaps almost completely with @park9140's work on atom-typescript-tools. He can probably give you some pointers, or maybe you two could collaborate on a single package?

[basarat]

Yes it does. @park9140's work is most excellent. I believe his project is also async. I will collab once the codebase is more stable.

[joefitzgerald]

Why waste time and effort building what amounts to the same thing? I'm unsure how the purpose of your two projects differ? @park9140 has already solved the problems that 3 of your issues raise.

[park9140]

@basarat, I took another look at this. I'm really just bypassing the issue by forcibly outputting the '(' and retriggering autocomplete. Which is not exactly the best solution, since it would be nice to not autocomplete the '(' in case the user wants to set the function to a value...

I'm going to take a peak at the way we determine the 'prefix' and trigger autocomplete, we may need a way for providers to declare what scopes it finds interesting for autocomplete. Or perhaps just open the flood gates and make providers filter for themselves where they give autocomplete responses back.

[basarat]

has already solved the problems that 3 of your issues rais

And yet I hit the same blocks. Perhaps these should be fixed in this project instead of every project that uses autocomplete-plus. @park9140's workaround for this issue is an excellent example.

[basarat]

@joefitzgerald bit sad that you temporarily labeled as wontfix. I'm just trying to be helpful by reporting these.

[joefitzgerald]

You're missing my point @basarat. Some of what you describe may indeed belong in autocomplete-plus.

What I'm trying to impress upon you is that creating a package that almost entirely duplicates the functionality of another is probably not the best use of your time.

Why not contribute to atom-typescript-tools instead of creating your package separately?

Alternatively, how do you plan to differentiate your package from @park9140's? In lieu of differentiation, I fear you'll just end up confusing typescript users regarding which autocomplete package to install for typescript. Do your packages interoperate well when both installed at the same time?

[joefitzgerald]

The won't fix label was accidental when I was labeling other issues and was immediately removed.

[basarat]

The won't fix label was accidental when I was labeling other issues and was immediately removed.

all good then ❤️. Thanks for this excellent package!

[basarat]

Or perhaps just open the flood gates and make providers filter for themselves where they give autocomplete responses back.

I would expect this to be the case really.

@joefitzgerald you can reproduce it quite simply by typing foo( and any autocomplete provider will be triggered for f,fo,foo but not foo( (or even ()

[joefitzgerald]

I'll have to test but I'm not sure I agree with your assertion. As you can see, no filtering by prefix is done:

https://github.com/atom-community/autocomplete-plus/blob/master/lib/autocomplete-manager.coffee#L103-l124

The only filtering that occurs is one related to the number of characters in new text or old text in bufferChanged. Which wouldn't explain the behavior you describe.

[joefitzgerald]

@acormier has discovered this is due to bracket-matcher - when it matches a (, newText actually has a length of 2, suppressing the suggestion request.

[joefitzgerald]

Fixed in v2.4.2.