-
Notifications
You must be signed in to change notification settings - Fork 12.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
65e23b1
commit 1dca562
Showing
1 changed file
with
41 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1171,7 +1171,26 @@ module ts { | |
} | ||
|
||
export interface Classifier { | ||
getClassificationsForLine(text: string, lexState: EndOfLineState, syntacticClassifierAbsent?: boolean): ClassificationResult; | ||
/** | ||
* Gives lexical classifications of tokens on a line without any syntactic context. | ||
* For instance, a token consisting of the text 'string' can be either an identifier | ||
* named 'string' or the keyword 'string', however, because this classifier is not aware, | ||
* it relies on certain heuristics to give acceptable results. For classifications where | ||
* speed trumps accuracy, this function is preferable; however, for true accuracy, the | ||
* syntactic classifier is ideal. In fact, in certain editing scenarios, combining the | ||
* lexical, syntactic, and semantic classifiers may issue the best user experience. | ||
* | ||
* @param text The text of a line to classify. | ||
* @param lexState The state of the lexical classifier at the end of the previous line. | ||
* @param syntacticClassifierAbsent Whether the client is *not* using a syntactic classifier. | ||
* If there is no syntactic classifier (syntacticClassifierAbsent=true), | ||
* certain heuristics may be used in its place; however, if there is a | ||
* syntactic classifier (syntacticClassifierAbsent=false), certain | ||
* classifications which may be incorrectly categorized will be given | ||
* back as Identifiers in order to allow the syntactic classifier to | ||
* subsume the classification. | ||
*/ | ||
getClassificationsForLine(text: string, lexState: EndOfLineState, syntacticClassifierAbsent: boolean): ClassificationResult; | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
DanielRosenwasser
Author
Member
|
||
} | ||
|
||
/** | ||
|
@@ -5620,8 +5639,26 @@ module ts { | |
noRegexTable[SyntaxKind.TrueKeyword] = true; | ||
noRegexTable[SyntaxKind.FalseKeyword] = true; | ||
|
||
// Just a stack of TemplateHeads and OpenCurlyBraces, used | ||
// to perform rudimentary classification on templates. | ||
// Just a stack of TemplateHeads and OpenCurlyBraces, used to perform rudimentary (inexact) | ||
// classification on template strings. Because of the context free nature of templates, | ||
// the only precise way to classify a template portion would be by propagating the stack across | ||
// lines, just as we do with the end-of-line state. However, this is a burden for implementers, | ||
// and the behavior is entirely subsumed by the syntactic classifier anyway, so we instead | ||
// flatten any nesting when the template stack is non-empty and encode it in the end-of-line state. | ||
// Situations in which this fails are | ||
// 1) When template strings are nested across different lines: | ||
// `hello ${ `world | ||
// ` }` | ||
// | ||
// Where on the second line, you will get the closing of a template, | ||
// a closing curly, and a new template. | ||
// | ||
// 2) When substitution expressions have curly braces and the curly brace falls on the next line: | ||
// `hello ${ () => { | ||
// return "world" } } ` | ||
// | ||
// Where on the second line, you will get the 'return' keyword, | ||
// a string literal, and a template end consisting of '} } `'. | ||
var templateStack: SyntaxKind[] = []; | ||
|
||
function isAccessibilityModifier(kind: SyntaxKind) { | ||
|
@@ -5966,7 +6003,7 @@ module ts { | |
case SyntaxKind.Identifier: | ||
default: | ||
if (isTemplateLiteralKind(token)) { | ||
return TokenClass.StringLiteral; // maybe make a TemplateLiteral | ||
return TokenClass.StringLiteral; | ||
} | ||
return TokenClass.Identifier; | ||
} | ||
|
This seems to have broken tests/cases/unittests/services/colorization.ts: