Subject: bug#67008: 30.0.50; Multiple major mode parents

From: Mattias Engdegård <[email-masked]>
Date: Thu, 16 Nov 2023 12:07:58 +0100

> Yes we strictly obey the vertical edges (and call `error-function` when
> that's not an option) and we use the horizontal edges when there's
> a choice.

Yes, but `merge-ordered-lists` doesn't distinguish between vertical and horizontal edges in any way, does it? We only get a consistent (monotonic) result if the input is ordered correctly.

In that respect `merge-ordered-lists` is just half an algorithm. We could add the other half but presumably this wouldn't be a good fit in places where the function is currently used?

The other half might be something like: compute the linear order for each parent in sequence, then add the partial order (NODE PARENT1...PARENTn).

The documentation text

> The order of the (sub)lists determines the final order in those cases where
> the order within the sublists does not impose a unique choice.
> Equality of elements is tested with `eql'.

could perhaps be written more precisely to say that when the constraints do not impose a relative order between elements (not sublists), they are ordered by their occurrence in the input.

`merge-ordered-lists` should also have the left-to-right property that

(merge-ordered-lists (append X Y))
= (merge-ordered-lists (cons (merge-ordered-lists X) Y))

although I haven't verified this.