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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
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 10:15:22 -0500

>> 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?

The text I wrote above says that it does (and I stand by it, and your
test cases additionally shows that it does), so I don't understand
the question.

> We only get a consistent (monotonic) result if the input is
> ordered correctly.

Not sure what you mean by that.  The vertical edges are the ones that
need to be obeyed to guarantee monotonicity (because they are the ones
that come from linearizations of other classes), the horizontal ones
represent the preferences expressed by the order in which direct parents
are listed by the programmer, so they are "softer".

> 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).

If that's what you want to compute, then yes, that's what you need to do :-)

> 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.

I'm not super happy with my phrasing, but I must say that really your
above paragraph I don't really know what it means either, so for me it's
a wash.  I have now pushed my code to `master`, so feel free to update
the docstring there as you see fit.

> `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.

Let me know if you find out.


        Stefan

Previous Next

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