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: Thu, 03 Dec 2015 08:49:20 +0200 Message-ID: <83610gjabz.fsf@gnu.org> References: <87mvttsvsj.fsf@fastmail.fm> <83k2oxj7d6.fsf@gnu.org> <565F2DD3.9020400@gmx.at> <838u5cka88.fsf@gnu.org> <565F3441.1020707@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 1449125438 20227 80.91.229.3 (3 Dec 2015 06:50:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Dec 2015 06:50:38 +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 Thu Dec 03 07:50:29 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 1a4Nil-0001An-VU for ged-emacs-devel@m.gmane.org; Thu, 03 Dec 2015 07:50:28 +0100 Original-Received: from localhost ([::1]:33625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Nig-0007hN-22 for ged-emacs-devel@m.gmane.org; Thu, 03 Dec 2015 01:50:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4NiU-0007er-Ma for emacs-devel@gnu.org; Thu, 03 Dec 2015 01:50:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4NiQ-0007jp-L4 for emacs-devel@gnu.org; Thu, 03 Dec 2015 01:50:10 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:45567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4NiQ-0007hK-8b for emacs-devel@gnu.org; Thu, 03 Dec 2015 01:50:06 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NYR00900SCS7M00@mtaout26.012.net.il> for emacs-devel@gnu.org; Thu, 03 Dec 2015 08:52:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYR001IASF58S70@mtaout26.012.net.il>; Thu, 03 Dec 2015 08:52:18 +0200 (IST) In-reply-to: <565F3441.1020707@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.182 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:195795 Archived-At: > Date: Wed, 02 Dec 2015 19:11:13 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, emacs-devel@gnu.org >=20 > >> > For example, linum-mode > >> > will specify a margin width of N columns, and display width= of the > >> > same N columns in pixels. > >> > >> How would this work with scaled text? > > > > Not sure what problem bothers you. >=20 > You say that linum-mode will specify a "display width of the same N > columns in pixels". How would it react to an increase of the width= of > the default face? How is it covered today? > IIUC this is not covered by any special hook so it has to be done > via =E2=80=98post-command-hook=E2=80=99. No great deal but it show= s that > =E2=80=98post-command-hook=E2=80=99 is indispensable for such modes= . Even if this conclusion is correct, is it really relevant to the concrete issue being discussed? If the only problems we could think about, after my suggested solution is implemented, are the ones that don't have any good solution now, it means the main problem -- how to allow several features request display margins without stomping on each other's toes -- is most probably solved. Then the other problem= s should be considered and solutions for them sought. IOW, what I suggested wasn't supposed to solve any problem except one= : how can several features display simultaneously on the same display margin. It wasn't supposed magically solve other related or unrelate= d problems. > >> > . for splitting the window with "C-x 2" and "C-x 3", the = mode could > >> > simply invoke the correct splitting function itself > >> > >> When two modes simultaneously use the margins, which splitting = function > >> would be chosen? > > > > It's up to the mode that wants to support splitting in any non-t= rivial > > manner. The mode knows exactly what are its needs, so it is fre= e of > > the guesswork. >=20 > So you mean there's no need for any new infrastructure here - the > =E2=80=98split-window=E2=80=99 window parameter can take care of th= is. I simply don't believe there could be a generic solution that doesn't involve active participation of the modes that are affected by this. > > In any case, the same problem exists if this is somehow guessed.= The > > infrastructure cannot know enough about the modes to make a deci= sion. > > > >> > . for splitting the window as result of some command call= ing > >> > display-buffer, we could expect the modes to customize = the > >> > display-buffer-* variables to control how the window is= split (if > >> > there are currently no features/variables to that effec= t, we should > >> > add them) > >> > >> When two modes simultaneously use the margins, which buffer dis= play > >> function would be chosen? > > > > The same problem exists with the proposed solution, doesn't it? >=20 > Is there one? Of course: imagine that the effects of 2 or more elements of the list contradict each other. Which one to choose?