From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: The future of Follow Mode - a proposal. Date: Fri, 19 Feb 2016 14:25:10 -0500 Message-ID: References: <20160218195630.GA2697@acm.fritz.box> <20160219162159.GB3193@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0b8c0e0bc305052c24715e X-Trace: ger.gmane.org 1455909962 5338 80.91.229.3 (19 Feb 2016 19:26:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 19:26:02 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 19 20:26:01 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aWqgi-0004qw-83 for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 20:26:00 +0100 Original-Received: from localhost ([::1]:54812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWqgh-0002mD-MP for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 14:25:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWqfw-0001gN-NH for emacs-devel@gnu.org; Fri, 19 Feb 2016 14:25:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWqfv-00041B-HY for emacs-devel@gnu.org; Fri, 19 Feb 2016 14:25:12 -0500 Original-Received: from mail-pf0-x232.google.com ([2607:f8b0:400e:c00::232]:35728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWqfv-00040a-7D for emacs-devel@gnu.org; Fri, 19 Feb 2016 14:25:11 -0500 Original-Received: by mail-pf0-x232.google.com with SMTP id c10so57605350pfc.2 for ; Fri, 19 Feb 2016 11:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HaLqmd3lIv2IxzSl3gs16xWppPqMmlyHpTyalpPNkm4=; b=yl0qAj0mobaCfG+Va6vK4aYu+Sti7auoWzJX7L/+8jEgRz0mRzIBSZRkN1Hpauy5uq 8ZACFLUnQrnUSnq3/feil6YLq64prgHgRXpp+Rum6tDEKlLr+DnIdq0REdsuLFenKBox lryeb/mDI3dWhEN++hAZfBd3tvUpOpFZOy9DqLFKxSQiKLy83bdjJLj8xHYPF83KuxRN nCm68TubcWhS724pDgdGyMLKDhcFDv+y1/9JJgPc3duPniV1Ua1ltZKKLhgkNHJa7oAZ kXonuF08T4aJvLGhNSZFJcDddR7WZD9QcvfJi+MLqaZ+HMOzCWBUNRG8rfBhOoGXg/lz F7Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HaLqmd3lIv2IxzSl3gs16xWppPqMmlyHpTyalpPNkm4=; b=DEeqrOX6u6DTzp+0oiAeSsDaMdrDKnU/BMlVXwtQI0GIT9HetAqeGs938efyKidCVW G71HnLw9uHGvK0H/GlLyXfIFR0flTLJHJB+vE/ho+98cwXaSqOjMPu1Xf3wmwUDZiArj hAbn2G0wU738sBhMx9Xmfjd7Ecdftwr2DrwCyqBPZtW6QR1FSokAi8jOmItYjQwFHZD3 4LxRV2+/N3QOOHEd78kAIyVNQxh6Nps2WEIkUSEmOd/ba4V90fvwo9ePUED01fSzB41y YBYRG5Cc3Yj/d2Op2AnjgGOIpjk92ifTU3ZD4AKE46BFAJPZipt/sEwCSwm2XA2JRXKD XZ5w== X-Gm-Message-State: AG10YOQFOxvdYs3DtqRUi8akGg9gN2G+uLfjXPJKF5Jve34OkfQ128KYLeG6Gka3Dpf1VYV/eYBDQM/9RkpMeA== X-Received: by 10.98.73.205 with SMTP id r74mr20637906pfi.118.1455909910592; Fri, 19 Feb 2016 11:25:10 -0800 (PST) Original-Received: by 10.66.246.137 with HTTP; Fri, 19 Feb 2016 11:25:10 -0800 (PST) In-Reply-To: <20160219162159.GB3193@acm.fritz.box> X-Google-Sender-Auth: dEiR1ixxN4uVCtk6YZ0s1sMI2kE X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c00::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:200241 Archived-At: --94eb2c0b8c0e0bc305052c24715e Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 11:21 AM, Alan Mackenzie wrote: > One problem I > foresee is that there would no longer be anything to separate the main > window area from the minibuffer. Have you any thoughts on how this > would be handled? This may seem heretical but I would move the mini-buffer to the topof the frame. I can already approximate such a layout using a separate mini-buffer frame and the _NET_WM_STRUT_PARTIAL property. Ideally there would be a frame parameter that would allow me to specify that the mini-buffer should be positioned at the top of the frame. My motivation here is that I have a single, large, very high resolution screen. I maintain a set of tall, horizontally arrayed windows. I advise split-window and delete-window to keep all windows balanced. Since these windows are so tall very often they are only partially filled. The net effect is that interesting content is concentrated at the top of my screen. That being the case needing to look to the bottom of the screen to inspect the mode-line and/or mini-buffer only slows me down. I would be much happier if I could have: * the mini-buffer at the top of its frame * the mode-line at the top of its window /john --94eb2c0b8c0e0bc305052c24715e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 19, 2016 at 11:21 AM, Alan Mackenzie <acm@muc.de> wrote:
One problem I
foresee is that there would no longer be anything to separate the main
window area from the minibuffer.=C2=A0 Have you any thoughts on how this would be handled?

This may seem heretical but I = would move the mini-buffer to the topof
the= frame.=C2=A0 I can already approximate such a layout using a separate
mini-buffer frame and the _NET_WM_STRUT_PARTIAL= property.

Ideally there would be a frame parameter that would allow me to specif= y
that the mini-buffer should be positioned= at the top of the frame.

My motivation here is that I have a single, large, very= high resolution
screen.=C2=A0 I maintain a= set of tall, horizontally arrayed windows.=C2=A0 I advise
split-window and delete-window to keep all windows balance= d.=C2=A0 Since
these windows are so tall ve= ry often they are only partially filled.=C2=A0 The
net effect is that interesting content is concentrated at the top o= f my
screen.=C2=A0 That being the case need= ing to look to the bottom of the
screen to = inspect the mode-line and/or mini-buffer only slows me down.
I would be much happier if I could have:
=C2=A0 =C2=A0 * the mini-buffer at the top of its frame
=C2=A0 =C2=A0 * the mode-line at the top = of its window

/john
--94eb2c0b8c0e0bc305052c24715e--