{"action":"created","issue":{"url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser/issues/9","repository_url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser","labels_url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser/issues/9/labels{/name}","comments_url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser/issues/9/comments","events_url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser/issues/9/events","html_url":"https://github.com/Mogztter/asciidoctor-inline-parser/issues/9","id":384000184,"node_id":"MDU6SXNzdWUzODQwMDAxODQ=","number":9,"title":"From prototype to core","user":{"login":"mojavelinux","id":79351,"node_id":"MDQ6VXNlcjc5MzUx","avatar_url":"https://avatars2.githubusercontent.com/u/79351?v=4","gravatar_id":"","url":"https://api.github.com/users/mojavelinux","html_url":"https://github.com/mojavelinux","followers_url":"https://api.github.com/users/mojavelinux/followers","following_url":"https://api.github.com/users/mojavelinux/following{/other_user}","gists_url":"https://api.github.com/users/mojavelinux/gists{/gist_id}","starred_url":"https://api.github.com/users/mojavelinux/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mojavelinux/subscriptions","organizations_url":"https://api.github.com/users/mojavelinux/orgs","repos_url":"https://api.github.com/users/mojavelinux/repos","events_url":"https://api.github.com/users/mojavelinux/events{/privacy}","received_events_url":"https://api.github.com/users/mojavelinux/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-11-24T15:56:07Z","updated_at":"2018-11-24T19:46:16Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"This issue hosts the planning discussion for how take the current code from a prototype state to the point its ready to use in core. Once we've established a plan of action and created the issues to track the individual tasks, this issue can be closed.\r\n\r\nFirst, let's remind ourselves why we're doing this. The existing regex-based parser uses multiple passes over the same source text while performing conversion at the same time. That means it operates on a hybrid of source and output text. It's also blind to context, so it ends up processing the same text multiple times, which makes escaping nearly impossible to get right.\r\n\r\nThere are two cases in particular we really want to solve:\r\n\r\n1. Be able to parse an inline passthrough without having to extract the text. This is just a matter of terminating the recursion when a passthrough is found.\r\n2. Be able to parse a link macro without risk of substitutions being applied to the target URL. This is similar to the passthrough in that the recursion just needs to be terminated.\r\n\r\nAt a high level, here are some of the goals we want to meet:\r\n\r\n* Parse the inline source into an AST so each run of text (character sequence) is represented by a node.\r\n  * This includes contiguous unformatted text, which should be represented by a text node like in the HTML DOM.\r\n  * We may need a \"clean tree\" step that combines adjacent text nodes together\r\n* It should be possible to adapt the node structure so existing converters can be reused. This may mean presenting objects to the converter that emulate the Inline object from core (duck typing).\r\n* Be able to parse most of the syntax the existing processor allows. There are going to be edge cases. We just need to keep track of what those are and make the best decision we can make about how to handle it.\r\n\r\nIt's very likely we're going to have to take a hybrid approach to parsing. The idea is to use the treetop parser/grammar as a tool. It does not mean the parser has to grab everything in one shot. If we have to call it recursively, we can do that."},"comment":{"url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser/issues/comments/441391265","html_url":"https://github.com/Mogztter/asciidoctor-inline-parser/issues/9#issuecomment-441391265","issue_url":"https://api.github.com/repos/Mogztter/asciidoctor-inline-parser/issues/9","id":441391265,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MTM5MTI2NQ==","user":{"login":"mojavelinux","id":79351,"node_id":"MDQ6VXNlcjc5MzUx","avatar_url":"https://avatars2.githubusercontent.com/u/79351?v=4","gravatar_id":"","url":"https://api.github.com/users/mojavelinux","html_url":"https://github.com/mojavelinux","followers_url":"https://api.github.com/users/mojavelinux/followers","following_url":"https://api.github.com/users/mojavelinux/following{/other_user}","gists_url":"https://api.github.com/users/mojavelinux/gists{/gist_id}","starred_url":"https://api.github.com/users/mojavelinux/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mojavelinux/subscriptions","organizations_url":"https://api.github.com/users/mojavelinux/orgs","repos_url":"https://api.github.com/users/mojavelinux/repos","events_url":"https://api.github.com/users/mojavelinux/events{/privacy}","received_events_url":"https://api.github.com/users/mojavelinux/received_events","type":"User","site_admin":false},"created_at":"2018-11-24T19:46:16Z","updated_at":"2018-11-24T19:46:16Z","author_association":"CONTRIBUTOR","body":"As I thought more about it, I realized that the recursive grammar would quickly get too complicated to reason about, at least for me right now. The treetop parser is greedy by default, so we'd end up needing extremely complex negation rules to prevent the parser from matching too much.\r\n\r\nBut it goes deeper than that. In many cases, the AsciiDoc syntax isn't recursive. Consider the following source:\r\n\r\n```\r\n**one **two** three**\r\n```\r\n\r\nIf we parsed recursively, we'd end up with:\r\n\r\n```\r\n<strong>one <strong>two</strong> three</strong>\r\n```\r\n\r\nHowever, that would not be AsciiDoc compliant. Instead, it should be:\r\n\r\n```\r\n<strong>one </strong>two<strong> three</strong>\r\n```\r\n\r\nAdmittedly, the first interpretation seems more correct. But the goal here isn't to change the AsciiDoc syntax rules (even if we really want to).\r\n\r\nTherefore, it's probably best to stick with the flat parser grammar, then recurse into those nodes as necessary. It feels less sophisticated, but ultimately will be easier to manage.\r\n\r\nWe might still use recursion in the grammar in some places, but it would be places where it is obvious. One example might be in the attribute list of a macro, which is more like an XML tag."}}
{"actor":{"display_login":"mojavelinux"}}