Snippets are sometimes disabled and sometimes not

[savetheclocktower]

Prerequisites

• 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

This is a multi-pronged issue. I’ll try to organize my thoughts. My goal is to understand why the current behavior is in place and if it’s intentional.

Snippets

Most snippets provided by this package are explicitly disabled when the cursor is inside of any HTML tag. I’ve sifted through the history of this repo to try to find the rationale for this decision, but I haven’t come across a PR discussion or commit message that explains it. It’s obvious to me why you’d want to disable HTML snippets when the cursor is inside a style or script block, but I don’t understand why the snippets are also disabled inside any meta.tag scope.

Scope quirks

The impact of this is minimized by a grammar issue that I think is unintentional. Consider these code examples (with ^ used to represent the cursor):

<li>^</li>

In this example, there are three scopes at the given cursor position: text.html.basic, meta.tag.inline.li.html, and punctuation.definition.tag.begin.html.

<li>
  ^
</li>

In this example, there is only one scope at the given cursor position: text.html.basic.

I’ll grant you that punctuation.definition.tag.begin.html is rightfully missing from the second example since we’re on a new line. But I don’t think it’s logical for meta.tag to be missing from the second example.

The effect is that an HTML snippet gets disabled in the first example, but works fine in the second example. I think this is surprising behavior, and if it’s intentional, it ought to be spelled out somewhere.

Why is this a problem?

It’s also caused a couple of bug reports on the snippets package, even though these snippets are working as designed.

The workarounds require a larger than usual amount of savvy. A user wanting to override this behavior could define an HTML snippet in their own snippets.cson…

'.text.html':
  'Anchor':
    'prefix': 'a'
    'body': '<a href="${1:#}">$2</a>$0'

…but this naïve example won’t work as expected. User-defined snippets supersede package-defined snippets, but only when all else is equal. When the cursor is inside a .text.html .meta.tag scope, the package-defined snippet still wins because it’s a more specific scope. The user has to be experienced enough with Atom to know that their scope selector needs to be at least as specific in order to win out:

'.text.html .meta-tag':
  'Anchor':
    'prefix': 'a'
    'body': '<a href="${1:#}">$2</a>$0'

Package-provided snippets are not currently shown in the package’s settings panel, so discoverability is low. atom/settings-view#1084 will fix this. But even after that issue lands, the UI for showing a package’s snippets won’t fully communicate a complex scenario like this one — in which many snippets are defined broadly but null’d out in more specific scopes. A user will still have to dig into the package’s source code to figure out how specific their override needs to be.

Steps to Reproduce

1. Open a blank document and set it to HTML.
2. Type a; hit Tab. The “Anchor” snippet expands.
3. On the next line, type li; hit Tab. The “List Item” snippet expands.
4. With the cursor in between the opening and closing li tags, type a and press Tab. A literal tab is inserted and no snippet is expanded. (The snippet is disabled in the .text.html meta.tag scope.)
5. Repeat step 4, but first add spaces (or newlines) before and after the cursor. The “Anchor” snippet expands. (The HTML grammar no longer scopes the cursor as being inside .meta.tag.)

Actual behavior is described in each step.

Expected behavior: I’d expect step 4 to result in an expanded snippet rather than a literal tab insertion. The outcome of step 5 is what I want, but it happens for the wrong reason, and is an inconsistency with step 4’s actual behavior.

Reproduces how often: Always.

Versions

Occurring on 1.31.2 (apm 2.1.1).