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

[Stefan Monnier]

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

Indeed.  But the extra annoyance of having to use `get-buffer`
everywhere may push them to try and store the result of that
`get-buffer` somewhere.  It wouldn't eliminate the problem, but it would
have made it less common, I believe.  Not like it matters, tho.

[ When I look at all the programming languages out there, and how they
  are fundamentally almost all identical except for "cosmetic details"
  here and there, and the sometimes wildly different coding styles that
  come out of them, I end up with the conviction that those "cosmetic
  details" are what drives the coding styles.  :-)  ]

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

Oh, thanks.  Yes, these are very much the kinds of examples of
reductions I asked.  And indeed `grep` suggests we have quite some
number of those; and by now, you can guess that I see those as latent
bugs (aka "code smells")  :-(
Maybe we should add a compiler warning for that :-)

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

I'm a big fan of that, also.  But indeed, while using a string as
"buffer" for one-off code in `M-:` would be handy, refusing it in "real"
ELisp code would help the programmer avoid that mistake :-)

> Also I would argue, that is similar to what is already
> present in Emacs with the dwim commands.

Indeed, commands are like `M-:`, so we like to have them "guess the
right thing" for us.  But note that we have DWIM commands but not DWIM
functions, because code needs to work right in "all" cases rather just
in the current specific circumstance, so it's much easier to write code
using functions that do just one thing only than using DWIM functions
which can do all kinds of different operations depending on
the circumstances.

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

That can be handy, but encourages bad coding practices, so when we do
accept it we usually like to emit a warning.  Especially since most
ELisp programmers are far from experts at ELisp.  So we need to try and
help them avoid pitfalls.

Most buffers never change name, so it's easy for the occasional ELisp
programmer to think of the name as being just as good as the buffer
itself.  But their code will break down when it gets run in someone
else's setup where some local customization dynamically renames all
buffers to use a particular naming scheme.


        Stefan