Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(handlebars): add subexpressions, block-params and hash-parameters #2344

Merged
merged 15 commits into from May 19, 2020

Conversation

@nknapp
Copy link
Contributor

@nknapp nknapp commented Jan 2, 2020

closes #2181

  • Support for sub-expressions: Helper names in sub-expressions are now highlighted properly. The mode-tree is built recursively for sub-expressions so that sub-elements (nested sub-expressions in params) are also highlighted properly (like {{helper1 (helper2 (helper3 param) ) }}).
  • Support for hashes ("attr-assignments" in the "htmlbars"-language) (like {{helper key=value}} or {{helper key=(sub-helper value)}}
  • Path expressions are highlighted: {{path.expression}}. Up to know, only path would be highlighted.
  • Block parameters are highlighted correctly: In {{#with as as | as | }} , only the middle as is a keyword.
  • Literals in helper-parameters are highlighted as keyword, number or string.
  • Merged built-ins with the list from 'htmlbars'
  • Added 'htmlbars' as alias
  • Deleted the 'htmlbars' language
@nknapp nknapp force-pushed the nknapp:master branch from 72967d5 to c33ae2f Jan 6, 2020
@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

@yyyc514 I think I am about ready except for some cleanup and the following questions:

  • what should happen to 'htmlbars' now?
    I have removed the whole language in my branch because the auto-detection tests were failing all the time.
  • should the changes go to the wip_version_10 branch?
  • The expression inside I basic mustache ({{test}}) is now highlighted as "hljs-name" just like in block-mustaches. I felt that they should because they essentially have the same semantics. Should I revert that to retain the previous behaviour?
@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Jan 6, 2020

what should happen to 'htmlbars' now?

I've changed my thinking on this and now think it should simply be an alias of handlbars. (particularly if we feel it really covers everything).

should the changes go to the wip_version_10 branch?

Sure, though I hope to merge it soon anyways, so that's not a necessity.

The expression inside I basic mustache ({{test}}) is now highlighted as "hljs-name" just like in block-mustaches. I felt that they should because they essentially have the same semantics. Should I revert that to retain the previous behaviour?

What was the previous behavior again?

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

Before (on the current master), non-block mustache expressions are rendered like this:

Selection_005

After the PR like this:

Selection_004

Here is a complete overview of all testcases:

Before the PR:

handlebars-testcases-before

After the PR:

handlebars-testcases-after

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

What I also changed (in my next version, is the attr-assignment-rule of htmlbars (in Handlebars-speak, this is called "Hash"). The 'htmlbars'-language highlights the value (behind the equal-sign) as attr, but as I understand it, the part in front of the equal sign should be highlighted.

This change is not visible in the default theme, because the "attr"-class has no special highlighting, but it is there.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Jan 6, 2020

The expression inside I basic mustache ({{test}}) is now highlighted as "hljs-name" just like in block-mustaches.

I kind of dislike this for simple variable expressions, but I don't really know what to suggest as figuring out one from the other might not be worth the effort.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Jan 6, 2020

but as I understand it, the part in front of the equal sign should be highlighted.

Makes sense to me, of course if the value was a number or string I'd still expect it to be highlighted as such.

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

I kind of dislike this for simple variable expressions, but I don't really know what to suggest as figuring out one from the other might not be worth the effort.

The distinction between function-call and property-access is not between blocks and basic mustaches (see https://jsfiddle.net/nL91aohe/1/):

  • {{test}} can be a property-access (i.e. variable) or a function-call (if 'test' is a function) or a helper call (if a helper 'test' is registered)
  • {{#test}}...{{/test}} can be a block-helper, or a property-access that dives into a object.

But, I have left the classes "variable" and "tag" as they were. I just gave the first element in a a basic mustache the class "name", which makes it bold.

@nknapp nknapp force-pushed the nknapp:master branch from e90bae2 to fdf9aa5 Jan 6, 2020
@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Jan 6, 2020

I just gave the first element in a a basic mustache the class "name", which makes it bold.

Don't presume this, how it looks all depends on the theme used...

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

This has gotten really complex now. I wonder if you'll be able to review...

It is really difficult to verify the tests manually. I tried to make them self-explanatory, but the HTML-tags in the expect-files really mess up with readability.

It might be a good idea to create use a visual regression-testing tool to create screenshots of the test-cases. Just an idea... Of course, we would need a theme that makes more classes visible...

I'll try to update the description of the PR with a summary of what has changed...

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

What I am still unsure about is the class for built-in helpers and keywords:

As far as I understand the class reference it should be like this:

  • built-in helpers like 'each', 'with' (and probably all the other keywords in the built-ins list as well) should get the class builtin-name because they are a "name from the language standard library" .
  • keywords like {{else}} or as in {{#with x as | y |}} should get the class "keyword" because they are part of the language and not the standard library

What is the 'built_in' class used for? Should any of those be built_in instead?

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 6, 2020

Apart from that, I am done here for now. I think you can start your review...

@nknapp nknapp changed the title WIP: Handlebars: add subexpressions, block-params and hash-parameters feat(handlebars): add subexpressions, block-params and hash-parameters Jan 12, 2020
@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Jan 20, 2020

I'd love a better way to write markup tests, but it seems a tough problem. The way we do it now is surely because we never know what might be a validate language so there is no safe way to escape anything inside the test file.... hence we end up with raw text or using comments to describe individual test cases. (but those can get in the way of seeing the test cases themselves)

Something like JSON/YAML would probably be preferable but then optimally we'd have to build out a whole test case editor... which I don't think anyone has the time for.

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 30, 2020

I was just wondering if you are waiting for a answer to your last comment. But I didn't see a question, that's why I didn't write anything new.

I'm just doing it now, a friendly reminder that this is ready for review from my point of view.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Jan 31, 2020

I asked a few questions/requested changes in the sub-responses.

Copy link
Member

@joshgoebel joshgoebel left a comment

See my individual comments.

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Jan 31, 2020

Haven't seen the comment. Will look at it.

@joshgoebel joshgoebel added this to the 10.0 milestone Jan 31, 2020
@joshgoebel joshgoebel modified the milestones: 10.0, 10.1 Feb 29, 2020
@nknapp nknapp force-pushed the nknapp:master branch from ec8e1ac to a9ebc7b Apr 10, 2020
@nknapp nknapp closed this Apr 10, 2020
@nknapp nknapp force-pushed the nknapp:master branch from a9ebc7b to 512ae5f Apr 10, 2020
@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Apr 10, 2020

@yyyc514
I have refactored the commits and some tests and rebased everything onto the master. The commits are now structured as follows:

  1. Implementation of changes, adjustet test-cases expectations to reflect the new rules. This should allow you to see the changes that the new code does to the old tests
  2. Add more tests for the new rules.
  3. Change of the behaviour regarding {{else}} that you requested above.

I have not added any text parts to the new tests, except in the test "combinations-with-text.txt".

I have left the text parts in the old test-cases, because I didn't want to change the tests (make it easier for you to compare the results). I can clean-up those tests as well, if you want me to.

@nknapp nknapp reopened this Apr 10, 2020
@nknapp
Copy link
Contributor Author

@nknapp nknapp commented Apr 10, 2020

Somehow, GitHub displays the commits in the wrong order. The correct order (in my git repo) is:

9468f00 wip: adjustments for integrating handlebars rules
30a5e54 fixup: add more tests
c6fbcec fixup: make only "else" in {{else}} the keywords, not "{{else}}" as whole

@nknapp nknapp force-pushed the nknapp:master branch from 9a75b9d to 88f76a0 May 16, 2020
@nknapp
Copy link
Contributor Author

@nknapp nknapp commented May 16, 2020

@yyyc514 I have added a few commits that hopefully address all of your points: Some commits, I have also noticed and fixed the following things:

  • Typo in variable IDENFIFIER_REGEX (commit 74f0c87 was somehow attributed to you, not me. I made an interactive rebase and moved that commit to the beginning and something went wrong. I don't mind if you don't).
  • The jsdoc-comment in regex.concat was not accurate. IntelliJ gave me a warning, a varargs-
    parameter is not an array in jsdoc.

I think it would generally be better to use

import {concat} from '../lib/regex'

then

import * as regex from '../lib/regex' 

because then, rollup can optimize using tree-shaking. I haven't done it because the wildcard import was used in other places. This might be an additional PR, for other languages as well.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 17, 2020

Thanks for the type fix. :-) Your right.


I prefer seeing the regex namespace in the code. Though I suppose you could still import them one at a time then put them back in a the regex namespace, but ugh.

because then, rollup can optimize using tree-shaking. I haven't done it because the wildcard import was used in other places.

This is a point, but one I'm not 100% sure I'm in a hurry to address, though welcome to discuss it here further since you noticed it and brought it up. :-)

My thoughts:

  • regex may eventually get hung off of hljs like everything else... I'm wait to see what "feels right"... but at that point it's just an API of the core library and can't be tree-shaken because we have no idea who might need it.
  • Eventually we will build the "common" distributable build (ie, common languages) as one huge module (rather than individual languages as it's built now) and in that case there will be effectively no tree-shaking because the code wouldn't existing in the codebase if it wasn't used SOMEWHERE. And when we build as one huge module the code will also only be included a single time, rather than duplicated.

At that point the only thing tree-shaking would do for us is make the CDN modules a bit "tighter"... and even that wouldn't be true if regex moved back into being hung off of the main library.

Does that make sense?

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented May 17, 2020

Moving it into core makes sense.

I don't if making a huge module makes sense if people use their own bundler. If you just need 3 languages (like in the handlebars website) you probably don't want to have all other rules in the code as well. So it would be better to import distinct rules and let webpack do the, well, tree-shaking. From that point of view it also makes sense not to use the wildcard import.

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented May 17, 2020

Actually I may have spoken too soon because of my last change before 10.0:

  var SHOULD_INHERIT_FROM_HANDLEBARS = hljs.requireLanguage('handlebars');

That would make a hard error if someone wasn't also loading handlebars, although I suppose someone could still be using the file in a manual require pipeline... so perhaps the htmlbars.js file is still required just to cover that edge case.

Is there something to do for me in this respect?

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 17, 2020

Is there something to do for me in this respect?

Nope. I think the commit I added earlier adding the file back and making it point to handlebars resolves it until v11, when the file can be completely removed.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 17, 2020

So it would be better to import distinct rules and let webpack do the, well, tree-shaking.

I’m not sure I follow. Do you think the code should hung off of hljs or be imported? If it hangs off of hljs it cannot be tree-shaken because it’s a public API and the dependencies are not known at compile-time... so all the code has to be included (not that it’s a huge amount of code).

So there are a few different decisions to make here. Ex: If we hang all the util functions off of hljs then how we import them becomes irrelevant.

As as I’ve said elsewhere I’m always hesitant to add more public API because then it’s much easier to add than it is to remove... so I was playing it by ear until some of our 3rd party modules started to want to use this stuff and then see how it works.

I’m more interested in what is clean and simple to do vs shrinking an 100kb library another 3kb or something trivial. Again keeping common use cases in mind,not edge cases.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 17, 2020

If a size critical build was really an issue there are much better places to look for savings than whether all the functions in regex.js are tree-shaken or not.

@nknapp
Copy link
Contributor Author

@nknapp nknapp commented May 17, 2020

You are right in that there is not much to gain and I wonder if this discussion is really worth it.

I understand your arguments and I don't want to tell you how to build highlight.js. I just wanted to point out that people may be using ESM-import directly.

Since the core actually does an import * as regex from './lib/regex' the tree-shaking would not change much in this particular case. But there may be other cases in the future where it becomes relevant, who knows.

But I don't want to refactor highlightjs. I think you have done a great job moving to ESM in the first play. And to be honest, I am happy, when this PR is done and out of my mind ✔️

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 18, 2020

And to be honest, I am happy, when this PR is done and out of my mind ✔️

Sorry it got so complicated and I took so long to come back to it. :-) It's awesome to finally get this finished.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 18, 2020

Would you mind writing up a changelog entry (or a few)? I was going to just do it myself but then wasn't sure I could do it all justice... since my big-picture take is that we finally killed htmlbars but I think this makes a lot of other improvements that perhaps you'd like to mention?

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 19, 2020

@nknapp Take a deep breather and have a cold beverage today. :-) Thanks again!

@joshgoebel joshgoebel merged commit e9e7b44 into highlightjs:master May 19, 2020
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@nknapp
Copy link
Contributor Author

@nknapp nknapp commented May 19, 2020

I pushed an entry that contains that things that are important to me. But I haven't mentioned htmlbars, because I'm not sure what to write about it exactly.

Should I rebase and squash the commits into semantically relevant ones?

Oh, you merged already 😁

While I was writing this, the label went from "open" to "merged"

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 19, 2020

But I haven't mentioned htmlbars

I added an entry for the deprecation.

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 19, 2020

Now we need someone as tenacious as you to tackle all the CSS stuff. :-)

0xflotus added a commit to 0xflotus/highlight.js that referenced this pull request Jun 12, 2020
* (docs) Add Chaos to supported languages (highlightjs#2510)

* fix(parser) fixes sublanguage with no rule matches (highlightjs#2506)

* fix(parser) fixes sublanguage with no rule matches

Resolves highlightjs#2504.

* (chore) Add ESLint config and clean up the major stuff (highlightjs#2503)

* (chore) eslint:recommended
* (chore): eslint_standard
* relax eslint rules for language grammars (to discourage rewriting them in one fell swoop; I'd rather have the blame history intact)
* remove extra escaping
* clean up variables
* more camelcase

* (docs) Add Visual Basic for Applications (VBA) to supported languages (highlightjs#2512)

* (yaml) improve tag support; add verbatim tags (highlightjs#2487)

* YAML parse non-word characters as part of tags
* adds support for verbatim tags

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* fix(javascript/typescript): lambda with parens in parameters fails (highlightjs#2502)

* fix(javascript/typescript): lambda with parens in parameters fails

- Fixes both JavaScript and TypeScript grammars

Fixes samples like:

    const bad = ((a, b) => [...a, b]);
    sides.every((length,width=(3+2+(4/5))) => length > 0 );

This is done by counting parens in the regex that finds arrows
functions. Currently we can only handle 2 levels of nesting as
shown in the second example above.

* allow much richer highlighting inside params
* improve highlighting inside arguments on typescript

* enh(cpp): Improve highlighting of unterminated raw strings

PR highlightjs#1897 switched C++ raw strings to use backreferences, however this
breaks souce files where raw strings are truncated. Like comments, it
would be preferable to highlight them.

- Add `on:begin` and `on:end` to allow more granular matching when
  then end match is dynamic and based on a part of the begin match
- This deprecates the `endSameAsBegin` attribute. That attribute was
  a very specific way to solve this problem, but now we have a much
  more general solution in these added callbacks.

Also related: highlightjs#2259.

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* (chore) C-like uses the new END_SAME_AS_BEGIN mode

* (chore) Ruby uses END_SAME_AS_BEGIN mode/rule

* (parser) make END_SAME_AS_BEGIN a function helper

Adds a mode helper to replace the deprecated `endSameAsBegin` attribute.

The first match group from the begin regex will be compared to the first
match group from the end regex and the end regex will only match if both
strings are identical.

Note this is more advanced functionality than before since now you can
match a larger selection of text yet only use a small portion of it for
the actual "end must match begin" portion.

* (pgsql) add test for $$ quoting existing behavior

- even if that existing behavior is questionable
- the ending span should really close before the $$, not after

Fixing this would involve delving into the sublanguage behavior and I'm
not sure we have time to tackle that right this moment.

* (chore) pgsql uses END_SAME_AS_BEGIN mode/rule now also

* (docs) rename to `mode_reference`; docs for callbacks

- I can never find this file because it's name didn't fully match.
- rename callbacks to `on:begin` and `on:end`

* prevented setter keyword conflicting with setTimeout|setInterval and highlighted them (highlightjs#2514) (highlightjs#2515)

* fix(javascript) prevent setter keyword 'set' conflicting with setTimeout|setInterval (highlightjs#2514)
* enh(javascript) setTimeout|setInterval now highlighted (highlightjs#2514)
* enh (javascript) clearInterval and clearTimeout now highlighted
* add keywords to TypeScript also

* (docs) add TLDR instructions for building and testing

* (dev) improve developer tool UI

* (parser) Build common EMCAscript foundation

Builds a common keyword foundation for any grammar that is
building on top of JavaScript:

- LiveScript
- CoffeeScript
- TypeScript

Also uses this common foundation for JS itself.

* (parser) Adds SHEBANG mode

* (yaml) Add support for inline sequences and mappings (highlightjs#2513)

* Use containers to match inline sequences and mappings
* Add string type for inside inline elements
* Handle nested inline sequences and mappings
* Disallow all braces brackets and commas from strings inside inline mappings or sequences
* clean up implementation
* feed the linter

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* [enh] Add `OPTIMIZE:` and `HACK:` to comment doctags

* (build) browser build is CommonJS and IIFE, no more AMD (highlightjs#2511)

* (build) browser build is CommonJS and IIFE (global) now
* (build) dropping support for AMD, which we never truly supported
  properly in the first place
* (build) add test to make sure browser build works as commonJS module

  Resolves highlightjs#2505

* fix(parser) Fix freezing issue with illegal 0 width matches (highlightjs#2524)

* fix[parser] add edge case handle for illegal 0 width matches
* add last ditch catch all that tries to detect other uncaught freezes

* (docs) added unicorn-rails-log as an 3rd-party language (highlightjs#2528)

- (docs) Add syntax highlighting for Rails Unicorn logging to supported languages.

* (docs) fix supported languages link: it moved again! (highlightjs#2533)

* fix(ts/js) use identifier to match potential keywords (highlightjs#2519)

- (parser) Adds `keywords.$pattern` key to grammar definitions
- `lexemes` is now deprecated in favor of `keywords.$pattern` key
- enh(typescript) use identifier to match potential keywords, preventing false positives 
- enh(javascript) use identifier to match potential keywords, preventing false positives

* fix(javascript) fix regex inside parens after a non-regex (highlightjs#2531)

* make the object attr container smarter
* deal with multi-line comments also
* comments in any order, spanning multiple lines

Essentially makes the object attr container much more sensitive by allowing it to look-ahead thru comments to find object keys - and therefore prevent them from being incorrectly matched by the "value container" rule.

* (parser) Add hljs.registerAlias() public API (highlightjs#2540)

* Add hljs.registerAlias(alias, languageName) public API
* Add .registerAlias() test

* enh(cpp) add `pair`, `make_pair`, `priority_queue` as built-ins (highlightjs#2538)

* (fix) `fixMarkup` would rarely destroy markup when `useBR` was enabled (highlightjs#2532)

* enh(cpp) Recognize `priority_queue`, `pair` as containers (highlightjs#2541)

* chore: rename `registerAlias` to `registerAliases`

Plural form is clearly better as it's not surprising to the reader
to see it being passed an array - where as the singular form might
have been.  Meanwhile it's also easy to assume that it also supports
arrays of any size - including an array with a singular alias.

The fact that it can magically accept a string as the first argument
might not be obvious, but we document it and even if one didn't know
this they could still use the array form of the API without any issue
by passing a one item array.

* (swift) @objcMembers not completely highlighted (highlightjs#2543)

* Fixed @objcMembers in Swift

Would match `@objc` first, and the `Members` part would be unhighlighted

* Update CHANGES.md

* Update swift.js

* (docs) add OCL to list of supported languages (highlightjs#2547)

* (docs) Add Svelte to list of supported languages (highlightjs#2549)

* enh(dart) Add `late` and `required` keywords, and `Never` built-in type (Dart 2.9) (highlightjs#2551)

* Add new Dart 2.9 keywords for Null Safety language feature

* enh(erlang) add support for underscore separators in numeric literals (highlightjs#2554)

* (erlang) add support for underscore separators in numeric literals
* (erlang) add tests

* (docs) add Jolie to Supported Languages (highlightjs#2556)

* (parser/docs) Add jsdoc annotations and TypeScript type file (highlightjs#2517)

Adds JSDoc annotations and a .tsconfig that allows TypeScript to be run in it's "allowJS" mode and apply type and sanity checking to JavaScript code also. See Type Checking JavaScript Files.

I've been using TypeScript a lot lately and finding it very beneficial and wanted to get those same benefits here but without converting the whole project to TypeScript. It was rough at the beginning but now that this is finished I think it's about 80%-90% of the benefits without any of the TS compilation pipeline. The big difference in being JSDoc for adding typing information vs inline types with TypeScript.

Should be super helpful for maintainers using an editor with tight TypeScript integration and the improved docs/comments should help everyone else.

- Adds types/index.d.ts to NPM build (should be useful for TypeScript peeps)
- Improves documentation of many functions
- Adds JSDoc annotations to almost all functions
- Adds JSDoc type annotations to variables that can't be inferred
- Refactors a few smaller things to allow the TypeScript compiler to better infer what 
   is happening (and usually also made the code clearer)

* (parser) highlightBlock result key `re` => `relevance` (highlightjs#2553)

* enh(handlebars) Support for sub-expressions, path-expressions, hashes, block-parameters and literals (highlightjs#2344)

- `htmlbars` grammar is now deprecated. Use `handlebars` instead.

A stub is included so that anyone literally referencing the old `htmlbars` file (say manually requiring it in Node.js, etc) is still covered, but everyone should transition to `handlebars` now.

* fix(typescript) Add missing `readonly` keyword (highlightjs#2562)

* (docs) Mention `c` is a possible class for C (highlightjs#2577)

* fix(groovy) strings are not allowed inside ternary clauses (highlightjs#2565)

* fix(groovy) strings are not allowed inside ternary clauses
* whitespace can also include tabs

* Update @typescript-eslint/parser to the latest version 🚀 (highlightjs#2575)

* chore(package): update @typescript-eslint/parser to version 3.0.0
* chore(package): update lockfile package-lock.json

Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Josh Goebel <me@joshgoebel.com>

* Update @typescript-eslint/eslint-plugin to the latest version 🚀 (highlightjs#2576)

* chore(package): update @typescript-eslint/eslint-plugin to version 3.0.0
* chore(package): update lockfile package-lock.json

Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Josh Goebel <me@joshgoebel.com>

* (parser) properly escape ' and " in HTML output (highlightjs#2564)

* escape quotes also in final HTML output
* [style] update test coding style
* update markup tests with new escaping

This shouldn't be a security issue -- we've always escaped double quotes inside of HTML attribute values (where they could be used to break out of context) - and we've always used double quotes for enclosing attribute values. 

This just goes all the way and now properly escapes quotes everywhere.  Better safe than sorry.

* (docs) add changelog entry for last PR

* add nnfx theme (highlightjs#2571)

* (themes) Add new lioshi theme (highlightjs#2581)

* Added Cisco Command Line to SUPPORTED_LANGUAGES.md (highlightjs#2583)

* (themes) add `nnfx-dark` theme (highlightjs#2584)

* enh(protobuf) Support multiline comments  (highlightjs#2597)

* enh(java) added support for hexadecimal floating point literals (highlightjs#2509)

- Added support for many additional types of floating point literals
- Added related tests

There still may be a few gaps, but this is a pretty large improvement.

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* (chore) Update issue templates (highlightjs#2574)

Co-authored-by: Vladimir Jimenez <allejo@me.com>

* enh(toml)(ini) Improve parsing of complex keys (highlightjs#2595)

Fixes: highlightjs#2594

* (chore) add `.js` extension to import statements (highlightjs#2601)

Adds file extensions to all import specifiers in ./src/ files.  This is useful to run the files straight from source with a web browser , Node.js ESM or Deno.

- Also add eslint rules regarding extensions for imports

* enh(dart) highlight built-in nullable types (highlightjs#2598)

* Dart: allow built-in nullable types with trailing ? to be highlighted

* enh(csharp) highlight generics in more cases (highlightjs#2599)

* (chore) fix tiny style issues, add linting npm task

- fixes tiny style issues
- adds `npm run lint` for linting the main library source
  (not languages which are still much messier)

* (chore) bump dev dependencies

* (chore) upgrade some dev stuff to newer versions

* bump v10.1.0

* (chore) bump copyright

* (chore) more import below metadata comment

Co-authored-by: M. Mert Yıldıran <mehmetmertyildiran@gmail.com>
Co-authored-by: Josh Goebel <me@joshgoebel.com>
Co-authored-by: Hugo Leblanc <dullin@hololink.org>
Co-authored-by: Peter Massey-Plantinga <plantinga.peter@gmail.com>
Co-authored-by: David Benjamin <davidben@google.com>
Co-authored-by: Vania Kucher <dev.kucher@gmail.com>
Co-authored-by: SweetPPro <sweetppro@users.noreply.github.com>
Co-authored-by: Alexandre ZANNI <16578570+noraj@users.noreply.github.com>
Co-authored-by: Taufik Nurrohman <t.nurrohman77@gmail.com>
Co-authored-by: Lin <50829219+Linhk1606@users.noreply.github.com>
Co-authored-by: nicked <nicked@gmail.com>
Co-authored-by: Nicolas Homble <nhomble@terpmail.umd.edu>
Co-authored-by: Ryandi Tjia <ryandi.tjia@me.com>
Co-authored-by: Sam Rawlins <srawlins@google.com>
Co-authored-by: Sergey Prokhorov <seriy.pr@gmail.com>
Co-authored-by: Brian Alberg <brian@alberg.org>
Co-authored-by: Nils Knappmeier <github@knappi.org>
Co-authored-by: Martin <7252614+Lhoerion@users.noreply.github.com>
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Jim Mason <jmason@ibinx.com>
Co-authored-by: lioshi <lionel.fenneteau@gmail.com>
Co-authored-by: BMatheas <65114274+BMatheas@users.noreply.github.com>
Co-authored-by: Pavel Evstigneev <pavel.evst@gmail.com>
Co-authored-by: Vladimir Jimenez <allejo@me.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: TupikovVladimir <vladimir.tupikov@devexpress.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

2 participants