From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.devel Subject: Re: Window splitting issues with margins Date: Tue, 24 Nov 2015 13:59:07 +0100 Message-ID: <87610rlfj8.fsf@fastmail.fm> References: <874mgrwerb.fsf@fastmail.fm> <5644A2AC.3080703@gmx.at> <871tbux3vb.fsf@fastmail.fm> <564599A6.6060306@gmx.at> <838u62guhm.fsf@gnu.org> <87mvugs4la.fsf@fastmail.fm> <836112c554.fsf@gnu.org> <87mvudlw6g.fsf@fastmail.fm> <564A26ED.6000208@gmx.at> <564AE6ED.5080002@gmx.at> <87si4214q5.fsf@fastmail.fm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448369988 27911 80.91.229.3 (24 Nov 2015 12:59:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2015 12:59:48 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 24 13:59:31 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 1a1DBv-0008SW-OY for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2015 13:59:28 +0100 Original-Received: from localhost ([::1]:38202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1DBw-0006lK-M4 for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2015 07:59:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1DBi-0006jK-1A for emacs-devel@gnu.org; Tue, 24 Nov 2015 07:59:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1DBe-0004GK-Qe for emacs-devel@gnu.org; Tue, 24 Nov 2015 07:59:13 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:60240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1DBe-0004G9-Mu for emacs-devel@gnu.org; Tue, 24 Nov 2015 07:59:10 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0F2FB20C89 for ; Tue, 24 Nov 2015 07:59:10 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 24 Nov 2015 07:59:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=nN9+m gGMoxuc8WNoiYe4pEoHUM0=; b=Ew1kCQfsHJX3DCkKUXwmnf+1JgaWjZHdetlHb 3xrceCsCycFS7F2RU4H+OOKY02sK+Ct2QSXaYp4dAeDmG9POydPR+rzxxGnpYBLg eQzrVm6Oy2JXMY3G8iiu5UzJOmEgWizOE3K0aD1w79whb8Ylp0Epb3REsl8I+D0O 39XCcE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=nN9+mgGMoxuc8WNoiYe4pEoHUM0=; b=lz0uE p/IOrnpGTltDfsc2WP85IvaJqiDK+lyVtCav99xARkvA6WQxKEbs+xtP+7UF1kbp ApFHp3hMhPMbtTD1NKzQM7eJvseQ2BiclUGCvkGK2JdMxuLm/C2aGgyRzBFsCsbw Mofq1jWFyzWM13bf/SbEu87D1Z31LyO6yrPZPQ= X-Sasl-enc: 8iriHF/BxK67AE0mB3eWtDYHJf9qQBuxTC5iz0m6X/SX 1448369949 Original-Received: from IdeaPad.messagingengine.com (eruc065.goemobile.de [134.76.38.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D5B8680117; Tue, 24 Nov 2015 07:59:09 -0500 (EST) User-agent: mu4e 0.9.13; emacs 24.5.50.1 In-reply-to: <87si4214q5.fsf@fastmail.fm> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.26 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:195163 Archived-At: On Do, Nov 19 2015, Joost Kremers wrote: > On Di, Nov 17 2015, martin rudalics wrote: >> The only thing we can do is to say in the documentation that when two >> packages contend for the same margin, the one that tries to do that >> later in the redisplay cycle will succeed. > > Perhaps it could also be added that in order to reduce (though not > eliminate) the risk of interoperability problems, packages (1) should > examine the width of the margins before changing them (e.g., in > `window-configuration-change-hook'); (2) should not set the margins to a > width lower than the existing width; and (3) should restore the original > width when they are disabled (or rather, restore the width that existed > before the last time they changed the margins). [These comments are mainly for future reference, in case anyone revisits this discussion.] Well, I tried implementing this policy in `visual-fill-column-mode', but it didn't work, because it's not clear at all where margins come from. E.g., suppose `nlinum-mode' and `visual-fill-column-mode' are both active in a buffer. Now, `nlinum-mode' only sets the left margin, so when `visual-fill-column-mode' needs to reset the margins, the existing width of the right margin has been set by `visual-fill-column-mode' during the previous margin update. The problem is that `visual-fill-column-mode' has no way of knowing this and therefore assumes it cannot reduce the right margin, even though it can. So, summarising, the situation as it is doesn't really provide a way to allow multiple packages to use the margins safely. Making that possible would require some big changes to the way margins are handled. -- Joost Kremers Life has its moments