| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |\ |
|
| | |
| |
| |
| | |
lexer files
|
| |/ |
|
| |\
| |
| |
| | |
Implement guessing and resolution between TypeScript and TypoScript.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These values would trigger problems when guessing content without a filename,
and really aren't needed. They've been removed, allowing the standard behavior
to take place.
On top of this, the regex for TypeScript has been slightly altered to include
a whitespace match after "export" to be within the group for the "export"
text.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new TypoScript lexer was taking precedence over TypeScript, which share
the same file extension. This meant that any previously-working TypeScript
source files would be misidentified and highlighted incorrectly. This was due
to the lack of a guesser for TypeScript, and TypoScript having a naturally
higher priority.
This change balances things a bit between the lexers. TypoScript now has an
explicitly-higher priority than TypeScript, both for the file extension and
defaults when guessing content, as it has less we can rely on in terms of
content. TypeScript has a lower priority, but has an analyse_text() method
that checks for common symbols in code, giving it a better chance of matching
for actual TypeScript source files.
TypeScript also gains an additional file extension, *.tsx. Ideally, this would
have its own lexer that understood inline JSX syntax, but giving general
TypeScript syntax highlighting for these files is a step in the right
direction.
|
| |\ \
| | |
| | |
| | | |
update LassoLexer
|
| | |\ \
| | | |
| | | |
| | | | |
Add support for string literals to TypeScriptLexer.
|
| | | |/
| | |
| | |
| | |
| | |
| | | |
This introduces support for string literals to the TypeScript lexer. The rules
are consistent with those in JavascriptLexer, helping to ensure the same
behavior and capabilities between the two.
|
| | | |
| | |
| | |
| | | |
punctuation and add new es2015 regex flags (sticky and unicode)
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
devoncarew1/pygments-main/devoncarew1/javascriptpy-edited-online-with-bitbucke-1472355033252 (pull request #657)
javascript.py edited online with Bitbucket
|
| | | |/ |
|
| | | | |
|
| | /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces support for some missing features to the Handlebars lexer:
Partials and path segments. Partials mostly appeared to work before, but the
`>` in `{{> ... }}` would appear as a syntax error, as could other
components of the partial. This change introduces support for:
* Standard partials: `{{> partialName}}`
* Partials with parameters: `{{> partialName varname="value"}}`
* Ddynamic partials: `{{> (partialFunc)}}`
* Ddynamic partials with lookups: `{{> (lookup ../path "partialName")}}`
* Partial blocks: `{{> @partial-block}}`
* Inline partials: `{{#*inline}}..{{/inline}}`
It also introduces support for path segments, which can reference content in
the current context or in a parent context. For instance, `this.name`,
`this/name`, `./name`, `../name`, `this/name`, etc. These are all now tracked
as variables.
|
| | | |
|
| |/ |
|
| |
|
|
| |
Fixes #991
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
