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 10:14:53 +0200 Message-ID: <83d1umiq9u.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449216925 30480 80.91.229.3 (4 Dec 2015 08:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2015 08:15:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 04 09:15:20 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 1a4lWR-00014U-7N for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 09:15:19 +0100 Original-Received: from localhost ([::1]:39332 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4lWQ-0006jX-KF for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 03:15:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4lWL-0006jR-PU for emacs-devel@gnu.org; Fri, 04 Dec 2015 03:15:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4lWG-0002rH-Px for emacs-devel@gnu.org; Fri, 04 Dec 2015 03:15:13 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:57482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4lWG-0002qn-I1 for emacs-devel@gnu.org; Fri, 04 Dec 2015 03:15:08 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NYT00B00QCIXQ00@mtaout25.012.net.il> for emacs-devel@gnu.org; Fri, 04 Dec 2015 10:12:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYT00ASFQSBKF40@mtaout25.012.net.il>; Fri, 04 Dec 2015 10:12:11 +0200 (IST) In-reply-to: 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.181 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:195852 Archived-At: > From: Stefan Monnier > Date: Thu, 03 Dec 2015 15:43:34 -0500 > > > My suggestion wasn't supposed to do anything about post-command-hook. > > It aimed only at allowing separate features display in the margins > > without interfering with one another. > > WRT to sizing the margin, I think if we want to "do it right" it'd make > sense to provide an Elisp-layer that defines two functions which could > look like: > > (window-margin-register OWNER SIZING-DESCRIPTOR) > > and > > (window-margin-unregister OWNER) > > so those two functions can appropriately combine the SIZING-DESCRIPTORS > still active. Not sure why window-margin-register and window-margin-unregister couldn't be set-window-margins with additional arguments. > Not sure what SIZING-DESCRIPTOR should look like (it could be > a function which takes a size and returns a new size). I don't think such a function can be implemented by any particular mode, because a mode only knows well what it needs from the margins, it has no better idea about other modes' needs than the rest of Emacs. Given the SIZING-DESCRIPTOR I suggested, it's trivial to determine how wide the margins should be at any given time in order to accommodate the needs of all the modes that requested screen estate in the margins. So we can do that without asking modes to provide their functions for it. To say nothing of the fact that having more than one function again raises a problem of in what order to apply them, and what would be the results of applying conflicting functions in any order.