GNU bug report logs - #22009
Inconsistent handling of window splitting with margins

Previous Next

Full log

View this message in rfc822 format

From: Joost Kremers <joostkremers <at> fastmail.fm>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22009 <at> debbugs.gnu.org
Subject: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p'
Date: Tue, 01 Dec 2015 13:47:29 +0100

On Sa, Nov 28 2015, martin rudalics <rudalics <at> gmx.at> wrote:
>  > Yes, but this doesn't seem to answer my question.  I already agreed
>  > that there's inconsistency, the question is how to fix it.  I
>  > suggested one way of reasoning, but you rejected it saying that the
>  > code in question only affects a function that is only used by
>  > display-buffer.  But display-buffer is not relevant to the use case
>  > that Joost described, with those modes which use margins.
>
> Indeed.  Joost's description of his fix is too general, it alludes to
> solving problems with C-x 3.  I initially misunderstood too 

Yes, sorry about the confusion. I was initially confused myself (but not
aware of it) when I posted my first message. It only became clear to me
later that there were two issues.

> Joost's use case with making a window on the right of an existing one to
> show a buffer for `display-buffer'.

Yes.

> It's relevant because above you said that "display-buffer is not
> relevant to the use case that Joost described, with those modes which
> use margins".  All I'm trying to do is to say that "only display-buffer
> is relevant to the use case Joost cares about, with those modes which
> use margins".  But maybe it's better for Joost to tell.

AFAICT that pretty much sums it up, at least as far as the patch that I
sent is concerned.

>  > I should probably bail out of this discussion, because I feel I'm not
>  > contributing anything but my own confusion to it.
>
> Let me try to sum up the possible ways to get confused here.  For a long
> time we didn't have any problems or reports in this area because margins
> were only used occasionally and in a very disciplined way.  Then we had
> ‘(n)linum-mode’ which started to use margins for displaying line
> numbers.  And now we have modes that use potentially large margins to
> center text within a window.  It's only the latter that introduce the
> problems I list below.
>
> Another problem is that these modes conflict(ed) with ‘(n)linum-mode’
> when deciding on the size of the margins.  This is part of other
> threads, so I won't describe it here.

Yes, it is necessary to keep these two issues apart. But. I think the
only right way to solve the issue of *this* thread will involve solving
the other issue as well.

>  The three major problems I see
> are:
>
> (1) When a mode uses margins to center text and you want to split the
>      corresponding window via C-x 3, ‘split-window-right’ may refuse to
>      split the window because the decision whether to split the window is
>      based on the assumption that the margin widths in the original
>      window shall be preserved.
>
> (2) When a mode uses margins to center text and you want to resize the
>      corresponding window horizontally via ‘mouse-drag-vertical-line’,
>      the latter may refuse to do that because the decision whether to
>      shrink the window is based on the assumption that its margin widths
>      shall be preserved.
>
> (3) When a mode uses margins to center text and you want to split the
>      corresponding window for displaying a buffer via ‘display-buffer’,
>      ‘split-window-sensibly’ may refuse to split the window because the
>      decision whether to split the window is based on the assumption that
>      the window to be split is only as wide as its text area.  Since this
>      wide can be comparably small in a window that uses margins to center
>      text, the attempt to display a buffer on the right may often fail
>      unexpectedly.
>

> Joost's fix is exclusively for problem (3).

Yes. And it has two additional problems: it counts fringes, scroll bars
and right dividers as well (as mentioned above). Plus it assumes that
the *entire* margins are reducible if necessary, which is also not the
case, since modes such as (n)linum-mode set a (left) margin and expect
this margin to be preserved when the window is split horizontally.

AFAIU all three problems amount to the same thing: currently, Emacs
assumes that when a window's width is changed, the margins must be
preserved. This assumption used to be correct, but with the introduction
of `visual-line-mode', various hacks and modes have been written that
use the margins to narrow the text area. When used this way, the margins
do *not* have to be preserved when the window width changes.

So essentially, since `visual-line-mode', the margins are being used in
ways that have conflicting requirements when a window's width changes:
some modes (such as (n)linum-mode) want the margins to be preserved,
other modes (such as `visual-fill-column-mode' / `writeroom-mode') want
the margins to be adjusted.

The only way to resolve such conflicts is to keep track of what mode set
the margins and whether they are adjustable or not. Then any part of
Emacs that needs to decide whether or how a window's width can be
changed can determine whether to just consider the text width, or the
text width plus the margins.

In other words, I don't think there's an easy fix that will really
resolve the issue. From what I understand from Martin's comments, a
proper fix is too involved to include in Emacs 25, so probably the best
thing to do is to update the doc strings and close this bug. A proper
solution can then be discussed on emacs-devel.

-- 
Joost Kremers
Life has its moments

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.