From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62417: ; Regression: 59ecf25fc860 is the first bad commit Date: Fri, 24 Mar 2023 19:48:35 +0000 Message-ID: <87pm8yaq24.fsf_-_@gmail.com> References: <87sfducmrc.fsf@gmail.com> <87o7oicgy4.fsf@gmail.com> <87wn365e3t.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17038"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62417@debbugs.gnu.org To: Philip Kaludercic , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 24 23:02:49 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 1pfpUm-00046m-F9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Mar 2023 23:02:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfpTB-000401-Cz; Fri, 24 Mar 2023 18:01:09 -0400 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 1pfpT8-0003xR-Gr for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 18:01:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pfpT8-0000eY-7y for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 18:01:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pfnNN-0003Ws-VR for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 15:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Mar 2023 19:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62417 X-GNU-PR-Package: emacs Original-Received: via spool by 62417-submit@debbugs.gnu.org id=B62417.167968720613541 (code B ref 62417); Fri, 24 Mar 2023 19:47:01 +0000 Original-Received: (at 62417) by debbugs.gnu.org; 24 Mar 2023 19:46:46 +0000 Original-Received: from localhost ([127.0.0.1]:41413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfnN7-0003WL-JT for submit@debbugs.gnu.org; Fri, 24 Mar 2023 15:46:45 -0400 Original-Received: from mail-ed1-f50.google.com ([209.85.208.50]:34736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfnN6-0003W7-2k for 62417@debbugs.gnu.org; Fri, 24 Mar 2023 15:46:44 -0400 Original-Received: by mail-ed1-f50.google.com with SMTP id b20so12198072edd.1 for <62417@debbugs.gnu.org>; Fri, 24 Mar 2023 12:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679687198; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uH0QQ38M4PtmAAKrbS8AdB2WGVne4pDeCySeyOWse7E=; b=GdeERv4Ur4JvTIcbdj4mimDmQDlEtAlHybHQ28UvYBrcTuBtmxJ09mW07EqnnQ/qoH Tz6S1bQUzf7TKYyZCbSOXoX7WdVzdGYUKW1q/vzFsosEG3RHBbS4AgiKbHUfehVdlE+a uCT3VKilr8rhsGX+vUS+FMVwxnl6bSGc7rx/EuO0ItC3rAnhPKzGKALplm5JL20xvDBr DiVMipxZM3xshe8vszj9KkbJXp8eOAvPOz8Jr4cniEmsYUs9hjSxazXrVClpB2FeU2Kp iItlIsB8JiCXyfkH7vpy/+tDhARNGJS4q6wU8ttXEwBGxxumPDFrNiPiyfcjPawdsBdr VdLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679687198; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uH0QQ38M4PtmAAKrbS8AdB2WGVne4pDeCySeyOWse7E=; b=TSt3dsXippXmf0b+wFrzwLbPkMvs9I8fissz85sL5jNjF50dXwNwmuhV1akZ/G2Xjl qOFlQvkN1mjdWH7dYnwIuqsffM9WUYA/c/sKKWm7ELW2Wpcv+fI5MDeL/lQu5NVKBxKo J8jAedVWeQwyzUVh3S9k8Z0xnFd+Sa8xPh5/ev9aVH6sWwGIoiZTVi9andKPSH5b8UyH u2nw2QQiYXaxF8mgrAG4kzQWMElajlWfM80s90A7S0CqVS9uyoxwJeXbGZvU2XF58Enj 2X+s/ZLXYVqMWfaLnA/WLsgtW/lZ7gze0t0/isfBvaxKoBVHZrPmjgiQ2Im5QC7lHayT y8aw== X-Gm-Message-State: AAQBX9f/dQkNnLTWsjTyVTR87EKRQyXdG7m3hPHineArW85c7zJPBv4s XnIK+GkL1X2u1k5r10eC/uuNh+CCCMQ= X-Google-Smtp-Source: AKy350a91ZGdKmsNxmlAhP7aAqNopRrbNemoK9+9KQxfEdMTKg+FnlbFHW8HwbdOQxapx5shmWwOTg== X-Received: by 2002:a17:906:7109:b0:931:32f5:1f31 with SMTP id x9-20020a170906710900b0093132f51f31mr4005818ejj.9.1679687197834; Fri, 24 Mar 2023 12:46:37 -0700 (PDT) Original-Received: from krug (87-196-72-75.net.novis.pt. [87.196.72.75]) by smtp.gmail.com with ESMTPSA id gt6-20020a170906f20600b0092a3b199db8sm10539971ejb.186.2023.03.24.12.46.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 12:46:37 -0700 (PDT) In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Fri, 24 Mar 2023 16:07:52 +0000") 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:258513 Archived-At: Jo=C3=A3o T=C3=A1vora writes: >> > Another way would be to fix this in buffer-match-p. >> I cannot make out what is broken in `buffer-match-p'? The patch would >> appear to me to be redundant, because both strings and functions are >> handled the same way in that function. If you could explain the >> background, I think it would be better to fix `buffer-match-p', >> considering that this should be how it behaves. > If you pass a string to buffer-match-p, it will become > a buffer by the time it is passed to the function. So > functions that expect strings cannot be in > buffer-display-alist after your change, whereas before > they could. If the previous explanation is somehow hard to understand, here's a hopefully simpler one with a repro which doesn't require SLY. In Emacs 28 the docstring for `display-buffer-alist` states (emphasis mine): If non-nil, this is an alist of elements (CONDITION . ACTION), where: =20=20=20=20 CONDITION is either a regexp matching buffer names, or a function that takes two arguments - a buffer name and the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ACTION argument of `display-buffer' - and returns a boolean. In Emacs 29, the docstring was changed to state: If non-nil, this is an alist of elements (CONDITION . ACTION), where: =20=20=20=20=20 CONDITION is passed to `buffer-match-p', along with the buffer that is to be displayed and the ACTION argument of `display-buffer', to check if ACTION should be used. Any code that was written for the Emacs 28 contract in mind like, for example: (defun foop (buffer-name _alist) (string-match "foop" buffer-name)) (add-to-list 'display-buffer-alist '(foop . display-buffer-other-frame)) Will now fail with an obscure error message. I've checked "Incompatible Lisp Changes in Emacs 29.1" in etc/NEWS and could not find a mention to this, so I assume it was not intentional. So it is most clearly a regression. We should plug it in Emacs 29 as quickly as possible.=20=20 I showed one way to go about it, but maybe other ways are possible, like extending the `buffer-match-p' mini-language to allow for this case -- not sure that is feasible since it could require asking its CONDITION function if it accepts buffers or buffer names. Or requiring that all CONDITION functions added in the wild now also support buffer names. Whichever way we go, the Emacs 28 contract of `display-buffer-alist` must be upheld before Emacs 29 is released. Jo=C3=A3o