Short term plans

[jaytaph]

My idea of the short term actions would be this:

• Make sure the tokenizer can tokenize html5 input into tokens (completed, most tests passing)
• Make sure the parser can tokenize the tokens into a node-tree (in progress, some tests passing)
• Have a different system (the user-agent (UA)) that receives the node-tree in some form, and prints
  this only the screen (textmode, maybe graphical).
• Analyze the current code and see we can fix all the beginner Rust mistakes i've made.
• Get the CI tests up and running, and make sure they pass the standard tests (clippy, fmt, tests etc) (completed)
• generate a DOM tree from the given node tree (or maybe better, convert the node-tree so it can
  be used as the DOM tree.
• Optional: start with the CSS parser (relatively easy compared to the html5 parser?)

[jaytaph]

Maybe we can use github discussions instead of using the issue lists, but I think we need to do this in an organisation repo.

[jaytaph]

I've added a discussion board on the repository: https://github.com/jaytaph/gosub-browser/discussions

[emwalker]

Analyze the current code and see we can fix all the beginner Rust mistakes i've made.

A general pattern in Rust libraries and projects is to wrap / translate errors from third-party libraries into ones owned by the project. For libraries (e.g., internal code), thiserror is often used. For application code (code near fn main()), anyhow, which is convenient but less suitable for libraries, is often used.

I propose carrying out a pass through the code, looking for occurrences of unwrap(), panic!, use of errors from third party libraries and Box<dyn Error> and opportunistically replacing these things with idiomatic Rust error handling when it makes sense.

Example here.

I am not sure how the project-owned ParserError would fit into this. Perhaps it would be one among the larger set of errors to handle, as it seems focused on the actual task of parsing?

[emwalker]

I am not sure how the project-owned ParserError would fit into this.

Thinking about ParserError a little more, I had a question about whether there were too many variants in that enum. The variants should be useful for downstream code. In this case, many of those variants can perhaps be generalized into a single variant that accepts an HTML5-related code:

pub enum ParserError {
  Validation { code: String },
}

// Later
ParserError::Validation { code: "control-character-in-input-stream".to_owned() }

You'd only break out separate variants beyond this when it's convenient for match statements.