prettydiff
Question: Markup and Script/Style?
Playing around with this idea. Users of Liquid (for example) use this language in combination with JavaScript, while not something anyone recommends it's common practice. Trying to beautify Liquid and JavaScript would render the parser to fail (logically) however, if you were to exclude the Markup tags before passing the syntax to PrettyDiff this can be achieved.
See this working Flems example which simply replaces the Liquid markup tags with a string value and comments out the Liquid tags based on a simple expression. This approach fools PrettyDiff into thinking the syntax it's receiving is JavaScript and thus formatting can be applied.
Just curious, is there a more logical way to exclude Markup tags from certain lexers? Has this been explored or is there a different way one could go about this?
Edit:
Regarding the Flems example, press the "Example Code" checkbox and use the tabs to see the different states of parsing.
Markup tags embedded in script or style code isn't something that I encounter as often and so it isn't something I am supporting as well as I should. In this case its probably a defect. You could easily check for something like {% markup %} or ${ markup } but looking for {{ markup }} would be more challenging, because that looks like accepted script and style code.
I could replace all the confused code delimiters with something and then replace it back later, but before I do could you provide an example of failing code and I will see if I can parse for it properly first.
No stress on this, I was just curious and more so looking for your expertise to better guide me in achieving such a result. I am working with this code base in my spare time and as I get deeper, the language aware aspect of this project becomes more prevalent in all areas. It's very interesting.
It would indeed by a unique feature to implement. From a logical standpoint the use cases would be minimal for infused markup and script or style code, this is much more Liquid related than other markup languages.
If this is something you do explore deeper, for the parser to recognize markup tags contained in script and/or style code maybe an option set within the API would be the way to go.