split-window-right doesn't work with wide margins

split-window-right doesn't work with wide margins

[Joost Kremers]

Hi all,

a recent change on emacs-25 seems to cause problems for
split-window-right when a window has wide margins. To reproduce, simply
create a wide frame with one window, create a wide right margin with
`M-: (set-window-margins nil nil 130)` and then `C-x 3`. This will
produce the following error

split-window: Window #<window 3 on *scratch*> too small for splitting (2)

Does anyone know what change may have caused this? And is it intentional
behaviour or should this be considered a bug?

TIA

Joost



-- 
Joost Kremers
Life has its moments

Re: split-window-right doesn't work with wide margins

[martin rudalics]

 > a recent change on emacs-25 seems to cause problems for
 > split-window-right when a window has wide margins. To reproduce, simply
 > create a wide frame with one window, create a wide right margin with
 > `M-: (set-window-margins nil nil 130)` and then `C-x 3`. This will
 > produce the following error
 >
 > split-window: Window #<window 3 on *scratch*> too small for splitting (2)
 >
 > Does anyone know what change may have caused this?

If you're sure that this is a recent change, please try to locate it.
Here Emacs 25 behaves right as Emacs 24.5 in this regard.

 > And is it intentional
 > behaviour or should this be considered a bug?

The window on the right conceptually inherits the margins from the
original window.  If the margins won't fit, Emacs signals an error.

You could try to bind C-x 3 to a function based on ‘split-window’ that
explicitly sets its SIZE argument to something like half of the width of
the selected window.  Obviously, this will rely on a suitable function
on ‘window-configuration-change-hook’ that resets margins appropriately.

Or write a ‘split-window-function’ which, when a window shall be split
horizontally, first resets the margins of the original window to a small
value, calls the orginal ‘split-window’ and restores the margins to some
suitable value afterwards.

martin

Re: split-window-right doesn't work with wide margins

[Joost Kremers]

On Mon, Jan 18 2016, martin rudalics <rudalics@gmx.at> wrote:
>  > a recent change on emacs-25 seems to cause problems for
>  > split-window-right when a window has wide margins. To reproduce, simply
>  > create a wide frame with one window, create a wide right margin with
>  > `M-: (set-window-margins nil nil 130)` and then `C-x 3`. This will
>  > produce the following error
>  >
>  > split-window: Window #<window 3 on *scratch*> too small for splitting (2)
>  >
>  > Does anyone know what change may have caused this?
>
> If you're sure that this is a recent change, please try to locate it.
> Here Emacs 25 behaves right as Emacs 24.5 in this regard.

`git bisect` points to commit 3477e27 `Complete pixelwise frame/window
resizing, add horizontal scrollbar support.'

>  > And is it intentional
>  > behaviour or should this be considered a bug?
>
> The window on the right conceptually inherits the margins from the
> original window.  If the margins won't fit, Emacs signals an error.

Actually, Emacs 24.5 adjusts the window margins:

- emacs -Q
- create a wide frame with one window (window-width reports 236 in my
  case)
- M-: (set-window-margins nil nil 130)
- C-x 3

In Emacs 24.5, I am now left with two side-by-side windows that each
have a right margin of 114 (as reported by `window-margins`), but after
the commit above, the same procedure leads to an error message.

> Or write a ‘split-window-function’ which, when a window shall be split
> horizontally, first resets the margins of the original window to a small
> value, calls the orginal ‘split-window’ and restores the margins to some
> suitable value afterwards.

I found a variable `split-window-preferred-function`, which is probably
what you mean? Would it be possible to give that variable a buffer-local
value and set it to a function that first resets the window margins and
then calls the default value of `split-window-preferred-function`?



-- 
Joost Kremers
Life has its moments

Re: split-window-right doesn't work with wide margins

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

 > `git bisect` points to commit 3477e27 `Complete pixelwise frame/window
 > resizing, add horizontal scrollbar support.'

I remember now.  The situation is as follows: There is a common function
‘window-min-size’ which reports the minimum possible size for each
window.  In the horizontal case this includes the window's margins.
This function is used in virtually all size sanity checks, when resizing
windows or frames, adding scroll bars, fringes or margins, or splitting
windows as in the case at hand.

Now we have two choices: Either we do count margins in this function.
Then ‘split-window’ will fail as indicated in this report.  Or we do not
count them.  Then we will have to automatically cut margins down as we
did previously.  This will, however, affect user-set margins that are
_not_ continuously refreshed via a hook.

Suppose, for example, that you have a window on the left with user-set
margins and drag the divider of that window to the left in order to show
more contents of the window on the right.  In this case you may lose the
margins in the window on the left and Emacs won't restore them when you
drag the divider back.

 >> Or write a ‘split-window-function’ which, when a window shall be split
 >> horizontally, first resets the margins of the original window to a small
 >> value, calls the orginal ‘split-window’ and restores the margins to some
 >> suitable value afterwards.
 >
 > I found a variable `split-window-preferred-function`, which is probably
 > what you mean? Would it be possible to give that variable a buffer-local
 > value and set it to a function that first resets the window margins and
 > then calls the default value of `split-window-preferred-function`?

