[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66890: 29.1; buffer-size should also accept the buffer's name as str
From: |
Daniel Nagy |
Subject: |
bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument |
Date: |
Sat, 04 Nov 2023 20:57:41 +0000 |
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
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Daniel Nagy, 2023/11/02
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Eli Zaretskii, 2023/11/02
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Stefan Kangas, 2023/11/02
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Daniel Nagy, 2023/11/02
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Stefan Monnier, 2023/11/03
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Stefan Kangas, 2023/11/03
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Stefan Monnier, 2023/11/04
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Stefan Kangas, 2023/11/04
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument,
Daniel Nagy <=
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Drew Adams, 2023/11/04
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Eli Zaretskii, 2023/11/05
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Stefan Monnier, 2023/11/05
- Message not available
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, Eli Zaretskii, 2023/11/03