It was even more work than it seems, because I've already done all of it, but deleted it all and started over here.

See the Search section of my AutoKey useful links gist for lots of ways to search AutoKey on GitHub. The commits search is what you'd be after, although when you're doing a deep investigation, you'll want to search the code, the commits, the pull requests, etc.

I can understand why you might like the major or minor sorting, but it's harder to quickly search and is completely disorienting to those of us who expect alphabetical sorts, so I'd vote for alphabetical listing. It's how listings are done in pretty much every field everywhere, so it's what our brains tend to expect to encounter.

As an example of why something like that is problematic, look at my public gists. I don't have a lot of them compared to some folks, but there are enough of them that it's annoying to try to find the one you want because they're not sorted alphabetically. That's not offered as an option [sigh], so I'm stuck with them the way they are. I can sort them by when they were updated, so I could edit all of them in a specific order in order to force an alphabetic sort, but I'd have to repeat that every time I added a gist, which would be frustrating and shouldn't be necessary. I've either created or joined in on an issue about this (can't remember which), but nothing has been done yet. Here's hoping...

Upgrades are badly named. I'm not sure how to refer to them. Maybe you can help me come up with a better name. This refers to the times when we make big leaps that make a change significant in comparison to most other changes. As an example, when we went from using Python 2 to using Python 3.which is a dramatic upgrade to the code-base, that would be considered an upgrade. If we were, for example, to switch from using X to using Wayland, that would also be considered an upgrade. Come to think of it, that category is unnecessary. After all, those two examples would fit into the Breaking changes category, which is for any change that will break things unless we manually intervene (by updating our scripts, for example). I'll get rid of Upgrades above.

I used the Emoji selector program that's in our Utilities menu in Kubuntu and copied the stop sign and pasted it into the message. We can use those all over GitHub. Here's another as an example: ❤️

The new Gist used as an index is a good idea, so I've done it. Thanks for the suggestion. It also decluttered my GitHub home page. I'm still hoping they'll fix the sort, though, because when it comes to editing the Gists, there will still be hunting necessary to find the one(s) you want to edit.

As far as orthogonal entries, those would be problematic, because each entry should only appear once. I'm hoping that that can be dealt with by significantly whittling down the number of possible categories. Also, sometimes a choice will just have to be made between one category and another. If it's the wrong one, entries are easy enough to move later.

I decided to fix the blank issue issue first and will start on all of the changes mentioned above after that. I came up with two possible plans for doing that and can do either one, but have a feeling you'd prefer the alternative one. Each plan consists of a number of steps. Each step will become a separate issue in our tracker so that it can be handled independently and be referenced and linked to in the CHANGELOG.rst file:

The original plan:

1. Fix the python3 setup.py test code snippet in line 113 of the CHANGELOG.rst file on the master branch.
2. Make all links clickable.
3. Convert all entries to one-liners.
4. Choose new headings.
5. Adjust length of heading syntax.
6. Adjust heading levels, replace the headings with the new ones, and organize the entries under the new headings.

Step 5 may not be necessary if the broken headings will no longer be used based on the choices made in step 4. The problem is going to be that step 6 is what should be three separate steps done all at once in one commit (that cannot be done in separate commits because of the way the document was written and the unforgiving nature of RST files), which will be a dramatic change in the document that will be challenging to review when checking my work.

A possible alternative plan:

The only way I can see around that would be to get rid of most of the headings (leaving us with just version headings and the entries beneath them) in one commit, and then creating new headings and using them by organizing the entries beneath them in the next commit. That would look like this:

1. Fix the python3 setup.py test code snippet in line 113 of the CHANGELOG.rst file on the master branch.
2. Make all links clickable
3. Convert all entries to one-liners
4. Choose new headings.
5. Remove all headings except version headings.
6. Add new headings and organize the entries under them.

Only the first four steps in either scenario will give you that, and those are the ones I intend to do first, in the order provided. You should have an easy time reviewing the changes in those four steps.

Step 5 is different in both scenarios:

• It's optional in the first scenario and will depend on which headings were chosen in step 4. If the ones that are broken are on that list, they'll need to be adjusted in step 5 of that scenario.
• It's required in the second scenario, but will be easy for you to review.

Where we run into trouble is in step 6:

• In the first scenario, this step involves removals, changes, additions, and movement, making it messy and difficult to review.
• In the second scenario, this step involves additions and movement, which should be easier to review.

Step 6 will be rough in either case, because there's a lot of change happening, but more is happening in the first scenario. What's most important about all of this, though, is that we're not ever losing any of the entries. The only data we'll lose or gain are headings.

Thank you for thinking of me, but neither is less work for me. The file is a mess. Also, this discussion was opened for you because the pull request I did in #892 was so difficult to review that you gave up almost immediately. It makes sense to do it in steps, with each step being a commit, to make it gentler to follow.

Since steps 1 through 4 are identical in both scenarios, I'll do those on the beta, develop, and master branches individually (lots of commits). The file (in each branch) won't look much different than it does now, but we'll both be looking at exactly what it's giving us to work with.

Then, we can take it from there, and I'm basically going to be hitting you with either a sledgehammer or a mallet in the last step (possibly the last two steps, but we'll know that once we complete step 4). In either case, the diff will be misleading and will show additions and deletions rather than moves, so there's not going to be any way to get around going through both files line by line to find each one manually if you want to be certain that nothing got deleted.

How does that sound?

Oh, I sincerely hope not. I'm going to be the last woman standing who's against the use of AI and is watching its negative impacts already beginning to unfold with great interest as it follows its inevitable course to gradually fulfill her predictions.

Also, depending on what's decided in issue #493, this may become a gentler process, because Markdown files would be more forgiving of heading levels and easier to compare in diffs.