No.  ‘split-window-preferred-function’ only affects ‘display-buffer’.
It does not affect ‘split-window’.  I attached a possible solution which
is far from ideal.  I hope you get the idea.  A similar solution would
be needed for ‘split-window-preferred-function’.  Essentially you would
have to rewrite ‘split-window-sensibly’ with a reset/restore mechanism
around the (window-splittable-p window t) and (split-window-right)
forms.  Slightly more tricky ...

Sooner or later we should find a way to dynamically insert some stretch
space on the left and right of a window body without affecting the value
of ‘window-margins’.

martin

[-- Attachment #2: window-margins.el --]
[-- Type: application/emacs-lisp, Size: 1008 bytes --]

Re: split-window-right doesn't work with wide margins

[Joost Kremers]

On Wed, Jan 20 2016, martin rudalics <rudalics@gmx.at> wrote:
> Now we have two choices: Either we do count margins in this function.
> Then ‘split-window’ will fail as indicated in this report.  Or we do not
> count them.  Then we will have to automatically cut margins down as we
> did previously.

May I ask what the rationale for this change of behaviour was? (I
scanned the thread discussing your patch but I didn't see any mention of
it.)

>  This will, however, affect user-set margins that are
> _not_ continuously refreshed via a hook.

Does that happen? Users setting window margins, I mean?

> No.  ‘split-window-preferred-function’ only affects ‘display-buffer’.
> It does not affect ‘split-window’.  I attached a possible solution which
> is far from ideal.  I hope you get the idea.  A similar solution would
> be needed for ‘split-window-preferred-function’.  Essentially you would
> have to rewrite ‘split-window-sensibly’ with a reset/restore mechanism
> around the (window-splittable-p window t) and (split-window-right)
> forms.  Slightly more tricky ...

I'll take a closer look at it next week, when I have more time. 

> Sooner or later we should find a way to dynamically insert some stretch
> space on the left and right of a window body without affecting the value
> of ‘window-margins’.

Yes, that would be ideal.

-- 
Joost Kremers
Life has its moments

Re: split-window-right doesn't work with wide margins

[martin rudalics]

 > May I ask what the rationale for this change of behaviour was? (I
 > scanned the thread discussing your patch but I didn't see any mention of
 > it.)

Emacs emulates a tiling window manager.  One major complication results
from the fact that frames can get resized continuously.  Traditional
tiling window managers don't have to cope with the problem that a screen
gets resized or its resolution being changed frequently.

The window code lacked a coherent mechanism to determine whether to
refuse a change of any of a window's size or that of its components.
Earlier Emacsen were allowed to delete windows when shrinking the frame
or enlarging other windows.  Later versions did not restore the original
size of windows when shrinking a frame and restoring its previous size
afterwards.  And there were versions that allowed to shrink a window's
margins when shrinking its frame and not restoring them when enlarging
the frame again.

A main motivation of the later changes was to allow users to smoothly
switch from a maximized/fullscreen frame to a normal one and back to the
maximized/fullscreen frame such that the size and layout of windows in
the respective maximized/fullscreen frames do not differ.  I hope I
succeeded removing most associated problems by now.  Some of them might
still be present though.

 >>   This will, however, affect user-set margins that are
 >> _not_ continuously refreshed via a hook.
 >
 > Does that happen? Users setting window margins, I mean?

To my experience the first margins continuously refreshed by a hook were
introduced by ‘line-number-mode’.  Till then, margins were usually
specified once per buffer and kept their original size until the buffer
was killed.  But my memory might fail.

martin

Re: split-window-right doesn't work with wide margins

[Joost Kremers]

On Wed, Jan 20 2016, martin rudalics wrote:>
[split-window function that first reduces the margins]
> No.  ‘split-window-preferred-function’ only affects ‘display-buffer’.
> It does not affect ‘split-window’.  I attached a possible solution which
> is far from ideal.  I hope you get the idea.

I've finally gotten around to implementing this. Yes, I get the idea,
but there wasn't much I could improve, so I've basically taken your
function and adapted it for use in my package. Works fine for me so far,
and I haven't had any serious bug reports (yet).

>  A similar solution would
> be needed for ‘split-window-preferred-function’.  Essentially you would
> have to rewrite ‘split-window-sensibly’ with a reset/restore mechanism
> around the (window-splittable-p window t) and (split-window-right)
> forms.  Slightly more tricky ...

I've taken a slightly different approach. I wrote a function that unsets
the margins and then simply calls `split-window'. Since
`split-window-preferred-function' is a user option, it's not installed
by default. I've left that up to the user to decide. (Though I've set
the option and so far, everything works fine.)

Thanks for your help


-- 
Joost Kremers
Life has its moments