[BUG] Building Cursive with `--features ansi` yields a future incompatibility warning due to nom v4.2.3 about cursive

[cpdean]

Ah sorry I see this issue is actually coming from ansi-parser v0.8.0

[christoph-heiss]

Ah sorry I see this issue is actually coming from ansi-parser v0.8.0

Yep, this issue stems from nom 4.x pulled in transitively by ansi-parser 0.8.
There is an open, draft merge request upstream, but neither the MR nor the repo seems to have seen any activity since ~1y ago.

Since I do have worked with nom a lot before, I'll might take a look at it.
Besides that .. looking at the current usage of the ansi-parser crate, it might be even possible to get by without it. Only a small subset is used anyway, and parsing out these sequences isn't a lot of work (as can be evidently seen when looking at the source of the ansi-parser crate itself).

Should still be fine for some time though.

[gyscos]

I agree, I'm not very happy with the current state of ansi-parser. We're using a pretty old version (though there has been some development on the gitlab page since), and the logic should be simple enough to re-implement.

I'd still ideally make this as a separate crate (either a fork of ansi-parser or something new) than having the ansi implementation literally in cursive - makes it easier to re-use, and easy to switch out if needed.