From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Better handling of window margins Date: Fri, 04 Dec 2015 11:42:03 +0200 Message-ID: <83zixqh7o4.fsf@gnu.org> References: <87mvttsvsj.fsf@fastmail.fm> <83k2oxj7d6.fsf@gnu.org> <565F2DD3.9020400@gmx.at> <838u5cka88.fsf@gnu.org> <565F3441.1020707@gmx.at> <83610gjabz.fsf@gnu.org> <566086FA.6010603@gmx.at> <83h9jzi99p.fsf@gnu.org> <566149DC.8020803@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1449222188 16184 80.91.229.3 (4 Dec 2015 09:43:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2015 09:43:08 +0000 (UTC) Cc: joostkremers@fastmail.fm, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 04 10:42:59 2015 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 1a4mtG-0007Ao-IP for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 10:42:58 +0100 Original-Received: from localhost ([::1]:39639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4mtF-0002ww-KL for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 04:42:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4mt5-0002nI-OF for emacs-devel@gnu.org; Fri, 04 Dec 2015 04:42:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4mt2-0000Fs-GE for emacs-devel@gnu.org; Fri, 04 Dec 2015 04:42:47 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:50770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4mt1-0000EK-Op for emacs-devel@gnu.org; Fri, 04 Dec 2015 04:42:44 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NYT00M00UOQJX00@mtaout28.012.net.il> for emacs-devel@gnu.org; Fri, 04 Dec 2015 11:41:21 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYT00KNCUWXXN30@mtaout28.012.net.il>; Fri, 04 Dec 2015 11:41:21 +0200 (IST) In-reply-to: <566149DC.8020803@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:195867 Archived-At: > Date: Fri, 04 Dec 2015 09:07:56 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, emacs-devel@gnu.org >=20 > >> If modes can specify their needs for each window they act on, t= he > >> overhead will be encapsulated in calculating a window's minimum= width. > > > > How can you encapsulate what an unknown mode will want to do? >=20 > The unknown mode will have posted its display-width as you suggeste= d. > =E2=80=98window-min-size=E2=80=99 (better =E2=80=98window--min-size= -1=E2=80=99) will then, instead of > calling =E2=80=98window-margins=E2=80=99, call a function say =E2= =80=98window-min-margins=E2=80=99 which > returns the sum of the display-widths of all modes that want to dis= play > something in the margins of that window. And how will this help in deciding how to split a window, when you cannot predict how the margins will change (or _whether_ they will change) as result of the split? We are still talking about splitting windows here, right? > >> If we can't manage that, then modes will also have to intervene= every > >> time we set a window's fringes or scroll-bar width or adjust it= s right > >> trailing edge. I'm afraid that mode authors won't want to do t= hat. > > > > Sorry, you lost me. What do fringes and scroll bars have in com= mon > > with the issue at point? Do you envision a window with 20-colum= n wide > > fringes or something? >=20 > No. I meant that enlarging a fringe by a few pixels or calling > =E2=80=98adjust-window-trailing-edge=E2=80=99 should probably be al= lowed to reduce the > margin-width for that window while preserving the display-width of = its > margins. Currently these work by the simple magic that the text ar= ea is > usually large enough so it can be shrunk when the window gets resiz= ed or > its fringes enlarged. OK, but how does this lead to "modes will also have to intervene ever= y time we set a window's fringes" part?