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

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

I've lost all my changes in the edited file because of the wrong
input arguments for window-in-direction.  Here's is what happened:
I forgot that the minibuffer was activated, and in the buffer
called the command windmove-display-down.  But it displayed
the text buffer in the minibuffer window.  Then I noticed this
and exited the minibuffer.  But exiting the minibuffer wiped off
the contents of the minibuffer window, i.e. cleared the text buffer
that was displayed in the minibuffer window.  This is because
currently windmove-display-in-direction doesn't send the arg
'nomini' to window-in-direction.  And it can't send this arg,
because currently window-in-direction ignores the value 'nomini',
and doesn't send its MINIBUF arg to walk-window-tree unchanged.

So here is a patch to avoid such accidents.  It sends MINIBUF arg
from window-in-direction to MINIBUF arg of walk-window-tree:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: window-in-direction-minibuf.patch --]
[-- Type: text/x-diff, Size: 3370 bytes --]

diff --git a/lisp/windmove.el b/lisp/windmove.el
index 6557960064..5db13cf6b3 100644
--- a/lisp/windmove.el
+++ b/lisp/windmove.el
@@ -485,7 +485,7 @@ windmove-display-in-direction
                        (t (window-in-direction
                            dir nil nil
                            (and arg (prefix-numeric-value arg))
-                           windmove-wrap-around)))))
+                           windmove-wrap-around 'nomini)))))
          (unless window
            (setq window (split-window nil nil dir) type 'window))
          (cons window type)))
@@ -569,7 +569,7 @@ windmove-delete-in-direction
 When `windmove-wrap-around' is non-nil, takes the window
 from the opposite side of the frame."
   (let ((other-window (window-in-direction dir nil nil arg
-                                           windmove-wrap-around t)))
+                                           windmove-wrap-around 'nomini)))
     (cond ((null other-window)
            (user-error "No window %s from selected window" dir))
           (t
@@ -637,7 +637,7 @@ windmove-swap-states-in-direction
 When `windmove-wrap-around' is non-nil, takes the window
 from the opposite side of the frame."
   (let ((other-window (window-in-direction dir nil nil nil
-                                           windmove-wrap-around t)))
+                                           windmove-wrap-around 'nomini)))
     (cond ((or (null other-window) (window-minibuffer-p other-window))
            (user-error "No window %s from selected window" dir))
           (t
diff --git a/lisp/window.el b/lisp/window.el
index d564ec5546..82976bf836 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -2309,7 +2309,7 @@ window--in-direction-2
 ;; Neither of these allow one to selectively ignore specific windows
 ;; (windows whose `no-other-window' parameter is non-nil) as targets of
 ;; the movement.
-(defun window-in-direction (direction &optional window ignore sign wrap mini)
+(defun window-in-direction (direction &optional window ignore sign wrap minibuf)
   "Return window in DIRECTION as seen from WINDOW.
 More precisely, return the nearest window in direction DIRECTION
 as seen from the position of `window-point' in window WINDOW.
@@ -2332,10 +2332,11 @@ window-in-direction
 frame and DIRECTION `above' the minibuffer window if the frame
 has one, and a window at the bottom of the frame otherwise.
 
-Optional argument MINI nil means to return the minibuffer window
-if and only if it is currently active.  MINI non-nil means to
-return the minibuffer window even when it's not active.  However,
-if WRAP is non-nil, always act as if MINI were nil.
+Optional argument MINIBUF t means to return the minibuffer
+window even if it isn't active.  MINIBUF nil or omitted means
+to return the minibuffer window if and only if it is currently active.
+MINIBUF neither nil nor t means never return the minibuffer window.
+However, if WRAP is non-nil, always act as if MINIBUF were nil.
 
 Return nil if no suitable window can be found."
   (setq window (window-normalize-window window t))
@@ -2451,7 +2452,7 @@ window-in-direction
 	   (setq best-edge-2 w-top)
 	   (setq best-diff-2 best-diff-2-new)
 	   (setq best-2 w)))))
-     frame nil (and mini t))
+     frame nil minibuf)
     (or best best-2)))
 
 (defun get-window-with-predicate (predicate &optional minibuf all-frames default)

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

[martin rudalics]

 > So here is a patch to avoid such accidents.  It sends MINIBUF arg
 > from window-in-direction to MINIBUF arg of walk-window-tree:

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.

martin

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

[Juri Linkov]

tags 44932 fixed
close 44932 28.0.50
quit

> 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.
Now at least renaming in window-in-direction is pushed to master.

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

[martin rudalics]

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

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

martin

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

[Juri Linkov]

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

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

[Drew Adams]

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

IMHO, MINI-WINDOW would be worse.  It's not
about a small window.  If someone wants to
be extra clear with the name (not needed,
if the rest of the doc string is clear about
what this is), then just use a longer name:

  MINIBUF-WINDOW

or if that's not clear enough (it should be):

  MINIBUFFER-WINDOW

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

[Eli Zaretskii]

> Date: Mon, 30 Nov 2020 13:09:07 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 44932@debbugs.gnu.org
> 
> > I don't know why MINI-WINDOW would be better than MINIBUF.
> > Is this distinction significant here?
> 
> IMHO, MINI-WINDOW would be worse.  It's not
> about a small window.

"Mini-window" is accepted terminology in Emacs, it is used, e.g., in
resize-mini-windows.  So there's nothing wrong with using that.  (And
yes, usually that window _is_ small.)

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

[martin rudalics]

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

OK.

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

Thanks in advance.

martin

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

[Drew Adams]

> > > I don't know why MINI-WINDOW would be better than
> > > MINIBUF. Is this distinction significant here?
> >
> > IMHO, MINI-WINDOW would be worse.  It's not
> > about a small window.
> 
> "Mini-window" is accepted terminology in Emacs, it is used, e.g., in
> resize-mini-windows.  So there's nothing wrong with using that.  (And
> yes, usually that window _is_ small.)

You're discussing only how to refer to this
parameter in doc strings.  I contributed my 2 cents.

As for the "accepted terminology" of "mini-window",
I've also given my opinion about that unfortunate
name more generally:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11276#24

  "it is wrong to use only "mini" here.  This is not
   just a mini-window, i.e., a small window - it is a
   minibuffer window.  See bug #3320, deemed "wont-fix"
   by Lars:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3320.

   Perhaps now that others consider that
   `resize-mini-windows' is a misnomer (for
   additional reasons), this misuse of "mini" can
   be reconsidered."

Bug #3320 was filed at the request of another who also
felt that such "accepted terminology" is unfortunate:

  "these misleading names have bitten me too."

> it is used, e.g., in resize-mini-windows"

And now what was discussed as a bad-name bug has
been canonized as a model of good naming.

You have a chance now, when considering parameter
names, to start to put things on the right track,
even if you don't rename `resize-mini-windows'.

Multiplying wrongs doesn't make a right.

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

[Eli Zaretskii]

> Date: Mon, 30 Nov 2020 19:49:44 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, rudalics@gmx.at, 44932@debbugs.gnu.org
> 
> Multiplying wrongs doesn't make a right.

This is a logical fallacy: I don't agree that the name is wrong to
begin with.