helix-editor
Match inside/around closest surrounding pair sometimes fails
As a noob to Rust, I’ve started reading the rust book. The finished code block for Chapter 2 looks like this:
use rand::Rng;
use std::cmp::Ordering;
use std::io;
fn main() {
println!("Guess the number!");
let secret_number = rand::thread_rng().gen_range(1..=100);
loop {
println!("Please input your guess.");
let mut guess = String::new();
io::stdin()
.read_line(&mut guess)
.expect("Failed to read line");
let guess: u32 = match guess.trim().parse() {
Ok(num) => num,
Err(_) => continue,
};
println!("You guessed: {guess}");
match guess.cmp(&secret_number) {
Ordering::Less => println!("Too small!"),
Ordering::Greater => println!("Too big!"),
Ordering::Equal => {
println!("You win!");
break;
}
}
}
}
When I position my cursor into any part of the curly brace enclosed blocks (except for the lines with only right curly brackets) and issue the mim or mam command, no selection is made. mm goes to the enclosing braces just fine, and mi{ / mi} works as expected and selects within the enclosing brackets.
After a little investigation I came to the conclusion this is caused by < and > not always being used as a matching pair (here in the arrow of the match cases). Do you think we should just ignore them when searching for the closest pair or should we employ some more sophisticated algorithm for searching for the matching pair? (perhaps something that looks in both directions)
I've found that mam and mim both work from the ending bracket, but not the beginning bracket of the block of code.
Also, mm, mim, and mam don't work with back-ticks.
I feel like these two could be separate from 4568 though. Would you like another new issue for each to keep them apart?
@Ktoks the end/start thing is precisely this issue, the current algorithm to figure out the closest pair only looks for a mismatched closing pair, and it starts from the cursor — so with your cursor on an opening brace it will never find the correct closing brace. furthermore, if there's any mismatched closing brace (including <s) within the braces you're trying to select, it will fail to match as well.
About backticks, however, they aren't a matching surround pair, so the current algorithm doesn't even consider them when looking.
But for good news I think I thought of something that'll fix both of those issues in one — using the tree-sitter to find the closest pair, and only falling back to a general algorithm if no tree-sitter is active. I'll definitely experiment with this more later today