From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Shrinking mini windows to one pixel height Date: Sat, 3 Mar 2018 09:07:06 -0800 (PST) Message-ID: <2eaebf9b-6053-445e-a7d2-94ba9c3a6c6a@default> References: <5A9A658A.5080207@gmx.at> <83d10lv4ko.fsf@gnu.org> <5A9A86D3.3070201@gmx.at> <955e646f-9610-3dbc-a12d-285dae95aa1a@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1520096937 6028 195.159.176.226 (3 Mar 2018 17:08:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2018 17:08:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov , martin rudalics , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 18:08:52 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1esAeQ-0000le-D1 for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2018 18:08:50 +0100 Original-Received: from localhost ([::1]:40976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esAgS-0001SU-Um for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2018 12:10:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esAfn-0001S0-4R for emacs-devel@gnu.org; Sat, 03 Mar 2018 12:10:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1esAfl-00007o-Tl for emacs-devel@gnu.org; Sat, 03 Mar 2018 12:10:15 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:52916) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1esAfi-00005r-4Y; Sat, 03 Mar 2018 12:10:10 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w23H9uli007021; Sat, 3 Mar 2018 17:09:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=mjHSVGLn4+DcLSTueX84diUrZC+RwC6y6nFgW9+9STM=; b=iAdO4KU0+xhVa6Cxu1se4EjCzqjoZr16HWV51FQTS5k5dZ0YCMqyVqAYd9WLUlgF2bh2 Ht95rRnQoRMTXpCuz/djvW4J7lrobuOce9wqXpWPlTRgqiTt1be+JHN8z7d+wR1VRM9h Iuu8sTuW72aj06MDE+tVNn4ULaqHlfwf4EEppjPSmbIIMKex/zHlZgfMx3CF+BrORJqX XWYNi0DUI8RDptdGflGVZqeaIZ8zKlIdLPkixtuvKHRq3+69o36dTvg5kHZBfz0Fyf+a pGKaEzmFRexE6la9w8FhwCzTE3fz3iJ91uFBm6obhjgmhLTFM7oI7+NAl+2m+rIdjWwC ug== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2gfuwgrby6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Mar 2018 17:09:57 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w23H77RA021499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Mar 2018 17:07:07 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w23H76PC027711; Sat, 3 Mar 2018 17:07:06 GMT In-Reply-To: <955e646f-9610-3dbc-a12d-285dae95aa1a@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4654.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8821 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=790 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803030218 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.79 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223244 Archived-At: > > > If you feel strongly about disabling this by default, on behalf of t= he > > > innocent and the na=C3=AFve, I could agree with a defcustom that wou= ld do > > > that.=C2=A0 Maybe. > > > > So let's wait for an innocent or na=C3=AFve to speak up. >=20 > 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. >=20 > 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.