From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument Date: Fri, 3 Nov 2023 17:21:44 -0700 Message-ID: References: <8734xp77vl.fsf@posteo.de> <83edh88y2h.fsf@gnu.org> <877cmzzxf5.fsf@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14237"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66890@debbugs.gnu.org To: Stefan Monnier , Daniel Nagy Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 04 01:22:47 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 1qz4R4-0003Vn-JE for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Nov 2023 01:22:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qz4Ql-0002XW-Ku; Fri, 03 Nov 2023 20:22:27 -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 1qz4Qk-0002XN-DU for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 20:22:26 -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 1qz4Qk-0002nR-50 for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 20:22:26 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qz4RJ-00030t-VL for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 20:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Nov 2023 00:23:01 +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.169905734811543 (code B ref 66890); Sat, 04 Nov 2023 00:23:01 +0000 Original-Received: (at 66890) by debbugs.gnu.org; 4 Nov 2023 00:22:28 +0000 Original-Received: from localhost ([127.0.0.1]:60105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz4Qm-000306-18 for submit@debbugs.gnu.org; Fri, 03 Nov 2023 20:22:28 -0400 Original-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 ) id 1qz4Ql-0002zu-4F for 66890@debbugs.gnu.org; Fri, 03 Nov 2023 20:22:27 -0400 Original-Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-507adc3381cso3297493e87.3 for <66890@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) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 3 Nov 2023 17:21:44 -0700 In-Reply-To: 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:273735 Archived-At: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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'.