From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument Date: Fri, 03 Nov 2023 09:38:26 -0400 Message-ID: References: <8734xp77vl.fsf@posteo.de> <83edh88y2h.fsf@gnu.org> <877cmzzxf5.fsf@posteo.de> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14671"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66890@debbugs.gnu.org To: Daniel Nagy Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 03 14:39:44 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 1qyuOl-0003Zz-NW for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Nov 2023 14:39:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyuOY-0008Ce-A8; Fri, 03 Nov 2023 09:39:30 -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 1qyuOW-0008CV-Ja for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 09:39:28 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyuOV-0006hw-6O for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 09:39:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyuP4-0002VB-EI for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 09:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 13:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66890 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 66890-submit@debbugs.gnu.org id=B66890.16990187519550 (code B ref 66890); Fri, 03 Nov 2023 13:40:02 +0000 Original-Received: (at 66890) by debbugs.gnu.org; 3 Nov 2023 13:39:11 +0000 Original-Received: from localhost ([127.0.0.1]:57305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyuOF-0002Ty-3W for submit@debbugs.gnu.org; Fri, 03 Nov 2023 09:39:11 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyuOD-0002Tk-5n for 66890@debbugs.gnu.org; Fri, 03 Nov 2023 09:39:10 -0400 Original-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== Original-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) Original-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) In-Reply-To: <877cmzzxf5.fsf@posteo.de> (Daniel Nagy's message of "Thu, 02 Nov 2023 20:55:55 +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:273708 Archived-At: 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