Invalid emmet abbr returns weird expanded value in css files

[Tyriar]

• VSCode Version: Code - Insiders 1.13.0-insider (c2a17a7, 2017-05-30T05:12:15.312Z)
• OS Version: Linux x64 4.10.0-21-generic
• Extensions:

Extension	Author	Version
EditorConfig	EditorConfig	0.9.3
lorem-ipsum	Tyriar	1.0.0
sort-lines	Tyriar	1.3.0
theme-sapphire	Tyriar	0.2.1
vscode-svgviewer	cssho	1.4.1
tslint	eg2	0.15.0
git-project-manager	felipecaputo	1.3.2
md-navigate	jrieken	0.0.1
vscode-scss	mrmlnc	0.6.2
seti-icons	qinjia	0.1.3

---

#27316

[ramya-rao-a]

haha .foo is not a valid abbreviation to expand, and the extension should handle it better.

[ramya-rao-a]

@sergeche Would you expect the plugin to parse the css file and call expand-abbreviation only if the cursor is in the "rule" part of the css file? Or is there any validation from the emmet modules that we can make use of?

[jens1o]

Sorry to interrupt but this is valid? .class => <div class="class">|</div>

(such as #header => <div id="header"></div>)

https://docs.emmet.io/cheat-sheet/

[ramya-rao-a]

@jens1o It is valid html, so yes it is valid

[jens1o]

Then I'm sorry, but I do not understand what you're trying to say.

haha .foo is not a valid abbreviation to expand, and the extension should handle it better.

[ramya-rao-a]

Oh I mean when taken in the context of css .foo is not a valid abbreviation
In the context of html it certainly is.

In this issue we are talking about css abbreviation

[jens1o]

Ah, sorry, then I didn't get the subject.

[ramya-rao-a]

Since auto-complete will get triggered for every new letter typed, either the emmet plugin should be smart enough not to try to expand .foo in the context of css or the css parser being used should not treat it as an abbreviation

[jens1o]

But is it the css parser who should say this is a valid expression or an invalid? (like d:b; => display: block;)

I think that would overwhelm the css parser, and block other extensions. I think it should be handled by the emmet extension.

[ramya-rao-a]

There's work to be done on both sides.

div for eg expands to display:inline-block by the css-abbreviation module because that's the nearest match it can find

But .foo clearly is an invalid CSS abbreviation and can be easily be invalidated by the css-abbreviation module.

Additionally, the extension shouldn't ask for expansion if it can beforehand figure out that the cursor is not in a "property" line

[jens1o]

nice idea. I think I still tune to the Insiders to give you feedback.

[sergeche]

The plugin itself should implement logic whether a string can be expanded as abbreviation or not. It’s one of the reasons I’ve moved from monolithic codebase to a small, re-usable modules: to allow authors to use editor API for a better Emmet integration with editor features.

You use Atom plugin as a reference, here’s an example where I decide where abbreviation can be expanded: https://github.com/emmetio/atom-plugin/blob/master/lib/detect-syntax.js#L17-L20

[ramya-rao-a]

@sergeche Ah the catch there is that scope info is not available to VS Code extensions :( See #580

And so I will either end up parsing the whole file to see if cursor is in a selector/rule or try to do some regex magic.

[sergeche]

@ramya-rao-a you can re-use @emmetio/html-matcher and @emmetio/css-parser to quickly parse a document. These parsers are pretty fast: on my MacBook Pro they are able to parse a 500 KB document in about 10 ms. But it’s a good idea to implement a VSCode-specific StreamReader as in Atom plugin. The goal of this reader is to use text coordinates native to editor and use editor’s content representation model. For example, Atom stores text content as lines of text so instead of spending resources on allocating memory for a whole text content and then translate text coordinates into editor ones, I simply read directly from editor in it’s coordiantes

[Fred-Vatin]

In the new emmet, would this issue solve the current one when something like c:r is expanded as color: r; instead of color: rgb(0, 0, 0); ?

[sergeche]

Can be solved by providing more value samples for c snippet: https://github.com/emmetio/snippets/blob/master/css.json#L76

[ramya-rao-a]

@sergeche I implemented a stream reader for VS Code's TextDocument, and am currently parsing the document to avoid suggesting emmet expansions in invalid locations like inside the open tag in html or a selector in css.

But take the case of scss where you can have nested selectors. In this case, when we start typing a nested selector, the parser is not aware of whether the user is typing another property or a new selector. In this case, we end up with the below both in Atom and VS Code

So even though editors try and figure out the right scope for emmet abbreviations, I believe the extract-abbreviation module can use some validation of its own based on simple regex.

[sergeche]

Yes, stubled with this issue too, will fix CSS abbreviation parser

[ramya-rao-a]

@sergeche Can we do the same for html as well? That would solve #27975

[sergeche]

Yes. Please create a separate issue at https://github.com/emmetio/atom-plugin/issues so I can better track bugs

[ramya-rao-a]

Thanks @sergeche !

Logged emmetio/atom-plugin#22

[ramya-rao-a]

Closing this in favor of #27975