Fix sorting

[rom1dep]

• Ensure that "folders first" ordering mode doesn't place folder notes on top of notes flagged as #top
• Improve tests by documenting the new behaviour and increasing coverage for existing sorting functions

[gemini-code-assist]

Summary of Changes

Hello @rom1dep, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical issue in the note sorting mechanism where the 'folders first' preference could inadvertently displace notes explicitly marked for the top or bottom of a list. The core change involves a strategic reordering of sorting rule application to guarantee that pinned notes always take precedence. Concurrently, the PR enhances the reliability of the sorting features by introducing comprehensive new tests that cover various sorting scenarios, including natural sorting and the corrected interaction of folder prioritization with pinned notes.

Highlights

• Sorting Logic Fix: The sorting logic has been corrected to ensure that notes flagged with #top or #bottom always maintain their pinned positions, even when the 'folders first' ordering mode is active. Previously, folder notes could incorrectly override #top notes.
• Improved Test Coverage: New test cases have been added to validate basic title sorting, natural sorting, and the specific scenario where 'folders first' interacts with #top and #bottom notes, significantly increasing the robustness of the sorting functions.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly adjusts the sort priority to ensure #top notes are always placed above folders when sortFoldersFirst is active. The added tests improve coverage for sorting functionality.

I've found one issue with the sortFoldersFirst logic when combined with reverse sorting, which causes folders to be sorted last. I've left a detailed comment with a suggested fix and also recommended adding a test case to cover this scenario.

Overall, a good change that addresses the primary issue.

[rom1dep]

I've found one issue with the sortFoldersFirst logic when combined with reverse sorting, which causes folders to be sorted last.

It is kept this way in case the user would wish, for any reason, sort folders last.

[eliandoran]

I've found one issue with the sortFoldersFirst logic when combined with reverse sorting, which causes folders to be sorted last.

It is kept this way in case the user would wish, for any reason, sort folders last.

@rom1dep ,
Are you sure it's the best approach? We recently changed #top to appear first even when the order is descending. I would prefer if we maintain consistency.

[eliandoran]

Don't forget to update the documentation.

[rom1dep]

@rom1dep , Are you sure it's the best approach? We recently changed #top to appear first even when the order is descending. I would prefer if we maintain consistency.

@eliandoran this PR is consistent with the current behaviour in that #top remains on top, no matter what. I amended a couple of test-cases to make sure we don't inadvertently regress on it in the future.

Stepping back a bit, I certainly don't like the syntax of it all, but I also don't think that this PR makes things worse. My preference, if I had a shot at a clean slate design, would be to have #sortFoldersOrder=first|last combined with #sortFoldersDirection=asc|desc (instead of #sortFoldersFirst), but here we are.

If we were to migrate to something like that, I am not sure what the resulting PR would look like (I suppose that we would have to bump the data model version and run a post-update full-document migration, and I don't trust my abilities to get that right).

Point taken about the documentation, though. Once we reach consensus on the above, I will get on to it and clarify how the different sorting modes interact with one another (which, tbf, should have been done a long time ago).

[eliandoran]

@rom1dep ,

Let's reach consensus.

Here's how I see it:

• #top keeps the items at the top, regardless of sort direction. As mentioned previously, we had a bug where top items ended up at the end of the list if sort direction was reversed.
• I would want #sortFoldersFirst to act exactly like #top (arguably first and top are slightly synonymous). Perhaps we can rename it if needed.
• I wouldn't go for changing the existing attributes since at some point they'll become system attributes and mostly be used through the UI. Only "hard-core" users would still care about these attributes, case in which they could tolerate a bit of mess in naming.