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: Wed, 02 Dec 2015 15:41:09 +0200 Message-ID: <83k2oxj7d6.fsf@gnu.org> References: <87mvttsvsj.fsf@fastmail.fm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449063702 32729 80.91.229.3 (2 Dec 2015 13:41:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Dec 2015 13:41:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Joost Kremers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 02 14:41:33 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 1a47f0-0000H1-DD for ged-emacs-devel@m.gmane.org; Wed, 02 Dec 2015 14:41:30 +0100 Original-Received: from localhost ([::1]:58141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a47es-0004tH-IT for ged-emacs-devel@m.gmane.org; Wed, 02 Dec 2015 08:41:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a47en-0004t0-6v for emacs-devel@gnu.org; Wed, 02 Dec 2015 08:41:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a47ei-0001ON-60 for emacs-devel@gnu.org; Wed, 02 Dec 2015 08:41:17 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:38170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a47eh-0001O5-Pz for emacs-devel@gnu.org; Wed, 02 Dec 2015 08:41:12 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NYQ00D00GLMRV00@mtaout28.012.net.il> for emacs-devel@gnu.org; Wed, 02 Dec 2015 15:40:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYQ009ETGMZIP40@mtaout28.012.net.il>; Wed, 02 Dec 2015 15:40:11 +0200 (IST) In-reply-to: <87mvttsvsj.fsf@fastmail.fm> 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:195744 Archived-At: > From: Joost Kremers > Date: Tue, 01 Dec 2015 22:28:44 +0100 I think we should consider the 2 issues separately: . how can multiple features each display its own stuff in the margins without breaking other such features . how to split windows that have margins For the first issue, IMO it isn't enough to specify just one value, the required margin width. You need also to specify the width of the stuff, if any, that is displayed in the margin. (This will have to be specified in pixels, because you can display images and pixel-granular stretches of white space in the margins.) For example, linum-mode will specify a margin width of N columns, and display width of the same N columns in pixels. By contrast, modes such as writeroom-mode will specify a margin width of M columns and display width of zero. So we need to maintain, for each of the 2 margins, a list of elements of the form: (SYMBOL MARGIN-WIDTH DISPLAY-WIDTH) where SYMBOL is a unique symbol used to identify the request that came from a specific feature/mode. We should provide a function to return this list, or maybe make it the value of a local public variable. We should also have a way for a feature to update its request. Given such a list of requests, we compute the required margin width using the following simple algorithm: . compute maximum of all MARGIN-WIDTH values . compute the sum of all DISPLAY-WIDTH values . take the maximum of the above two (I omitted the translation from columns to pixels and back that will be needed here.) This solves a large portion of the interference issue, but it still leaves at least one aspect unsolved: what if some feature wants to limit the margin width from above? For example, I presume that writeroom-mode and its ilk would like to do that, because they want to keep the text area at some constant width. But if the width calculated as above is greater than that, the text area will have no alternative but to shrink. Is that acceptable? Or should we refuse the request that causes this? (In the latter case, we will have to ask each feature to supply one more parameter with its request.) Now regarding the split-window issue. I believe we shouldn't try to second-guess how to split windows in these cases. Instead, we should place the burden of doing TRT on the modes. Specifically: . for splitting the window with "C-x 2" and "C-x 3", the mode could simply invoke the correct splitting function itself . for splitting the window as result of some command calling 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 effect, we should add them) The reason I don't believe in some general-purpose heuristics in this case is that there's any number of possible needs of modes wrt margins. You are trying to classify these into "static" and "dynamic", but the "dynamic" kind can be something very different from what writeroom-mode and its ilk need in this regard. So the heuristics will fail when we have a mode whose margins are not "static", but not like writeroom-mode, either. Does this make sense?