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: Sat, 05 Dec 2015 09:56:33 +0200 Message-ID: <83si3hfhvy.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> <83vb8dgbo6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449302256 3451 80.91.229.3 (5 Dec 2015 07:57:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Dec 2015 07:57:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 05 08:57:26 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 1a57if-0005sg-FJ for ged-emacs-devel@m.gmane.org; Sat, 05 Dec 2015 08:57:25 +0100 Original-Received: from localhost ([::1]:44865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a57ie-0008I0-Q4 for ged-emacs-devel@m.gmane.org; Sat, 05 Dec 2015 02:57:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a57ib-0008Hu-0i for emacs-devel@gnu.org; Sat, 05 Dec 2015 02:57:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a57iX-00060P-RW for emacs-devel@gnu.org; Sat, 05 Dec 2015 02:57:20 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:33088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a57iX-0005z9-JT for emacs-devel@gnu.org; Sat, 05 Dec 2015 02:57:17 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NYV00900K0DCA00@mtaout29.012.net.il> for emacs-devel@gnu.org; Sat, 05 Dec 2015 09:56:37 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYV009RLKQCBZ30@mtaout29.012.net.il>; Sat, 05 Dec 2015 09:56:37 +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.185 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:195915 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 04 Dec 2015 16:33:00 -0500 > > >> 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 the packages themselves know that? > > Good question. Presumably they'd need to detect when they add > a display-margin element somewhere where there is already another > such element. It is much simpler to assume that each one of the packages displays something in the margin on each screen line, at least potentially. It wastes some screen real estate, but it will never fail to show what the packages want to display. > >> 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. > > I'm not sure whether we can handle well all possible cases, indeed. > But if we design an API where the elements are always associated with > lines rather than with precise buffer positions, it should > be manageable. Maybe this API will be inconvenient for some use cases, > of course. Once again, my proposal handles this for all cases. So I think it's a good starting point.