Closed aldrichtr closed 2 years ago
Originally, I thought I should try to mirror the emacs parser as much as possible, but now I realize that is not the correct way to go about it. org-element.el has the buffer available to it all the time. Think of it like some function that "slurps in" the entire input to a global variable. Each parse function only needs a start and end marker and can use the buffer "object" that is already there as part of emacs. It isn't the same with a PowerShell (or any script for that matter). Something needs to process the input line by line as it is presented to the function(s).
I'm closing this issue because to implement this means "fighting" the way PowerShell works.
Mode vs Type
org-element.el uses both "mode" and "type" to control the parsing of the current text. Although very similar, the mode and the type control the parser in different ways.
Mode
When text is passed to
org-element--current-element
it can be given an optional mode. These are:If this is set, then the text is sent to a secondary parsing function, for example, 'first-section'... Although the first section is of the org class 'element' and the type is 'section', the first section needs to be treated specially. It still gets sent to
org-element-section-parser
, but the text is computed up to the 'next outline heading' first. rather than the current text.Type
In org-element, once a parser completes the input it returns a list like
(TYPE PROPS)
where TYPE is, well... the type of element, and PROPS is a plist of properties associated with the element. The list of possible element types is much larger than the narrowed list of modes, and modes can be said to be a subset of typesConvertFrom-OrgMode mode setting
Given the recursive nature of the parser, the mode needs to be set as a parameter, and when it is, modify the lex/parse functionality accordingly.