Quite a bit!
- It is hard to reason about the interaction between flags. There are a lot of flags, and every time a new one is added, it's almost guaranteed that there is some interaction that wasn't anticipated.
- This one came up in the conversation above: there are two different implementations of search in ripgrep, where one operates over buffers and one operates over a single big slice. The latter doesn't have some features implemented, such as context handling. So one consequence of this is that any time you request contexts, ripgrep will never be able to use memory maps. This is a failing on my part to write a more generic search routine and this is fixed in my in-progress work on libripgrep.
- While the UTF-16 transcoder wasn't a lot of work on my part, I really think it should live in a separate crate since it is generically useful.
- The parallel directory iterator API is baroque.
- The printer has become very complex. This is partially due to the fact that this is primarily where all the interactions between flags are resolved. I'm working on a rewrite of the printer in libripgrep, and there are some marginal improvements, but there is still case analysis strewn about everywhere that I know is going to make the code hard to read. I don't have any good ideas here unfortunately.
- ripgrep's
src/main.rsis a bit too busy for my taste. There's a lot going on and very little meaningful abstraction happening. - The
ignorecrate's directory traversal code is quite complex and also very busy.