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 23:13:13 +0200 Message-ID: <83vb8dgbo6.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> <834mfygihw.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449263634 15726 80.91.229.3 (4 Dec 2015 21:13:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2015 21:13:54 +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 22:13:45 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 1a4xfj-0000vR-Lm for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 22:13:43 +0100 Original-Received: from localhost ([::1]:43500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4xfj-0006CV-5k for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 16:13:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4xfW-0006CN-KE for emacs-devel@gnu.org; Fri, 04 Dec 2015 16:13:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4xfT-0005Pq-Cr for emacs-devel@gnu.org; Fri, 04 Dec 2015 16:13:30 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:57763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4xfT-0005Ph-4o for emacs-devel@gnu.org; Fri, 04 Dec 2015 16:13:27 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NYU00K00Q81Z800@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 04 Dec 2015 23:13:25 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYU00KM7QYDYM40@a-mtaout21.012.net.il>; Fri, 04 Dec 2015 23:13:25 +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.169 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:195901 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 04 Dec 2015 15:55:59 -0500 > > > My suggestion was to ask each package to provide 2 numbers, not one. > > Each package above knows (internally) a single number in this case, but > it does not provide it. It only provides a function which combines this > number with the one it gets from the rest. That's a different proposal. I think it's more complex, and don't quite see the need for the added complexity. > > (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?) > > It means that package A and B place their things on different lines, so > the needed margin size is the max of X and Y rather than the sum. How can we know that they will never try to display anything on the same screen line? How can the packages themselves know that? > > How can you provide a single display property when the original > > properties are in different buffer locations? > > You can't. But if you need to share those two properties, it means > they're displayed at the same place, which also means that maybe they > don't need to be in different buffer location. > At least, that's my assumption. I don't see how that assumption could be a valid one. Imagine a buffer with linum-mode turned on, and an (imaginary) package that displays in the margin short notes to specific places in the buffer. The buffer position that correspond to the notes must be obeyed, or else editing the buffer will not move the notes as expected.