From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Minibuffer positioned at a location other than the bottom of the frame? Date: Sat, 25 Nov 2017 09:43:13 -0500 Message-ID: References: <5A13F19A.9000502@gmx.at> <83fu97d43z.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1145675e64cbd3055ecfb038" X-Trace: blaine.gmane.org 1511621005 26251 195.159.176.226 (25 Nov 2017 14:43:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Nov 2017 14:43:25 +0000 (UTC) Cc: martin rudalics , zhenya1007@gmail.com, Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 25 15:43:21 2017 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 1eIbfs-0006Uy-CT for ged-emacs-devel@m.gmane.org; Sat, 25 Nov 2017 15:43:20 +0100 Original-Received: from localhost ([::1]:53378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIbfz-0005n2-Q1 for ged-emacs-devel@m.gmane.org; Sat, 25 Nov 2017 09:43:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIbfq-0005lx-Th for emacs-devel@gnu.org; Sat, 25 Nov 2017 09:43:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIbfp-0007O5-Me for emacs-devel@gnu.org; Sat, 25 Nov 2017 09:43:18 -0500 Original-Received: from mail-ua0-x241.google.com ([2607:f8b0:400c:c08::241]:40154) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIbfn-0007NY-RO; Sat, 25 Nov 2017 09:43:15 -0500 Original-Received: by mail-ua0-x241.google.com with SMTP id z43so16382699uac.7; Sat, 25 Nov 2017 06:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+QqtHgRss6Q0N8Rw3RC5V5XwLl9BJcxvGc2lpuYMrek=; b=Bj1SaOGaCfjwK2+1FKDS/1uDvrH01SS9Z8ncxl/dmWpTcJY/x7kAD0JJWfZIvDoiOO +E2hKmGh8pNqBpZFdbqzuoA5Bt8efVw0/0BfGI14vlgir8b2kkAAXI7rYGNPnQGWadNl j7W1BT6jDtfBWcK6I3QRVxfPL4eWaNDMAe2K5fviNeDXFUcmmbJq4lz1yuge9SYH3s80 COYKbXyTbXR3gynVpqaww7gWeQtFseIKi2FTL0do8HfgLkWcSTfR1qHmOH2d2M1j336j njYc3yGgB7aJs0FaTEBdOUVDdngunZCdiOcDHMSWMQv1l8LtjUpCYoZWaHA5TVswY4nf Iesg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+QqtHgRss6Q0N8Rw3RC5V5XwLl9BJcxvGc2lpuYMrek=; b=Gy1fsrDFRg7msSt38mQ50glogG15HG6x5Cs9bSXe3bfDu6KKyk1DmKqWUrgov9R08w MSZMa4jpPB+IXnsh2p+SyXCnGDDeC8bIPRTUXlJS2qMlIV3uAmadAtc1cuDiL9qMNOtC 96Vb6xYMNKMzuZsEdOgPbMB2W7fXH+2dZXkHze51Z+xlWgNyarEMgl6PidedCDtrM3pj Kk4YhVUruiiGMNtlrAZDa2OsH4vmzo9Rqp7E2cuN2kClcmM93oUdlDlYnX27RqjRDJ88 /vNAgBmXzxnEZGZD9HFN0fay6p7szFho8ODwGyFcOXsYLcZFlO3Qqj1789BuPGcEzm0t XCug== X-Gm-Message-State: AJaThX7ptzT8UcM2ub2XchiiMOxbp593/qTl03Pe1MKhIKOykUHcMRzu w6e/MnRjvHwKjDplp4dre6CON/8xrvttpJIcSiO1Vg== X-Google-Smtp-Source: AGs4zMaX+dfglxg7cm1xYsbTmHrKgcS3nfXhUDEz34r3SLj4BZ/k7kqZxfUAqvQHjZ7getrCoOnXUH4lQze2BYD1Yn4= X-Received: by 10.176.19.130 with SMTP id m2mr27062824uae.57.1511620994188; Sat, 25 Nov 2017 06:43:14 -0800 (PST) Original-Received: by 10.31.188.85 with HTTP; Sat, 25 Nov 2017 06:43:13 -0800 (PST) In-Reply-To: <83fu97d43z.fsf@gnu.org> X-Google-Sender-Auth: algGSnX_hrTvDMHLhzv5bt71laU X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400c:c08::241 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:220452 Archived-At: --001a1145675e64cbd3055ecfb038 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8BThe OP suggested a dynamic positioning of the minibuffer.= That would be a significant change in the UI and as Eli points out would present many aspects that would need to be worked out. A little over a year ago I broached a more modest change in this thread:=E2= =80=8B=E2=80=8B https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00859.html There I raised the notion of (optionally) moving the modeline to the top of each window and positioning the minibuffer to the top of the frame. Screen technology keeps=E2=80=8B,=E2=80=8B evolving enabling ever larger sc= reens with ever more pixels. At the time =E2=80=8Bthat =E2=80=8BI initiated that thread I o= wned a 3=E2=80=8B0=E2=80=8B" (diagonal) 2560x1600 monitor. Since that time my employer has provided me a 43" 3840x2160 monster (HxW =3D 26"x38"). This is a thing of beauty but sadl= y a miserable experience when emacs =E2=80=8Btries=E2=80=8B to manage the who= le screen as =E2=80=8Ba single frame. Yes, I can have many full height windows side by side showing me an unprecedented amount from each buffer. =E2=80=8BAnd=E2=80=8B I =E2=80= =8Bcan =E2=80=8Bcope with the 38" screen width by =E2=80=8Bcollecting the two or three windows of most cu= rrent interest side by side at the center of the frame. But _very_ often buffer content fails to fill =E2=80=8Bits=E2=80=8B window. This means that I canno= t scroll =E2=80=8Bthat=E2=80=8B content to the middle of the screen. This leaves buffer content often displayed nearly 2 feet removed from its mode line and the minibuffer. Trying to work in this configuration is essentially impossible. =E2=80=8BMy= current compromise is to waste 2/3 of the screen=E2=80=8B's pixels=E2=80=8B, creati= ng a 1/3 height, full width frame. Interestingly, I feel much less disoriented using the =E2=80=8Bfull screen = height with a tiling window manager (awesome) displaying full height web pages and GUI desktop productivity apps. My conclusion is =E2=80=8B=E2=80=8Bthat =E2= =80=8Bsome =E2=80=8Baspects of the emacs UI =E2=80=8B(=E2=80=8Brooted=E2=80=8B at least partially =E2=80= =8Bin considerations of repainting early glass TTYs=E2=80=8B)=E2=80=8B could stand to be reassessed. For inst= ance, positioning the modeline at the top of our windows would align emacs with the now nearly universal UI idiom that positions a titlebar at the top of a window. /john=E2=80=8B --001a1145675e64cbd3055ecfb038 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8BThe OP suggested a dynamic positionin= g of the minibuffer. That would be a significant change in the UI and as El= i points out would present many aspects that would need to be worked out.

