Create a Private Helper for Inline Parsing

Mục tiêu: Define a new private Rust function, parse\_inline\_elements, as a placeholder to handle inline Markdown syntax. This sets up the architecture for parsing elements like bold and italics.

Fantastic work on building your block-level parser! Your parse function in src/parser.rs is now a capable engine that correctly identifies and transforms entire lines of text into their corresponding HTML block tags (<h1>, <h2>, ). This is a huge accomplishment. You’ve taught your program to see the “big picture” structure of a Markdown document.

Now, we’re going to teach it to see the details. Markdown’s power comes from its ability to format text within a line—making text bold or italicized. This is known as inline formatting, as opposed to the block formatting (headings, paragraphs) you’ve already mastered.

The Need for a New Layer of Parsing

Consider how you currently handle a paragraph: let p_tag = format!("{}\\n", line);

This takes the entire line and places it directly inside the  tags. If the line is This is **important** text., the resulting HTML will be This is **important** text., which a browser will not render as bold.

To solve this, we need to process the content of each line before wrapping it in its block-level tag. This suggests a new architectural layer: a dedicated function whose sole responsibility is to handle inline-level syntax. Creating a separate function for this task is a classic example of the separation of concerns principle in software design. Your main parse loop will continue to identify the block type (Is this a heading or a paragraph?), and this new helper function will handle the details within that block.

Creating a Private Helper Function

We will create a new function called parse_inline_elements inside src/parser.rs. This function will be an internal implementation detail of our parser module. The outside world (i.e., main.rs) doesn’t need to know about it; it only needs to call the main parser::parse function. Therefore, we will make this new function private by omitting the pub keyword. In Rust, items are private by default, which is a powerful feature for encapsulation, as it prevents other parts of your code from depending on internal details that might change.

Let’s define the function’s signature and create a placeholder implementation for now.

Add the following new function to your src/parser.rs file. A good place for it is right above your existing pub fn parse(...) function.

// src/parser.rs

/// Parses a line of Markdown for inline elements like bold and italics.
///
/// This is a private helper function, indicated by the lack of the `pub` keyword.
/// It is only meant to be used within the `parser` module.
///
/// # Arguments
/// * `line` - A borrowed string slice (`&str`) representing the raw content of a line.
///
/// # Returns
/// An owned `String` with inline Markdown syntax converted to HTML tags.
fn parse_inline_elements(line: &str) -> String {
    // For now, this is a placeholder. It simply converts the borrowed &str
    // into an owned String, without any changes.
    // In subsequent tasks, we will add the logic here to find and replace
    // syntax like `**text**` with `<strong>text</strong>`.
    line.to_string()
}

// Your existing pub fn parse(...) function follows below
pub fn parse(markdown_input: &str) -> String {
    // ... existing function body ...
}

Deconstructing the New Function

Let’s analyze the function you just created in detail:

fn parse_inline_elements(...): By not putting pub in front of fn, we are making this function private to the parser module. It can be called by parse (which is in the same module), but it cannot be called from main.rs using parser::parse_inline_elements(...). This is excellent practice for hiding implementation details.
Input: line: &str: The function takes a borrowed string slice. This is highly efficient. When we eventually call this function with the content of a heading or a paragraph, we will be “lending” it the text to read. The function doesn’t need to own the data, just inspect it, making &str the perfect choice.
Output: -> String: The function promises to return an owned String. This is crucial because this function’s job is to create new data. It will take an input like This is **important** and transform it into a new string, This is important. This new, modified string needs its own memory, which is what the String type provides.
Implementation: line.to_string(): This is our placeholder logic. The .to_string() method is called on the &str to create a new, owned String with the exact same content. This fulfills the function’s contract (-> String) and allows us to set up the architecture correctly before we add the more complex replacement logic in the next tasks.

You have now successfully created the structural foundation for handling inline elements. You’ve defined a clear, encapsulated boundary for this new responsibility, keeping your overall parser design clean and modular.

Next Steps

With the parse_inline_elements function now defined, the next logical step is to integrate it into your main parse function’s loop. You will modify the logic for headings and paragraphs to call this new helper function on their content before wrapping them in HTML tags.

Integrate Inline Parsing Helper Function

Mục tiêu: Modify the main parse function to call the parse\_inline\_elements helper function. This involves delegating the processing of raw content from headings and paragraphs to the new helper before wrapping it in HTML tags.

