From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Better handling of window margins Date: Fri, 04 Dec 2015 16:33:00 -0500 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1449264812 1997 80.91.229.3 (4 Dec 2015 21:33:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2015 21:33:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 04 22:33:24 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 1a4xyk-0006Qv-SM for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 22:33:23 +0100 Original-Received: from localhost ([::1]:43597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4xyk-00077v-3X for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 16:33:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4xyW-00074W-2d for emacs-devel@gnu.org; Fri, 04 Dec 2015 16:33:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4xyV-00035q-95 for emacs-devel@gnu.org; Fri, 04 Dec 2015 16:33:08 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4xyP-00030s-NF; Fri, 04 Dec 2015 16:33:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxFgA731xV/yr292hcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjEAs0EhQYDSSINwjPIwEBAQEGAQEBAR6LOoUFB4QtBYwwqFQjhBYggngBAQE X-IPAS-Result: A0AxFgA731xV/yr292hcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjEAs0EhQYDSSINwjPIwEBAQEGAQEBAR6LOoUFB4QtBYwwqFQjhBYggngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="184514737" Original-Received: from 104-247-246-42.cpe.teksavvy.com (HELO pastel.home) ([104.247.246.42]) by ironport2-out.teksavvy.com with ESMTP; 04 Dec 2015 16:33:00 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 459AB61753; Fri, 4 Dec 2015 16:33:00 -0500 (EST) In-Reply-To: <83vb8dgbo6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Dec 2015 23:13:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.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:195903 Archived-At: >> 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. >> 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. Stefan