{"action":"created","issue":{"url":"https://api.github.com/repos/Unibeautify/unibeautify/issues/9","repository_url":"https://api.github.com/repos/Unibeautify/unibeautify","labels_url":"https://api.github.com/repos/Unibeautify/unibeautify/issues/9/labels{/name}","comments_url":"https://api.github.com/repos/Unibeautify/unibeautify/issues/9/comments","events_url":"https://api.github.com/repos/Unibeautify/unibeautify/issues/9/events","html_url":"https://github.com/Unibeautify/unibeautify/issues/9","id":233026715,"number":9,"title":"Parsing framework ","user":{"login":"bitwiseman","id":1958953,"avatar_url":"https://avatars3.githubusercontent.com/u/1958953?v=4","gravatar_id":"","url":"https://api.github.com/users/bitwiseman","html_url":"https://github.com/bitwiseman","followers_url":"https://api.github.com/users/bitwiseman/followers","following_url":"https://api.github.com/users/bitwiseman/following{/other_user}","gists_url":"https://api.github.com/users/bitwiseman/gists{/gist_id}","starred_url":"https://api.github.com/users/bitwiseman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bitwiseman/subscriptions","organizations_url":"https://api.github.com/users/bitwiseman/orgs","repos_url":"https://api.github.com/users/bitwiseman/repos","events_url":"https://api.github.com/users/bitwiseman/events{/privacy}","received_events_url":"https://api.github.com/users/bitwiseman/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2017-06-01T22:18:50Z","updated_at":"2017-08-12T15:07:40Z","closed_at":null,"body":"@Glavin001 \r\n\r\n@prettydiff - I'm interested in separating parsers from formatting rules (what we often call \"beautifiers\"), but at a more basic level I'd like to see a parsing framework that produces unified lossless parsed source trees. \r\n\r\nMost parsers are optimized for speed, accuracy, and producing _abstract_ syntax trees.  This means they have source that is hard to read (because it does obtuse things to make it faster), they throw errors and halt on unknown syntax, and they discard whitespace and comments.  All of these are bad beautifiers.     \r\n\r\nParsers also do not interconnect or communicate - I can parse html and then parse the javascript inside the `<script>` tags, but the resulting parsed javascript tree is completely separate from the html tree.  I could beautify each separately, but they can't interact.  When we go to templating (mustache, php, braces for example), this gets really ugly.  What we want is a framework of parsers that produce one syntax tree (or at very least one token stream with trees that can interact). \r\n\r\n"},"comment":{"url":"https://api.github.com/repos/Unibeautify/unibeautify/issues/comments/321986963","html_url":"https://github.com/Unibeautify/unibeautify/issues/9#issuecomment-321986963","issue_url":"https://api.github.com/repos/Unibeautify/unibeautify/issues/9","id":321986963,"user":{"login":"prettydiff","id":524902,"avatar_url":"https://avatars0.githubusercontent.com/u/524902?v=4","gravatar_id":"","url":"https://api.github.com/users/prettydiff","html_url":"https://github.com/prettydiff","followers_url":"https://api.github.com/users/prettydiff/followers","following_url":"https://api.github.com/users/prettydiff/following{/other_user}","gists_url":"https://api.github.com/users/prettydiff/gists{/gist_id}","starred_url":"https://api.github.com/users/prettydiff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/prettydiff/subscriptions","organizations_url":"https://api.github.com/users/prettydiff/orgs","repos_url":"https://api.github.com/users/prettydiff/repos","events_url":"https://api.github.com/users/prettydiff/events{/privacy}","received_events_url":"https://api.github.com/users/prettydiff/received_events","type":"User","site_admin":false},"created_at":"2017-08-12T15:07:40Z","updated_at":"2017-08-12T15:07:40Z","body":"Update - https://github.com/Unibeautify/parse-framework/tree/tests\r\n\r\n## Good stuff\r\n* Framework is complete and documented\r\n* In refactoring the code I have found what made the JavaScript parser slow.  Now it is tied with the latest version of Esprima for speed making it tied for being the fastest JavaScript parser written in JavaScript (on my Windows box).\r\n\r\n## Bad stuff\r\n* Still not ready.  I am still occasionally finding things to fix.\r\n* I am putting together unit tests right now.... this is excruciatingly painful.  In Pretty Diff the unit tests output beautified code which is easy to scan and read, but the parse framework outputs a parse table with additional data.  I need to find a way to speed this up or provide some additional automation to validate the parse tables generated from code samples is accurate as this is taking too long.\r\n\r\n## Plans (in this order after unit tests are populated)\r\n* Provide lexer specific documentation\r\n* Convert `var` to `let` and `const`\r\n* Convert the code to TypeScript\r\n* Bring in a markdown lexer.  I wrote a markdown parser for biddle (so half this work is already done)\r\n* Add reporting of parse errors and strong error reporting"}}
{"actor":{"display_login":"prettydiff"}}