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: Sun, 05 Nov 2023 18:02:03 -0500 Message-ID: References: <8734xp77vl.fsf@posteo.de> <83edh88y2h.fsf@gnu.org> <877cmzzxf5.fsf@posteo.de> <87jzqxgrof.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="27113"; 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 Mon Nov 06 00:02:45 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 1qzm8i-0006pv-BV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Nov 2023 00:02:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzm8R-0006AB-Fo; Sun, 05 Nov 2023 18:02:27 -0500 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 1qzm8P-00069o-SE for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2023 18:02:26 -0500 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 1qzm8P-00069a-Js for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2023 18:02:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qzm90-0006uq-If for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2023 18:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2023 23:03: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.169922537126565 (code B ref 66890); Sun, 05 Nov 2023 23:03:02 +0000 Original-Received: (at 66890) by debbugs.gnu.org; 5 Nov 2023 23:02:51 +0000 Original-Received: from localhost ([127.0.0.1]:38349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzm8o-0006uP-Lr for submit@debbugs.gnu.org; Sun, 05 Nov 2023 18:02:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzm8m-0006uA-S4 for 66890@debbugs.gnu.org; Sun, 05 Nov 2023 18:02:49 -0500 Original-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== Original-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) Original-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) In-Reply-To: <87jzqxgrof.fsf@posteo.de> (Daniel Nagy's message of "Sat, 04 Nov 2023 20:57:41 +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:273846 Archived-At: >> 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