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: Mon, 27 Mar 2023 17:38:45 +0100 Message-ID: <871qlaup2i.fsf@gmail.com> References: <87sfducmrc.fsf@gmail.com> <87o7oicgy4.fsf@gmail.com> <87wn365e3t.fsf@posteo.net> <87pm8yaq24.fsf_-_@gmail.com> <83fs9tc7o9.fsf@gnu.org> <83cz4xc6hg.fsf@gnu.org> <83zg80c40u.fsf@gnu.org> <87a5zzuutl.fsf@gmail.com> <83h6u79bjl.fsf@gnu.org> <875yamv1ox.fsf@gmail.com> <838rfi9udc.fsf@gnu.org> <83zg7y8blb.fsf@gnu.org> 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="5902"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: philipk@posteo.net, 62417@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 27 18:37:28 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 1pgpqZ-0001BQ-P4 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Mar 2023 18:37:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgpqN-0000Xe-HU; Mon, 27 Mar 2023 12:37:15 -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 1pgpqB-0000VD-L3 for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 12:37:04 -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 1pgpqB-0004b5-8h for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 12:37:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgpqA-0004CN-Js for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 12:37:02 -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: Mon, 27 Mar 2023 16:37:02 +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.167993501316116 (code B ref 62417); Mon, 27 Mar 2023 16:37:02 +0000 Original-Received: (at 62417) by debbugs.gnu.org; 27 Mar 2023 16:36:53 +0000 Original-Received: from localhost ([127.0.0.1]:48297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgpq0-0004Br-Se for submit@debbugs.gnu.org; Mon, 27 Mar 2023 12:36:53 -0400 Original-Received: from mail-wm1-f47.google.com ([209.85.128.47]:36391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgppz-0004Bb-32 for 62417@debbugs.gnu.org; Mon, 27 Mar 2023 12:36:51 -0400 Original-Received: by mail-wm1-f47.google.com with SMTP id j18-20020a05600c1c1200b003ee5157346cso7784658wms.1 for <62417@debbugs.gnu.org>; Mon, 27 Mar 2023 09:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679935004; 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=o53PfKExfAYCJzmMdPsVzxia2eSFiT5/DvebDRCaBcg=; b=ASO+UKjZFVJ3V6IIeL8hW38QW0HhCkeWW5w6GjSKV1Kx9JKLClWQuO3ND4aYpcpOcU 0BUm/ISY7gDQdokWKAmBRnzPgPGi1Ank3Acyc6Ctf0iFdGwPq13RgzUU//RIn4STaFEz 19+0I6fYiXaH/g0ZfoYiqpZ04h8J96i7ZZ0pYrfMUdQL5Vm8QOMhQU1ye71WomWGgFsF SSr1Yh44xXGz/FplCnTcwafbBbsBi5DLLSUO6h22CT9S2cCTAduMQR1Wrw6pScgcl57c nbSxc7ZRFcOhhAW/vk7IrvltYcxvrWdLyGGYb0MWL+8x1vex0KvN2jxp/BLJeMim2K/i Cg8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679935004; 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=o53PfKExfAYCJzmMdPsVzxia2eSFiT5/DvebDRCaBcg=; b=Y34RPIDYbjjm9umbO0T4N4+lXYzGdBflGr/UTyRUZLbhHaOW5DPX9rsaAajJhxlrw4 vV50tfzeNO+ejpE2q+TN29n3Ehdk2qYILUaA/41F1urBUKw9c7dzw018bf0z0QOkeNwc v9henI1ozPhcQUpOAwAfLVPT4HvjsBXgZN3/qE5TAlCdkioK3Cf2sb2tDgo20c3mw8ru TN0s4lQ8ISmV8KfVlR5QiVx2zJAHGO1Sn2WYuaqbJGPTZmEI4ycZobSpk0kiqwUEAPUu 7pLAyR+RShFdObZxUoqkxgxezzXRk4I0GAgWENTqiSpIB62btlSMG2ckbZKOtaD2yvpR OgJg== X-Gm-Message-State: AAQBX9dfDsijpQGiBlhvFdy6vMUJWa+ZmmM5h3Nx2kxzp48932RtDicC UoQlWOMvcot3fk6u9dCheprRxQtjptk= X-Google-Smtp-Source: AKy350ZZDPH0HeZJd1Uev+mCRPap8bwVARvh2GwFLRPxyPtLxdefY2PatDd9g5osjXCNpphw0RSuiQ== X-Received: by 2002:a7b:cd18:0:b0:3ef:6aa1:9284 with SMTP id f24-20020a7bcd18000000b003ef6aa19284mr4184491wmj.29.1679935003999; Mon, 27 Mar 2023 09:36:43 -0700 (PDT) Original-Received: from krug ([87.196.74.168]) by smtp.gmail.com with ESMTPSA id f23-20020a7bcd17000000b003eea205671fsm12680783wmj.39.2023.03.27.09.36.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Mar 2023 09:36:43 -0700 (PDT) In-Reply-To: <83zg7y8blb.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 27 Mar 2023 18:20:48 +0300") 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:258758 Archived-At: Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Date: Mon, 27 Mar 2023 14:08:17 +0000 >> Cc: philipk@posteo.net, 62417@debbugs.gnu.org >>=20 >> > since buffer-match-p accepts >> > both buffers and their names. Please explain. >>=20 >> In the patch I showed, which you and Philip approved, the docstring of >> the variable display-buffer-alist was clarified to state that it is a bu= ffer >> name string, and _not_ a buffer object, that is passed to buffer-match-p. >> This is absolutely necessary, and we've already been through this. > > I don't understand why this is necessary, and I didn't intend to limit > buffer-match-p to accepting only buffer names. I'm _not_ doing that. Buffer-match-p continues to accept buffer objects or buffer names. It's only that _when given a buffer name and a function, it will call that function on the buffer name string_.=20 > Please explain why is it necessary. I've tried already 3 or 4 times. I don't understand how better to explain than to show you some perfectly code that worked on Emacs 28 and doesn't work in Emacs 29 from yesterday. If you want I will revert the patch, but _some_ solution should be found. Unforeseen, unmotivated, backward-incompatible lisp changes this late in the game would be a sad thing. > What I did say was that _if_ buffer-match-p will be able to accept > _both_ buffer names and objects _and_ will pass to the function > exactly the argument it was passed, i.e. either a buffer object or a > name of a buffer, _then_ the backward-incompatibility will be solved. And this is _exactly_ what happens. But that, by itself is not enough, becase display-buffer-assq-regexp was _also_ changed to always pass buffer objects along with functions that expect buffer names. > > which prepares the alist that will be passed to display-buffer. > >> But naturally it's not enough to simply state that fact in a docstring. >> You have to actually make good on the promise by actually passing a >> buffer name to buffer-match-p, and not a buffer. Otherwise, the user >> functions that the user places in display-buffer-alist WILL be called wi= th a >> buffer _object_ always. And for people programming against Emacs < 29, >> those functions are always passed a buffer name _string_. > > Yes, but why in display-buffer-assq-regexp? That function is not > supposed to have any knowledge about functions in > display-buffer-alist. With the change you made you basically preclude > display-buffer-alist from having functions that want to accept buffer > objects. That is not right. Because that function was changed in order for buffer-match-p. It was _that_ change that broken compatiblity. But it can be fixed anywhere else. > So why cannot the code which prepares the alist make sure the function > accepts only buffer names, not buffer objects? The alist is open to the public, it is the user-facing interface. The "code that prepares the alist" is out in the wild and has worked fine from Emacs 24 on, maybe even earlier. >> I think there is still confusion. It's understandable, as this new >> buffer-match-p protocol makes what was previously a relatively simple >> protocol is much harder to understand, because there's an added level >> of indirection. Presumably added in the name of flexibility, but that >> flexibility actually already existed in Emacs 28, the buffer-match-p >> mini-language just adds so-called syntactic sugar. >>=20 >> As I said: there are other perfectly plausible ways to address this >> problem, including removing buffer-match-p from display-buffer-alist >> logic and losing this particular sugar. > > Please don't fight "rearguard fights". We are not going back on this > change which introduced buffer-match-p. So suggesting that is a > non-starter. Just a suggestion. It is one of the many things that would fix this. >> > (And I wish you >> > explained this before pushing, since there's no special rush anyway.) >>=20 >> There are people with broken SLYs in the Emacs 29 builds and master >> for a long time. See the original link. I wish I didn't let it get >> this far, that was my bad, but this is hurting users today. > > The users can easily make local changes. That is not a reason to rush > changes which were not agreed upon, and leave some of us with bad > taste. The bad tasting thing here was introducing the bug in the first place. I'm just trying to solve it. I've proposed two ways already. If you have better one, go ahead, I don't care, I really don't. I just want SLY users not to have to worry about this. Jo=C3=A3o