unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: 67008@debbugs.gnu.org, Ikumi Keita <ikumi@ikumi.que.jp>,
	Yuan Fu <casouri@gmail.com>, Dmitry Gutov <dgutov@yandex.ru>
Subject: bug#67008: 30.0.50; Multiple major mode parents
Date: Thu, 16 Nov 2023 10:15:22 -0500	[thread overview]
Message-ID: <jwvy1exlorh.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <7717747E-42EB-445A-8487-822C0E932465@gmail.com> ("Mattias Engdegård"'s message of "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?

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






  reply	other threads:[~2023-11-16 15:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09  5:38 bug#67008: 30.0.50; Multiple major mode parents Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-09  7:43 ` Yuan Fu
2023-11-12 22:11   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-16 15:16     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-11  0:01 ` Dmitry Gutov
2023-11-11  4:23   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-11 10:14 ` Mattias Engdegård
2023-11-11 16:20   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-11 18:12     ` Mattias Engdegård
2023-11-11 18:43       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-11 20:13     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12 13:37       ` Mattias Engdegård
2023-11-12 16:41         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-13 12:45           ` Mattias Engdegård
2023-11-13 13:30             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-13 16:44               ` Mattias Engdegård
2023-11-13 17:46                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-16 11:07                   ` Mattias Engdegård
2023-11-16 15:15                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-11-16 19:35                       ` Mattias Engdegård
2023-11-16 21:40                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-17 14:04                           ` Mattias Engdegård
2023-11-17 14:20                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-17 16:15                               ` Mattias Engdegård
2023-11-11 12:21 ` Ikumi Keita
2023-11-11 16:57   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12  9:50     ` Ikumi Keita
2023-11-12 16:04       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvy1exlorh.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=67008@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=dgutov@yandex.ru \
    --cc=ikumi@ikumi.que.jp \
    --cc=mattias.engdegard@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).