[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Window splitting issues with margins

From: Joost Kremers
Subject: Re: Window splitting issues with margins
Date: Tue, 24 Nov 2015 13:59:07 +0100
User-agent: mu4e 0.9.13; emacs

On Do, Nov 19 2015, Joost Kremers <address@hidden> wrote:
> On Di, Nov 17 2015, martin rudalics <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]