Minor doc-fix, proposed modification to "=" operator and addition of "=~" wrapper operator

[atreyasha]

1. Minor man-doc fix

• c87b140: modification to man-doc to sort the hierarchies of man-pages

2. Minor fix assuming we keep the current = operator

• c87b140...0a306a6: minor bugfix for current = operator in case regex does not match and vercmp does match. This could be the case where 8.2.33 would not regex match 8.2.0033, but it would still be a vercmp match.

• 0a306a6...085b4b6: when inputting a (failing) version bound such as downgrade vim=1.2, the error message will state Unable to downgrade vim=1.2. I added a slight modification such that the error message would say Unable to downgrade vim to show that downgrade was able to parse the actual package.

3. Major fix assuming we modify the current = operator

I found it surprising (that = doesn't just mean =), but I suppose the unexpected behavior would result in multiple results and present the list to the user, so it's not particularly problematic.

I was thinking about your comment in #118 and came to realize that the = operator should indeed really mean equals and nothing else. To address this, I reverted the original = operator to have the correct meaning and added a new =~ operator which behaves exactly like that in bash (it just a wrapper for that). This will provide the user with the ability to conduct regex on package versions directly from the command line, for example downgrade "vim=~\.0033".

To address this, I chunked similar commits as per (2):

• 085b4b6...0cbd8a3: revert = operator to equal meaning and add regex matching operator =~. Add respective tests for this as well.

• 0cbd8a3...99f35d4: when inputting a (failing) version bound such as downgrade vim=~1.2, the error message will state Unable to downgrade vim=~1.2. I added a slight modification such that the error message would say Unable to downgrade vim to show that downgrade was able to parse the actual package.

Commits chunking

In this PR, (2) and (3) are mutually exclusive so we should choose what we like best. I would personally go for (3) since it addresses your comment in #118 and also provides the user with more flexibility in filtering packages while keeping the meaning of = to a hard equal.

If we like (2) more than (3), we can just drop the commits from 4868622 onward. If we like (3), we can just merge everything since the commits in (2) will be directly overriden.

I hope the chunking of commits helps in selecting what we find best. I tried to structure it as independently as possible so we can just pick and choose.

[pbrisbin]

LGTM.

In the future, let's not update the rendered man page or update the locales files in PRs; it's just diff noise that slows down the GitHub UI :). I will do all that as part of release, along with the CHANGELOG, etc.

[atreyasha]

LGTM.

In the future, let's not update the rendered man page or update the locales files in PRs; it's just diff noise that slows down the GitHub UI :). I will do all that as part of release, along with the CHANGELOG, etc.

Got it. I will edit the commits now just to ensure there are no conflicts for the other PR. Just to check, so for this PR you would prefer option (3) over option (2)? In that case, I can simplify the commits too.

[pbrisbin]

for this PR you would prefer option (3) over option (2)?

Oh sorry, I forgot there were choices and just reviewed the PR as-is (which I guess is (3)?). I don't have a strong opinion, I'd defer to you. If pressed, I guess (3).

[atreyasha]

Reduced everything to 5 commits. Changes in locale and man-doc are now ommitted. If everything is fine, you can merge it.