Glad to see you've tackled this... I had a similar nested-token-styling issue in a different project that relies on RSH, and hadn't yet attempted a solution. I'll take a look as soon as I can.

Great, thanks!

Since I've worked a bunch on PrismJS/prism-themes#103 recently, I guess there is a weakness in this approach:

It doesn't cover the case of features requiring descendant combinator CSS (the space), such as .token.imports .token.maybe-class-name or .token.atrule .token.rule:

PrismJS/prism#2533

Edit: this is because these nested elements do not yet exist in react-syntax-highlighter (see #305 (comment))

Ah I guess there's a DOM element missing on the react-syntax-highlighter side for this:

prism (from https://prismjs.com/test.html#language=css)

react-syntax-highlighter (from https://react-syntax-highlighter.github.io/react-syntax-highlighter/demo/prism.html)

refractor

refractor does already return this structure from refractor.highlight (demo: https://runkit.com/embed/mfigg7b3rcb5):

Code

@media (max-width: 800px) {
width: 400px;
}

@simmerer if I can ask, is there a requirement by react-syntax-highlighter to NOT include this extra DOM element for whatever reason?

Because otherwise, I could also take a look at adding in these extra containers...

@karlhorky Not that I know of. @conorhastings is the original creator of this package (I just stepped in to assist), so he might have an opinion.

In my understanding, Prism (or Highlight) themes should work the same in react-syntax-highlighter as if you were using Prism (or Highlight) directly, which means the DOM should provide all of the expected structure. If refractor provides those elements, we probably should as well.

We'd be super grateful for your help on this!

Ok sounds good. I'll take a look at this over the next days, see if I can figure out why that DOM structure is not being reproduced, and try my hand at fixing it.

It looks like the flattening behavior comes from a flattenCodeTree function written in 2017 by @conorhastings - #64

It was originally introduced to avoid some undesirable wrapping behavior (see #63).

I guess the problems / difficulties are caused because of code like this:

@media (



max-width: 800px) {
width: 400px;
}

This is the structure that comes out of this (see example: https://runkit.com/karlhorky/5f4a5c661cb06e001acdff31):

This makes it potentially complicated to work around these issues (see wooorm/refractor#3). That's why #46 is somewhat complicated.

Maybe we can work around the wrapping problems differently.

Does the wrapLines option actually work? Can't find an example where it actually wraps to the container width properly.

Oh I guess wrapLines does not mean what I (and others) think it does.

Looking at the original issue that motivated this change #44, it's about wrapping each line in a container element, not wrapping when the code size exceeds the width.

Maybe the option name should be changed to something less ambiguous...

Ok @simmerer I gave it another shot, this time styling all permutations and array subsets (power sets) of the classnames on a node.

It avoids having to rework the DOM structure (which is that way for a reason), and should be pretty performant (usually adds up to only a few milliseconds to style a whole document).

Let me know what you think, and if it's acceptable, we can try to land this (I suppose we'll need tests? or to adapt existing ones?)

Oh actually, wait - why am I trying to do this in an algorithmic way (such as my solution or this Stack Overflow answer) when it can just be declarative?

I don't think the number of class names will be greater than 3. Even with 4, adding all combinations would still be faster.

This is way better and more performant:

- function recursivePermute(arr, permutation = []) {
-   return arr.length === 0
-     ? [permutation]
-     : arr.flatMap((item, i, arr) =>
-         recursivePermute(
-           arr.filter((_, j) => j !== i),
-           [...permutation, item]
-         )
-       );
- }
- 
- const permutations = {};
- function permute(arr) {
-   const key = arr.join(".");
-   if (!permutations[key]) {
-     permutations[key] = recursivePermute(arr);
-   }
-   return permutations[key];
- }
- 
- function getSubArrays(arr) {
-   if (arr.length === 1) return [arr];
-   else {
-     const subarr = getSubArrays(arr.slice(1));
-     return subarr.concat(
-       subarr.map((el) => el.concat(arr[0])),
-       [[arr[0]]]
-     );
-   }
- }
+ // Get all possible permutations of all power sets
+ //
+ // Super simple, non-algorithmic solution since the
+ // number of class names will not be greater than 3
+ function powerSetPermutations(arr) {
+   if (arr.length === 0) return [];
+   if (arr.length === 1) return arr;
+   if (arr.length === 2) {
+     return [
+       arr[0],
+       arr[1],
+       `${arr[0]}.${arr[1]}`,
+       `${arr[1]}.${arr[0]}`,
+     ]
+   }
+   if (arr.length >= 3) {
+     // Currently does not support more than 3 class names
+     return [
+       arr[0],
+       arr[1],
+       arr[2],
+       `${arr[0]}.${arr[1]}`,
+       `${arr[0]}.${arr[2]}`,
+       `${arr[1]}.${arr[0]}`,
+       `${arr[1]}.${arr[2]}`,
+       `${arr[2]}.${arr[0]}`,
+       `${arr[2]}.${arr[1]}`,
+       `${arr[0]}.${arr[1]}.${arr[2]}`,
+       `${arr[0]}.${arr[2]}.${arr[1]}`,
+       `${arr[1]}.${arr[0]}.${arr[2]}`,
+       `${arr[1]}.${arr[2]}.${arr[0]}`,
+       `${arr[2]}.${arr[0]}.${arr[1]}`,
+       `${arr[2]}.${arr[1]}.${arr[0]}`,
+     ]
+   }
+ }

const classNameCombinations = {};
function getClassNameCombinations(classNames) {
  if (classNames.length === 0) return [];
  if (classNames.length === 1) return classNames;
  const key = classNames.join(".");
  if (!classNameCombinations[key]) {
-     classNameCombinations[key] = getSubArrays(classNames)
-       .flatMap((classNames) => classNames.length > 1 ? permute(classNames) : [classNames])
-       // Less specific (fewer class names) to more specific (more class names)
-       .sort((a, b) => (a.length < b.length ? -1 : 1))
-       .map((arr) => arr.join("."));
+     classNameCombinations[key] = powerSetPermutations(classNames);
  }
  return classNameCombinations[key];
}

Ok, this is looking much cleaner now.

One breaking change that this will require is that class names in the styles no longer have the spaces that they currently have. I have noted this above in the description.

Alright I've also fixed the build script now, seems to be working. I've marked this as a breaking change (mentioned in the description why).

Ok, I've also ran the tests and found some other incompatibilities that I've now fixed.

The only 2 tests that are failing also fail on the master branch:

So this PR should be ready to go!

cc @simmerer

Great work here @karlhorky. I should be able to take a look tomorrow... thanks for your patience.

In regards to wrapLines, I've got a PR here which introduces a wrapLongLines prop that does what everyone thought wrapLines did. Would love your thoughts on that: #309

Cool! Wrote a few comments. Not sure about the overall approach and if there aren't any edge cases with using pre-wrap, but seems like it could be legit!

@simmerer I guess you haven't had a chance to take a look at this one yet, right? Any estimate on when you'll be able to take a look?

Thanks for the merge @simmerer!

Super exciting that this is out now in 15.0.1 (sorry for missing the fixes on the demo themes)!

I'll give this a shot soon!

No worries. npm publish (which runs npm run build) is still frequently the point at which I realize I haven't run npm run build to update the demos. :)

Ah, @simmerer would it be possible to update to the latest prism-themes@1.4.1 version too? (similar to your commit 7e26d31 ?)

I did a pull request to improve the accuracy of the VS Code Dark theme: PrismJS/prism-themes#103 (comment)

If you want, I can also open a new issue for this.

I'll have a PR up shortly!

🎉 Released in 15.1.0: https://github.com/react-syntax-highlighter/react-syntax-highlighter/releases/tag/v15.1.0

Awesome, thanks for that!