3 ms·

> Right, so you want a POSIX compatiblr tool because POSIX is what you're used to and you don't want to use any other interface. Well, I would want to use a si

by hvdijk 4y ago

> Right, so you want a POSIX compatiblr tool because POSIX is what you're used to and you don't want to use any other interface. Well, I would want to use a single RE syntax if possible. It does not have to be POSIX BRE with GNU extensions but that's what is used by the other tools I use. Looking closer, GNU grep, git grep, ripgrep all support PCRE. That might be an okay alternative. It would take some time and effort to switch over. I do not know yet whether it would be worth the effort, but getting used to a different syntax that's used by a wide number of tools seems more useful than getting used to a different syntax that's used by a single tool, no matter how useful the tool. > Which is fine. Keep using the old stuff. I don't see any good reason to exactly imitate POSIX when I can go build something that I think is better without being constrained by POSIX. For example, I think just having \b is better than having both \< and \>. To be clear, \< and \> are GNU extensions, not part of POSIX. I can't really see how making \< and \> errors is better for users than supporting it in addition to \b. I can see an argument that it's not worth the cost to implement the feature, and that's of course one you're entirely within your rights to make, but not that the feature has a negative overall value. For the rest, it seems like you and I have different ideas about what the author meant that are going to be impossible to clear up without input from the author, so I will suggest that we drop that unless and until we do get such input.

