Read sxhkdrc formatting config from file comments

[Hoboneer]

Without this, one would have to set up a way to include the parser arguments with every call if parsing sections or metadata from the config is wanted.

[Hoboneer]

These directives must be placed before any section headers or metadata comments are made--which also means before any keybinds are defined.

They should correspond to the global "section config" and "metadata config" options available for each bundled cli tool, and be key-value pairs in the form Key: Value (with whitespace between the : and Value stripped). Maybe they should be uniform such that they are prefixed by their type, e.g., --description under "metadata config" should be Metadata-Description. For more uniformity, perhaps the canonical option names for each config option should be prefixed by their type, so --description would canonically be --metadata-description.

Should there be delimiters for these directives? Order shouldn't matter.

# ...non- directive/section-header comments
#? Begin-Parser-Config
#? Metadata-Type: ...
#? Section-Type: ...
# ...more non- directive/section-header comments
#? Section-Header: ...(some regex)
# ...
#? End-Parser-Config
(begin sections and keybinds)

When the End-Parser-Config directive is seen, the relevant classes are instantiated.

[Hoboneer]

In the case where the section handler and/or metadata parser are determined from directives in the file, they cannot be accessed by the caller. This should be available, perhaps as a ConfigReader class, in which those instances can be accessed as attributes.

ConfigReader

Constructor: same signature as util.read_sxhkdrc

ConfigReader(file: Union[str, os.PathLike[str], TextIO], section_handler: Optional[SectionHandler], metadata_parser: Optional[MetadataParser]) (excluding hotkey_errors, as I now think it's a bad idea for hotkeys to include those checks in its constructor--so it should be removed).

None values for section_handler or metadata_parser should mean that the value should be taken from the directives ("auto"). That is, arguments to the constructor take precedence over the in-file directives.

Attributes

• section_handler (in an undefined state before the config is fully read)
• metadata_parser (in an undefined state before the config is fully read)
• filename (optional str)
• ~options (dict of str->str): options used to generate section handler and metadata parser (merged form of cli and in-file parsing directives)~ (this could and should be made outside of this code: just use the TYPENAME and OPTIONS classvars)

Usage

It should be iterable. Upon iteration end, section_handler and metadata_parser should have non-None values: if None was passed in to the constructor for section_handler or metadata_parser, it should be a RootSectionHandler with all keybinds added as keybind children or NullMetadataParser, respectively.

[Hoboneer]

A big cause of complexity is that the sxhkdrc reading code only reads each line of the config once. Maybe this can be done away with to massively simplify the code by using two passes: (1) directive pass, (2) section and keybind reading pass.

However, this reduces the utility of feeding in a stream for input since all the data must be read into memory before anything useful happens (although the directive pass could process the input as it comes in). A memory-usage argument doesn't really apply as another point against this potential change because, by iteration end, the SectionHandler instance will have every single keybind as a child somewhere in its tree of SectionTreeNodes.

Could we reasonably expect that the input to this library won't be enormous?

[Hoboneer]

Since this introduces directives into the syntax (albeit only in comments), this should wait until a unified approach to directives is hashed out. I don't want them to be adhoc.