Skip to content

List upcoming goals after active ones#2690

Closed
byorgey wants to merge 1 commit intomainfrom
feature/byorgey/active-before-upcoming
Closed

List upcoming goals after active ones#2690
byorgey wants to merge 1 commit intomainfrom
feature/byorgey/active-before-upcoming

Conversation

@byorgey
Copy link
Member

@byorgey byorgey commented Feb 20, 2026

Closes #1169, by implementing the second idea I listed there: fix an order in which to display goal categories and update the display code so it explicitly uses that order, rather than implicitly relying on the order in which the GoalStatus constructors were declared. The downside is that if we were to ever add a new type of GoalStatus we would need to manually update that list in order to display those goals. However, if someone adds a new goal type it should be obvious if those goals are not being displayed.

To see the difference, try first running

cabal run -O0 swarm:exe:swarm -- -i Testing/795-prerequisite/795-prerequisite-or

and note that the first highlighted goal is "Upcoming":
before

Then, after applying this patch, run the same command; the first highlighted goal is now one of the "Active" ones:
after

objList = intercalate [Spacer] $ map f $ M.toList categorizedObjs
f (h, xs) = Header h : map (Goal h) (NE.toList xs)
categoryDisplayOrder :: [GoalStatus]
categoryDisplayOrder = [Active, Upcoming, Completed, Failed]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would prefer that we had the protection of exhaustiveness checking.

What about a manual implementation of Ord? Then the docstring of that instance could explain the purpose, and additions to the enum would not silently break the display order.

Personally I'd be fine with option 1 plus a docstring.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, good point. Yes, a manual implementation of Ord is a good idea too, I didn't think of that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But maybe you're right, option 1 is fine as long as we carefully document what is going on, especially since that's the only place we use that particular data type.

@byorgey byorgey closed this Feb 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

First active goal should be highlighted by default

2 participants