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 20:45:47 +0200 Message-ID: <834mfygihw.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> <83d1umiq9u.fsf@gnu.org> <83lh9agtke.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449254801 5169 80.91.229.3 (4 Dec 2015 18:46:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2015 18:46:41 +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 19:46:32 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 1a4vNG-00053m-QW for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 19:46:30 +0100 Original-Received: from localhost ([::1]:42690 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4vNF-0006P1-Tl for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 13:46:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4vN6-0006JM-AK for emacs-devel@gnu.org; Fri, 04 Dec 2015 13:46:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4vMo-0002if-0a for emacs-devel@gnu.org; Fri, 04 Dec 2015 13:46:20 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4vMn-0002hr-Ne for emacs-devel@gnu.org; Fri, 04 Dec 2015 13:46:01 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NYU00K00JZCG500@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 04 Dec 2015 20:45:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYU00KTGK4N6NF0@a-mtaout22.012.net.il>; Fri, 04 Dec 2015 20:45:59 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:195896 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 04 Dec 2015 12:30:21 -0500 > > >> That's the point of having SIZING-DESCRIPTOR be a function: it receives > >> a description of the margin chosen by "all other users" and adjusts it > >> according to its own needs. > > Then that function is not specific to any particular user of the margin, > > To me it's obvious that it is specific. So I think I lost you. If the function needs to consider what other modes want, it is not mode specific. It should know enough about any other possible modes that could need the margins. Such functions should be provided by the infrastructure, since no mode author is wiser than the Emacs maintainers. > Basically, package A uses the margin to place a few things in it. So it > needs a left margin that at least X pixels wide so its goodies > are visible (i.e. its function will return the max between X and > whatever else is decided). > > Then comes package B which uses that same margin for other things of > size Y. Since its other things are placed elsewhere, it requests that > the margin be the max of Y and whatever else is decided. > > Then comes package C which adds something of size Z to every line in > that same margin. So it requests (with "depth") to be placed > last, and its function returns the sum of Z and whatever else > is decided. My suggestion was to ask each package to provide 2 numbers, not one. You provided only one for each package, so I don't know how to interpret this within the model that I described. (I also don't understand the "displayed elsewhere" part of package B. What does "elsewhere" mean here? Is that stuff displayed on the margins or not?) If you are saying that both numbers are the same for each of the packages in your scenario, then the result under my suggestion will be X+Y+Z, and we don't need to rely on any package for this wisdom, or request them to understand how we allocate space for the margins. > PS: Clearly, this is related to the issue of how to share the margin > itself (rather than how to cooperate in setting the margin's width). Under the model I suggested, the two parameters determine both the margin width and how that width is shared. > Currently, this is done arbitrarily by the display engine, but we should > instead provide new functions which perform this combination in Elisp > and then place a single `display' property for the margin. How can you provide a single display property when the original properties are in different buffer locations? (I also don't understand why should we bother to produce a single property, but that's a separate issue.)