Addressed CR feedback.
This commit is contained in:
parent
65e23b1e60
commit
1dca5620f5
1 changed files with 41 additions and 4 deletions
|
@ -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;
|
||||
}
|
||||
|
||||
/**
|
||||
|
@ -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;
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue