GNU logs - #66890, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Daniel Nagy <danielnagy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Nov 2023 05:54:02 +0000
Resent-Message-ID: <handler.66890.B.169890442312125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 66890 <at> debbugs.gnu.org
From: Daniel Nagy <danielnagy@HIDDEN>
Date: Wed, 01 Nov 2023 16:31:01 +0000
Message-ID: <8734xp77vl.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.66; envelope-from=danielnagy@HIDDEN;
 helo=mout02.posteo.de
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Mailman-Approved-At: Thu, 02 Nov 2023 01:53:40 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello,

The current signature of #'buffer-size is:

    (buffer-size &optional BUFFER)

It can only handle actual buffer objects as the argument. Could it be
made to accept the buffer name as a string as well? So that it's
signature would become:

    (buffer-size &optional BUFFER-OR-NAME)

Other functions, like #'get-buffer already do this.

Thanks,
--
Daniel Nagy

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Daniel Nagy <danielnagy@HIDDEN>
Subject: bug#66890: Acknowledgement (29.1; buffer-size should also accept
 the buffer's name as string argument)
Message-ID: <handler.66890.B.169890442312125.ack <at> debbugs.gnu.org>
References: <8734xp77vl.fsf@HIDDEN>
X-Gnu-PR-Message: ack 66890
X-Gnu-PR-Package: emacs
Reply-To: 66890 <at> debbugs.gnu.org
Date: Thu, 02 Nov 2023 05:54:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 66890 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
66890: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66890
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Nov 2023 06:34:02 +0000
Resent-Message-ID: <handler.66890.B66890.169890681716385 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Daniel Nagy <danielnagy@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org
Date: Thu, 02 Nov 2023 08:32:38 +0200
Message-Id: <83edh88y2h.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <8734xp77vl.fsf@HIDDEN> (message from Daniel Nagy on Wed, 01
 Nov 2023 16:31:01 +0000)
References: <8734xp77vl.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Daniel Nagy <danielnagy@HIDDEN>
> Date: Wed, 01 Nov 2023 16:31:01 +0000
> 
> The current signature of #'buffer-size is:
> 
>     (buffer-size &optional BUFFER)
> 
> It can only handle actual buffer objects as the argument. Could it be
> made to accept the buffer name as a string as well? So that it's
> signature would become:
> 
>     (buffer-size &optional BUFFER-OR-NAME)
> 
> Other functions, like #'get-buffer already do this.

It's very easy to get the buffer from its name.  You could do

  (buffer-size (get-buffer BUFFER-OR-NAME))

So I wonder whether it is worth our while to convert more functions to
accept both buffers and names of buffers.

Stefan, WDYT?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Nov 2023 19:40:02 +0000
Resent-Message-ID: <handler.66890.B66890.169895395120283 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>, Daniel Nagy <danielnagy@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <83edh88y2h.fsf@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
MIME-Version: 1.0
Date: Thu, 2 Nov 2023 12:38:26 -0700
Message-ID: <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

tags 66890 + moreinfo
thanks

Eli Zaretskii <eliz@HIDDEN> writes:

> It's very easy to get the buffer from its name.  You could do
>
>   (buffer-size (get-buffer BUFFER-OR-NAME))
>
> So I wonder whether it is worth our while to convert more functions to
> accept both buffers and names of buffers.
>
> Stefan, WDYT?

I'd lean towards not making the proposed change, as it stands.

Perhaps, for the sake of consistency, we should allow buffer names in
either none or all buffer-related functions.  But the only example given
so far is `get-buffer', and I don't really see how we could possibly
disallow using strings there.  Thus, it's not very convincing.

If anyone is interested in making a better case for this change, a
single example is not enough.  I'd suggest starting with a review of
what we have now, for example something like `M-x apropos-function RET
^buffer- RET'.

Without such a review, I don't really see that we have grounds for
making any changes here.  So I'm tagging this bug "moreinfo".

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 2 Nov 2023 19:39:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 15:39:10 2023
Received: from localhost ([127.0.0.1]:56171 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qydX4-0005Gy-Cn
	for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 15:39:10 -0400
Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:42165)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1qydX2-0005Ga-HB
 for control <at> debbugs.gnu.org; Thu, 02 Nov 2023 15:39:09 -0400
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-2c6b5841f61so14679491fa.0
 for <control <at> debbugs.gnu.org>; Thu, 02 Nov 2023 12:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1698953907; x=1699558707; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=j9E4XhLvoXWMlLwTpqI7MccJx+gtmp71ZduL4L6MR/k=;
 b=cB9ljjAOMT8sY7+bGAfAnib6kGq36lYqO7vMsitmwOz8n4CcVKUNkiXeq+pKp1iSVH
 bW+wjyVYOBdzy/QhqmdXiROSMnVj/iPqSPstUx3i6pUS1UBWH2Bas4sixyah9x6HbTbo
 IFNdU4Xmx+D2iG8Ot9gt8f81yKvMgtSVAGUWj3Kpk/29GXrfvBV8H5jIG2MK6nV3KQt4
 vTCpUaVMoIHFGHxEnBlot7yAs1MbJ3Ehza0x3VO7jPD/nhUmI9Hdo9AVbdBDEk0AgJPN
 X50DYCR6wRT5XdbOqBi9rWnCBzUuqtoMTgh5ob6Om0KLl2LiMwKODYKUP1kLqTe1nSRM
 YYXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698953907; x=1699558707;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=j9E4XhLvoXWMlLwTpqI7MccJx+gtmp71ZduL4L6MR/k=;
 b=raZ60WX2F39OsZPQzltUI5+YgTW+tgCpOQbin/494tcJQ+NCGGdG4OBnkvMwc5sFab
 P6PhPGoy1GWGCwTh/BI9r6tH5e2djhqDUGKYMsno3sJWNJGB3YT4UyTQFetdPfg8132D
 tHZ3k0S/QNvwajlkoCLseiOwwuauGLG8okG5xZGU/2zfIC/Udqbyr0RWwUxPMvmSH5SZ
 1VJTCkxkouPYoNGJ+L3tNYxRlq5E0KduDbN2C4LpBHD9/D9wqGTLpH9matoKtoOwFkeB
 Pm9zm7FSfzs3ejMT+gHKyslHtOzR28cCOiqNJhEpe8oew3HbwwDOoYQdvwtdvnmpBcti
 fQ+A==
X-Gm-Message-State: AOJu0YzINMU82rYkAGHi+dY9TWdKscmvTuTenSGTBJdtqqg5/6AGcAuQ
 5wTdn7IDRvrqfR4so11zQb/UwNZRiHMbQVMTWFI=
X-Google-Smtp-Source: AGHT+IGk0N//VGl+AKJa47wr9F2HQ1qwNEVaqUKB/qndGW6nDDsIcuylHxdo40+CPzLgVmEPDS7mLHYiC0+PoxkwQv8=
X-Received: by 2002:a2e:990c:0:b0:2c5:dc3:5780 with SMTP id
 v12-20020a2e990c000000b002c50dc35780mr261930lji.8.1698953907135; Thu, 02 Nov
 2023 12:38:27 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Thu, 2 Nov 2023 12:38:26 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <83edh88y2h.fsf@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
MIME-Version: 1.0
Date: Thu, 2 Nov 2023 12:38:26 -0700
Message-ID: <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
Subject: Re: bug#66890: 29.1; buffer-size should also accept the buffer's name
 as string argument
To: Eli Zaretskii <eliz@HIDDEN>, Daniel Nagy <danielnagy@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Bcc: control <at> debbugs.gnu.org
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
Cc: 66890 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

tags 66890 + moreinfo
thanks

Eli Zaretskii <eliz@HIDDEN> writes:

> It's very easy to get the buffer from its name.  You could do
>
>   (buffer-size (get-buffer BUFFER-OR-NAME))
>
> So I wonder whether it is worth our while to convert more functions to
> accept both buffers and names of buffers.
>
> Stefan, WDYT?

I'd lean towards not making the proposed change, as it stands.

Perhaps, for the sake of consistency, we should allow buffer names in
either none or all buffer-related functions.  But the only example given
so far is `get-buffer', and I don't really see how we could possibly
disallow using strings there.  Thus, it's not very convincing.

If anyone is interested in making a better case for this change, a
single example is not enough.  I'd suggest starting with a review of
what we have now, for example something like `M-x apropos-function RET
^buffer- RET'.

Without such a review, I don't really see that we have grounds for
making any changes here.  So I'm tagging this bug "moreinfo".

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Daniel Nagy <danielnagy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Nov 2023 20:58:02 +0000
Resent-Message-ID: <handler.66890.B66890.16989586546172 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: 66890 <at> debbugs.gnu.org
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.16989586546172
          (code B ref 66890); Thu, 02 Nov 2023 20:58:02 +0000
Received: (at 66890) by debbugs.gnu.org; 2 Nov 2023 20:57:34 +0000
Received: from localhost ([127.0.0.1]:56274 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qyekw-0001bU-20
	for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 16:57:34 -0400
Received: from mout01.posteo.de ([185.67.36.65]:43715)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <danielnagy@HIDDEN>) id 1qyekr-0001b9-TW
 for 66890 <at> debbugs.gnu.org; Thu, 02 Nov 2023 16:57:32 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 916E2240027
 for <66890 <at> debbugs.gnu.org>; Thu,  2 Nov 2023 21:56:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017;
 t=1698958608; bh=9J0EVrvbVXULRrV0APCYQdkmKWNOO0ENU9AOuf/rmwY=;
 h=From:To:Subject:Date:Message-ID:MIME-Version:From;
 b=r4sRPhYshbfrBGRbCFNNAPn45bS5kpdSk1AdruvG7Mv9emyHkrZpd6Gxsu6KXUYYH
 EopAMhM5LSh0GMLgd99xM+yymnPDjB0EGtZNJ/VCnRgl8fCmTOA9rLxzb6jocmmZdl
 fIs/OdXAruDptLl9wRaIFxsikhtnudRpvSunSKoxdN6wnbVoPydwW8HCz87cLXjlcD
 dd+ZUx7Gb6wqBD9jccd4h3GM6LWheom9pGtzMzn7hcIaKXrgikoBVEA0dpDUqKKw56
 K180KSkDpRn/q3s8ax1UoAAGliRXWwm2UoUcGcNmOkvlOcLgv0qtQc0mLs+buEV7Q7
 xm16udZ1ymOWw==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4SLx4w11G5z6tvb
 for <66890 <at> debbugs.gnu.org>; Thu,  2 Nov 2023 21:56:48 +0100 (CET)
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
From: Daniel Nagy <danielnagy@HIDDEN>
Date: Thu, 02 Nov 2023 20:55:55 +0000
In-reply-to: <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
Message-ID: <877cmzzxf5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

(resending only to debbugs.gnu.org because my previous mail had delivery
problems)

These are the additional functions/macros, that I found using `M-x
apropos-function', that accept both types of arguments:

    `buffer-hash'
    `buffer-match-p'
    `buffer-text-pixel-size'
    `bury-buffer'
    `display-buffer'
    `get-buffer-create'
    `get-buffer-window'
    `get-buffer-window-list'
    `kill-buffer'
    `pop-to-buffer'
    `project-display-buffer'
    `project-display-buffer-other-frame'
    `project-switch-to-buffer'
    `replace-buffer-in-windows'
    `set-buffer'
    `set-window-buffer'
    `switch-to-buffer'
    `switch-to-buffer-other-frame'
    `switch-to-buffer-other-tab'
    `switch-to-buffer-other-window'
    `tab-bar-get-buffer-tab'
    `temp-buffer-window-setup'
    `window-normalize-buffer'
    `window-normalize-buffer-to-switch-to'
    `with-current-buffer'
    `with-current-buffer-window'
    `with-displayed-buffer-window'
    `with-temp-buffer-window'

The number of functions, that only accept a buffer is vast and probably
outnumbers that list above, so I am not going to list them here.

These are some disadvantages of such a change, that come to my mind:

    1. Could the acceptance of a string in that place of the argument
       prohibit possible future possibilites?

    2. Does the newly accepted argument type sacrifice function purity
       and/or side-effect-freeness?

    3. API inconsistency.

    4. Slightly increased code complexity, especially in the C part of
       the code base.

My commentary in this particular case would be, that I dont see how now
accepting strings in addition would shadow any future usage of that ( or
other ) functions. Neither do I see how it would break function purity
or side-effect-freeness, but that could just be my lack of imagination.

As for the advantage my main argument would be convenience. It does
reduce user's elisp code and and makes smaller evaluations in the
minibuffer easier to type.

I wanted to file some more of such polymorphism suggestions. Would those
be welcome?

--
Daniel Nagy

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Nov 2023 06:48:02 +0000
Resent-Message-ID: <handler.66890.B66890.16989940261563 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Daniel Nagy <danielnagy@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org, stefankangas@HIDDEN
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.16989940261563
          (code B ref 66890); Fri, 03 Nov 2023 06:48:02 +0000
Received: (at 66890) by debbugs.gnu.org; 3 Nov 2023 06:47:06 +0000
Received: from localhost ([127.0.0.1]:56649 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qynxO-0000Oo-42
	for submit <at> debbugs.gnu.org; Fri, 03 Nov 2023 02:47:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35726)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qynxI-0000OT-A3
 for 66890 <at> debbugs.gnu.org; Fri, 03 Nov 2023 02:47:00 -0400
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 <eliz@HIDDEN>)
 id 1qynwc-0004LZ-Qi; Fri, 03 Nov 2023 02:46:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=Det+b7IVU7YEltT0KUbFF2YVzmZocNiTkw03ZUYY3+4=; b=d55y8i74cGxv
 cYcDkMnIjrqkpDESyWzX6kn2qAvCcAkAJ729PmSf5qQMvXcpMfItllUDazVK+ekiI5d2CGcU7B6E5
 JkalBsNW+JKOVZw9pNAJIx9P1VsIgabIQZNd3JabDlDVDQWjhq+YMHWHNqQcCaQ63l7+iouJzYN+s
 6Boa9SUnVjAzlYXvgeoYg2t+g/8nmbYYbSTMll4Iu7+LGcDYWmlkYLKC7kwh95783KgqymsaVJVR9
 vB9WZFyfR6KoPp0I3Ur/60rtHMF85ywWgTBOt3pcy+Wl1Gyw5ScyQqOu08kXsOMn5qm2CfDDzaeGI
 /Tt6pUz/ixJppZLAl5jY0g==;
Date: Fri, 03 Nov 2023 08:46:09 +0200
Message-Id: <83sf5n72ry.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87bkcbzy6c.fsf@HIDDEN> (message from Daniel Nagy on Thu, 02
 Nov 2023 20:38:35 +0000)
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <87bkcbzy6c.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Nagy <danielnagy@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 66890 <at> debbugs.gnu.org
> Date: Thu, 02 Nov 2023 20:38:35 +0000
> 
> These are the additional functions/macros, that I found using `M-x
> apropos-function', that accept both types of arguments:
> 
>     `buffer-hash'
>     `buffer-match-p'
>     `buffer-text-pixel-size'
>     `bury-buffer'
>     `display-buffer'
>     `get-buffer-create'
>     `get-buffer-window'
>     `get-buffer-window-list'
>     `kill-buffer'
>     `pop-to-buffer'
>     `project-display-buffer'
>     `project-display-buffer-other-frame'
>     `project-switch-to-buffer'
>     `replace-buffer-in-windows'
>     `set-buffer'
>     `set-window-buffer'
>     `switch-to-buffer'
>     `switch-to-buffer-other-frame'
>     `switch-to-buffer-other-tab'
>     `switch-to-buffer-other-window'
>     `tab-bar-get-buffer-tab'
>     `temp-buffer-window-setup'
>     `window-normalize-buffer'
>     `window-normalize-buffer-to-switch-to'
>     `with-current-buffer'
>     `with-current-buffer-window'
>     `with-displayed-buffer-window'
>     `with-temp-buffer-window'
> 
> The number of functions, that only accept a buffer is vast and probably
> outnumbers that list above, so I am not going to list them here.
> 
> These are some disadvantages of such a change, that come to my mind:
> 
>     1. Could the acceptance of a string in that place of the argument
>        prohibit possible future possibilites?
> 
>     2. Does the newly accepted argument type sacrifice function purity
>        and/or side-effect-freeness?
> 
>     3. API inconsistency.
> 
>     4. Slightly increased code complexity, especially in the C part of
>        the code base.
> 
> My commentary in this particular case would be, that I dont see how now
> accepting strings in addition would shadow any future usage of that ( or
> other ) functions. Neither do I see how it would break function purity
> or side-effect-freeness, but that could just be my lack of imagination.
> 
> As for the advantage my main argument would be convenience. It does
> reduce user's elisp code and and makes smaller evaluations in the
> minibuffer easier to type.
> 
> I wanted to file some more of such polymorphism suggestions. Would those
> be welcome?

I added Stefan Monnier to this discussion, in case he has an opinion
on this issue, which seems now to be about a vast change in Emacs.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Nov 2023 13:40:02 +0000
Resent-Message-ID: <handler.66890.B66890.16990187519550 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Daniel Nagy <danielnagy@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.16990187519550
          (code B ref 66890); Fri, 03 Nov 2023 13:40:02 +0000
Received: (at 66890) by debbugs.gnu.org; 3 Nov 2023 13:39:11 +0000
Received: from localhost ([127.0.0.1]:57305 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qyuOF-0002Ty-3W
	for submit <at> debbugs.gnu.org; Fri, 03 Nov 2023 09:39:11 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62210)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qyuOD-0002Tk-5n
 for 66890 <at> debbugs.gnu.org; Fri, 03 Nov 2023 09:39:10 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F227580577;
 Fri,  3 Nov 2023 09:38:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1699018707;
 bh=ofFIIBuHoKuzywPZjcz0g8+ZWWTKUuV2Il9uLmXXb/Y=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=NnEn4ZbHzTLVt9fefXbMP5Xxa7swf3YhNo1DRkQZuvElby9xHX05vu6gcA9Yzd7W0
 GxqBTsWqDtLe7oowuGL7iCNP7b+kQUP7lpMYNdWkaW9pXB6yDZMc/uEAUAGq0nueho
 XniS4Oi0Q0/v/4SceBCsVIzVrK6LhDy5e5UGLnHwfRhLHMw+0+hMHo/N81ZK15tvPP
 2ADskyXYUEkVRHPacElwH4jH60PDM82XKrqpTnHwgifSLIeRO7ClzVIeQDHSj2oYSu
 f+LFup6c9wBCHoXPuDcSINjlqvm9IRhKZC7HS5WafBXIp4KKoMda0QZ25sijGpJ/bb
 r0pW1Hvbu0ICQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2DA4B80098;
 Fri,  3 Nov 2023 09:38:27 -0400 (EDT)
Received: from pastel (unknown [45.72.195.71])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0C3F81202C0;
 Fri,  3 Nov 2023 09:38:27 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <877cmzzxf5.fsf@HIDDEN> (Daniel Nagy's message of "Thu, 02 Nov
 2023 20:55:55 +0000")
Message-ID: <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN>
Date: Fri, 03 Nov 2023 09:38:26 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.007 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Daniel wrote:
> My commentary in this particular case would be, that I dont see how now
> accepting strings in addition would shadow any future usage of that ( or
> other ) functions.

In most cases, the arg is meant to hold nothing but a buffer, and
allowing a string would probably not get in the way at all, indeed.

This said, there are functions out there that accept either buffers
or strings where the meaning of strings is not "buffer name" (e.g. where
a buffer is instead taken to mean "the `buffer-string` of that buffer"),
so we couldn't make it work "everywhere".

> Neither do I see how it would break function purity or
> side-effect-freeness, but that could just be my lack of imagination.

Agreed.  There is a slight cost to accepting strings, tho.
Not a very strong argument either, tho.

> As for the advantage my main argument would be convenience.  It does
> reduce user's elisp code

Does it?  Could you show some examples of the kind of reductions you're
thinking of?

> and and makes smaller evaluations in the minibuffer easier to type.

Indeed, it can be occasionally handy in `M-:`.

Eli wrote:
> I added Stefan Monnier to this discussion, in case he has an opinion
> on this issue, which seems now to be about a vast change in Emacs.

I do have an opinion on this: I wish I could go back in time and get rid
of this `buffer-or-string` business altogether.

The reason is that I've seen several ELisp packages which abused buffer
names as "handles" for buffers, leading to nasty bugs when those buffers
get renamed (e.g. by things like uniquify).

It's not important enough to motivate making backward
incompatible changes.

Maybe we should just "de-emphasize" the fact that those functions also
accept strings, and instead insist that you have to go through
`get-buffer` (or `get-buffer-create`).  If that sounds vague and you
don't know what that would mean concretely, well.. you're not alone :-)


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Nov 2023 00:23:01 +0000
Resent-Message-ID: <handler.66890.B66890.169905734811543 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Stefan Monnier <monnier@HIDDEN>, Daniel Nagy <danielnagy@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.169905734811543
          (code B ref 66890); Sat, 04 Nov 2023 00:23:01 +0000
Received: (at 66890) by debbugs.gnu.org; 4 Nov 2023 00:22:28 +0000
Received: from localhost ([127.0.0.1]:60105 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qz4Qm-000306-18
	for submit <at> debbugs.gnu.org; Fri, 03 Nov 2023 20:22:28 -0400
Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:59744)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1qz4Ql-0002zu-4F
 for 66890 <at> debbugs.gnu.org; Fri, 03 Nov 2023 20:22:27 -0400
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-507adc3381cso3297493e87.3
 for <66890 <at> debbugs.gnu.org>; Fri, 03 Nov 2023 17:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1699057305; x=1699662105; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=iDksFOmpmr/+ruTKfHXBZnP/+DagjLJvxp62EF7pYJM=;
 b=PU6tBp1e5reuEaMwrJn3u8TFaXDs/hTy87voymXoa7pnrMjP/U9NLESdYQiYOUwnWO
 MGQfTQ9MynFkWp843lYXQ6CoT8Q6l18ZLnqJLncRgF42w4V3PJWi+upcxZ+QYolbJRNN
 cw0laK4Eoq0YEWUyTf3RHL7unF3Sy4Rvz3Hq6zHMqS6fgVLy8FM6PIrQbpCeT3FaSiXn
 Yr7MjDKloQ89wcOYrOa4+2mV9MvvoSZm8YhH1ZHgC63UvyC66TYCkCSGK/Xf8oDwP0mb
 4/Fb10HbG+pHoZ6VApGfS/7QmckA+AaKCkQ+BEZ2QqcN2LbdmlF1Vwr1FADALRDoqipF
 7c7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1699057305; x=1699662105;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=iDksFOmpmr/+ruTKfHXBZnP/+DagjLJvxp62EF7pYJM=;
 b=effi8AXJBbtDxt4AK6bQBWgYcpst6OnYhzBD9RNUoB1vuEBj4WxQ//s295biGvo7JD
 nJ/vQXSsVubZp2bEePKwLz5P2QhlnRKXTOj1Rjj84t2JB8bmfGD8IUzJSBK8LPI5ivU6
 WpByFBoY4nkn8BFmFmmd7poF9wVgIJh3QwMdE4LhzNGHmPhiVscJcCtOp3jfGojY3pp7
 pbIo5AfMgLTtWQCI1xBpu5Mbb5WnAnS9gCS2ua8cUJYLiTwjSgBwC+fUGkERcSKY8Bgy
 g78bPvZwvRujNwRa3VeBC6xv3IjEsFkQjHFkuCKgLH3+3zNbVaaBShh9HXB5hpO4QcZR
 rguw==
X-Gm-Message-State: AOJu0YyK/9XI2dRR8CckbM9HK4IhdHVkGsxiC3Dw8kD2Ivmdk7di/Stw
 QS12pXKVSS5ulIZEjF0qikJbI7ZljXyaZOB9Fp3zN2GA
X-Google-Smtp-Source: AGHT+IGNE/OpUJUfIWDi0nUmxCOMUmaVYxY5Or3E49MpNxSa6wXuuSqp/LkEyceGWdWjFpg1DAHVrfbY8Gff0BqTtIo=
X-Received: by 2002:a05:6512:3610:b0:4fe:af1:c3ae with SMTP id
 f16-20020a056512361000b004fe0af1c3aemr16816570lfs.15.1699057305268; Fri, 03
 Nov 2023 17:21:45 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Fri, 3 Nov 2023 17:21:44 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Date: Fri, 3 Nov 2023 17:21:44 -0700
Message-ID: <CADwFkmkNRvg9gcHcsATKz1SjEbutxEnPr84HCWcUWv6KDxNZ1A@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> writes:

> I do have an opinion on this: I wish I could go back in time and get rid
> of this `buffer-or-string` business altogether.
>
> The reason is that I've seen several ELisp packages which abused buffer
> names as "handles" for buffers, leading to nasty bugs when those buffers
> get renamed (e.g. by things like uniquify).

I'm not sure which way to lean here: writing ELisp customizations is
easier for regular users if these functions accept either buffer or
string.  It's also less verbose.

OTOH, perhaps you're right that it's just too brittle.

Do you have some sense for how common that class of bugs are?
My guess is that we have a few of them in our tree, too.

> It's not important enough to motivate making backward
> incompatible changes.
>
> Maybe we should just "de-emphasize" the fact that those functions also
> accept strings, and instead insist that you have to go through
> `get-buffer` (or `get-buffer-create`).  If that sounds vague and you
> don't know what that would mean concretely, well.. you're not alone :-)

Perhaps we could recommend against abusing it in `(elisp) Tips'.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Nov 2023 06:05:02 +0000
Resent-Message-ID: <handler.66890.B66890.169907784814073 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Stefan Kangas <stefankangas@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org, Daniel Nagy <danielnagy@HIDDEN>
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.169907784814073
          (code B ref 66890); Sat, 04 Nov 2023 06:05:02 +0000
Received: (at 66890) by debbugs.gnu.org; 4 Nov 2023 06:04:08 +0000
Received: from localhost ([127.0.0.1]:60233 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qz9lP-0003ev-U4
	for submit <at> debbugs.gnu.org; Sat, 04 Nov 2023 02:04:08 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11586)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qz9lN-0003eO-DQ
 for 66890 <at> debbugs.gnu.org; Sat, 04 Nov 2023 02:04:06 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9E6F38076B;
 Sat,  4 Nov 2023 02:03:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1699077802;
 bh=Qx+CcwWrE/HZ/Mrwn0l+rnoV6iLxfdIcsMhAjPf/PUE=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=m1P/IpG2noTzOxCjoAseuWlezetEweLFw1MWydUNqgsB7l5KD7jAMe3NtbKw+7TT7
 a14joEmnqrELtFlI7k+n7X49fWM4toRBH5Z3yLqGUeJdBjK18oYh25ODHK28DDFvOE
 aVckH+4bYrwLQx+BtBhoyTxsd2FTW7F3DKiTC0Doh2jZ68yEhykEmbLi4t0IRF3BYU
 DN7oqwWfJ5PIg4nHjXPHgonQhyr2lFnOXj24txV4IjnlPBeLCEJhnIFzw6RurHtZAB
 rP3T/d4IX6KKvXner5AnV8vHVvXCi/ywdSLIHdNugZXWsEJVJ+lH6dPZt7B+kRTSJz
 vI3u/+50t3Euw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B9B7B80577;
 Sat,  4 Nov 2023 02:03:22 -0400 (EDT)
Received: from pastel (unknown [45.72.195.71])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B415120209;
 Sat,  4 Nov 2023 02:03:22 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <CADwFkmkNRvg9gcHcsATKz1SjEbutxEnPr84HCWcUWv6KDxNZ1A@HIDDEN>
 (Stefan Kangas's message of "Fri, 3 Nov 2023 17:21:44 -0700")
Message-ID: <jwvttq29ia1.fsf-monnier+emacs@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
 <CADwFkmkNRvg9gcHcsATKz1SjEbutxEnPr84HCWcUWv6KDxNZ1A@HIDDEN>
Date: Sat, 04 Nov 2023 02:03:11 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.007 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I do have an opinion on this: I wish I could go back in time and get rid
>> of this `buffer-or-string` business altogether.
>>
>> The reason is that I've seen several ELisp packages which abused buffer
>> names as "handles" for buffers, leading to nasty bugs when those buffers
>> get renamed (e.g. by things like uniquify).
>
> I'm not sure which way to lean here: writing ELisp customizations is
> easier for regular users if these functions accept either buffer or
> string.  It's also less verbose.

What you write sounds obvious, but at the same time I'm hard pressed to
think of a customization where I'd pass a buffer name to a function that
usually takes a buffer.

The only use of `get-buffer` I could find in my own customizations is
one where accepting buffers-or-strings wouldn't help (I pass the
buffer to functions like `eq` rather than to functions that
specifically expect a buffer).

>> Maybe we should just "de-emphasize" the fact that those functions also
>> accept strings, and instead insist that you have to go through
>> `get-buffer` (or `get-buffer-create`).  If that sounds vague and you
>> don't know what that would mean concretely, well.. you're not alone :-)
> Perhaps we could recommend against abusing it in `(elisp) Tips'.

It's not as strong a "de-emphasize" as I was picturing, but yes,
that counts.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Nov 2023 10:45:02 +0000
Resent-Message-ID: <handler.66890.B66890.169909465111779 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Stefan Monnier <monnier@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org, Daniel Nagy <danielnagy@HIDDEN>
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.169909465111779
          (code B ref 66890); Sat, 04 Nov 2023 10:45:02 +0000
Received: (at 66890) by debbugs.gnu.org; 4 Nov 2023 10:44:11 +0000
Received: from localhost ([127.0.0.1]:32943 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qzE8R-00033v-9K
	for submit <at> debbugs.gnu.org; Sat, 04 Nov 2023 06:44:11 -0400
Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:59676)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1qzE8P-00033h-Qj
 for 66890 <at> debbugs.gnu.org; Sat, 04 Nov 2023 06:44:10 -0400
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2c5028e5b88so40620851fa.3
 for <66890 <at> debbugs.gnu.org>; Sat, 04 Nov 2023 03:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1699094608; x=1699699408; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=6FE2pq2H4YiwFKsegmP9772O7kyVe7zOkfwM0XoR/Cc=;
 b=gsJZzUGX7tLOKaCcTh/SRmAfIIMFhQw5UytYuK9x0AX/4ec5oI7338TT+UYCM+axII
 Q441TWP9TRJp0noqOzM91XUk0fA+qUEHVCXyiSwTUCZy325Ybj15qdv9IAWgzV9uI3Qf
 Fr4lINv1eoDcifL3MMzrAK6XmWdCHZJYFD8e4WUQS04UXL2F8DMGA8qcFJwNiXxLc1lJ
 SM3E1Eaig9cMNR3m7814wcnH4abwPm68tmaNi1Tx5xq254TLdylSd7F0eCOMqV/5iPq5
 LAzqaStm4b8T30ILOkOlBB5O7f+6z6z+CQJf6UrpJMHdXB5CzGNqq1y5k4uZrlklgO54
 5N3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1699094608; x=1699699408;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=6FE2pq2H4YiwFKsegmP9772O7kyVe7zOkfwM0XoR/Cc=;
 b=X0gMrqJf6kDNqC3p24ZF5tUO6WFTbUg+H8YyEcRxmX3SlQskjFfE3iDeKEDVHbfR7j
 1FkeUJIW1NBR8vdidWMw08yVyFm/oQKeQ0hqsZtGKOJt+anOH4RjaYlmBjCdqWletTDA
 WDbW0/YPmq+Dk/yUZvQ2oAhi5ltwQJ3VKAT/gvx7ppj8A/f13yMkD8c6gmM3pysGK9uK
 b7p7xxOVvQPI/62/z0hZ7YM6iVjXfrtG6fB6qxz7+WPUtW/XaBS3o8r789dEuZjUDcB2
 Rf1mWo6KTqxDOp8e85E3BmINmUQ282nCUpiAcNnOyrkQuDHCxsXOF94WOyzQ+gDecfil
 G9yQ==
X-Gm-Message-State: AOJu0YwYNgOVuGK3PgbYJbbQaTA3OB1GWQxxgUWxPvHBwLIJmVWQIsl4
 9vEgNvVgCIDWA08yrVvW5zAlT980wmf7NsJ3oYU=
X-Google-Smtp-Source: AGHT+IEZ5uavdbSgUAU9SL6H0A0mbVizILuq+KwrmDUAo89tTvTroY+EKtzwZ56XRt1aZVfHQn/jijMbrILTfcF7s5k=
X-Received: by 2002:a2e:3912:0:b0:2c5:1f92:b464 with SMTP id
 g18-20020a2e3912000000b002c51f92b464mr16582023lja.10.1699094607329; Sat, 04
 Nov 2023 03:43:27 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Sat, 4 Nov 2023 03:43:26 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <jwvttq29ia1.fsf-monnier+emacs@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
 <CADwFkmkNRvg9gcHcsATKz1SjEbutxEnPr84HCWcUWv6KDxNZ1A@HIDDEN>
 <jwvttq29ia1.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Date: Sat, 4 Nov 2023 03:43:26 -0700
Message-ID: <CADwFkm=izXd=MRihT5avvZyEYnrQFaMGiSNr_mLN-rYSvK836g@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>>> Maybe we should just "de-emphasize" the fact that those functions also
>>> accept strings, and instead insist that you have to go through
>>> `get-buffer` (or `get-buffer-create`).  If that sounds vague and you
>>> don't know what that would mean concretely, well.. you're not alone :-)
>> Perhaps we could recommend against abusing it in `(elisp) Tips'.
>
> It's not as strong a "de-emphasize" as I was picturing, but yes,
> that counts.

Feel free to propose other things we could do.  I just proposed the
first one that came to mind.  :-)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Daniel Nagy <danielnagy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Nov 2023 21:02:01 +0000
Resent-Message-ID: <handler.66890.B66890.169913166525562 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Stefan Monnier <monnier@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.169913166525562
          (code B ref 66890); Sat, 04 Nov 2023 21:02:01 +0000
Received: (at 66890) by debbugs.gnu.org; 4 Nov 2023 21:01:05 +0000
Received: from localhost ([127.0.0.1]:35824 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qzNlR-0006eD-DI
	for submit <at> debbugs.gnu.org; Sat, 04 Nov 2023 17:01:05 -0400
Received: from mout01.posteo.de ([185.67.36.65]:36165)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <danielnagy@HIDDEN>) id 1qzNlO-0006db-2B
 for 66890 <at> debbugs.gnu.org; Sat, 04 Nov 2023 17:01:03 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 446AC240028
 for <66890 <at> debbugs.gnu.org>; Sat,  4 Nov 2023 22:00:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017;
 t=1699131619; bh=RIuxCIQzVcawctgUohpjWaGd5IyEOlf6KjCNog/mZRg=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=QHL7jFqaWGXiPDZUjLn+ikWdPuhCMbAHDrLIBNrKoFHKQYgB5ox8u2U6/RWcrYG4f
 DoCqQww15wuClLZdqHhWfP9K5RNJ3wigKNiRuAgrr99Yn1iLOfJU1LM6wHo+nX03Nq
 F+gG70deQ82f3deMzUO1ifaZVW3cMD4IUQTIigYpQHOPh7xlsVfKT4Frb9xawhsVRb
 +CX5SPMyaJtdUeJfQ2y7dtyvwGKTvhR7p85ZKjeWNGV+3nN/5F6AXfgOdiImseDaFl
 vjQ64kddER9wyFQFbixx9dEAHc7F2k3A/70aMkPQMMX0VMlgLtktilqRQvEF038+Ol
 +cMiMzSTmH+Uw==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4SN9420T70z6tvJ;
 Sat,  4 Nov 2023 22:00:17 +0100 (CET)
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
From: Daniel Nagy <danielnagy@HIDDEN>
Date: Sat, 04 Nov 2023 20:57:41 +0000
In-reply-to: <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
Message-ID: <87jzqxgrof.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)


Stefan Monnier <monnier@HIDDEN> writes:

> I do have an opinion on this: I wish I could go back in time and get
> rid of this `buffer-or-string` business altogether.

> The reason is that I've seen several ELisp packages which abused
> buffer names as "handles" for buffers, leading to nasty bugs when
> those buffers get renamed (e.g. by things like uniquify).

A reduced API surface will not prevent people from using buffer names as
handles. They will just wrap the string with `(get-buffer ...)' and call
it a day. That seems like a logic problem, that you cannot check for via
function arguments.

> Could you show some examples of the kind of reductions you're thinking
> of?

No, I cannot. This was mostly meant as a general statement. But maybe I
can argue in the other direction. What if things from that list above
were requiring to be more explicit. Such that you would need to write
`(with-current-buffer (get-buffer "mybuffer") ...)' instead of
`(with-current-buffer "mybuffer" ...)'. That would seem to me like an
(unnecessary) complication.

In general, I would say that, if the computer can unambigously decide
what is supposed to happen, it should help me and automatically correct
my "mistakes". Also I would argue, that is similar to what is already
present in Emacs with the dwim commands. Commands can behave differently
if, for example a region is active. So the "Do what I mean" notion
means, if I pass in a string, does the function unambigously know what I
mean with that? If yes, then it should do that.


--
Daniel Nagy

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Nov 2023 22:14:02 +0000
Resent-Message-ID: <handler.66890.B66890.1699136016841 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Daniel Nagy <danielnagy@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: "66890 <at> debbugs.gnu.org" <66890 <at> debbugs.gnu.org>
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.1699136016841
          (code B ref 66890); Sat, 04 Nov 2023 22:14:02 +0000
Received: (at 66890) by debbugs.gnu.org; 4 Nov 2023 22:13:36 +0000
Received: from localhost ([127.0.0.1]:35867 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qzOtb-0000DV-Jb
	for submit <at> debbugs.gnu.org; Sat, 04 Nov 2023 18:13:35 -0400
Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:45538)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1qzOtY-0000DI-0k
 for 66890 <at> debbugs.gnu.org; Sat, 04 Nov 2023 18:13:33 -0400
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id
 3A4LcPA7019399; Sat, 4 Nov 2023 22:12:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2023-03-30;
 bh=d6paODNyvJk/OxqAp01lymcVYnrDoacgiVtxodRGsAo=;
 b=QLQ0QVwGmQpKfhaz+W4idtcUg24dqbcFpmkXxhDDmdDxgeT0RGwbBfDNXJJNx+EvdSIf
 9TWOeBAlNQLjuAR7mnY33mlwYEMTYcyh7KI/34OvNP/g5wbKUmnAWNOQ7YcNirBx4D12
 bv7ZFiiEhsZW5ArsRQic3ZDB4maPxq/LSDtUlOexvfOwcF9dg9ZjS+mQ72QQ0TG1wsQu
 znAyi3MIgZ8LUsIU3mF7KlPzeQKuJrfCyvuElN7ZlIM+4Ilo8wVs3t8iBc20yDevwNua
 Ng132MB0GYYPnnE+cLTRdDG+nvSmhP0Lx/TXT4dnuuu5le+ecxOq3uPeYK1aXhSKzPMc qw== 
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3u5egv8n9d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 04 Nov 2023 22:12:54 +0000
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19)
 with ESMTP id 3A4K0diQ023561; Sat, 4 Nov 2023 22:12:53 GMT
Received: from nam12-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 3u5cd35rs4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 04 Nov 2023 22:12:53 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=KMzGL3E82V3odew09Vd6bwAktptX+MwqKXdlbzXuT5x47yvsR0pOMf17cYtRbNpKOu39TyHOAvZst8m+9nJPtjtZLhJjs0mG3xOozoPSxxXt6yd9brT0gKIFsNvoV5gGHCC42rC0FXK/gEOsHpRX1l5Z3yNF+YOGgHyvSNiZo0UZn9HD5NICmmO9n2MqEcNipzrepmMlg6xH2QSWtNc3dMtFn/S4fLe7aw+XhPrSkpeTFlRMT7vTSdUWERO6abXGVirSqHO0+I4rnELd+k9lMqTnhh6bD4JeS3EflQSukAuls9km+im1h2tZeZFmEbqzWc3ZYER1DbiLwDaMvl3AiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=d6paODNyvJk/OxqAp01lymcVYnrDoacgiVtxodRGsAo=;
 b=Xur2OK9RBz9Q9VTaIztdqbiO5afAT1yHpdMyTCPlm1IkJWNJMjlncDu/FGnuU9WF3oKAtDtpJ+nGjM2SliKifgyMwbUQcgG04srfIx7A20gii7eIPIJxKNbxQqWnFQK2ziRunHfafSGPc+/I0nQXqcfuijRSiyCLYszQfhT5lXr7/mMm0CDayRdr/H4pIcdp7YcHos8yLnc6Zy3Vst5LcDejhi/4PbdHRXzV9tjfd9EU2hlG2szi4UY7+6/kIJDg/T9upS2FKIxM6TmWck3XDrb4tY0w/KvVc5FvwKr4FjIJu9K5KI48rF3RvZ4wbhcxDHyYaIUGzHQtcPK8Xm9xqA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=d6paODNyvJk/OxqAp01lymcVYnrDoacgiVtxodRGsAo=;
 b=rm4Ls/28jv5YiW2rkZMhO/+vIAGHQT2vcFcipykacQYf0wxXks6ILl0vAK0due7a1lrzH5g0RpbWL37HtKMSc1GJs3c04bKzCcRjvRnGEsSqfj+W+6sXaPGoISBmlvloDWlFInGPA9tD5buMmq5O9/B0buCZ69eAVRfq++Gs+Kw=
Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19)
 by DM4PR10MB6791.namprd10.prod.outlook.com (2603:10b6:8:109::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.25; Sat, 4 Nov
 2023 22:12:51 +0000
Received: from SJ0PR10MB5488.namprd10.prod.outlook.com
 ([fe80::9e11:9d8c:b7f4:f45b]) by SJ0PR10MB5488.namprd10.prod.outlook.com
 ([fe80::9e11:9d8c:b7f4:f45b%7]) with mapi id 15.20.6954.025; Sat, 4 Nov 2023
 22:12:50 +0000
From: Drew Adams <drew.adams@HIDDEN>
Thread-Topic: [External] : bug#66890: 29.1; buffer-size should also accept the
 buffer's name as string argument
Thread-Index: AQHaD2Ipp71erJoW9UWqsuhNXvB/F7Bqri2w
Date: Sat, 4 Nov 2023 22:12:50 +0000
Message-ID: <SJ0PR10MB5488BA4FB3E3C2D5C05192DDF3A4A@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
 <87jzqxgrof.fsf@HIDDEN>
In-Reply-To: <87jzqxgrof.fsf@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|DM4PR10MB6791:EE_
x-ms-office365-filtering-correlation-id: 99390d3e-7e66-4d86-8f3d-08dbdd832f48
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iYoSRI/OoTWq1J8UGslGAPIrCmRU6kJnMY2L5d9Cejeyjf8jarvNXqWJZmJLdLVToy262+r9QAjM08MAJFHp42icSwqfsZ289E3ycjXoVrG19h5jLrwnjvgcPI11ZHOy76rTLzA+esbaAaM/00Q2Cpy9YwEb0a3bYbK3YIJqIK4QgvYWrXHtZcWPsUSsdoiRPqDZ0HGXGl8Y3eW/3GUT6qAqBmWGCDaMURL/jkAaAq/lMUDFFm3+lCvhN55ol6G+ThnseJlzwAFy04NyTyluvT6sJCfM7Bb71fEArEHfrmhZ1mAAnqev5lHKp9NvELAaovXy87B8nazjgQndxnwEjBE8pg5p9fvoqHTUUu8poIw+mxcCglw0ixMzz3Lf2bqmWcYibSqTT4LIzX4WmucuvaTn5wdnTJgA9bJ5yrn7D6/ERfpzwb9E82Sm67xgJvEZwR0tgbJJ5zyHjlATjwHFJNptQBRmIw+yxVt0Gy8fqXuRKyUHlrnU79pTuNVEGLCBKsz01wcrV5mcXEvY6rGI7ib1jPTgK5PT/zWEwt74olHv8rWhBxV8mQddcOiWW/B8Iw6J4bZe/REPdhxI0bNKHxmSNiiObkPKfT/g6KQP/g9MgPrPcWg8k+x1JbOM0ZZ1
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230031)(346002)(39860400002)(376002)(366004)(136003)(396003)(230922051799003)(64100799003)(186009)(1800799009)(451199024)(9686003)(26005)(7696005)(71200400001)(6506007)(478600001)(8936002)(4326008)(8676002)(5660300002)(2906002)(52536014)(44832011)(110136005)(41300700001)(76116006)(66556008)(64756008)(66476007)(66446008)(316002)(66946007)(38070700009)(122000001)(38100700002)(86362001)(33656002)(55016003);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: xtpx/WiEB4aYp8jTXhlaBClVz7sLD4cBFvh9/+6HRM1GlFckM58To7yt9bPpGpcajWOGES2bx9pbl6DXxsISJwCe0uju3iLWT9SRzyoyCQMzImrz2q1EbwdVH+zYiGCoqgMHANJMZ+SKuKWk2b2nzDu1zxXkcBSvT6QwYqnmw4q8yhTPZL1/1Mx2ip664+jS2GWnn4z1bbQHU9I/hyB1IEILaj5eRvlRgMp5KbTq+H6+o6lpD0PLqK0yCL98aIYdQXUJ4c4w9ovQwbujThTLo81z7OR7yiDbR9SlMcqX8UWkpy4emfYlzkCS43CZLaZPF1TtqYnyWkklQS/9IbU1YvPfQBRj7XgfA9asHCpUu2fOXcwXtD5d/kBo3N51k/Z4hq2BA4wNZTD3ZEm+L0yUtuQ6d7bQ4LvunUp0DyQwHWPQKqNyeoHKGAG7e5Vr08LC2ghsjOU0rFaIYKolDndKtnKwXR7klguq08oBxB5Dw0PcIUJBVoht/8dhOHPfNSjNZ//vD9Mj56/KGfWJGdPwzVx+aYMiH66ZDD5hKa4jTuNnsg9Q1/D+z+tA0hdxDklYR75++bkPOgTQ7UPVcPdbS2av3vsAmZrQj64OFqFKUwXrsqRwZCc5L23SFSVkebPJUH8xqtiBVBgeBaSlVf0+WBvTnsmkPDGwBHTZD3KjKnAW+yccZi2ZutaWsCACh0wsbXWYaSnQ5fwPkKfRS+YJBKCBZe14kwuWo3LXXx8qMwOxNQVbIczxZxmAUDt9uw+m8spI2LUo4PtdLVVUzthuKfYtrYeP/s18QXhX0mGW3Ir5Fk3FVdZCKxLUun1MthI3SW7OhYRv5oRDBURpn/Eb/5lKU0dhNKBJV1pijQheVjQTDffQN/adWyAeAFsFNc3Lbd1NoFDi2OlAEUFAavXZvDzu27paF2lSsx7wSc5JWaUuvVq0hpkG+AktHHcrMI25h4sgxcCtx/AW9kkVFxM4fmzETHewxrHjrSttq7apByp+wOtTW8DuwASddDA4NctOPJEyr8DsEWPOIn5azMtNnpuuPilphDYHZKCHWypYgQYUMf2zEtNJw2ri2FE0KdCxDTgy7kxYsYtqjgCs0wNxOFiMh15Hp3rcC14jiMchFRz0n45zFytQZAoGkTS4fIqMDMtEob9FtcU6+/+m6PLbe35ihuf4GkdwCWGTEsFNToqksNRAVVnCfsyUAFwd8RBJtyuZTOsNU8iDuaPC8PXXGru5E5COKTqDSqhf3Pds+VBZLRVWMLdSlAriGtLkt6SYhlE7vWVUxABBpaqX5bEJKmow4VzJnGaPxVi+dPKITbS4wDHoSSRaJs7V2mlNGCfzhS1FuZurk8BuyAYXAIJUz49RviYBNWWkYvCdxLoKPZu9wObBC1DXRLr4+8hrcJKh8g+zR3lTXhFc4pIe1rH/eM2gM9uV2ZJ1bULRZ6IODwhgsfPQ0stdccehj0gJnIRDMK92XW0hJd1bfwtGldGgKejpAet07TJYccukekw5aFaD8m6cO/NIkGpD16qn3zSZ/tM3an6Hlum5qxPIb0wI13S+YKjA8skdF1WKPyQ4glYjlG8euSts5XsV1EGEgLwN
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: OlHlJhk89/E6KEV0FO47PaKxn/XxUJir5JQj7fvjJLyR/IqRhIB7nMpppGQeh9gzPkDZ3Wl1G8T8GT3O7oceJsB6/uAKtnHvEPmH+EhmeklgIEHzJCwJ+e4uK9YY9nflB0E0dwovaujIw8s7dP4tOnnJCCrXUZfGv28/QKGqcJ47MmHqmFZ3wwRpxBBQgsi5QJnVDU5saobsQVePwshc5T0RtAH32tBAKjFRg8ORpxbD/3HsOpssRy9mNvQjhepaTYLE280u62vbfbzaKQfP4JfvJDM2NCeuPHbmkKjx9yi9q522lH/tqx7oYfWuU3keksOGdpKFxsUTR9ImVDA8PORF0tzAO4abd5lKK89TOORDCAb+0e3IfuioU/4aUhi4Ai7B/ZXRDEtSmafQZ/ep6S+18rIcgJl4G2sb/x5k168SHaajgOqIM/eCHaLTtEhrjtHa9Qy79oLOKb7ctSaJPwFmNCwpLKzn+dGCZC2f1n9HtP29HuKIDU3YTz1zRrhU6vZINncQxMVFb76CloIafMDfIk514shydWyMjJH85Zo2RJPL+sCRNE0fqI+0XKeZLX52dLE3QECHCRpAq/wUzz9aNI0DrcjF4IWeNN9cobP+4HYg3v74Y6KbAyA4r2G0iQ+8sD4YguYybT1doIuKQAdhmTmo2EmlanBUIVz8WuM1BaQeKb9s8Vjdl1fScWh1KRqBQJJcT+NE38vgN6KXt2DRHQd5kCKM74EtqnBOTfpXldJg2sXecS+CnC9Nci0kR1JnxWwryau6FWUecKllV/sBjSpjZEOtQKCz2ZnZJzoyxi3LIYqsaQTWeoS7prOk5vR9Y9cOi8GINQIibM5p1g==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 99390d3e-7e66-4d86-8f3d-08dbdd832f48
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2023 22:12:50.6234 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hwRvXQoLxcct7XUUYLxxRjnsHletY0dUWQT0r85od1+kJr0CDxxmOpvSF3K6WIf4O0i5WsX8PwP7DZCVYN0mRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB6791
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-11-04_19,2023-11-02_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 mlxscore=0 adultscore=0
 suspectscore=0 phishscore=0 spamscore=0 mlxlogscore=798 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000
 definitions=main-2311040191
X-Proofpoint-GUID: yQg6y7w3qL8OBj_x-kXxBUiWIihhw7po
X-Proofpoint-ORIG-GUID: yQg6y7w3qL8OBj_x-kXxBUiWIihhw7po
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

My 2c, FWIW -

Things don't have to be all-or-nothing.  A general
principle or approach is one consideration.  But
there can be others.

Stefan mentioned, I think, some specific contexts
where it makes little/no sense to accept a buffer
name in place of a buffer, as an argument.  Fine.
The doc should anyway make clear whether an actual
buffer is required.

There are other (maybe most?) contexts where it
can make sense to accept either one.

Please take a look at vanilla library bookmark.el.
I'm not saying that things are equivalent.  And
bookmark functions constitute a more isolated
context than buffer contexts - the latter are more
numerous and more variable.

But FWIW, bookmark.el functions used to accept
only a bookmark as argument.  Over time they were
systematically changed to accept either a bookmark
name (a string) or a bookmark (a list structure).
___

(This wasn't influenced by Bookmark+, BTW; it has
nothing to do with me.  And in Bookmark+ I prefer
to use the less cumbersome arg name BOOKMARK
instead of the name BOOKMARK-NAME-OR-RECORD, even
when the arg can be either a name or a bookmark.)
___

Similarly, vanilla Emacs used to use the arg name
BUFFER everywhere (whether or not a name was also
allowed), and in many places that was changed
over time to BUFFER-OR-NAME.  That there might be
more places where it makes sense for a function to
accept either seems reasonable.  That functions
should be considered individually also makes sense.

