autocomplete-plus
autocomplete-plus copied to clipboard
`configSuggestionsBuffer.findWordsWithSubsequence` throws when typing fast in certain files
Edited by @Ben3eeE to include steps to reproduce and an issue template from https://github.com/atom/autocomplete-plus/issues/965
Prerequisites
- [x] Put an X between the brackets on this line if you have done all of the following:
- Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
- Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
- Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
- Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
- Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages
Description
The following code fails to check the return value for findWordsWithSubsequence
and assumes it returned a list of suggestions:
https://github.com/atom/autocomplete-plus/blob/b8e2223e973ac3253e2ffd47fccb59e52336d955/lib/subsequence-provider.js#L100-L105
This can lead to the following error being thrown:
Cannot read property 'length' of null; stack: TypeError: Cannot read property 'length' of null
at configSuggestionsBuffer.findWordsWithSubsequence.then.matches (/Applications/Atom.app/Contents/Resources/app/node_modules/autocomplete-plus/lib/subsequence-provider.js:123:40)
Refs https://github.com/atom/autocomplete-plus/pull/921#issuecomment-380608223
Steps to Reproduce
- Open Atom in safe mode
atom --safe
- Open a new untitled buffer
- Change language mode to
php
- Enter the following:
<?php
?>
- Type fast between the php start and end tags.
Expected behavior:
No errors logged in the console.
Actual behavior:
Multiple errors logged in the console.
Reproduces how often:
100%
Versions
Atom : 1.28.0-dev-7b46b970b Electron: 1.7.11 Chrome : 58.0.3029.110 Node : 7.9.0
Greetings,
Follow up from https://github.com/James-Yu/Atom-LaTeX/issues/131.
For the LaTeX plugin, there is a provider for $
completion, over and above the {
autocomplete. However, with a large buffer, typing becomes laggy within nested text such as $ Some text that is {painful to type here}$
Console throws up:
Uncaught (in promise) TypeError: Cannot read property 'length' of null
at configSuggestionsBuffer.findWordsWithSubsequence.then.matches
(\resources\app\node_modules\autocomplete-plus\lib\subsequence-provider.js:123:40)
Having the same issue.
I see this in the console when typing fast between php tags:
/cc: @ungb
I'll take a look at this and see if I can repro.
@Ben3eeE I was able to reproduce the specific error you showed when typing quickly between PHP tags in a PHP file. But I was unable to reproduce it when typing in a Markdown file, despite the fact that autocomplete suggestions were popping up repeatedly.
I used Atom v1.25.1 on Mac OS X 10.13.4.
Editing the title since this is not the cause of the lag. The cause of the lag is in the bracket-matcher
/cc: https://github.com/atom/bracket-matcher/issues/341
Should this be closed then?
On Tue, Apr 17, 2018 at 10:59 PM, Linus Eriksson [email protected] wrote:
Editing the title since this is not the cause of the lag. The cause of the lag is in the bracket-matcher /cc: atom/bracket-matcher#341 https://github.com/atom/bracket-matcher/issues/341
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/atom/autocomplete-plus/issues/948#issuecomment-382271576, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_XKdaHqpyqH7v2v0QrnWrr3U1MjGqYks5tptY2gaJpZM4RsLI1 .
@lee-dohm No. This is still an issue. It's just not the cause of the performance issues that the author was observing.
I edited the body of the issue to copy over the template from https://github.com/atom/autocomplete-plus/issues/965 and to add steps to reproduce.
@Ben3eeE @lee-dohm any ideas/updates on this?
If this is just errors in the console, this is probably not going to be a high priority. We'll see what we can find when we get a chance.
The actual find function can be traced directly to the superstring
buffer. In it, see this resolve. Could this be the cause? (Yes, I was running into this issue when trying to monitor my own packages console logs).