burntsushi 4y ago
> Looking closer, GNU grep, git grep, ripgrep all support PCRE. That might be an okay alternative. It would take some time and effort to switch over. I do not know yet whether it would be worth the effort, but getting used to a different syntax that's used by a wide number of tools seems more useful than getting used to a different syntax that's used by a single tool, no matter how useful the tool. Yes, that's true. You could do that. I will say though that if you take PCRE, EREs and ripgrep's default regex engine, they all support largely the same syntax. There are differences of course (you've pointed out one already), but they're a lot more alike than they are different. BREs are the oddball with its escaping rules. But if you know the escaping rules they can be quite useful in a context where most of what you're searching for is a literal with some regex aspects. Vim's default regex syntax is like this for example and it is quite useful in that context. And yes, grep's tend to have a lot of extensions. So I guess what you're after is "GNU's particular extension of regex syntax." Idk, just seems like if that's what you care most about, then just keep using GNU tooling. Otherwise, ripgrep's default regex engine is very very similar to EREs and other Perl inspired regex syntaxes. Which is intentional. The \< and \> stuff might be something I implement eventually, but I've always found them strange. YMMV.
- hvdijk 4y ago
  BRE vs ERE is really a non-issue for me: the way they're done in GNU's regular expression implementation, BRE and ERE are the same except for small differences in when you do and don't put \ in front of certain characters. GNU supports \< and \> in BRE and in ERE mode exactly the same way, and I do use ERE mode a lot as well. I had a stab at implementing this to see how easy or difficult it would be. Coming from someone who doesn't write Rust: it seems to be pretty much trivial. A quick and dirty implementation is at <https://github.com/hvdijk/regex/commit/511c6485e49c22c79b47a3663a97624348343e6d https://github.com/hvdijk/regex/commit/511c6485e49c22c79b47a...>. I guess I can use ripgrep with this patch for now to stop my own complaining.
  - burntsushi 4y ago
    > BRE and ERE are the same except for small differences in when you do and don't put \ in front of certain characters I guess I'd argue that EREs and the regex crate syntax are the same except for small differences too. :P And I'd absolutely categorize "use \b instead of \< or \>" as a pretty small difference. In any case, yes, I agree that adding \< and \> to the regex crate is not a difficult implementation challenge. To me, it's not "can we" but "should we." Another question is whether we need to also add the negation of each of \< and \> too, to match \b and \B. (I don't know of any commonly accepted syntax for the negation of \< or \>.)
    - hvdijk 4y ago
      > And I'd absolutely categorize "use \b instead of \< or \>" as a pretty small difference. I don't know, to me \b always felt like a bad idea. Start of string (^) and end of string ($) make sense as different symbols, I'm not aware of people asking for a single "boundary of string" symbol that acts as (^|$), I'm not aware of any realistic use case for it that isn't better written using plain old ^ or $. I feel the same way about \< and \>: in any place where I would otherwise have to write \b I already know whether I'll want "start of word" or "end of word" and it won't make sense to allow the other, but \b forces that to be accepted too. That said... > Another question is whether we need to also add the negation of each of \< and \> too, to match \b and \B. (I don't know of any commonly accepted syntax for the negation of \< or \>.) ...the negation of word boundaries clearly has uses, but the negation of \< or \> would be a new invention that would add more incompatibilities between ripgrep and other implementations. As much as I'd be in favour of a negation of \< and \>, I'd be more in favour of something that also works in other implementations, which is the \B that you already have. Just my personal views. I'm served either way by my locally patched version of ripgrep, I'll assume you know better what the rest of your users want.

by hvdijk 4y ago

burntsushi 4y ago

> Looking closer, GNU grep, git grep, ripgrep all support PCRE. That might be an okay alternative. It would take some time and effort to switch over. I do not know yet whether it would be worth the effort, but getting used to a different syntax that's used by a wide number of tools seems more useful than getting used to a different syntax that's used by a single tool, no matter how useful the tool. Yes, that's true. You could do that. I will say though that if you take PCRE, EREs and ripgrep's default regex engine, they all support largely the same syntax. There are differences of course (you've pointed out one already), but they're a lot more alike than they are different. BREs are the oddball with its escaping rules. But if you know the escaping rules they can be quite useful in a context where most of what you're searching for is a literal with some regex aspects. Vim's default regex syntax is like this for example and it is quite useful in that context. And yes, grep's tend to have a lot of extensions. So I guess what you're after is "GNU's particular extension of regex syntax." Idk, just seems like if that's what you care most about, then just keep using GNU tooling. Otherwise, ripgrep's default regex engine is very very similar to EREs and other Perl inspired regex syntaxes. Which is intentional. The \< and \> stuff might be something I implement eventually, but I've always found them strange. YMMV.

hvdijk 4y ago
BRE vs ERE is really a non-issue for me: the way they're done in GNU's regular expression implementation, BRE and ERE are the same except for small differences in when you do and don't put \ in front of certain characters. GNU supports \< and \> in BRE and in ERE mode exactly the same way, and I do use ERE mode a lot as well. I had a stab at implementing this to see how easy or difficult it would be. Coming from someone who doesn't write Rust: it seems to be pretty much trivial. A quick and dirty implementation is at <https://github.com/hvdijk/regex/commit/511c6485e49c22c79b47a3663a97624348343e6d https://github.com/hvdijk/regex/commit/511c6485e49c22c79b47a...>. I guess I can use ripgrep with this patch for now to stop my own complaining.
- burntsushi 4y ago
  > BRE and ERE are the same except for small differences in when you do and don't put \ in front of certain characters I guess I'd argue that EREs and the regex crate syntax are the same except for small differences too. :P And I'd absolutely categorize "use \b instead of \< or \>" as a pretty small difference. In any case, yes, I agree that adding \< and \> to the regex crate is not a difficult implementation challenge. To me, it's not "can we" but "should we." Another question is whether we need to also add the negation of each of \< and \> too, to match \b and \B. (I don't know of any commonly accepted syntax for the negation of \< or \>.)
  - hvdijk 4y ago
    > And I'd absolutely categorize "use \b instead of \< or \>" as a pretty small difference. I don't know, to me \b always felt like a bad idea. Start of string (^) and end of string ($) make sense as different symbols, I'm not aware of people asking for a single "boundary of string" symbol that acts as (^|$), I'm not aware of any realistic use case for it that isn't better written using plain old ^ or $. I feel the same way about \< and \>: in any place where I would otherwise have to write \b I already know whether I'll want "start of word" or "end of word" and it won't make sense to allow the other, but \b forces that to be accepted too. That said... > Another question is whether we need to also add the negation of each of \< and \> too, to match \b and \B. (I don't know of any commonly accepted syntax for the negation of \< or \>.) ...the negation of word boundaries clearly has uses, but the negation of \< or \> would be a new invention that would add more incompatibilities between ripgrep and other implementations. As much as I'd be in favour of a negation of \< and \>, I'd be more in favour of something that also works in other implementations, which is the \B that you already have. Just my personal views. I'm served either way by my locally patched version of ripgrep, I'll assume you know better what the rest of your users want.