Complete in strings and comments

[lalomartins]

I'd like to be able to write snippets for strings and comments. For example, language-coffee-script has a snippet for "#{interpolation}" which doesn't work so it had to hack around it somehow (I'm not quite sure how, couldn't find it in the source). Some snippets, such as lorem and legal, are clearly only useful (in source code files) inside a string or comment.

Currently it's not possible to complete in strings and comments, due to disableForSelector: '.comment, .string'. Furthermore, since autocomplete+ hijacks tab from snippets, I can't trigger the snippet by hand with tab either, if there's a symbol (fuzzy-)matching the snippet name.

I believe that does more harm than good; if the symbol provider works in strings and comments, why not snippets?

Even if it turns out people really don't like them, I'd suggest an alternative implementation is to match only snippets that actually have .string or .comment in the selector. Hacking around the devtools console, I managed to make that happen by passing only the current scope as the scope option to config.get. I managed to make that happen with the following code:

  getSuggestions: ({scopeDescriptor, prefix}) ->
    return unless prefix?.length
    isStringOrComment = scopeDescriptor.getScopeChain().match(/\s([^ ]*\.(string|comment)\b[^ ]*)$/)
    if isStringOrComment
      # could also use isStringOrComment[1]
      scopes = scopeDescriptor.getScopesArray()
      scopeDescriptor = [scopes[scopes.length - 1]]
    scopeSnippets = atom.config.get('snippets', {scope: scopeDescriptor})
    @findSuggestionsForPrefix(scopeSnippets, prefix)

(Not very happy with using a regex, but I couldn't find an API to check for a selector match; then again personally I'd rather not have this hack at all, just enable the provider and leave it at that.)

[joefitzgerald]

Your expectations of the package and the presence of snippets in comments is reasonable. I agree that filtering the snippets to the current scope when inside comments is the way to go.

[joefitzgerald]

@lalomartins would you be open to creating a PR for this?

[lalomartins]

I have it in a branch, so yes. I just need to check if there's a bug in it wrt punctuation (as punctuation would be the last scope in this case, which prevents the snippet from triggering if it's just before the closing quote).

Thanks for the quick feedback!

[lalomartins]

On the other hand, wouldn't it be better, both in terms of UX and code maintainability, to just remove the disableForSelector property and see if anyone complains? It's one less hack, and the behaviour would be less surprising.

[joefitzgerald]

remove the disableForSelector property

Yes, but I'd like to ensure we're only then suggesting snippets that are valid in comments. So it may somewhat invert the code you have and the way it goes about filtering the suggestions and having them displayed.

[lalomartins]

The thing is… without getting too philosophical… how do we know what's valid? I thought at first symbol completion in strings was useless, until I had to write the name of a class in an error message. If I'm writing a Python docstring, I might want a full if-else block as part of my code example. I'm sure you can think of other cases.

I just don't see the justification for “protecting” the user like that. It's not like autocomplete is forcing anything on you anyway, right? You don't want the snippet, just don't select it.

[joefitzgerald]

It got out there because people complained (rather vehemently) that
suggestions in comments were not desirable. Perhaps the solution is just to
make it configurable.
On Wed, Jun 24, 2015 at 1:04 PM Lalo Martins notifications@github.com
wrote:

The thing is… without getting too philosophical… how do we know what's
valid? I thought at first symbol completion in strings was useless, until I
had to write the name of a class in an error message. If I'm writing a
Python docstring, I might want a full if-else block as part of my code
example. I'm sure you can think of other cases.

I just don't see the justification for “protecting” the user like that.
It's not like autocomplete is forcing anything on you anyway, right? You
don't want the snippet, just don't select it.

—
Reply to this email directly or view it on GitHub
#55 (comment)
.

Best Regards,

Joe Fitzgerald
Director, Pivotal Cloud Foundry Solutions
Mobile: (303) 888-3964 | jfitzgerald@pivotal.io
LinkedIn: @jfitzgerald | Twitter: @joefitzgerald | Github: @joefitzgerald

[lalomartins]

I can relate to that point of view, but then the solution is to disable autocomplete-plus in comments/strings, not autocomplete-snippets. Having a suggestions box with everything but snippets is not only too surprising in terms of UX, it also doesn't solve the problem of suggestions not being desirable 😸

And by the way, disabling the autocomplete box in comments/strings (with or without config option) would also solve my own problem, as I'd be able to expand snippets by pressing tab. So +1 for that.

[joefitzgerald]

You can do this today in ac+ preferences: scope blacklist.

[lalomartins]

In which case it seems to me the right fix is to remove the disableForSelector from autocomplete-snippets entirely, and then change ac+'s default scope blacklist to remove it from comments and strings

[joefitzgerald]

The default for ac+ won't change because it would prevent precisely the kind of use case you described: suggestions in comments.

[lalomartins]

But isn't that exactly what people complained about?

[lalomartins]

You can't have it both ways, you know. If suggestions in comments are disruptive, you want them all off. If you want suggestions in comments, it makes no sense to disable only snippets, since you can simply ignore them when the list does pop up. There is no benefit to blacklisting only snippets.

[joefitzgerald]

@lalomartins you are quite right - you can't have it both ways: defaults can never please 100% of people. Thats why it's configurable in ac+. Perhaps the fix is just to make it configurable in autocomplete-snippets too. There is benefit to blacklisting only snippets, for some people. Just not you :)