From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62417: ; Regression: 59ecf25fc860 is the first bad commit Date: Mon, 27 Mar 2023 18:20:48 +0300 Message-ID: <83zg7y8blb.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39629"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, 62417@debbugs.gnu.org To: =?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 Mon Mar 27 17:21:19 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 1pgoes-0009yY-Au for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Mar 2023 17:21:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgoef-0004nk-4b; Mon, 27 Mar 2023 11:21:05 -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 1pgoed-0004mD-Ov for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 11:21:03 -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 1pgoed-0004yJ-B8 for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 11:21:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgoec-0007sP-Hg for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 11:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Mar 2023 15:21: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.167993045630243 (code B ref 62417); Mon, 27 Mar 2023 15:21:02 +0000 Original-Received: (at 62417) by debbugs.gnu.org; 27 Mar 2023 15:20:56 +0000 Original-Received: from localhost ([127.0.0.1]:47983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgoeW-0007ri-AH for submit@debbugs.gnu.org; Mon, 27 Mar 2023 11:20:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgoeU-0007rS-5G for 62417@debbugs.gnu.org; Mon, 27 Mar 2023 11:20:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pgoeM-0004uW-9f; Mon, 27 Mar 2023 11:20:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=WHzqYGIsuyoLaSG3IpBUZo8b04gmaPagAdHD5qic9IY=; b=TQwjIMKcWHMP0ebS8E6E pMjzA2Rft5rPL7z+el6zcC03TvRYXAkwMkMvtFiwXQb9/UXAN50s3RD8aYOWlu8g0EC4CxJmLYszE H2eGKYmeD4+jkUYbBbb2OqUlyeDSUIFbMzi93NwsvmV9H2+mUkIrEuNbj4W5rf4f15YL16UwpXpDU UWqz4W2C6bFG7cmEfT9FAuCKqoiFYiivjsyEh6JOgZvXzeOox0JH1Z2KTgNLCo/TsB1DawLD/hdqj s4sjeC1MRMblBnG2oidyXex2jhTZOJXUnq6iDS/ctD4gWl379kwdZd78cFlDazkjsCrRxEHbpqVXp NWJJAmm1/ED1zg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pgoeL-0006oi-4w; Mon, 27 Mar 2023 11:20:45 -0400 In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 27 Mar 2023 14:08:17 +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:258742 Archived-At: > From: João Távora > Date: Mon, 27 Mar 2023 14:08:17 +0000 > Cc: philipk@posteo.net, 62417@debbugs.gnu.org > > > since buffer-match-p accepts > > both buffers and their names. Please explain. > > 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 buffer > 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. Please explain why is it necessary. 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. The responsibility of making sure buffer-match-p accepts a name when the function expects only names is _on_the_caller_. And the caller is NOT display-buffer, it's the Lisp code which calls display-buffer or 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 with 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. So why cannot the code which prepares the alist make sure the function accepts only buffer names, not buffer objects? > 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. > > 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. > > (And I wish you > > explained this before pushing, since there's no special rush anyway.) > > 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.