unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefankangas@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>,
	Daniel Nagy <danielnagy@posteo.de>
Cc: 66890@debbugs.gnu.org
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	[thread overview]
Message-ID: <CADwFkmkNRvg9gcHcsATKz1SjEbutxEnPr84HCWcUWv6KDxNZ1A@mail.gmail.com> (raw)
In-Reply-To: <jwvwmuzasav.fsf-monnier+emacs@gnu.org>

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> 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'.





  reply	other threads:[~2023-11-04  0:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01 16:31 bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument Daniel Nagy
2023-11-02  6:32 ` Eli Zaretskii
2023-11-02 19:38   ` Stefan Kangas
2023-11-02 20:55     ` Daniel Nagy
2023-11-03 13:38       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-04  0:21         ` Stefan Kangas [this message]
2023-11-04  6:03           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-04 10:43             ` Stefan Kangas
2023-11-04 20:57         ` Daniel Nagy
2023-11-04 22:12           ` Drew Adams
2023-11-05  5:35           ` Eli Zaretskii
2023-11-05 23:02           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]     ` <87bkcbzy6c.fsf@posteo.de>
2023-11-03  6:46       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADwFkmkNRvg9gcHcsATKz1SjEbutxEnPr84HCWcUWv6KDxNZ1A@mail.gmail.com \
    --to=stefankangas@gmail.com \
    --cc=66890@debbugs.gnu.org \
    --cc=danielnagy@posteo.de \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).