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: Mon, 13 Nov 2023 08:30:22 -0500 Message-ID: References: <445405AC-C0DA-4914-984E-B42671AB536D@gmail.com> <7C4E82A5-0F5A-4E04-B2BD-AD6DEC56A8C0@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="7904"; 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 Mon Nov 13 14:31:52 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 1r2X2c-0001kJ-64 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Nov 2023 14:31:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2X2D-00013W-1Q; Mon, 13 Nov 2023 08:31:25 -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 1r2X2A-000130-7X for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2023 08:31:22 -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 1r2X28-00046l-TH for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2023 08:31:21 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r2X2n-0004u8-Up for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2023 08:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Nov 2023 13:32:01 +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.169988227418791 (code B ref 67008); Mon, 13 Nov 2023 13:32:01 +0000 Original-Received: (at 67008) by debbugs.gnu.org; 13 Nov 2023 13:31:14 +0000 Original-Received: from localhost ([127.0.0.1]:57663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2X22-0004t0-2C for submit@debbugs.gnu.org; Mon, 13 Nov 2023 08:31:14 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2X1z-0004sm-Fw for 67008@debbugs.gnu.org; Mon, 13 Nov 2023 08:31:12 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0FFF81000AD; Mon, 13 Nov 2023 08:30:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699882223; bh=APztaK8xO88x9Rf4LXQr8D2oHvfs/MwGEPhrv/5lD1c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WX5r7NcgWbVDiiCD3tdw+9IDgUeX7eSvKbAgthJmln5doVvBWuFLQ9jG221hWchH2 UeZAGUWhsucZJ5pnPjKZYzfysOLLVZVj5DpiaL7EUFHlcSETN0HDfPAm1r1hZtaJz3 wTVQ6HHHACdMpwwPs4/cQIfbEk04I16ilvQzPJElg316bnXOzpOxJtmJSKFD6aDiG1 k9m2A1NTtnGAuihALX9dCIXk0r0rnJT0wsXMDY9cXzADiA5H7h4MEVLJfTJMo3ebi0 GldpNA4E5ky1qCSigfsv5H+YDLxTu6pqOtYZk74AJGfAXOTsykrASLr17SlJ3037Iq dcXpsYIS3Altw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5E066100061; Mon, 13 Nov 2023 08:30:23 -0500 (EST) Original-Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2ACCE120270; Mon, 13 Nov 2023 08:30:23 -0500 (EST) In-Reply-To: <7C4E82A5-0F5A-4E04-B2BD-AD6DEC56A8C0@gmail.com> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Mon, 13 Nov 2023 13:45:59 +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:274254 Archived-At: >> I improved the docstring to try and clarify. > Thank you, but the new 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. > still doesn't explain how the sublist order affects the choice of linearisation. Suggestions welcome to make it better. I couldn't come up with a wording that is both short enough and clear. > Since I'm here: >> (while (cdr (setq lists (delq nil lists))) > When this loop is entered the first time, `lists` still holds the argument > which probably shouldn't be mutated even if it's for removing empty lists > inside. (In later iterations it seems to be a copy.) I guess you're right. The list passed to it is always freshly made, so it's not a real problem in practice, but it's a bit ugly. > +(ert-deftest subt-tests--merge-ordered-lists () > ^ > r Damn, you caught my subt-erfuge! > + (should (equal (merge-ordered-lists > + '((B A) (C A) (D B) (E D C))) > + '(E D B C A))) > + (should (equal (merge-ordered-lists > + '((E D C) (B A) (C A) (D B))) > + '(E D C B A))) > + (should-error (merge-ordered-lists > + '((E C D) (B A) (A C) (D B)) > + (lambda (_) (error "cycle"))))) > > All calls should error on cycles, not just the one that actually contains one. Fair enough. > Maybe the default value for the `error-function` argument should be one that > raises an error, so that callers need to specify something explicitly if > they want a different behaviour? I decided against that because the existing evidence is that we prefer to hide the problem than to signal an error. Part of the issue is also that in practice most "cycles" aren't real: they are the result of submode/subtype relationships where two types/modes have linearized their parents in incompatible ways. E.g. C inherits from (A B) D inherits from (B A) E inherits from (C D) there is no cycle in the inheritance, but since the linearization is done piecemeal (a.k.a locally), you get to merge ((C A B) (D B A)) and that finds a "cycle". That's why EIEIO calls it `inconsistent-class-hierarchy` rather than `cycle`. Stefan