A little over a year ago I broached a more modest c= hange in this thread:=E2=80=8B=E2=80=8B


There I raised the notion of (optionally) moving the mod= eline to the top of each window and positioning the minibuffer to the top o= f the frame.

Screen technology keeps=E2=80=8B,=E2= =80=8B evolving enabling ever larger screens with ever more pixels. At the = time =E2=80=8Bthat =E2=80=8BI initiated that thread I owned a 3=E2=80=8B0= =E2=80=8B" (diagonal) 2560x1600 monitor. Since that time my employer h= as provided me a 43" 3840x2160 monster (HxW =3D 26"x38"). Th= is is a thing of beauty but sadly a miserable experience when emacs =E2=80= =8Btries=E2=80=8B to manage the whole screen as =E2=80=8Ba single frame. Ye= s, I can have many full height windows side by side showing me an unprecede= nted amount from each buffer. =E2=80=8BAnd=E2=80=8B I =E2=80=8Bcan =E2=80= =8Bcope with the 38" screen width by =E2=80=8Bcollecting the two or th= ree windows of most current interest side by side at the center of the fram= e. But _very_ often buffer content fails to fill =E2=80=8Bits=E2=80=8B wind= ow. This means that I cannot scroll =E2=80=8Bthat=E2=80=8B content to the m= iddle of the screen. This leaves buffer content often displayed nearly 2 fe= et removed from its mode line and the minibuffer.

= Trying to work in this configuration is essentially impossible. =E2=80=8BMy= current compromise is to waste 2/3 of the screen=E2=80=8B's pixels=E2= =80=8B, creating a 1/3 height, full width frame.

I= nterestingly, I feel much less disoriented using the =E2=80=8Bfull screen h= eight with a tiling window manager (awesome) displaying full height web pag= es and GUI desktop productivity apps. My conclusion is =E2=80=8B=E2=80=8Bth= at =E2=80=8Bsome =E2=80=8Baspects of the emacs UI =E2=80=8B(=E2=80=8Brooted= =E2=80=8B at least partially =E2=80=8Bin considerations of repainting early= glass TTYs=E2=80=8B)=E2=80=8B could stand to be reassessed.=C2=A0 For inst= ance, positioning the modeline at the top of our windows would align emacs = with the now nearly universal UI idiom that positions a titlebar at the top= of a window.

/john=E2=80=8B

--001a1145675e64cbd3055ecfb038--