Re-evaluate UI design of recently added `cabal list --exact` flag

[hvr]

Follow-up from #4267 as separate ticket as requested (so please excuse if this feels like it's missing context):

---

@v0d1ch Actually, I have an alternative design for this I've been wanting to implement for the longest time; listing exact matches is something I can already do via cabal info. What's the point of listing somethign where you already know the exact name for? :-)

The most common search operations I want to perform are simple prefx/suffix matching:

1. I want to only list packages which match a prefix (e.g. ^servant-)
2. I want to only list packages which match a suffix (e.g. -orphans$)

Now the primary bikeshedding thing is what syntax to support here; there's various possibilities; two obvious ones:

1. glob-style: this works best if we default to "exact" matches; this matches the shell idioms (c.f. ls foo and ls foo-*); substring matches would then be strings surrounded by *, i.e. *foo*.
2. regex-style: this makes sense if we default to substring search (as we currently do) which is how many regex-style supporting UIs operate as well (i.e. if you don't use any regex operators, it acts like substring search); note that you don't need any CLI flags here to switch to exact matches: you'd simply say ^foo$ to denote an exact match!

I'm not sure which one's better; and it's more than enough to start by implementing only a basic subset which allows the common pre/suffix matches.

But this is something we should decide upon before we add an unnecessary flag like --exact which then might end up becoming a hard to remove again UI-wart because we didn't invest enough time to plan ahead what other kinds of patterns would make sense to match and come up with a more holistic UI design (and cabal unfortunately suffers from many tiny features stuck together because they seemed useful in isolation but weren't considered how they fit to the rest...)

[phadej]

I don't consider cabal-install interface carved in stone as hard as ./Setup one. So changes like removal of --exact are IMO not impossible. It's not nice to change UI, but it's not the same wart as we had with --allow-newer in ./Setup.hs.

[fendor]

I would prefer the regex style.
Although I admit, that the UI of something like cabal list servant-* looks nicer and more intuitive on CLI, I like the power and flexbility that comes with regex.

[phadej]

A problem with both glob and regex is how to denote case-(in)sensitivity. Currently the cabal list cabal e.g. is case-insensitive match.

Extra flag to control which way it matches?

[hvr]

I believe this is actually easier for the regex style: there's the idiom to say something like /^foo-/i to enable case-insensitive (and I'd suggest that when you use regex-style, we should be case-sensitive by default, unless the case-insensitive modifier is passed -- this is e.g. how search-engines built into stuff like "rocket-chat" work when you use the regex-syntax); another variant I've sometimes seen is /(?i)^foo-/ (but I consider the former one more obvious)

[phadej]

And interpret string which doesn't start with / as regexp surrounded by / characters. I.e. ^foo- would match foo- prefix (case-sensitively?)

[szabi]

@hvr, @phadej, it's common idiom in greppers to use the -i CLI flag to denote case insensitivity, and to use uppercase for negation.

So if the default behaviour of cabal list ^foo- would be case insensitive (for backwards compatibility), one could use cabal list -I ^foo- to specify to match case.

I would not recommend on a CLI interface to use the / regex delimiter characters or regex flags.

[phadej]

@szabi, -i and -I sounds good. I made a patch.