From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>,
martin rudalics <rudalics@gmx.at>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: Shrinking mini windows to one pixel height
Date: Sat, 3 Mar 2018 09:07:06 -0800 (PST) [thread overview]
Message-ID: <2eaebf9b-6053-445e-a7d2-94ba9c3a6c6a@default> (raw)
In-Reply-To: <955e646f-9610-3dbc-a12d-285dae95aa1a@yandex.ru>
> > > 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.
next prev parent reply other threads:[~2018-03-03 17:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-03 9:06 Shrinking mini windows to one pixel height martin rudalics
2018-03-03 10:25 ` Eli Zaretskii
2018-03-03 11:28 ` martin rudalics
2018-03-03 12:03 ` Dmitry Gutov
2018-03-03 13:42 ` martin rudalics
2018-03-03 17:07 ` Drew Adams [this message]
2018-03-03 12:58 ` Eli Zaretskii
2018-03-03 13:42 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2eaebf9b-6053-445e-a7d2-94ba9c3a6c6a@default \
--to=drew.adams@oracle.com \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).