Can't read closed issues

[driusan]

Only open issues are displayed, there's no way to read issues after they've been closed.

Maybe the issues directory should have new/closed/all subdirectories to match the possible states in the GitHub API?

[sirnewton01]

I released this very early to get feedback. It's missing even the most basic functionality but I wanted to get feedback. Thank you for giving it a try.

I was thinking about having the filters go into subdirectories like that. Also, there's the fact that PR's are showing up in the list. There's also no way to refresh an issue yet.

I think I want to make it easier to refer to another issue using simple cross-links that can be navigated easily. Also, the queries for the issues have more than one dimension. My current feeling is that I could add a control file (ctl) that you can read and then write to reconfigure and re-run the query. On top of that the filesystem will surface an issue on the fly if you access it while going through a link or open it directly, much like how the repos/ entries work.

I think that this design will make it easy to see open issues at a glance, access other issues and run different types of queries to see which issues match. What do you think?

[driusan]

One advantage of having pull requests mixed in (or at least having the option) is that it's easier to write a plumbing rule where something like '#[0-9]+' plumbs to the issue/pr

[sirnewton01]

After some refactoring there is now the ability to open/cat a closed issue even though it doesn't show up initially in the issues directory. I want to do more here so that you can change the filter using a ctl file as described above but this should allow you to peek at any issue you want now.

[sirnewton01]

I've implemented a special ctl file, which exposes the internal JSON object used to list the issues. You can open, change and save the ctl file and the contents of the directory match the options that you picked. In acme, you can Put and run Get on the issues directory to see your changes. I should add some documentation in the master README to let users know the values that they can put in when they aren't obvious. It is unfortunate that JSON file format doesn't allow inline comments, which would be useful here. It's possible that I could change this over to a markdown format to allow the inline comments.