Shrinking mini windows to one pixel height

Shrinking mini windows to one pixel height

[martin rudalics]

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

I just noticed that one can resize mini windows down to one pixel
which is maybe not what users want.  To reproduce with emacs -Q simply
type C-h f and drag the modeline of the only window down with the
mouse.  With some insistence you can make the minibuffer window almost
disappear.

A trivial patch is attached.  I think it should go to the release
branch but maybe the problem is too cosmetic for that.

Thanks, martin

[-- Attachment #2: window.el.diff --]
[-- Type: text/plain, Size: 670 bytes --]

--- a/lisp/window.el
+++ b/lisp/window.el
@@ -2730,13 +2730,14 @@ window--resize-mini-window
     (let* ((frame (window-frame window))
 	   (root (frame-root-window frame))
 	   (height (window-pixel-height window))
-	   (min-delta
+           (char-height (frame-char-height frame))
+           (min-delta
 	    (- (window-pixel-height root)
 	       (window-min-size root nil nil t))))
       ;; Sanitize DELTA.
       (cond
-       ((<= (+ height delta) 0)
-	(setq delta (- (frame-char-height (window-frame window)) height)))
+       ((<= (+ height delta) char-height)
+	(setq delta (- char-height height)))
        ((> delta min-delta)
 	(setq delta min-delta)))
 

Re: Shrinking mini windows to one pixel height

[Eli Zaretskii]

> Date: Sat, 03 Mar 2018 10:06:18 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> I just noticed that one can resize mini windows down to one pixel
> which is maybe not what users want.  To reproduce with emacs -Q simply
> type C-h f and drag the modeline of the only window down with the
> mouse.  With some insistence you can make the minibuffer window almost
> disappear.
> 
> A trivial patch is attached.  I think it should go to the release
> branch but maybe the problem is too cosmetic for that.

Does the capability or making a mini window 1-pixel tall cause us any
trouble?  If not, I'd prefer not to block it, let alone do that on the
release branch.

If you feel strongly about disabling this by default, on behalf of the
innocent and the naïve, I could agree with a defcustom that would do
that.  Maybe.

In any case, limiting this to frame-char-height sounds too harsh to
me, because using a suitably selected font one could produce quite
legible text in the mini window of a significantly smaller size.
E.g., AFAIR sizes as small as half that don't even trigger
reallocation of the glyph matrices, because their original allocation
tolerates up to twice as many screen lines as determined by the
frame's default font.

Thanks.

Re: Shrinking mini windows to one pixel height

[martin rudalics]

 > Does the capability or making a mini window 1-pixel tall cause us any
 > trouble?  If not, I'd prefer not to block it, let alone do that on the
 > release branch.

Fine with me.

 > If you feel strongly about disabling this by default, on behalf of the
 > innocent and the naïve, I could agree with a defcustom that would do
 > that.  Maybe.

So let's wait for an innocent or naïve to speak up.

 > In any case, limiting this to frame-char-height sounds too harsh to
 > me, because using a suitably selected font one could produce quite
 > legible text in the mini window of a significantly smaller size.
 > E.g., AFAIR sizes as small as half that don't even trigger
 > reallocation of the glyph matrices, because their original allocation
 > tolerates up to twice as many screen lines as determined by the
 > frame's default font.

Ideally we would remember the pixel height of the first text line and
never shrink it to anything less than that.

martin

Re: Shrinking mini windows to one pixel height

[Dmitry Gutov]

On 3/3/18 1:28 PM, martin rudalics wrote:

>  > If you feel strongly about disabling this by default, on behalf of the
>  > innocent and the naïve, I could agree with a defcustom that would do
>  > that.  Maybe.
> 
> So let's wait for an innocent or naïve to speak up.

Speaking from the naive camp, I'm not seeing a problem here. As long as 
the mode line area is still there to use the mouse to drag the window 
border back up.

Curiously, though, I can't reproduce this problem with icomplete-mode or 
ido-mode enabled. Try this: turn on icomplete-mode, type something (one 
character, or even a full function name), and try resizing the height of 
the minibuffer to smaller than one line tall.

Re: Shrinking mini windows to one pixel height

[Eli Zaretskii]

> Date: Sat, 03 Mar 2018 12:28:19 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > In any case, limiting this to frame-char-height sounds too harsh to
>  > me, because using a suitably selected font one could produce quite
>  > legible text in the mini window of a significantly smaller size.
>  > E.g., AFAIR sizes as small as half that don't even trigger
>  > reallocation of the glyph matrices, because their original allocation
>  > tolerates up to twice as many screen lines as determined by the
>  > frame's default font.
> 
> Ideally we would remember the pixel height of the first text line and
> never shrink it to anything less than that.

Not sure I'm following: what do you mean by "the first text line", and
what is its significance to the issue at hand?

Re: Shrinking mini windows to one pixel height

[martin rudalics]

 > Curiously, though, I can't reproduce this problem with icomplete-mode or ido-mode enabled. Try this: turn on icomplete-mode, type something (one character, or even a full function name), and try resizing the height of the minibuffer to smaller than one line tall.

Indeed.  It somehow manages to resize the window exactly.

martin

Re: Shrinking mini windows to one pixel height

[martin rudalics]

 > Not sure I'm following: what do you mean by "the first text line", and
 > what is its significance to the issue at hand?

I meant the first text line of the minibuffer, but obviously it should
be the minibuffer line containing the minibuffer's point.  If we
remembered the height of that line, we could allow miniwindow resizing
to always fully show that line at least.

martin

RE: Shrinking mini windows to one pixel height

[Drew Adams]

> >  > If you feel strongly about disabling this by default, on behalf of the
> >  > innocent and the naïve, I could agree with a defcustom that would do
> >  > that.  Maybe.
> >
> > So let's wait for an innocent or naïve to speak up.
> 
> Speaking from the naive camp, I'm not seeing a problem here. As long as
> the mode line area is still there to use the mouse to drag the window
> border back up.
> 
> Curiously, though, I can't reproduce this problem with icomplete-mode or
> ido-mode enabled. Try this: turn on icomplete-mode, type something (one
> character, or even a full function name), and try resizing the height of
> the minibuffer to smaller than one line tall.

I can repro it using Emacs 26 pretest 2 on MS Windows.
After `M-x', to make the minibuffer active, I can drag
the mode-line down so the minibuffer is only 1 pixel high.

This doesn't seem like a feature, to me - any more than,
e.g., allowing Emacs to have no frame showing a minibuffer.
I imagine that we should prevent/disallow this the same
way we do that.

On the other hand, an ability to use the mouse to remove
the minibuffer from a frame, as long as there is another
frame to move it to (so that it is still visible), might
be useful for some people in some contexts (no, I don't
have anything particular in mind).

Barring that possibility, I think it's important that
the minibuffer stay clearly visible. Users can reduce
its font height and so its overall height, but leaving
the font unchanged and reducing the window height much
more than the font height seems like a bad idea.

Remember that users can interact more with the
mode-line using the mouse these days, and someone
could easily slip while trying to click, and end
up dragging the mode-line down to visually "snuff out"
the minibuffer window.  That's a gotcha.

Martin's suggestion of keeping the window at least the
height of a minibuffer text line sounds reasonable.

But I'd love to hear descriptions of a use case for
letting the window height be reduced much more than
the font height.  Just because I can't think of such a
use case now doesn't mean there isn't one.