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]

rust-lang/regex#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.

[ndcontini]

I'd like to also add that this is a feature I used all the time in vim, and I'd love for the same feature to exist in Helix. I understand rust probably wants the most performant implementation to be the default. In cases where you need negative lookaround you can simply postprocess matches using another regex pattern. However, in the case of a text editor, often a search is made over a single text file, in which case any performance hit from "fancy" regex would be negligible. Furthermore being able to achieve the same effect with a single command is almost always better than doing it with two or more. It would be nice if we could at the least provide a configuration option to enable the fancy-regex crate instead of the default.

[kirawi]

We use a fork of regex with streaming capabilities for performance: https://github.com/pascalkuthe/regex-cursor. For fancy-regex to be considered, that fork would have to be merged upstream, and then the necessary changes adopted by fancy-regex AFAIK.