Steve, could you take a look? Possibly related to the histograms.xml/enums.xml split?

I suspect this was either a copy-paste error or a bug in the pretty printer script.

Regression introduced here: https://chromium.googlesource.com/chromium/src/+/d1ada059c7362462bf72dc44c103db994362d9c3%5E%21/#F18

It was a git cl format.

This isn't related to the xml split, it's been around for a while.  This occurs when the node immediately after the summary/comment is sorted to a new position, the summary/comment follows it.  So it's pretty-print stable to just move them back up to the top again.

There is a relevant comment in pretty_print_xml.py
          # Subnodes that we don't want to rearrange use the next node's key,
          # so they stay in the same relative position.
          # Therefore we delay setting key until the next node is found.

Basically all other kinds of nodes than the one being sorted (in this case, int) are considered attached to the next node.  This usually makes sense for comments, e.g. if you write a comment about the integer it should follow that value around when it gets sorted.  It doesn't make sense for summary, since there is a correct position for it, but the alphabetization rules don't currently express our preference for that.

I put the comment and summary back in the right place in https://chromium.googlesource.com/chromium/src/+/408bddbca79a0709ec2daa97872426c39bfe04b7. 

I'm not clear whether there's anything else we should do to the scripts to prevent future recurrence.

There are 2 things that need to happen.

1. We need to update the alphabetization rules in
tools/metrics/histograms/print_style.py to express an order preference

2. We need to update the code that applies those rules in:
tools/metrics/common/pretty_print_xml.py to to be able to understand and apply the rules we added in #1