Should `buffer-size' allow a string argument -
that's the question raise here, no?  And Eli asked
the more general question of "whether it is worth
our while to convert more functions to accept both
buffers and names of buffers."  Whether you look
at one or several functions at a time, each should
be considered individually.
___

(Again, to me, the arg name BUFFER is preferable,
as long as the doc string makes clear (which it
really needs to do anyway) that either a string
or a buffer can be passed as arg.  But I'm not
suggesting that Emacs should change its naming
convention (again) in this regard.)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 05 Nov 2023 05:37:02 +0000
Resent-Message-ID: <handler.66890.B66890.169916259218639 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Daniel Nagy <danielnagy@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.169916259218639
          (code B ref 66890); Sun, 05 Nov 2023 05:37:02 +0000
Received: (at 66890) by debbugs.gnu.org; 5 Nov 2023 05:36:32 +0000
Received: from localhost ([127.0.0.1]:35961 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qzVoG-0004qZ-10
	for submit <at> debbugs.gnu.org; Sun, 05 Nov 2023 01:36:32 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40000)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qzVoE-0004qJ-4p
 for 66890 <at> debbugs.gnu.org; Sun, 05 Nov 2023 01:36:31 -0400
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 <eliz@HIDDEN>)
 id 1qzVnY-0003U4-3v; Sun, 05 Nov 2023 01:35:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=KXQedoCHogwKjVZ2bK5RgoFBvsbw3/ztDm4210triqA=; b=M+DFksZi4Q2S
 /QgZd0pmtUoZlkhblWHjghBYHQfsPg6sjaixs7Nj47+iztEodCAXPVfiLgFOTw/Z0qgapNoKw6twr
 DbBLUhkMXZ6LPVurxgYI1v01KfAlrNlnzoOrnAn9oiBgLz1icZdcaeEVcC7BU2qmufFGpUCEqChzc
 K3/kcjLjSfczvpH1QUJtm5bo4wdXy9SKph8p3Tn+15QvkphUnqBC68aS8fwBcXksHh+A4b8Diuu06
 SoYdt0AoSUushXSFqqpaE7M2EbJYGHKn7f/IQYxcQnpK8CW27mXz3m3fkHh5S6T409QPDQvWeLBL0
 wlRycEsSZphjACzMnc1kBA==;
Date: Sun, 05 Nov 2023 07:35:30 +0200
Message-Id: <83edh44va5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87jzqxgrof.fsf@HIDDEN> (message from Daniel Nagy on Sat, 04
 Nov 2023 20:57:41 +0000)
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
 <87jzqxgrof.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 66890 <at> debbugs.gnu.org
> From: Daniel Nagy <danielnagy@HIDDEN>
> Date: Sat, 04 Nov 2023 20:57:41 +0000
> 
> In general, I would say that, if the computer can unambigously decide
> what is supposed to happen, it should help me and automatically correct
> my "mistakes".

IME, this is a somewhat dangerous tendency.  In practice, it is easy
for a program to mistakenly interpret invalid inputs as some
transformation of valid ones, and do something that is very far from
what the caller meant.  So whether to "correct mistakes" or fail the
call is largely a judgment call, and it is not an accident that most
APIs prefer to fail in those cases, reserving the "correction" path
only for documented polymorphic situations.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 05 Nov 2023 23:03:02 +0000
Resent-Message-ID: <handler.66890.B66890.169922537126565 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66890
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: moreinfo
To: Daniel Nagy <danielnagy@HIDDEN>
Cc: 66890 <at> debbugs.gnu.org
Received: via spool by 66890-submit <at> debbugs.gnu.org id=B66890.169922537126565
          (code B ref 66890); Sun, 05 Nov 2023 23:03:02 +0000
Received: (at 66890) by debbugs.gnu.org; 5 Nov 2023 23:02:51 +0000
Received: from localhost ([127.0.0.1]:38349 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qzm8o-0006uP-Lr
	for submit <at> debbugs.gnu.org; Sun, 05 Nov 2023 18:02:51 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27286)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qzm8m-0006uA-S4
 for 66890 <at> debbugs.gnu.org; Sun, 05 Nov 2023 18:02:49 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DD6A8804F6;
 Sun,  5 Nov 2023 18:02:05 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1699225324;
 bh=8lgS8wyoebxhd7/71ABYNwBmYHBbNoqhyAp1WgKqBKw=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=dU3XoFigFQyuFH+wakbNKlbavr612KJZzLDwQ8AgGqkL6u4Ep9/s5NlKeJJcd/5S/
 v06Pl6FoGeSvx7fZAltstOZG0XylRBOCcvpSLUxycFJOAMu/hXAr/Ncb4Jb4zrQKQZ
 89H2gFYpioIgyLS3SP0YeweCnN532KgAkOwshPaw24e54ZT7+wNaNYzE9tyg4wFsgS
 3m4VlG9PDuL7Wevg0mW6K8RLElYFHHMsHKHj4Ej25NMIWPWGrsvW674jMybPRJz641
 /iFrZ8TAD+pkOJZOd4smn7BmMzm5+zzBNWPt0OC3wWMZrRtBIfj2FXP5dgJIP0MoUe
 jxehdf9gao15Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D68F580283;
 Sun,  5 Nov 2023 18:02:04 -0500 (EST)
Received: from pastel (unknown [45.72.195.71])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B1CF912017B;
 Sun,  5 Nov 2023 18:02:04 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87jzqxgrof.fsf@HIDDEN> (Daniel Nagy's message of "Sat, 04 Nov
 2023 20:57:41 +0000")
Message-ID: <jwvwmuv6dtq.fsf-monnier+emacs@HIDDEN>
References: <8734xp77vl.fsf@HIDDEN> <83edh88y2h.fsf@HIDDEN>
 <CADwFkmnbX6X9T-cz4q_NFot1dZaxpPUY-0WN0r6ZCpMXqUyvXg@HIDDEN>
 <877cmzzxf5.fsf@HIDDEN> <jwvwmuzasav.fsf-monnier+emacs@HIDDEN>
 <87jzqxgrof.fsf@HIDDEN>
Date: Sun, 05 Nov 2023 18:02:03 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.007 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> The reason is that I've seen several ELisp packages which abused
>> buffer names as "handles" for buffers, leading to nasty bugs when
>> those buffers get renamed (e.g. by things like uniquify).
> A reduced API surface will not prevent people from using buffer names as
> handles.

Indeed.  But the extra annoyance of having to use `get-buffer`
everywhere may push them to try and store the result of that
`get-buffer` somewhere.  It wouldn't eliminate the problem, but it would
have made it less common, I believe.  Not like it matters, tho.

[ When I look at all the programming languages out there, and how they
  are fundamentally almost all identical except for "cosmetic details"
  here and there, and the sometimes wildly different coding styles that
  come out of them, I end up with the conviction that those "cosmetic
  details" are what drives the coding styles.  :-)  ]

>> Could you show some examples of the kind of reductions you're thinking
>> of?
> No, I cannot. This was mostly meant as a general statement. But maybe I
> can argue in the other direction. What if things from that list above
> were requiring to be more explicit. Such that you would need to write
> `(with-current-buffer (get-buffer "mybuffer") ...)' instead of
> `(with-current-buffer "mybuffer" ...)'.

Oh, thanks.  Yes, these are very much the kinds of examples of
reductions I asked.  And indeed `grep` suggests we have quite some
number of those; and by now, you can guess that I see those as latent
bugs (aka "code smells")  :-(
Maybe we should add a compiler warning for that :-)

> In general, I would say that, if the computer can unambigously decide
> what is supposed to happen, it should help me and automatically correct
> my "mistakes".

I'm a big fan of that, also.  But indeed, while using a string as
"buffer" for one-off code in `M-:` would be handy, refusing it in "real"
ELisp code would help the programmer avoid that mistake :-)

> Also I would argue, that is similar to what is already
> present in Emacs with the dwim commands.

Indeed, commands are like `M-:`, so we like to have them "guess the
right thing" for us.  But note that we have DWIM commands but not DWIM
functions, because code needs to work right in "all" cases rather just
in the current specific circumstance, so it's much easier to write code
using functions that do just one thing only than using DWIM functions
which can do all kinds of different operations depending on
the circumstances.

> Commands can behave differently if, for example a region is active. So
> the "Do what I mean" notion means, if I pass in a string, does the
> function unambigously know what I mean with that?  If yes, then it
> should do that.

That can be handy, but encourages bad coding practices, so when we do
accept it we usually like to emit a warning.  Especially since most
ELisp programmers are far from experts at ELisp.  So we need to try and
help them avoid pitfalls.

Most buffers never change name, so it's easy for the occasional ELisp
programmer to think of the name as being just as good as the buffer
itself.  But their code will break down when it gets run in someone
else's setup where some local customization dynamically renames all
buffers to use a particular naming scheme.


        Stefan

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 2 Mar 2025 03:46:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 22:46:42 2025
Received: from localhost ([127.0.0.1]:49270 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1toaHp-0007L7-UT
	for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:46:42 -0500
Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:61742)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1toaHn-0007FA-RL
 for control <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:46:40 -0500
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5e50de0b5easo1425617a12.3
 for <control <at> debbugs.gnu.org>; Sat, 01 Mar 2025 19:46:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1740887194; x=1741491994; darn=debbugs.gnu.org;
 h=to:subject:message-id:date:mime-version:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=89dHDp6oyJhks+sR/8BBr22n3J5//N5jCcZj3/vtnl0=;
 b=g8aNY3q6g6T8hfS9g8aTrL6FJAEZItdlBNSbYms/Ua4QEyUor1aU6XFwo1XBOZ+sOl
 f3wMKcl4rdO/k9xvUKLE/LgankBkNFrUyk4/pD2BlMeeyjdNuwFmLWFEqKmvXN9Qch2v
 zWcyymJtx6E6MY+8o91xcbJ/Mh38b1W65b+e18ByzjjLZxkzY8lu9zwWS9amNetsXF6c
 QKHi4Uu/wlEb8Z3Kh5XmT/lul03yvCkDoiefGPt/cF5bPLLloWrSSqq9VsZBI2achPhj
 nuZYhbnT29XMY7e5TL1j8vQGSp79BG/ZdwlNgWLLNu7siLIjzSaf69ckCpUpEld2S4+W
 ex5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1740887194; x=1741491994;
 h=to:subject:message-id:date:mime-version:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=89dHDp6oyJhks+sR/8BBr22n3J5//N5jCcZj3/vtnl0=;
 b=g5OYiqgfNUIiI+bsJU35GESe61beyynG2l1fQrIwQtBy5UGdXoQw2067Su2iU7mbJg
 aRPOuv3AJ7rzDgQ01x1U4i7c+qtDJYiFjfBpE/XAt42N4rcNdAeFxbt4s2baEryMQSaY
 CGm+x+rB/Cvb+GTMvJCojD+0+cmLF05HsPJKnYtPcpeV/Oow7pvS/XTiNAbKbAi7gbv8
 kYXZwU0nyeozrgOielhI8abkkMoWtJ6IH1M8BDt9RMxwEpqSiWNeck7GEGE9A2xmiwFF
 D4aRD6HDyLb3fyy0VzUgLyiNfetT+nE/LCx1Tu2XtQ/ucBw5uNfkEzSnI0xIlntBu3Ki
 TXwQ==
X-Gm-Message-State: AOJu0Yy7Sls4FwHHfqlIou+vl1MyE5f2I6Ieqvzjs5WS+YRiuqCO4cjA
 9iSfWXnhkYDBNWklwKhzL7FVwqn8HXQevAW5vEwp600n7twtZrgzsLEf0KVPpXe3yG6p9Xy2OLA
 IC7ryd9hKOOpqbFxl985YR4DdecYjKbvyhM4=
X-Gm-Gg: ASbGncsnLz8Qd7eR+VsaQiikkX5KFJh1yMQ6CeFO2fEWN9FUYBAdWXqlWWsrm5q6ohu
 eHWF6cwFemZkAQ/Wi/vai1XM2S/si3P3zF8PHCR6bMtBBq/YiAsrkuy61IzCOMhhoTaXYA3rkU4
 yyxHIx6Tm1mn14GrLq/vJT81JYNQ==
X-Google-Smtp-Source: AGHT+IHDVZPp9KR5umjKXU7X3qv6KkyIBo4QUDAslVfq/wVGdK4edMuJaaJa1xRPLQbkbj/TX5OdffgnvKXZ4+o1QBQ=
X-Received: by 2002:a05:6402:27d4:b0:5e4:c522:51cd with SMTP id
 4fb4d7f45d1cf-5e4d6b691cbmr9446844a12.20.1740887193676; Sat, 01 Mar 2025
 19:46:33 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Sat, 1 Mar 2025 19:46:33 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
MIME-Version: 1.0
Date: Sat, 1 Mar 2025 19:46:33 -0800
X-Gm-Features: AQ5f1JpxVMN_X8WMxeUvMvShqDaUN3UVpfKpniTau-2oeOhRa7sJAbGzBSLtIi8
Message-ID: <CADwFkmn3JN7YFoeHPR0g-rGkY-WS5nPLu8AM5vy_3c2Ma-9h1g@HIDDEN>
Subject: control message for bug #66890
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

severity 66890 wishlist
quit

Last modified: Sun, 2 Mar 2025 04:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.