unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 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, 03 Nov 2023 09:38:26 -0400	[thread overview]
Message-ID: <jwvwmuzasav.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <877cmzzxf5.fsf@posteo.de> (Daniel Nagy's message of "Thu, 02 Nov 2023 20:55:55 +0000")

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






  reply	other threads:[~2023-11-03 13:38 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 [this message]
2023-11-04  0:21         ` Stefan Kangas
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=jwvwmuzasav.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --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).