[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: |
Eli Zaretskii |
Subject: |
bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument |
Date: |
Fri, 03 Nov 2023 08:46:09 +0200 |
> From: Daniel Nagy <danielnagy@posteo.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 66890@debbugs.gnu.org
> Date: Thu, 02 Nov 2023 20:38:35 +0000
>
> These are the additional functions/macros, that I found using `M-x
> apropos-function', that accept both types of arguments:
>
> `buffer-hash'
> `buffer-match-p'
> `buffer-text-pixel-size'
> `bury-buffer'
> `display-buffer'
> `get-buffer-create'
> `get-buffer-window'
> `get-buffer-window-list'
> `kill-buffer'
> `pop-to-buffer'
> `project-display-buffer'
> `project-display-buffer-other-frame'
> `project-switch-to-buffer'
> `replace-buffer-in-windows'
> `set-buffer'
> `set-window-buffer'
> `switch-to-buffer'
> `switch-to-buffer-other-frame'
> `switch-to-buffer-other-tab'
> `switch-to-buffer-other-window'
> `tab-bar-get-buffer-tab'
> `temp-buffer-window-setup'
> `window-normalize-buffer'
> `window-normalize-buffer-to-switch-to'
> `with-current-buffer'
> `with-current-buffer-window'
> `with-displayed-buffer-window'
> `with-temp-buffer-window'
>
> The number of functions, that only accept a buffer is vast and probably
> outnumbers that list above, so I am not going to list them here.
>
> These are some disadvantages of such a change, that come to my mind:
>
> 1. Could the acceptance of a string in that place of the argument
> prohibit possible future possibilites?
>
> 2. Does the newly accepted argument type sacrifice function purity
> and/or side-effect-freeness?
>
> 3. API inconsistency.
>
> 4. Slightly increased code complexity, especially in the C part of
> the code base.
>
> 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. Neither do I see how it would break function purity
> or side-effect-freeness, but that could just be my lack of imagination.
>
> As for the advantage my main argument would be convenience. It does
> reduce user's elisp code and and makes smaller evaluations in the
> minibuffer easier to type.
>
> I wanted to file some more of such polymorphism suggestions. Would those
> be welcome?
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.
- bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument, (continued)
- 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, 2023/11/04
- 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 <=