From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67008: 30.0.50; Multiple major mode parents Date: Thu, 16 Nov 2023 10:15:22 -0500 Message-ID: References: <445405AC-C0DA-4914-984E-B42671AB536D@gmail.com> <7C4E82A5-0F5A-4E04-B2BD-AD6DEC56A8C0@gmail.com> <2D8636AB-AB86-4FB5-BCCB-E10D0B9CD8C8@gmail.com> <7717747E-42EB-445A-8487-822C0E932465@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20535"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67008@debbugs.gnu.org, Ikumi Keita , Yuan Fu , Dmitry Gutov To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 16 16:16:53 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r3e6u-00057k-VF for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Nov 2023 16:16:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3e6D-0004V9-2V; Thu, 16 Nov 2023 10:16:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3e67-0004M5-1Q for bug-gnu-emacs@gnu.org; Thu, 16 Nov 2023 10:16:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3e66-0008Eo-OO for bug-gnu-emacs@gnu.org; Thu, 16 Nov 2023 10:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r3e66-0007O0-1g for bug-gnu-emacs@gnu.org; Thu, 16 Nov 2023 10:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Nov 2023 15:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67008 X-GNU-PR-Package: emacs Original-Received: via spool by 67008-submit@debbugs.gnu.org id=B67008.170014773928358 (code B ref 67008); Thu, 16 Nov 2023 15:16:02 +0000 Original-Received: (at 67008) by debbugs.gnu.org; 16 Nov 2023 15:15:39 +0000 Original-Received: from localhost ([127.0.0.1]:57417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3e5i-0007NJ-AH for submit@debbugs.gnu.org; Thu, 16 Nov 2023 10:15:39 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3e5a-0007Mz-7h for 67008@debbugs.gnu.org; Thu, 16 Nov 2023 10:15:37 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B68BC1000AD; Thu, 16 Nov 2023 10:15:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1700147724; bh=a9F/QOG1dKRZziL2ktAOJ+bXxH8FUOkvJkXAKwefjKs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nxkKXR/s35EoTimA73m6OLiUHWYuDft6e/zVTpY8Xe1oBIE2qrvOReLCIGdb8HtdX e0EoV0V2coY1uhDHImyAopoI6LITkv6qajmvriqqA22eGZP2sym2mpEqGDeXuVLYzL 92N0yk7uZMH9a+Kx3DHgjlpC/34J/CJvoa8EK5Xe/A+eupZZOgX938X6Et2fZh2aSa ukke212/wmpbkMFUk6g0O16dHQKMxYdPQ4QndwDM6lSQ6XvXcmRQw6jE6xMwUodMQ4 2EmLCZVP9xQ7qbqn6yye8UF0IiNWSYzDp4kuP+K3/QTcaehhoj0LqEnf/tfsiV62vy v/K39PZw0PJEg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 071AC100043; Thu, 16 Nov 2023 10:15:24 -0500 (EST) Original-Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CA19D1203D8; Thu, 16 Nov 2023 10:15:23 -0500 (EST) In-Reply-To: <7717747E-42EB-445A-8487-822C0E932465@gmail.com> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Thu, 16 Nov 2023 12:07:58 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274463 Archived-At: >> 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