* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
@ 2020-11-28 20:40 Juri Linkov
2020-11-29 8:22 ` martin rudalics
0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2020-11-28 20:40 UTC (permalink / raw)
To: 44932
[-- 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)
^ permalink raw reply related [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-28 20:40 bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction Juri Linkov
@ 2020-11-29 8:22 ` martin rudalics
2020-11-29 19:49 ` Juri Linkov
0 siblings, 1 reply; 10+ messages in thread
From: martin rudalics @ 2020-11-29 8:22 UTC (permalink / raw)
To: Juri Linkov, 44932
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-29 8:22 ` martin rudalics
@ 2020-11-29 19:49 ` Juri Linkov
2020-11-30 9:05 ` martin rudalics
0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2020-11-29 19:49 UTC (permalink / raw)
To: martin rudalics; +Cc: 44932
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-29 19:49 ` Juri Linkov
@ 2020-11-30 9:05 ` martin rudalics
2020-11-30 20:49 ` Juri Linkov
0 siblings, 1 reply; 10+ messages in thread
From: martin rudalics @ 2020-11-30 9:05 UTC (permalink / raw)
To: Juri Linkov; +Cc: 44932
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-30 9:05 ` martin rudalics
@ 2020-11-30 20:49 ` Juri Linkov
2020-11-30 21:09 ` Drew Adams
2020-12-01 9:34 ` martin rudalics
0 siblings, 2 replies; 10+ messages in thread
From: Juri Linkov @ 2020-11-30 20:49 UTC (permalink / raw)
To: martin rudalics; +Cc: 44932
>>> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-30 20:49 ` Juri Linkov
@ 2020-11-30 21:09 ` Drew Adams
2020-12-01 3:24 ` Eli Zaretskii
2020-12-01 9:34 ` martin rudalics
1 sibling, 1 reply; 10+ messages in thread
From: Drew Adams @ 2020-11-30 21:09 UTC (permalink / raw)
To: Juri Linkov, martin rudalics; +Cc: 44932
> >> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-30 21:09 ` Drew Adams
@ 2020-12-01 3:24 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-12-01 3:24 UTC (permalink / raw)
To: Drew Adams; +Cc: 44932, juri
> 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.)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
[not found] ` <<83sg8qi4yy.fsf@gnu.org>
@ 2020-12-01 3:49 ` Drew Adams
2020-12-01 15:38 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2020-12-01 3:49 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams; +Cc: 44932, juri
> > > 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-11-30 20:49 ` Juri Linkov
2020-11-30 21:09 ` Drew Adams
@ 2020-12-01 9:34 ` martin rudalics
1 sibling, 0 replies; 10+ messages in thread
From: martin rudalics @ 2020-12-01 9:34 UTC (permalink / raw)
To: Juri Linkov; +Cc: 44932
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction
2020-12-01 3:49 ` Drew Adams
@ 2020-12-01 15:38 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-12-01 15:38 UTC (permalink / raw)
To: Drew Adams; +Cc: 44932, juri
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-12-01 15:38 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-28 20:40 bug#44932: 28.0.50; MINIBUF 'nomini' for window-in-direction Juri Linkov
2020-11-29 8:22 ` martin rudalics
2020-11-29 19:49 ` Juri Linkov
2020-11-30 9:05 ` martin rudalics
2020-11-30 20:49 ` Juri Linkov
2020-11-30 21:09 ` Drew Adams
2020-12-01 3:24 ` Eli Zaretskii
2020-12-01 9:34 ` martin rudalics
[not found] <<87r1odtdtx.fsf@mail.linkov.net>
[not found] ` <<342c23a3-e379-452c-6c5e-29dab7592c28@gmx.at>
[not found] ` <<87h7p8zeim.fsf@mail.linkov.net>
[not found] ` <<5dbd99a5-a51e-318f-0c9d-81dae921af96@gmx.at>
[not found] ` <<87eekaa8au.fsf@mail.linkov.net>
[not found] ` <<27c3eec9-5675-47ae-937e-b5440becf6b6@default>
[not found] ` <<83sg8qi4yy.fsf@gnu.org>
2020-12-01 3:49 ` Drew Adams
2020-12-01 15:38 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).