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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Nagy <danielnagy <at> posteo.de>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 66890 <at> debbugs.gnu.org, stefankangas <at> gmail.com
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 <at> posteo.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 66890 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.