regex lookaround

[seconddayout]

I expected to be able to use a positive lookahead to split my selection, but it didn't seem to work.

I was looking to prepend every line that wasn't empty with a greater than sign followed by a space. % → S → ^(?=\S) → ENTER → i → > 

The regex worked as expected when I checked it here: https://regex101.com/r/S99kPK/1

1. Why isn't this working in Helix; and
2. is there a better way, one that's more idiosyncratic to Helix?

[seconddayout]

I just tried the same thing —key for key— with Kakoune and it worked exactly as expected.

[seconddayout]

Just occurred to me that ^(?!\s*$) would be ideal —if one has, too, non-empty lines that begin with some sort of white space (indentation) that they also want to prepend. That works in neither Helix nor Kakoune, though 😢

[A-Walrus]

A better way might be: % → s → ^\w → i → > (using select and not split, and a simpler regex)

As for why the lookahead doesn't work, it appears that the regex crate doesn't support look-around. trying to run this simple example let re = Regex::new(r"q(?!u)").unwrap(); gives the error

regex parse error:
    q(?!u)
     ^^^
error: look-around, including look-ahead and look-behind, is not supported

[sudormrfbin]

https://github.com/rust-lang/regex/issues/127

[seconddayout]

@A-Walrus hm 🤔 seems I don't really understand the difference between select (s) and split (S). Care to elucidate for me?

[the-mikedavis]

s selects patterns positively ("does the pattern match? ok then it's included in the selection") while S splits an existing selection negatively ("does the pattern match? ok then separate the parts of the selection that don't match the pattern into separate selections")

[jakenvac]

As I understand it from the link above, the rust project has no intention of adding look arounds for their regex implementation.

Does that mean this will always be the case for Helix? What is the general consensus on using a third party crate that supports more regex features? I find myself quite regularly piping out to the shell or using kak to make use of these features.

If it's something the maintainers would consider, I'd love to have a crack at making a PR.

[the-mikedavis]

I don't really have strong opinions on this but I'm not convinced we need fancier regular expressions. In my experience you can convert most lookarounds to simpler regular expressions or sequences of s/S or other selection commands. In this case, you could do %<alt-s>s.+<ret> to select all non-empty lines

[Black616Angel]

I know, I'm a little late to the party, but why not just include the fancy-regex crate? It's an actively developed drop-in replacement for the official regex crate and supports backtracking and lookarounds. It also uses the official crate for all "non-fancy" regexes so there should be little to no slowdown on those.

Why do this? I often use negative lookaheads in my work, and those are hard or impossible to convert to non-fancy regexes.