fix: Merge configurations in lexicographic order #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A
for..in
loop on aBinaryHeap
is not sorted,see https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.iter
so the old code, whilst presumably intended to be sorted, was actually
iterating with a random order.
Collecting as a
Vec
then sorting is simpler and more efficient sinceread_dir
depends on FS and can be in ascending order which degradeseach insertion from
O(1)
toO(log(n))
, amortised, forBinaryHeap
,see https://doc.rust-lang.org/alloc/collections/binary_heap/struct.BinaryHeap.html#time-complexity-3
That random order was causing downstream bugs:
"system-ui"
/"sans-serif"
/"serif"
/"monospace"
for font family settings. zed-industries/zed#22676as, e.g. inside a flatpak,
/etc/fonts/conf.d/05-flatpak-fontpath.conf
features a
<reset-dirs />
that would then hide the flatpak-specific<dir>
s like/run/host/fonts
in/etc/fonts/conf.d/50-flatppk.conf
if the
05-
file gets merged after the50-
file.