GNU bug report logs - #67008
30.0.50; Multiple major mode parents

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67008 <at> debbugs.gnu.org, Ikumi Keita <ikumi <at> ikumi.que.jp>, Yuan Fu <casouri <at> gmail.com>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#67008: 30.0.50; Multiple major mode parents 
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.