Subject: Re: bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction

From: Juri Linkov <[email-masked]>
Date: Mon, 30 Nov 2020 22:49:12 +0200

>>> One day we should make up our mind whether we want this arg to be called
>>> MINI, MINIBUF or MINIBUFFER.  I have no personal preference but the
>>> current state (in particular on the C-level) confuses the hell out of
>>> me.
>>
>> I think MINIBUF is the shortest that is still unambiguous.
>
> It gives the impression that it stands for a buffer where it means a
> window that may also display the echo area.  'resize-mini-windows' and
> 'max-mini-window-height' tried to establish the "mini-windows (the
> minibuffer and the echo area)" nomenclature and we now take a step back
> in the other direction?

I don't know why MINI-WINDOW would be better than MINIBUF.
Is this distinction significant here?

Anyway, what I did is made all window functions consistent
in regard to their MINIBUF arg.  So now they are all have
the same arg name MINIBUF:

(defun walk-window-tree (fun &optional frame any MINIBUF)
(defun window-with-parameter (parameter &optional value frame any MINIBUF)
(defun walk-windows (fun &optional MINIBUF all-frames)
(defun window-in-direction (direction &optional window ignore sign wrap MINIBUF)
(defun get-window-with-predicate (predicate &optional MINIBUF all-frames default)
(defun get-buffer-window-list (&optional buffer-or-name MINIBUF all-frames)
(defun count-windows (&optional MINIBUF all-frames)

>> Now at least renaming in window-in-direction is pushed to master.
>
> And left MINI in the .texi file.  I spent some time trying to make
> manual and doc-strings congruent in this regard ...

Sorry, will update the manual soon.