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

[Daniel Nagy <danielnagy@posteo.de>]

Stefan Monnier <monnier@iro.umontreal.ca> 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).

A reduced API surface will not prevent people from using buffer names as
handles. They will just wrap the string with `(get-buffer ...)' and call
it a day. That seems like a logic problem, that you cannot check for via
function arguments.

> 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" ...)'. That would seem to me like an
(unnecessary) complication.

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". Also I would argue, that is similar to what is already
present in Emacs with the dwim commands. 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.


--
Daniel Nagy