bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument

[Stefan Monnier]

>> 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.

What you write sounds obvious, but at the same time I'm hard pressed to
think of a customization where I'd pass a buffer name to a function that
usually takes a buffer.

The only use of `get-buffer` I could find in my own customizations is
one where accepting buffers-or-strings wouldn't help (I pass the
buffer to functions like `eq` rather than to functions that
specifically expect a buffer).

>> 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'.

It's not as strong a "de-emphasize" as I was picturing, but yes,
that counts.


        Stefan