Scope blacklist doesn't seem to be working for me

[curtisblackwell]

I'm trying to prevent Autocomplete Plus from suggesting anything in comments. I tried setting the scope blacklist to the following:

• .comment
• .comment.block
• .source.js .comment.block
• comment

None have any effect. I've tried reloading the view and restarting the app entirely, but still no dice.

Am I doing something wrong?

[joefitzgerald]

Try .source.js .comment.

Also, you should check the scope(s) for the current cursor position using option-command-p (noting you need to prepend . to what you see.

Also, keep in mind that selectors can have wildcards.

[curtisblackwell]

.source.js .comment didn't do the trick.

The scopes are:

• source.js
• comment.line.double-slash.js

Neither of those scopes worked either. Tried:

• .source.js .comment.line.double-slash.js
• .comment.line.double-slash.js
• .source.js.comment.line.double-slash.js

[joefitzgerald]

I'll create a test today to test out your specific use case (cursor scopeChain is .source.js .comment.line.double-slash.js, blacklist is .source.js .comment, or .comment). In both cases, the blacklist should suppress autocomplete.

[mchasej]

The "Scope Blacklist" setting's help text is ambiguous. It can be taken to mean two things:

1. Suggestions are not provided when typing in the listed scopes.
2. Suggestions are not provided from text within the listed scope.

The Scope Blacklist provides the first function. I believe that the Built-In Provider Blacklist is meant to provide the second function, but adding .source .comment to the Built-In Provider Blacklist doesn't prevent the provider from suggesting from within comments.

Both of these functions are useful. Personally, I feel that the first is less important for comments -- If I'm typing comments, I don't see a drawback of suggesting class names, functions, etc. But when I'm typing actual code, I don't want to get suggestions based on words from within the comments -- that's where the second function above would be useful.

Does this need to be a separate issue? Reading previous issues, I think there is some confusion, and that users want the ability to limit both where suggestions are given and where suggestions are provided from.

[DweebsUnited]

@mchasej I completely agree. What I really want from a blacklist is not better control of when it suggests, I want smarter suggestions. Having variable names always be suggested is awesome for documentation, I can reference things and autocomplete will help me out. Suggesting plain english words that have nothing to do with my code is not helpful functionality. It's the opposite, hiding the useful suggestions in a wall of noise.

[WalterGR]

The scope blacklist still doesn't seem to be working, even with the new selector naming scheme, e.g.

.syntax--comment

I can repro this when in a Clojure file in Atom 1.15.0 on OS X.

[WalterGR]

Is this on anybody's radar? Since it's still tagged needs-reproduction, I'm guessing the answer is no?

Is there anything we end users can do to help someone on the Atom team repro this?

[MggMuggins]

Having the same issue:

Atom    : 1.14.2
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0

I am trying to build a provider, but scopes weren't working there (still aren't...), so I tried the blacklist. This issue...

[mangecoeur]

I'm seeing a similar problem trying to disable completions inside critic markup in Markdown files with the blackist set to: .source.gfm .comment.critic.markup.md , I still get suggestions.

[tornewuff]

Even the default blacklist value of .source.gfm doesn't appear to work for me - I get suggestions in markdown files. Is the right selector syntax something else, or is this feature just entirely broken?

[delatbabel]

Nope, appears to be entirely broken.

[gilbertohasnofb]

Up to recently, blacklisting .comment, .string.quoted, .text.plain worked like a charm for me. But since some short time ago, the .comment scope is not being blacklist when dealing with Python files, but it is blacklist in other languages that I tried (Fortran 95, for instance). The other two scopes (strings and plain text) work as expected in all languages. Any ideas of why that might be the case? I tried disabling all autocomplete-* packages leaving only autocomplete-plus enabled and the issue is still reproducible.