Excellent! You’ve successfully established the architectural foundation for handling inline elements by creating the private parse_inline_elements helper function. This is a critical step in separating the concerns of your parser. You’ve created a specialist function; now it’s time to put it to work by integrating it into your main parsing pipeline.

Connecting the Layers: The Power of Function Composition

Your main parse function is currently an expert at identifying block-level elements (headings and paragraphs). Your new parse_inline_elements function is destined to become an expert at handling inline details (bold, italics, etc.). The goal now is to make these two experts collaborate.

The process will look like this:

The parse function’s loop will identify a line’s block type, for example, an <h2> heading.
It will strip the Markdown syntax (##) to get the raw content (e.g., My **Important** Heading).
Instead of immediately wrapping this raw content in <h2> tags, it will first delegate the work of processing it to your new specialist function, parse_inline_elements.
parse_inline_elements will do its job (for now, just return the content as-is) and hand back the processed content.
Finally, the parse function will take this processed content and wrap it in the correct block-level HTML tags.

This pattern of one function calling another to progressively transform data is a fundamental concept in software development called function composition. It leads to cleaner, more modular, and easier-to-test code.

Let’s modify the parse function in src/parser.rs to call our new helper.

// src/parser.rs

/// Parses a line of Markdown for inline elements like bold and italics.
// ... (this function remains the same)
fn parse_inline_elements(line: &str) -> String {
    line.to_string()
}

/// Parses a Markdown string and converts it to an HTML string.
pub fn parse(markdown_input: &str) -> String {
    let mut html_output = String::new();
    let lines = markdown_input.lines();

    for line in lines {
        if line.starts_with("## ") {
            // First, get the raw content of the heading, just like before.
            let raw_content = line.strip_prefix("## ").unwrap();
            // NEW: Delegate the processing of the line's content to our helper function.
            let processed_content = parse_inline_elements(raw_content);
            // Finally, use the *processed* content to build the HTML tag.
            let h2_tag = format!("<h2>{}</h2>\n", processed_content);
            html_output.push_str(&h2_tag);
        } else if line.starts_with("# ") {
            // Do the same for H1 headings.
            let raw_content = line.strip_prefix("# ").unwrap();
            // NEW: Delegate to the helper function.
            let processed_content = parse_inline_elements(raw_content);
            // Use the processed result.
            let h1_tag = format!("<h1>{}</h1>\n", processed_content);
            html_output.push_str(&h1_tag);
        } else {
            // And do the same for paragraphs.
            if !line.is_empty() {
                // For a paragraph, the entire line is the raw content.
                // NEW: Delegate to the helper function.
                let processed_content = parse_inline_elements(line);
                // Use the processed result.
                let p_tag = format!("<p>{}</p>\n", processed_content);
                html_output.push_str(&p_tag);
            }
        }
    }

    html_output
}

Deconstructing the New Data Flow

The changes you’ve made are subtle but architecturally profound. Let’s trace the journey of a single line, ## This is **bold**, through your updated parse function:

if line.starts_with("## "): The condition is true.
let raw_content = line.strip_prefix("## ").unwrap();: The raw_content variable is bound to the string slice &str containing "This is **bold**".
let processed_content = parse_inline_elements(raw_content);: This is the new, crucial step.
- The raw_content slice is lent (or borrowed by) the parse_inline_elements function.
- Inside parse_inline_elements, line.to_string() creates a new, owned String with the same content.
- This new String is returned and its ownership is transferred to the processed_content variable.
let h2_tag = format!("<h2>{}</h2>\n", processed_content);: The format! macro now uses the processed_content string to build the final HTML.
html_output.push_str(&h2_tag);: The generated HTML is appended to our accumulator.

You have successfully inserted a new processing stage into your pipeline. The parse function is now responsible for identifying blocks, while parse_inline_elements is responsible for processing the content within those blocks.

Verifying the Architectural Change

It’s important to note what happens if you run your program now. Since parse_inline_elements is still a placeholder that just returns its input, the final output.html file will look exactly the same as it did before. This is expected! The change you just made was purely structural. You’ve re-wired your parser’s internal plumbing to prepare it for the new features you’re about to add.

Next Steps

The stage is now perfectly set. Your main parse loop is correctly delegating the content of each line to your new helper function. The next task is to begin adding real intelligence to parse_inline_elements by implementing the logic to find and replace the first inline syntax: **text** for bold.

Implement Bold Text Parsing in Rust Markdown Converter

Mục tiêu: Update the parse\_inline\_elements function to handle bold text. This involves using Rust’s split and enumerate methods to find and convert Markdown’s \*\*text\*\* syntax into HTML’s **text** tags.

You’ve done an excellent job setting up the architecture for inline parsing. By creating the private parse_inline_elements function and wiring it into your main parse loop, you’ve successfully separated the concern of identifying block elements from the concern of styling the text within them. Your main parse function is the “foreman” identifying the job site (a heading, a paragraph), and parse_inline_elements is the specialist you’ve just hired to do the detailed work.

It’s time to give that specialist its first tool. We will now add the logic to find and convert bold text, transforming Markdown’s **text** into HTML’s text.

A New Challenge: Parsing Within a Line

Previously, our parsing was simple: we only needed to check the very beginning of a line with .starts_with(). Inline parsing is more complex because the syntax can appear anywhere. Our goal is to transform a string like A line with **bold** text. into A line with bold text..

A simple search-and-replace won’t work well, as we need to replace the first ** with  and the second ** with . A much more robust and elegant approach in Rust is to use the .split() method, which allows us to break the string into pieces using the ** delimiter and then reassemble them correctly.

Implementing the Bold Parser with `.split()`

Let’s update our placeholder function in src/parser.rs with the logic to handle bold text. We will use the accumulator pattern again, but this time, the pieces we accumulate will be segments of the line, some of which will be wrapped in HTML tags.

The key insight is this: when you split a string like "some **bold** text" by the delimiter **, you get an iterator that yields ["some ", "bold", " text"]. Notice that the text that was inside the asterisks is at the odd-numbered index (index 1). This pattern holds true for multiple occurrences as well. We can leverage this with the .enumerate() iterator method to check the index of each segment.

Here are the changes for src/parser.rs. We are only modifying the parse_inline_elements function.

// src/parser.rs

/// Parses a line of Markdown for inline elements like bold and italics.
// ... (documentation comments remain the same)
fn parse_inline_elements(line: &str) -> String {
    // We'll build our new string with inline elements parsed into this variable.
    // Using `with_capacity` is a small optimization; we know the final string will
    // be at least as long as the original line, so we can pre-allocate memory.
    let mut processed_line = String::with_capacity(line.len());

    // The `split` method breaks a string slice into an iterator of subslices
    // based on a delimiter. In our case, the delimiter is "**".
    // "some **bold** text" becomes an iterator yielding ["some ", "bold", " text"].
    // We use `.enumerate()` to get both the index (0, 1, 2, ...) and the segment.
    for (index, segment) in line.split("**").enumerate() {
        // Segments at even indices (0, 2, 4...) are the text *outside* the bold markers.
        // Segments at odd indices (1, 3, 5...) are the text *inside* the bold markers.
        if index % 2 == 1 {
            // This segment was inside `**...**`, so we wrap it in `<strong>` tags.
            // We only do this if the segment is not empty, to avoid producing `<strong></strong>`
            // for syntax like `****`.
            if !segment.is_empty() {
                processed_line.push_str("<strong>");
                processed_line.push_str(segment);
                processed_line.push_str("</strong>");
            }
        } else {
            // This segment was outside any bold markers, so we append it as-is.
            processed_line.push_str(segment);
        }
    }

    // Return the newly constructed string with HTML tags.
    processed_line
}

/// Parses a Markdown string and converts it to an HTML string.
// The `parse` function below this remains completely unchanged.
pub fn parse(markdown_input: &str) -> String {
// ...

Deconstructing the New Logic

Let’s walk through the new implementation in parse_inline_elements step-by-step.

line.split("**"): This is the core of our strategy. It returns a lazy iterator that yields string slices (&str) of the parts of line that were separated by **. This is very efficient as it doesn’t create a new collection in memory.
.enumerate(): This is an “iterator adaptor.” It wraps our split iterator and changes what it produces. Instead of just yielding each segment ("some ", "bold", etc.), it yields a tuple containing the index and the segment: (0, "some "), (1, "bold"), and so on. This gives us the context we need to decide how to treat each piece.
if index % 2 == 1: This is our condition to identify the text that needs to be made bold.
- The modulo operator (%) gives the remainder of a division.
- index % 2 will be 0 for even numbers and 1 for odd numbers.
- As we observed, the text that was originally between the ** delimiters will always end up at an odd-numbered index in the sequence produced by split.
processed_line.push_str(...): Inside the if/else block, we reassemble the line. If the segment was inside the asterisks, we wrap it with  and  before appending. Otherwise, we append it directly.

This approach gracefully handles multiple bold sections on a single line. A line like **First** and **Second** will be split into ["", "First", " and ", "Second", ""], and the logic will correctly wrap “First” and “Second” while leaving the other parts as they are.

Verify Your Work

Now you can test your enhanced parser. Modify your sample.md to include some bold text within your existing headings and paragraphs.

# My **Awesome** Document
## A Section Heading

This is a paragraph of text. It's **very** exciting!

Run your converter again: cargo run -- sample.md output.html

Open the new output.html. Thanks to the changes you just made, the output will now be:

<h1>My <strong>Awesome</strong> Document</h1>
<h2>A Section Heading</h2>
<p>This is a paragraph of text. It's <strong>very</strong> exciting!</p>

Open this HTML file in a web browser, and you will see the bold text rendered correctly.

Next Steps

You’ve successfully implemented your first inline parsing rule! The logic you’ve used for bold text can be adapted very easily for other similar inline elements. In the next task, you will add another layer to your parse_inline_elements function to handle italics, which are denoted by a single asterisk (*text*).

Extend Markdown Parser to Handle Italic Text

Mục tiêu: Modify a Rust function to parse Markdown’s italic syntax (*text*) by implementing a layered processing approach. This involves parsing for bold text first, and then parsing the result for italics to correctly handle mixed formatting.

You have brilliantly implemented the logic for bold text! Your parse_inline_elements function is now a specialist that can find and replace **...** syntax using the clever split and enumerate pattern. This is a solid foundation for handling all sorts of inline formatting.

Building directly on that success, we will now empower your specialist function with a new tool: the ability to parse italics, which are denoted in Markdown with a single asterisk: *text*.

A Layered Approach to Inline Parsing

The logic for handling italics is almost identical to the logic for bold. However, we must consider how to handle a line that contains both bold and italic text, such as This is **bold** and *italic* text.. A naive approach might lead to conflicts.

The most robust and extensible solution is to adopt a layered or sequential processing approach. Instead of trying to parse everything at once, we’ll perform a series of transformations, one for each type of syntax:

First, we’ll take the raw input line and parse it only for bold text, producing an intermediate string.
Then, we’ll take that intermediate string (which now contains  tags) and parse it only for italic text.
The result of this second pass will be our final, fully processed string.

This approach is powerful because it’s composable. As we add more rules (like links or code snippets), we can simply add more layers to our processing pipeline, keeping each step simple and focused on a single task.

Let’s modify our parse_inline_elements function in src/parser.rs to implement this layered strategy.

// src/parser.rs

fn parse_inline_elements(line: &str) -> String {
    // --- BOLD PARSING (First Layer) ---
    // First, we process the line for bold elements, just like we did before.
    // The result is stored in an intermediate `String`.
    let mut bold_processed = String::with_capacity(line.len());
    for (index, segment) in line.split("**").enumerate() {
        if index % 2 == 1 {
            if !segment.is_empty() {
                bold_processed.push_str("<strong>");
                bold_processed.push_str(segment);
                bold_processed.push_str("</strong>");
            }
        } else {
            bold_processed.push_str(segment);
        }
    }

    // --- NEW: ITALIC PARSING (Second Layer) ---
    // Now, we create a new accumulator for our final result.
    let mut italic_processed = String::with_capacity(bold_processed.len());

    // We run the exact same logic, but this time we split the `bold_processed`
    // string by the single asterisk `*` for italics.
    for (index, segment) in bold_processed.split('*').enumerate() {
        // The logic is identical: odd-indexed segments were inside the asterisks.
        if index % 2 == 1 {
            if !segment.is_empty() {
                // We wrap the segment in `<em>` (emphasis) tags, the correct
                // semantic tag for Markdown italics.
                italic_processed.push_str("<em>");
                italic_processed.push_str(segment);
                italic_processed.push_str("</em>");
            }
        } else {
            // Even-indexed segments are appended as-is.
            italic_processed.push_str(segment);
        }
    }

    // Return the final result after all layers of processing are complete.
    italic_processed
}

Deconstructing the Layered Logic

The core of the split and enumerate logic for italics is identical to what you just mastered for bold text. The truly important concept here is the new two-step structure:

First Pass (Bold): The first for loop operates on the original line and produces bold_processed. If the input line was A **bold** and *italic* line., then after this first pass, bold_processed would contain the string A bold and *italic* line..
Second Pass (Italics): The second for loop does not operate on the original line. Crucially, it operates on the result of the first pass, bold_processed. It takes A bold and *italic* line. and splits it by *, producing the final correct result: A bold and italic line..

This ensures that the parsing of one element type doesn’t interfere with another. You have successfully composed two simple parsing operations to create a more powerful and sophisticated parser.

Verify Your Work

It’s time to see your enhanced parser in action. Update your sample.md file with some text that uses italics, both by itself and alongside bold text.

# My Document
## With *Inline* Formatting

This is a paragraph with *italic* text.
This is a paragraph with **bold** text.
This is a paragraph with both **bold** and *italic* text mixed together.

Now, run your converter from the terminal: cargo run -- sample.md output.html

Open the generated output.html file. You should see the correctly transformed output, demonstrating that your layered parsing approach works perfectly.

<h1>My Document</h1>
<h2>With <em>Inline</em> Formatting</h2>
<p>This is a paragraph with <em>italic</em> text.</p>
<p>This is a paragraph with <strong>bold</strong> text.</p>
<p>This is a paragraph with both <strong>bold</strong> and <em>italic</em> text mixed together.</p>

Next Steps

You’ve now mastered the split-based approach for symmetric delimiters like ** and *. However, this technique won’t work for more complex syntax like links, which have an asymmetric structure: [link text](url). In the next task, you will tackle this new challenge, which will require a different and more advanced string manipulation strategy.

Implement Markdown Link Parsing in Rust

Mục tiêu: Enhance a Rust-based Markdown parser to handle hyperlink syntax [text](url). This task involves implementing a stateful, sequential scan using string slicing and a while loop, as a simple split-based method is insufficient for this complex, structured element.

You’ve masterfully implemented parsing for both bold and italic text! Your layered approach, where you first process for bold and then process the result for italics, is a robust and scalable strategy. By composing simple, focused operations, you’ve built a parser that can already handle nested formatting correctly.

Now, we face our most complex inline element yet: the hyperlink. Markdown’s link syntax, [link text](url), presents a new and exciting challenge that our previous split-based technique cannot solve.

A New Challenge: Asymmetric and Structured Syntax

Our split("...") and enumerate pattern worked beautifully for ** and * because the opening and closing delimiters were identical. A link is different:

It has asymmetric delimiters: [ is closed by ], and ( is closed by ).
It has a specific internal structure: the text part must be immediately followed by the URL part in parentheses.

To handle this, we must graduate to a more powerful parsing technique: a stateful, sequential scan. Instead of splitting the string apart, we will iterate through it, actively looking for the sequence of characters [ -> ] -> ( -> ) that signals a valid link. This approach is more manual but gives us the precise control we need to deconstruct this complex syntax.

The Strategy: Find, Verify, and Reconstruct

Our new link-parsing layer will work like this:

Create an accumulator string for the final output.
Use a while loop to process the input string in chunks.
Inside the loop, search for the first [.
If found, search for the subsequent ].
If found, check if it’s immediately followed by (.
If it is, search for the final ).
If this entire sequence is valid, we’ve found a link! We will then:
- Append the text before the link to our accumulator.
- Extract the link text and URL.
- Format them into an <a> tag and append it to the accumulator.
- Update our view to the rest of the string after the link and continue the loop.
If at any point the pattern breaks, or if no [ is found, we’ll treat the text as plain text, append it, and finish.

Let’s add this third and final layer of processing to our parse_inline_elements function in src/parser.rs.

// src/parser.rs

fn parse_inline_elements(line: &str) -> String {
    // --- BOLD PARSING (First Layer) ---
    // This part remains unchanged.
    let mut bold_processed = String::with_capacity(line.len());
    for (index, segment) in line.split("**").enumerate() {
        if index % 2 == 1 {
            if !segment.is_empty() {
                bold_processed.push_str("<strong>");
                bold_processed.push_str(segment);
                bold_processed.push_str("</strong>");
            }
        } else {
            bold_processed.push_str(segment);
        }
    }

    // --- ITALIC PARSING (Second Layer) ---
    // This part also remains unchanged.
    let mut italic_processed = String::with_capacity(bold_processed.len());
    for (index, segment) in bold_processed.split('*').enumerate() {
        if index % 2 == 1 {
            if !segment.is_empty() {
                italic_processed.push_str("<em>");
                italic_processed.push_str(segment);
                italic_processed.push_str("</em>");
            }
        } else {
            italic_processed.push_str(segment);
        }
    }

    // --- NEW: LINK PARSING (Third Layer) ---
    // This is the new, more advanced parsing logic for links.
    let mut link_processed = String::new();
    // `current_slice` holds the portion of the string we haven't processed yet.
    let mut current_slice = &italic_processed[..];

    // Loop until we have processed the entire string.
    while let Some(start_bracket_pos) = current_slice.find('[') {
        // We found a potential start of a link.
        // Now, look for the closing bracket `]` *after* this position.
        if let Some(end_bracket_pos) = current_slice[start_bracket_pos..].find(']') {
            let absolute_end_bracket_pos = start_bracket_pos + end_bracket_pos;

            // Check if the character sequence is `](`.
            if current_slice.get(absolute_end_bracket_pos..absolute_end_bracket_pos + 2) == Some("](") {
                // Now, look for the closing parenthesis `)` after `](`.
                let url_slice_start = absolute_end_bracket_pos + 2;
                if let Some(end_paren_pos) = current_slice[url_slice_start..].find(')') {
                    // We found a complete `[text](url)` pattern!
                    let absolute_end_paren_pos = url_slice_start + end_paren_pos;

                    // 1. Append the text that came before the link pattern.
                    link_processed.push_str(&current_slice[..start_bracket_pos]);

                    // 2. Extract the link text and the URL.
                    let link_text = &current_slice[start_bracket_pos + 1..absolute_end_bracket_pos];
                    let url = &current_slice[url_slice_start..absolute_end_paren_pos];

                    // 3. Format and append the HTML `<a>` tag.
                    link_processed.push_str(&format!("<a href=\"{}\">{}</a>", url, link_text));

                    // 4. Move our slice forward to the part of the string *after* the parsed link.
                    current_slice = &current_slice[absolute_end_paren_pos + 1..];

                    // Go to the next iteration of the `while` loop.
                    continue;
                }
            }
        }

        // If we found a `[` but it wasn't part of a valid link pattern,
        // we append the text up to and including the `[` and continue scanning from there.
        // This prevents an infinite loop on invalid syntax like `[hello`.
        let text_to_keep = &current_slice[..start_bracket_pos + 1];
        link_processed.push_str(text_to_keep);
        current_slice = &current_slice[start_bracket_pos + 1..];

    }

    // After the loop, append any remaining part of the string that didn't contain a `[`.
    link_processed.push_str(current_slice);

    // Return the final, fully-processed string.
    link_processed
}

Deconstructing the Link Parser

This new logic is the most sophisticated piece of code you’ve written so far. Let’s break it down carefully.

let mut current_slice = &italic_processed[..];: We create a string slice that represents the portion of the string we are currently examining. Initially, it’s the whole string. In each iteration where we find a link, we will shrink this slice from the left, effectively “consuming” the string as we parse it.
while let Some(start_bracket_pos) = current_slice.find('['): This is the engine of our parser. The .find('[') method searches for the first occurrence of [ in the current_slice and returns its byte position inside an Option. The while let construct is a powerful Rust idiom that continues the loop as long as .find() keeps returning Some(position). If no [ is found, it returns None, and the loop terminates.
The if let Chain: Inside the loop, we have a nested series of checks to verify the link structure.
- current_slice[start_bracket_pos..].find(']'): We search for ] but crucially, we search in the slice that starts from the [ we just found, not from the beginning of the whole string.
- current_slice.get(..)== Some("]("): The .get() method on a slice is a safe way to access a sub-slice. It returns an Option, preventing a panic if the indices are out of bounds. We use it to check if the characters immediately following our found ] are (. This is a robust check for the link structure.
- current_slice[url_slice_start..].find(')'): The final check for the closing parenthesis.
Reconstruction: When all checks pass, we deconstruct the Markdown and reconstruct the HTML.
- link_processed.push_str(&current_slice[..start_bracket_pos]);: We grab all the text before the link and append it to our result.
- let link_text = ... and let url = ...: We use slicing with the positions we found to precisely extract the link text and the URL.
- format!("<a href=\"{}\">{}</a>", url, link_text): We build the final HTML tag.
- current_slice = &current_slice[absolute_end_paren_pos + 1..];: This is the most critical line for the loop’s progression. We re-assign current_slice to be the part of the string that comes after the entire [text](url) syntax we just parsed. The loop will then continue scanning from this new, shorter slice.
Handling Fallbacks: If a [ is found but it doesn’t lead to a valid link structure, the inner if conditions fail. We then drop down to the code that appends the text up to and including the [ and advances the slice, preventing an infinite loop. Finally, after the while loop finishes, we append any remaining text that was at the end of the string.

Verify Your Fully-Featured Parser

You now have a parser that handles bold, italics, and links! Update your sample.md to test all the features together.

# A **Document** with Links

Check out the *official* [Rust website](https://www.rust-lang.org).

Another paragraph with a link to [Google](https://www.google.com) and some **bold** text.

Run your converter: cargo run -- sample.md output.html

Open the generated output.html file, and you should see the perfect, combined result:

<h1>A <strong>Document</strong> with Links</h1>
<p>Check out the <em>official</em> <a href="https://www.rust-lang.org">Rust website</a>.</p>
<p>Another paragraph with a link to <a href="https://www.google.com">Google</a> and some <strong>bold</strong> text.</p>

Next Steps

Congratulations! You have successfully implemented the parsing logic for the three most common inline elements. Your layered, multi-strategy approach is a testament to great software design. The final task in this step is to confirm that your layered parser correctly handles multiple, mixed inline elements on a single line, which your current design already accomplishes beautifully.

Finalize and Verify the Inline Parsing Pipeline

Mục tiêu: Review the complete inline element parser, understand how its layered pipeline architecture handles mixed bold, italic, and link formatting, and run a final test to verify the output.

Absolutely phenomenal work! You have just implemented the most complex piece of your parser: the stateful, scanning logic for hyperlinks. By layering this on top of your existing bold and italic parsers, you have assembled a truly powerful and sophisticated inline processing engine.

This final task in our step is less about writing new code and more about stepping back to appreciate the incredible result of your design. The goal is to confirm that the layered architecture you’ve built naturally and correctly handles multiple, mixed inline elements on a single line. Your hard work in the previous tasks has already solved this problem; now, let’s understand why it works so well.

The Power of a Processing Pipeline

The design you have implemented in the parse_inline_elements function is a classic example of a processing pipeline (or a chain of transformations). Each type of inline syntax is handled by a distinct “stage” or “layer” that is simple and focused on its one job.

Let’s trace a complex example line through your pipeline to see this in action:

Input Line: Go to the **official** [*Rust* website](https://rust-lang.org)!

Stage 1: Bold Parsing
- Input to this stage: Go to the **official** [*Rust* website](https://rust-lang.org)!
- The split("**") logic runs. It finds the text official at an odd-indexed position.
- Output of this stage: Go to the official [*Rust* website](https://rust-lang.org)!
Stage 2: Italic Parsing
- Input to this stage: The output from the previous stage.
- The split("*") logic runs. It finds the text Rust at an odd-indexed position.
- Output of this stage: Go to the official [Rust website](https://rust-lang.org)!
Stage 3: Link Parsing
- Input to this stage: The output from the italic parsing stage.
- The while let scanning logic begins. It finds the pattern [...]...(...).
- It correctly identifies the link text as Rust website and the URL as https://rust-lang.org.
- It reconstructs this part of the string into the final <a> tag.
- Final Output of the function: Go to the official <a href="https://rust-lang.org">Rust website</a>!

This demonstrates the beauty of your design. Each stage is simple, but by composing them in a sequence, you’ve created a system that can handle complex, nested, and mixed formatting rules without any single piece of code becoming overwhelmingly complex. This is a hallmark of great software engineering.

Reviewing the Complete Inline Parser

Let’s look at the complete parse_inline_elements function one last time. No new code is needed. This is the finished product of this entire step, a testament to your incremental progress.

// src/parser.rs

fn parse_inline_elements(line: &str) -> String {
    // --- STAGE 1: BOLD PARSING ---
    // The first transformation in our pipeline. It takes the raw line
    // and produces a string with `<strong>` tags.
    let mut bold_processed = String::with_capacity(line.len());
    for (index, segment) in line.split("**").enumerate() {
        if index % 2 == 1 {
            if !segment.is_empty() {
                bold_processed.push_str("<strong>");
                bold_processed.push_str(segment);
                bold_processed.push_str("</strong>");
            }
        } else {
            bold_processed.push_str(segment);
        }
    }

    // --- STAGE 2: ITALIC PARSING ---
    // The second transformation. It takes the output of the bold stage
    // and produces a string that also has `<em>` tags.
    let mut italic_processed = String::with_capacity(bold_processed.len());
    for (index, segment) in bold_processed.split('*').enumerate() {
        if index % 2 == 1 {
            if !segment.is_empty() {
                italic_processed.push_str("<em>");
                italic_processed.push_str(segment);
                italic_processed.push_str("</em>");
            }
        } else {
            italic_processed.push_str(segment);
        }
    }

    // --- STAGE 3: LINK PARSING ---
    // The final transformation. It takes the output of the italic stage
    // and produces the final string with `<a>` tags.
    let mut link_processed = String::new();
    let mut current_slice = &italic_processed[..];

    while let Some(start_bracket_pos) = current_slice.find('[') {
        if let Some(end_bracket_pos) = current_slice[start_bracket_pos..].find(']') {
            let absolute_end_bracket_pos = start_bracket_pos + end_bracket_pos;

            if current_slice.get(absolute_end_bracket_pos..absolute_end_bracket_pos + 2) == Some("](") {
                let url_slice_start = absolute_end_bracket_pos + 2;
                if let Some(end_paren_pos) = current_slice[url_slice_start..].find(')') {
                    let absolute_end_paren_pos = url_slice_start + end_paren_pos;
                    link_processed.push_str(&current_slice[..start_bracket_pos]);
                    let link_text = &current_slice[start_bracket_pos + 1..absolute_end_bracket_pos];
                    let url = &current_slice[url_slice_start..absolute_end_paren_pos];
                    link_processed.push_str(&format!("<a href=\"{}\">{}</a>", url, link_text));
                    current_slice = &current_slice[absolute_end_paren_pos + 1..];
                    continue;
                }
            }
        }

        let text_to_keep = &current_slice[..start_bracket_pos + 1];
        link_processed.push_str(text_to_keep);
        current_slice = &current_slice[start_bracket_pos + 1..];
    }

    link_processed.push_str(current_slice);
    link_processed
}

// Your public `parse` function remains below, unchanged.
pub fn parse(markdown_input: &str) -> String {
    // ...
}

Final Verification

To put your fully-featured parser to the test, update your sample.md file with a comprehensive example that uses everything you’ve built.

# My **Awesome** Document

## A section with *mixed* content

This line has **bold**, *italic*, and a link to [Mozilla Developer Network](https://developer.mozilla.org).

Another paragraph. Here is a link with [*italic text*](https://www.rust-lang.org) inside it! What about **bold text**?

Now, run your converter one last time for this step:

cargo run -- sample.md output.html

Open the generated output.html file. You should see the perfectly rendered result of your sophisticated parsing engine:

<h1>My <strong>Awesome</strong> Document</h1>
<h2>A section with <em>mixed</em> content</h2>
<p>This line has <strong>bold</strong>, <em>italic</em>, and a link to <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p>
<p>Another paragraph. Here is a link with <a href="https://www.rust-lang.org"><em>italic text</em></a> inside it! What about <strong>bold text</strong>?</p>

Congratulations on completing this incredibly important and challenging step! You now have a parser that can handle both block-level and a wide range of inline-level Markdown syntax.

Next Steps

Your parser is now generating high-quality HTML fragments. However, a browser expects a complete HTML document, not just a collection of tags. In the next step of the project, you will create a new function that takes these fragments and wraps them in a valid HTML5 boilerplate, including the <!DOCTYPE>, <html>, <head>, and <body> tags, to produce a complete, self-contained web page.