Please, add keys that filter on closed/opened issues/PRs

[Anton-Latukha]

No description provided.

[Anton-Latukha]

Since a couple of days ago I started learning optparse-applicative and as so - the base of Haskell parser combinators at all - I've taken and started to implement this.

So far I am at: this status options require many keys/(set of values) that are resolved with Alternative many into a resulting set of rules that then filter the content. Something like that. Now "it 'only' needs to be implemented".

I do not know how far I would go currently, if I ever lose my courage - I would report about that.

[guibou]

@Anton-Latukha Thank you!

This is indeed a really good idea.

As your look motivated / advanced, I let you work on it. If you ever lose your courage or need help / guidance, please ping me, we'll work through this together. Don't hesitate to push a draft pull request to start the discussion.

Thank you for the time you are spending on krank, this is appreciated.

[Anton-Latukha]

I just got my hands full couple of days ago right when I was making the effort.

Suddenly I become a first maintainer in a project. And there is a lot of what should be done. And I have a lot to learn and squeeze through there at the same time.

So I prioritize to the maintainer responsibilities, because they are responsibilities.

So I apologize for not delivering. And ask you if you have time, or anyone wants I am no longer pursuing this.

---

peti already uses krank in his workflow.
Basically he requested this feature. And I happened to learn optparse-applicative same days so it looked like I can jump on it easy.

So when you would decide you are ready to - you can approach him and say your hi and thanks to him, he is a great man.

---

Overall, idea is a versatile genius.

---

Longterm goal is that usage of krank in Nixpkgs would be the tremendous success of course.

I want to push for structured patches in Nixpkgs, so people would start to actually include proper upstream and security info for patches they place in the packages. Then we would be able to track all of them.

---

About optparse-applicative - something is not possible to express in it, I encountered that writing the code.

Since it is all applicative and library allows to pass keys in any order - overlapping keys can not be implemented. That is what I encountered. Like, it should be decided - have a set of --open, but then all statuses are single keys OR a set of --status open,closed. And if those keys are not there - that means all.

Authority how to structure the CLI arguments & keys is yours, so I would need ask anyway, and you had and have the idea in the head so you would know how better to structure the CLI.

Keys may be random but there is possible:

command argumentLvl1 argumentLvl2 --keys -e -y -s

Those arguments and their submenu APIs are done through subparser in the library.

[Anton-Latukha]

Author of the optparse-applicative gave me explanation how to:

--getAllowedValues "the,set,of,the,values":

pcapriotti/optparse-applicative#390 (comment)

There's no official answer, but use eitherReader and some functions from attoparsec is probably the solution I would suggest. So yeah, write an attoparsec parser which does what you want, then build a ReadM by composing with eitherReader.

As states are an allowed set of values - here we received the proper answer where the limits of the library are and when and how to go into the other Haskell parsers and how to do parsing further.

[guibou]

@zimbatm We discussed about this last week.