Window splitting issues with margins

Window splitting issues with margins

[Joost Kremers]

Hi list,

[First-time poster. Sorry for the long post but I really couldn't find
a way to describe the problem using less text...]

I maintain a package called visual-fill-column[1] that mimicks the
effect of `fill-column' in buffers with `visual-line-mode' turned on by
widening the window margins. As such, I ran into an issue with window
splitting that I believe Emacs should handle better.

If I split a window horizontally[2] that has a wide margin, e.g., with
`split-window-right', the width of the text area is reduced to a minimum
of 2 columns before the margins are reduced. At least that is my
impression from the following test:

- emacs -Q
- make sure you have a wide frame
- load any text file (to better see the effect)
- M-x eval (set-window-margins (selected-window) 0 150)
- C-x 3 (split-window-right)

Depending on the width of the frame and the size of the right margin,
the text is now reduced to a very small width, while the margin is much
wider.

I think it would make more sense to reduce the margin before reducing
the text width.

A related problem is the fact that `window-splittable-p' only takes the
width of the text area into account when deciding if a window can be
split horizontally. This often leads to the situation where a window is
split vertically, although there appears to be enough room to split it
horizontally (said room being taken up by the margin).

Also, there is no built-in function that returns the width of the window
without the fringes, scroll bar and right divider, but *with* the
margins. There is `window-text-width' and `window-body-width' (which,
despite their names, both only look at the text width; though the latter
has a PIXELWISE argument that the former lacks). The function
`window-total-width' returns the window width *with* fringes, scroll
bars and right divider.

Such a function would be useful for packages that calculate some value
that depends on the width of the window, which often end up using a bad
value if the window has wide margins (e.g., windows showing buffers
where `visual-fill-column-mode' is in use). I have made several bug
reports / pull requests to packages asking them to use
`window-total-width' instead of `window-width' (which is an alias for
`window-body-width'), and most have been kind enough to make the change,
but my pull request to popwin.el[3] was rejected because the window
configuration wasn't always restored properly after closing the popup
window. This seems to be the result of using `window-total-width',
because using a custom function that returns justh the text width +
margins works fine (i.e., all of popwin.el's ERT tests now pass[4]).

Such a function would probably make sense for the other packages that
(now) use `window-total-width' as well, because what these packages
generally need to know is the maximum *potential* width of the text
area.

Joost Kremers




[1] https://github.com/joostkremers/visual-fill-column

[2] I.e., into two side-by-side windows; the terms "splitting
horizontally / vertically" always confuse me...

[3] https://github.com/m2ym/popwin-el/pull/119

[4] https://github.com/m2ym/popwin-el/pull/130

-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > I maintain a package called visual-fill-column[1] that mimicks the
 > effect of `fill-column' in buffers with `visual-line-mode' turned on by
 > widening the window margins. As such, I ran into an issue with window
 > splitting that I believe Emacs should handle better.
 >
 > If I split a window horizontally[2] that has a wide margin, e.g., with
 > `split-window-right', the width of the text area is reduced to a minimum
 > of 2 columns before the margins are reduced. At least that is my
 > impression from the following test:
 >
 > - emacs -Q
 > - make sure you have a wide frame
 > - load any text file (to better see the effect)
 > - M-x eval (set-window-margins (selected-window) 0 150)
 > - C-x 3 (split-window-right)
 >
 > Depending on the width of the frame and the size of the right margin,
 > the text is now reduced to a very small width, while the margin is much
 > wider.
 >
 > I think it would make more sense to reduce the margin before reducing
 > the text width.

The margins you set above become a window property.  If after C-x 3 you
do C-x 1 your are left with the reduced margins which might not be what
you want.  Deciding when and how to auto-adjust margins is not trivial.
I would do that in ‘visual-fill-column’.

 > A related problem is the fact that `window-splittable-p' only takes the
 > width of the text area into account when deciding if a window can be
 > split horizontally. This often leads to the situation where a window is
 > split vertically, although there appears to be enough room to split it
 > horizontally (said room being taken up by the margin).

I agree with this observation.  ‘window-splittable-p’ is asymmetric:
When it checks the width, it uses the text area while for the height it
uses the total area (inlcuding mode and header lines, scrollbar, divider
...).  If you want to change this, please provide a patch.  I certainly
won't object it but am afraid that some people eventually will complain
because one of their packages then doesn't work like it used to over the
past decades ...

BTW: Bug#5944 is about a related issue.  I never got around to resolve
it for a similar reason.

 > Also, there is no built-in function that returns the width of the window
 > without the fringes, scroll bar and right divider, but *with* the
 > margins.

But it's not overly hard to write such a function ;-)

 > There is `window-text-width' and `window-body-width' (which,
 > despite their names, both only look at the text width;

If your read the Elisp manual (section 27.3 Window Sizes) you will
notice that "text area" and "window body" denote one and the same thing.

 > though the latter
 > has a PIXELWISE argument that the former lacks

The former will have one in Emacs 25.1.  But you should always use
‘window-body-width’ now.

 > ).  The function
 > `window-total-width' returns the window width *with* fringes, scroll
 > bars and right divider.
 >
 > Such a function would be useful for packages that calculate some value
 > that depends on the width of the window, which often end up using a bad
 > value if the window has wide margins (e.g., windows showing buffers
 > where `visual-fill-column-mode' is in use). I have made several bug
 > reports / pull requests to packages asking them to use
 > `window-total-width' instead of `window-width' (which is an alias for
 > `window-body-width'), and most have been kind enough to make the change,
 > but my pull request to popwin.el[3] was rejected because the window
 > configuration wasn't always restored properly after closing the popup
 > window. This seems to be the result of using `window-total-width',
 > because using a custom function that returns justh the text width +
 > margins works fine (i.e., all of popwin.el's ERT tests now pass[4]).
 >
 > Such a function would probably make sense for the other packages that
 > (now) use `window-total-width' as well, because what these packages
 > generally need to know is the maximum *potential* width of the text
 > area.

The greatest problem I have with a function returning the combined size
of text area and margins is that it would leave out the fringes.  Hence
such a function would by default _not_ return the size of a contiguous
area on the screen which I personally would find slightly disconcerting.

But if you send us such a function (say ‘window-text+margins-width’)
and nobody objects I'll install it.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Thu, 12 Nov 2015 15:31:08 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> Deciding when and how to auto-adjust margins is not trivial.

I'm not sure margins should be auto-adjusted at all.  Whatever
application sets up those margins, they most probably need all that
space, and Emacs should not second guess such applications.  For
example, linum-mode sets the margin just wide enough to display the
longest line number; make the margin smaller, and the numbers will be
truncated.  That's a bug in my book.

Re: Window splitting issues with margins

[Joost Kremers]

On Do, Nov 12 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 12 Nov 2015 15:31:08 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> 
>> Deciding when and how to auto-adjust margins is not trivial.
>
> I'm not sure margins should be auto-adjusted at all.  Whatever
> application sets up those margins, they most probably need all that
> space, and Emacs should not second guess such applications.  For
> example, linum-mode sets the margin just wide enough to display the
> longest line number; make the margin smaller, and the numbers will be
> truncated.  That's a bug in my book.

Perhaps what is needed is for a mode that uses the margins to be able to
specify a minimum size for them, so that a window-resize can take that
into account. That would allow other modes to use the margin flexibly.

In fact, IIUC this is sorta what the patch that João Távora posted
earlier tries to do, but inside linum-mode. I have a package
writeroom-mode that is similar to his darkroom-mode and I've received
similar bug reports saying that writeroom-mode and linum-mode don't play
nice together.[1]

What writeroom-mode and darkroom-mode both do is use the margins to
display the text of a buffer in the center of the window, to create a
"distraction-free writing environment", as it's called. writeroom-mode
lets you specify the width of the text and adjusts the margins to make
that happen. (Actually, it uses visual-fill-column to do that.) With
every window resize, the margins are readjusted. So there's no
requirement that the margins have a minimum width, the width depends on
whatever the window width happens to be.

linum-mode seems to assume that no-one else is using the margins and
simply sets the left margin to the width it needs for itself. It'd be
great if linum-mode (or any other mode of course) would be able to
specify that it needs the left margin to be at least n characters wide
and if there were an easy way for other packages to respect this.

If it would also be possible to specify a margin width without locking
it, then this could help with the issue I posted about. If it's known
that parts of the margins are reserved, while others are not, the
window-splitting functions know what part of the margins they can safely
assume will be adjusted.

Perhaps an example to make things clearer: assume a window width of 200
characters. I want my text to be 80 chars wide and centered, so the left
and right margins need to be (200-80)/2 = 60 each. Package X sets the
margins to 60, but doesn't lock them. linum-mode says it needs a left
margin of at least 4, so a width of 4 chars is locked. Now, the window
is split and window-splittable-p must determine if the window can be
split horizontally. Currently, it will base its judgement on the width
of the text area, which is 80, the result being `nil' for 'no, the
window cannot be split horizontally'. If a mode could "lock" part of the
margin, it would know that it can assume a width of 200-4 = 196 and
return `t' for 'yes, the window can be split horizontally'. The window
is split and package X (through `window-configuration-change-hook')
adjusts the margins.

HTH

Joost




[1] E.g., here:

https://github.com/joostkremers/writeroom-mode/issues/20

and here:

https://github.com/joostkremers/writeroom-mode/issues/12

-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > linum-mode seems to assume that no-one else is using the margins

... the left margin only, to be precise ...

 > and
 > simply sets the left margin to the width it needs for itself. It'd be
 > great if linum-mode (or any other mode of course) would be able to
 > specify that it needs the left margin to be at least n characters wide
 > and if there were an easy way for other packages to respect this.

The number of characters used by ‘linum-mode’ can vary dynamically
according to the size of the buffer.  If ‘linum-mode’ is non-nil in a
buffer, the left margin width of any window showing that buffer
specifies the number of characters needed by ‘linum-mode’.

 > If it would also be possible to specify a margin width without locking
 > it, then this could help with the issue I posted about. If it's known
 > that parts of the margins are reserved, while others are not, the
 > window-splitting functions know what part of the margins they can safely
 > assume will be adjusted.
 >
 > Perhaps an example to make things clearer: assume a window width of 200
 > characters. I want my text to be 80 chars wide and centered, so the left
 > and right margins need to be (200-80)/2 = 60 each. Package X sets the
 > margins to 60, but doesn't lock them. linum-mode says it needs a left
 > margin of at least 4, so a width of 4 chars is locked. Now, the window
 > is split and window-splittable-p must determine if the window can be
 > split horizontally. Currently, it will base its judgement on the width
 > of the text area, which is 80, the result being `nil' for 'no, the
 > window cannot be split horizontally'. If a mode could "lock" part of the
 > margin, it would know that it can assume a width of 200-4 = 196 and
 > return `t' for 'yes, the window can be split horizontally'. The window
 > is split and package X (through `window-configuration-change-hook')
 > adjusts the margins.

I doubt it's easily possible for a package X to share the left margin
with ‘linum-mode’.  The latter has

(set-window-margins win width (cdr (window-margins win)))

so it simply doesn't care about other packages using the left margin.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
> Date: Thu, 12 Nov 2015 22:38:38 +0100
> 
> > I'm not sure margins should be auto-adjusted at all.  Whatever
> > application sets up those margins, they most probably need all that
> > space, and Emacs should not second guess such applications.  For
> > example, linum-mode sets the margin just wide enough to display the
> > longest line number; make the margin smaller, and the numbers will be
> > truncated.  That's a bug in my book.
> 
> Perhaps what is needed is for a mode that uses the margins to be able to
> specify a minimum size for them, so that a window-resize can take that
> into account. That would allow other modes to use the margin flexibly.

If we are talking about the needs of window-resize, then let's think
in terms of that function's needs.  How about if a window or a buffer
could specify the minimum width of its text body, and window-resize
could then use that information when it decides how to split?

Re: Window splitting issues with margins

[martin rudalics]

 > If we are talking about the needs of window-resize, then let's think
 > in terms of that function's needs.  How about if a window or a buffer
 > could specify the minimum width of its text body, and window-resize
 > could then use that information when it decides how to split?

‘window-resize’ doesn't split.  If you mean ‘split-window-sensibly’ then
it already compares ‘split-width-threshold’ with the width of the text
area of the window that shall be split.  But all this is very
hypothetical since ‘display-buffer’ will usually display another buffer
in the new window with different local variables and needs.  Neither
‘split-window-sensibly’ nor ‘window-splittable-p’ are up to this task.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Fri, 13 Nov 2015 11:01:48 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > If we are talking about the needs of window-resize, then let's think
>  > in terms of that function's needs.  How about if a window or a buffer
>  > could specify the minimum width of its text body, and window-resize
>  > could then use that information when it decides how to split?
> 
> ‘window-resize’ doesn't split.  If you mean ‘split-window-sensibly’ then
> it already compares ‘split-width-threshold’ with the width of the text
> area of the window that shall be split.  But all this is very
> hypothetical since ‘display-buffer’ will usually display another buffer
> in the new window with different local variables and needs.  Neither
> ‘split-window-sensibly’ nor ‘window-splittable-p’ are up to this task.

I'm sorry, how does display-buffer come into this picture?  I thought
the original problem was with splitting a wide window in which the
margins were set to a large size in order to keep the body text at a
smaller width.  I'm asking whether we could pass this information to
the code which splits the window, so that its decisions would take
that information into consideration.

Re: Window splitting issues with margins

[martin rudalics]

 > I'm sorry, how does display-buffer come into this picture?

In another other mail you said

 >> let's instead try to solve that on the
 >> window-splittable-p level

and that function is used only in the context of ‘display-buffer’.

 > I thought
 > the original problem was with splitting a wide window in which the
 > margins were set to a large size in order to keep the body text at a
 > smaller width.  I'm asking whether we could pass this information to
 > the code which splits the window, so that its decisions would take
 > that information into consideration.

This would have to be done in ‘split-window’ then.  More precisely it
would have to be done in the function ‘window--sanitize-window-sizes’
which tries to make sure that all windows have reasonable sizes
according to the sizes of their margins, fringes, ...

Note one aspect though: When you shrink margins while splitting or
shrinking windows you usually won't get back their old size after
deleting the other or enlarging this window.  That's why I think that
it's much easier when packages manage their preferred size of margins in
‘window-size-change-functions’ and ‘window-configuration-change-hook’.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Fri, 13 Nov 2015 15:53:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  > I thought
>  > the original problem was with splitting a wide window in which the
>  > margins were set to a large size in order to keep the body text at a
>  > smaller width.  I'm asking whether we could pass this information to
>  > the code which splits the window, so that its decisions would take
>  > that information into consideration.
> 
> This would have to be done in ‘split-window’ then.  More precisely it
> would have to be done in the function ‘window--sanitize-window-sizes’
> which tries to make sure that all windows have reasonable sizes
> according to the sizes of their margins, fringes, ...

Something like that, yes.

> Note one aspect though: When you shrink margins while splitting or
> shrinking windows you usually won't get back their old size after
> deleting the other or enlarging this window.  That's why I think that
> it's much easier when packages manage their preferred size of margins in
> ‘window-size-change-functions’ and ‘window-configuration-change-hook’.

Yes, that would perhaps be preferable.

Is there any reason why dark-room mode couldn't do that?

Re: Window splitting issues with margins

[Joost Kremers]

On Do, Nov 12 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > I think it would make more sense to reduce the margin before reducing
>  > the text width.
>
> The margins you set above become a window property.  If after C-x 3 you
> do C-x 1 your are left with the reduced margins which might not be what
> you want.  Deciding when and how to auto-adjust margins is not trivial.
> I would do that in ‘visual-fill-column’.

Except that I don't know if any other package is also using the margin
and should perhaps assume a minimum width larger than 0. Right now,
visual-fill-column will happily set the margin to 0 if the window width
is smaller than the requested text width.

> I agree with this observation.  ‘window-splittable-p’ is asymmetric:
> When it checks the width, it uses the text area while for the height it
> uses the total area (inlcuding mode and header lines, scrollbar, divider
> ...).  If you want to change this, please provide a patch.  I certainly
> won't object it but am afraid that some people eventually will complain
> because one of their packages then doesn't work like it used to over the
> past decades ...

Well, I've been using a modified `window-splittable-p' in my init file
for quite some time and *I* don't have any complaints. ;-)

> The greatest problem I have with a function returning the combined size
> of text area and margins is that it would leave out the fringes.  Hence
> such a function would by default _not_ return the size of a contiguous
> area on the screen which I personally would find slightly disconcerting.

True. I hadn't thought about that.

> But if you send us such a function (say ‘window-text+margins-width’)
> and nobody objects I'll install it.

I might do that, but I will think a bit about what to do with the fringes.

-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > Except that I don't know if any other package is also using the margin
 > and should perhaps assume a minimum width larger than 0. Right now,
 > visual-fill-column will happily set the margin to 0 if the window width
 > is smaller than the requested text width.

The question is whether it makes any sense for two packages to ever
share one and the same margin.  I doubt that.  And if one package uses
the left and the other package uses the right margin, they will have to
reach some sort of agreement when trying to auto-adjust margins.

 > Well, I've been using a modified `window-splittable-p' in my init file
 > for quite some time and *I* don't have any complaints. ;-)

But you are aware of the fact that ‘window-splittable-p’ is used only by
the buffer display functions.  All other ‘split-window’ calls (including
C-x 3) don't care about it.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Fri, 13 Nov 2015 09:04:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
>  > Except that I don't know if any other package is also using the margin
>  > and should perhaps assume a minimum width larger than 0. Right now,
>  > visual-fill-column will happily set the margin to 0 if the window width
>  > is smaller than the requested text width.
> 
> The question is whether it makes any sense for two packages to ever
> share one and the same margin.  I doubt that.  And if one package uses
> the left and the other package uses the right margin, they will have to
> reach some sort of agreement when trying to auto-adjust margins.

I agree.  Making the display margins shareable is a tough nut, it will
most probably require introduction of quite a few new functions that
every user of the margins will have to consult.  If the only use case
that needs that is these two modes, and if their problem is only with
splitting the window, let's instead try to solve that on the
window-splittable-p level.

Re: Window splitting issues with margins

[martin rudalics]

 > I agree.  Making the display margins shareable is a tough nut, it will
 > most probably require introduction of quite a few new functions that
 > every user of the margins will have to consult.  If the only use case
 > that needs that is these two modes, and if their problem is only with
 > splitting the window, let's instead try to solve that on the
 > window-splittable-p level.

Note: ‘window-splittable-p’ decides only if a window can be split for
‘display-buffer’.  It's not about C-x 2 or C-x 3.

martin

Re: Window splitting issues with margins

[Joost Kremers]

On Fr, Nov 13 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 13 Nov 2015 09:04:54 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> Cc: emacs-devel@gnu.org
>> 
>>  > Except that I don't know if any other package is also using the margin
>>  > and should perhaps assume a minimum width larger than 0. Right now,
>>  > visual-fill-column will happily set the margin to 0 if the window width
>>  > is smaller than the requested text width.
>> 
>> The question is whether it makes any sense for two packages to ever
>> share one and the same margin.  I doubt that.

Well, linum-mode uses the margins to display line numbers and both
writeroom-mode and darkroom-mode use them to center the text in a wide
window. Personally, I don't use both modes at the same time (I use
writeroom-mode when writing text, linum-mode to me only seems useful in
programming), but there are apparently users who would like to use both
at the same time. Which currently is not possible.

> I agree.  Making the display margins shareable is a tough nut, it will
> most probably require introduction of quite a few new functions that
> every user of the margins will have to consult.  If the only use case
> that needs that is these two modes,

For the moment, it seems so, yes, but who knows what uses for the
margins future packages come up with?

> and if their problem is only with
> splitting the window, let's instead try to solve that on the
> window-splittable-p level.

Actually, that's not the only problem. Just activating both linum-mode
and writeroom-mode in a single buffer is already problematic, because
linum-mode doesn't take the possibility into consideration that some
other package might have set the left margin to a value > 0.
writeroom-mode will do the same, BTW.

The window-splittable issue has nothing to do with linum-mode, it's just
a writeroom-mode issue.

It's just that I think both issues could be solved by the same
mechanism: allowing a (minor) mode to lock the margins to a certain
minimum width. window-splittable-p could then assume that those parts of
the margins that are not locked can be reduced along with the text area,
unlike now, where the underlying assumption seems to be that if the
margins are > 0, there's probably a reason for it and they shouldn't be
reduced.

At the same time, it would allow linum-mode and writeroom-mode to play
nice together: instead of setting the margin to the size it requires for
line numbers, linum-mode could set a minimum size, allowing other
packages to make them wider. writeroom-mode then would not be allowed to
set margins to less than the minimum size.

I'm not familiar with Emacs internals, so I can't say how difficult
something like this would be to implement or if it's really the best
method. It's also more of a "would be nice to have" rather than a "must
have" and it might be more trouble than it's worth. But still, it would
be nice to have. ;-)

-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Sat, 14 Nov 2015 21:34:09 +0100
> Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
> 
> It's just that I think both issues could be solved by the same
> mechanism: allowing a (minor) mode to lock the margins to a certain
> minimum width. window-splittable-p could then assume that those parts of
> the margins that are not locked can be reduced along with the text area,
> unlike now, where the underlying assumption seems to be that if the
> margins are > 0, there's probably a reason for it and they shouldn't be
> reduced.
> 
> At the same time, it would allow linum-mode and writeroom-mode to play
> nice together: instead of setting the margin to the size it requires for
> line numbers, linum-mode could set a minimum size, allowing other
> packages to make them wider. writeroom-mode then would not be allowed to
> set margins to less than the minimum size.

But this will only work in a very special case: when only one mode
actually displays something in the margin.  Once another mode wants to
put something there, all bets are off.  Right?

Re: Window splitting issues with margins

[Joost Kremers]

On Mo, Nov 16 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Date: Sat, 14 Nov 2015 21:34:09 +0100
>> Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
>> 
>> It's just that I think both issues could be solved by the same
>> mechanism: allowing a (minor) mode to lock the margins to a certain
>> minimum width. window-splittable-p could then assume that those parts of
>> the margins that are not locked can be reduced along with the text area,
>> unlike now, where the underlying assumption seems to be that if the
>> margins are > 0, there's probably a reason for it and they shouldn't be
>> reduced.
>> 
>> At the same time, it would allow linum-mode and writeroom-mode to play
>> nice together: instead of setting the margin to the size it requires for
>> line numbers, linum-mode could set a minimum size, allowing other
>> packages to make them wider. writeroom-mode then would not be allowed to
>> set margins to less than the minimum size.
>
> But this will only work in a very special case: when only one mode
> actually displays something in the margin.  Once another mode wants to
> put something there, all bets are off.  Right?

Yes, but isn't that currently the case as well?

Of course, to do it right, you'd have to come up with a scheme that
allows any number of modes to play nice. Perhaps a function
`add-to-window-margin N SYM' that a mode can use to add N columns to the
margin and have SYM added as a property of some sort or a window
parameter indicating which column(s) were added, and a similar function
`remove-from-window-margin SYM', which removes those columns again.
Modes could then manage their own part of the margins without stomping
on other modes. (A mode would simply request a number of columns, it
wouldn't need to know if it gets columns 1-4, or 5-6, etc., although it
could find that out by examining the SYM property/parameter.) Columns
that have such an associated SYM property are not considered reducible
by `window-splittable-p'.

It would still have to be possible for modes like writeroom-mode to set
the margin to a specific width without setting a property, but those
margins would be considered reducible by `window-splittable-p'.
Furthermore, it shouldn't be possible to set a width that is smaller
than what other modes have set. This could either be enforced by the API
or writeroom-mode would have to ensure this itself.

Anyway, it seems something similar is being discussed in the thread on
the linum patch, although as a more general option.



-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > Columns
 > that have such an associated SYM property are not considered reducible
 > by `window-splittable-p'.

As I tried to explain before: ‘window-splittable-p’ is hardly the
function we care about here.  We care about ‘split-window’ itself.

 > It would still have to be possible for modes like writeroom-mode to set
 > the margin to a specific width without setting a property, but those
 > margins would be considered reducible by `window-splittable-p'.
 > Furthermore, it shouldn't be possible to set a width that is smaller
 > than what other modes have set. This could either be enforced by the API
 > or writeroom-mode would have to ensure this itself.

There are two issues involved:

(1) ‘linum-mode’ sets the margin to some small, fixed value defeating
‘writeroom-mode’.  I think this can be fixed by having ‘writeroom-mode’
set a ‘margins-min-width’ window parameter and have either
‘set_window_margins’ or modes like ‘linum-mode’ respect that value.

(2) When a window is split via ‘split-window-right’ or is shrunk
horizontally, ‘writeroom-mode’ probably should reset its margins (and
the window parameter) to some lower value.  It should do that via
‘window-configuration-change-hook’ (when splitting) and
‘window-size-change-functions’ (when the window is resized).  When the
splitting is undone or the window is sized back, ‘writeroom-mode’ will
probably want to enlarge the margins again.

martin

Re: Window splitting issues with margins

[Joost Kremers]

> Op 16 nov. 2015 om 19:56 heeft martin rudalics <rudalics@gmx.at> het volgende geschreven:
> > Columns
> > that have such an associated SYM property are not considered reducible
> > by `window-splittable-p'.
> 
> As I tried to explain before: ‘window-splittable-p’ is hardly the
> function we care about here.  We care about ‘split-window’ itself.

Actually, I care about window-splittable-p, not about split-window. split-window is not a problem, because after it's done its work, window-configuration-change-hook is run, where writeroom-mode can (and in fact already does) adjust the window margins.

The problem with window-splittable-p is that it decides whether a window can be split horizontally *before* writeroom-mode has a chance to adjust the margins. Since in the cases I'm talking about, most of the window width is taken up by the margins, window-splittable-p thinks that the window is rather narrow (80 characters, the width of the text area), while in fact it is quite wide (over 200 chars) and could be split horizontally (because most of those 200 chars are not used for anything except keeping the text width small).

> > It would still have to be possible for modes like writeroom-mode to set
> > the margin to a specific width without setting a property, but those
> > margins would be considered reducible by `window-splittable-p'.
> > Furthermore, it shouldn't be possible to set a width that is smaller
> > than what other modes have set. This could either be enforced by the API
> > or writeroom-mode would have to ensure this itself.
> 
> There are two issues involved:
> 
> (1) ‘linum-mode’ sets the margin to some small, fixed value defeating
> ‘writeroom-mode’.  I think this can be fixed by having ‘writeroom-mode’
> set a ‘margins-min-width’ window parameter and have either
> ‘set_window_margins’ or modes like ‘linum-mode’ respect that value.

Actually, it's the other way around: linum-mode should set margins-min-width and writeroom-mode should respect that value. writeroom-mode's goal is to set the text width to a certain value. It doesn't care about the margins, except that it needs them in order achieve this goal. If the margins need to be set to 0 to achieve the desired text width, that's fine. It's linum-mode that requires a minimum width for the left margin, because it needs to display something there.

Of course I'd be happy to update writeroom-mode to make it respect a minimum margin width set by some other package, but right now, I don't see any way of doing that.

> (2) When a window is split via ‘split-window-right’ or is shrunk
> horizontally, ‘writeroom-mode’ probably should reset its margins (and
> the window parameter) to some lower value.  It should do that via
> ‘window-configuration-change-hook’ (when splitting) and
> ‘window-size-change-functions’ (when the window is resized).  When the
> splitting is undone or the window is sized back, ‘writeroom-mode’ will
> probably want to enlarge the margins again.

Like I said, writeroom-mode already adjusts the margins when the window configuration changes.

There are indeed two issues, though I would formulate them somewhat differently:

(1) Different packages that use the margins have no way of interoperating without running into trouble at some point.

(2) When the margins are used to narrow the text width, window-splittable-p should take that into consideration when deciding if a window can be split horizontally. Right now, it doesn't.

I think (2) is a relatively minor issue. The worst thing that happens is that a window is split vertically that could have been split horizontally, e.g., when a help window is popped up. Still, I think it would be fairly easy to fix once issue (1) is taken care of.

(1) is a more serious issue, and one thing (though not the only thing) that needs to be recognised in order to find a way to deal with it is that the margins can be used for two fundamentally different types of purposes. On the one hand, they can be used to display some useful information about the buffer being shown in the window. On the other hand, they can be used to adjust the width of the text area. The crucial difference is that for the former purpose, the margins should not be reduced when the window width changes, while for the latter purpose, they can be adjusted freely. (Put differently, in the former case, the margins trump the text width, while in the latter, the text width trumps the margins).


-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > Actually, I care about window-splittable-p, not about
 > split-window. split-window is not a problem, because after it's done
 > its work, window-configuration-change-hook is run, where
 > writeroom-mode can (and in fact already does) adjust the window
 > margins.

If it's arranged to run after the function ‘linum-mode’ put on
‘window-configuration-change-hook’.

 > The problem with window-splittable-p is that it decides whether a
 > window can be split horizontally *before* writeroom-mode has a chance
 > to adjust the margins. Since in the cases I'm talking about, most of
 > the window width is taken up by the margins, window-splittable-p
 > thinks that the window is rather narrow (80 characters, the width of
 > the text area), while in fact it is quite wide (over 200 chars) and
 > could be split horizontally (because most of those 200 chars are not
 > used for anything except keeping the text width small).

Aha.  So you want to use ‘window-total-width’ instead of
‘window-text-width’ here.  Sounds reasonable.

‘window-splittable-p’ uses ‘window-width’ and ‘window-height’ just
because these were there at the time the function was written.  If no
one objects let's make it use total sizes in both directions.

 > Actually, it's the other way around: linum-mode should set
 > margins-min-width and writeroom-mode should respect that
 > value. writeroom-mode's goal is to set the text width to a certain
 > value. It doesn't care about the margins, except that it needs them in
 > order achieve this goal. If the margins need to be set to 0 to achieve
 > the desired text width, that's fine. It's linum-mode that requires a
 > minimum width for the left margin, because it needs to display
 > something there.

OK.  But you rely on the fact that ‘writeroom-mode’ is able to run its
hook functions after ‘linum-mode’.  This dependency is not very stable.

 > Of course I'd be happy to update writeroom-mode to make it respect a
 > minimum margin width set by some other package, but right now, I don't
 > see any way of doing that.

 > (1) Different packages that use the margins have no way of
 > interoperating without running into trouble at some point.

Yes.

 > (2) When the margins are used to narrow the text width,
 > window-splittable-p should take that into consideration when deciding
 > if a window can be split horizontally. Right now, it doesn't.
 >
 > I think (2) is a relatively minor issue. The worst thing that happens
 > is that a window is split vertically that could have been split
 > horizontally, e.g., when a help window is popped up. Still, I think it
 > would be fairly easy to fix once issue (1) is taken care of.

But using ‘window-total-width’ in ‘window-splittable-p’ would fix (2).
Correct?

 > (1) is a more serious issue, and one thing (though not the only thing)
 > that needs to be recognised in order to find a way to deal with it is
 > that the margins can be used for two fundamentally different types of
 > purposes. On the one hand, they can be used to display some useful
 > information about the buffer being shown in the window. On the other
 > hand, they can be used to adjust the width of the text area. The
 > crucial difference is that for the former purpose, the margins should
 > not be reduced when the window width changes, while for the latter
 > purpose, they can be adjusted freely. (Put differently, in the former
 > case, the margins trump the text width, while in the latter, the text
 > width trumps the margins).

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.

martin

Re: Window splitting issues with margins

[Joost Kremers]

On Di, Nov 17 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > Actually, I care about window-splittable-p, not about
>  > split-window. split-window is not a problem, because after it's done
>  > its work, window-configuration-change-hook is run, where
>  > writeroom-mode can (and in fact already does) adjust the window
>  > margins.
>
> If it's arranged to run after the function ‘linum-mode’ put on
> ‘window-configuration-change-hook’.

Yes, which is why `writeroom-mode' appends its update function to
`window-configuration-change-hook'. However, even though `linum-mode'
prepends its own update function `linum-update-current', it still usurps
the left margin, probably because `linum-update-current' is also added
to `post-command-hook'.

For clarity, the value of `window-configuration-change-hook' when both
writeroom-mode and linum-mode are enabled in a buffer is:

```
(linum-update-current t visual-fill-column--adjust-window)
```

(Note that writeroom-mode doesn't actually modify the margins itself. It
uses `visual-fill-column-mode' for that).

`nlinum-mode' seems to behave better, BTW. It doesn't set the margins'
width after each change or after each command, it seems to do that in
just two cases: when the window configuration is changed, and if it
needs more room for the line numbers (e.g., when line number 100 is
reached). The former is handled by appending rather than prepending
`visual-fill-column--adjust-window' to
`window-configuration-change-hook', so is not a problem. The latter
unfortunately still destroys the margin set by `writeroom-mode', but
things are restored again by any operation that calls
`window-configuration-change-hook'.

>  > The problem with window-splittable-p is that it decides whether a
>  > window can be split horizontally *before* writeroom-mode has a chance
>  > to adjust the margins. Since in the cases I'm talking about, most of
>  > the window width is taken up by the margins, window-splittable-p
>  > thinks that the window is rather narrow (80 characters, the width of
>  > the text area), while in fact it is quite wide (over 200 chars) and
>  > could be split horizontally (because most of those 200 chars are not
>  > used for anything except keeping the text width small).
>
> Aha.  So you want to use ‘window-total-width’ instead of
> ‘window-text-width’ here.  Sounds reasonable.

Yes. Sorry, I could have been clearer about that earlier. The modified
`window-splittable-p' that I have in my init file makes exactly this
single change.

> ‘window-splittable-p’ uses ‘window-width’ and ‘window-height’ just
> because these were there at the time the function was written.  If no
> one objects let's make it use total sizes in both directions.

I'd be all for it.

> OK.  But you rely on the fact that ‘writeroom-mode’ is able to run its
> hook functions after ‘linum-mode’.  This dependency is not very stable.

Nope.

>  > (2) When the margins are used to narrow the text width,
>  > window-splittable-p should take that into consideration when deciding
>  > if a window can be split horizontally. Right now, it doesn't.
>  >
>  > I think (2) is a relatively minor issue. The worst thing that happens
>  > is that a window is split vertically that could have been split
>  > horizontally, e.g., when a help window is popped up. Still, I think it
>  > would be fairly easy to fix once issue (1) is taken care of.
>
> But using ‘window-total-width’ in ‘window-splittable-p’ would fix (2).
> Correct?

Yes.

>  > (1) is a more serious issue, and one thing (though not the only thing)
>  > that needs to be recognised in order to find a way to deal with it is
>  > that the margins can be used for two fundamentally different types of
>  > purposes. On the one hand, they can be used to display some useful
>  > information about the buffer being shown in the window. On the other
>  > hand, they can be used to adjust the width of the text area. The
>  > crucial difference is that for the former purpose, the margins should
>  > not be reduced when the window width changes, while for the latter
>  > purpose, they can be adjusted freely. (Put differently, in the former
>  > case, the margins trump the text width, while in the latter, the text
>  > width trumps the margins).
>
> 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).

This policy won't be failure proof, but it should minimise annoyances
for users and should make it easier to live with such annoyances when
they do occur (by doing something that causes
`window-configuration-change-hook' to be run, e.g., switching to another
buffer and back, splitting and unsplitting the window).


-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > Yes. Sorry, I could have been clearer about that earlier. The modified
 > `window-splittable-p' that I have in my init file makes exactly this
 > single change.

Make it a patch.  Maybe we can get it into emacs-25.

Thanks, martin

Re: Window splitting issues with margins

[Joost Kremers]

On Fr, Nov 20 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > Yes. Sorry, I could have been clearer about that earlier. The modified
>  > `window-splittable-p' that I have in my init file makes exactly this
>  > single change.
>
> Make it a patch.  Maybe we can get it into emacs-25.

Done. Posted to bugs-gnu-emacs.


-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[Joost Kremers]

On Do, Nov 19 2015, Joost Kremers <joostkremers@fastmail.fm> wrote:
> On Di, Nov 17 2015, martin rudalics <rudalics@gmx.at> 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

Re: Window splitting issues with margins

[martin rudalics]

 > 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.

I think we agree that ‘nlinum-mode’ and ‘visual-fill-column-mode’ have
to file their requests via ‘set-window-margins’ and the latter uses the
maximum value requested.  All this is simple until the moment when the
mode that requested the current maximum size gets turned off.

In any case I would maintain a window parameter as a list of requested
margin widths like ((4 . 0) (40 . 40)).  Basically there are then two
ways to handle this: Let ‘set-window-margins’ decide or let the modes
agree among themselves.

For the former, when a mode gets turned off it calls, for example,
(set-window-margins nil -40 -40) and ‘set-window-margins’ decides that
there is one contender less for a left margin width of 40 and a right
margin width of 40 and it may have to set new widths.  -0 might require
special care.

Having the modes agree among themselves means that a mode that wants to
change the margins has to consult that parameter, add its own value to
it and only if its own value is larger than the current value, use it in
a call to ‘set-window-margins’.  When a mode is turned off, it has to
remove its value from the window parameter, and possibly call
‘set-window-margins’ with the new largest value.

WDYT?

martin

Re: Window splitting issues with margins

[Joost Kremers]

On Di, Nov 24 2015, martin rudalics <rudalics@gmx.at> wrote:
> I think we agree that ‘nlinum-mode’ and ‘visual-fill-column-mode’ have
> to file their requests via ‘set-window-margins’ and the latter uses the
> maximum value requested.  All this is simple until the moment when the
> mode that requested the current maximum size gets turned off.
>
> In any case I would maintain a window parameter as a list of requested
> margin widths like ((4 . 0) (40 . 40)).  Basically there are then two
> ways to handle this: Let ‘set-window-margins’ decide or let the modes
> agree among themselves.
>
> For the former, when a mode gets turned off it calls, for example,
> (set-window-margins nil -40 -40) and ‘set-window-margins’ decides that
> there is one contender less for a left margin width of 40 and a right
> margin width of 40 and it may have to set new widths.  -0 might require
> special care.
>
> Having the modes agree among themselves means that a mode that wants to
> change the margins has to consult that parameter, add its own value to
> it and only if its own value is larger than the current value, use it in
> a call to ‘set-window-margins’.  When a mode is turned off, it has to
> remove its value from the window parameter, and possibly call
> ‘set-window-margins’ with the new largest value.
>
> WDYT?

One question that came up while reading this is whether it is possible
for two modes to display something in the (same) margin. If yes, your
proposal will probably not work right. If we have, say, nlinum-mode
requesting a left margin of 4 and some-other-mode requesting a margin of
2, also in order to display something there, the window parameter would
be ((4 . 0) (2 . 0)). Then the actual left margin width should not be
(max 4 2) but (+ 4 2).

writeroom-mode is different, however, because it just wants the margins
to be a certain width, regardless of what other packages display in them.

I would probably use a window parameter that stores the requested margin
widths in an alist with the requesting modes as keys, e.g.:

((nlinum 4 . 0) (some-other-mode 2 . 0))

(The symbol can be freely chosen by the mode, but it should obviously be
properly prefixed.) `set-window-margins' then sets the margins to the
sum of the requested values.

As a special case, the symbol can also be t, which indicates that the
associated widths are not additive but minimum widths. This is what
writeroom-mode would use. So if the window parameter has the value:

((nlinum 4 . 0) (some-other-mode 2 . 0) (t 40 . 40))

a call to set-window-margins would set the margins to (40 . 40), because
4+2=6 and 6<40. But if it has the value:

((nlinum 4 . 0) (some-other-mode 2 . 0) (t 4 . 4))

`set-window-margins' would set the margins to (6 . 4), because
nlinum-mode and some-other-mode request a total width of 6, while the
minimum width is 4.

This would require adding an additional argument to set-window-margins
for the symbol to be used as a key in the window-margin alist. If the
symbol is left out, set-window-margins would behave in the old way,
setting window margins to absolute values and ignoring the window-margin
alist.

Anyway, all of this probably only makes sense if it's actually possible
for two modes to display something in the same margin without
interfering with each other.


-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[martin rudalics]

 > One question that came up while reading this is whether it is possible
 > for two modes to display something in the (same) margin.

Can we do that?

 > If yes, your
 > proposal will probably not work right. If we have, say, nlinum-mode
 > requesting a left margin of 4 and some-other-mode requesting a margin of
 > 2, also in order to display something there, the window parameter would
 > be ((4 . 0) (2 . 0)). Then the actual left margin width should not be
 > (max 4 2) but (+ 4 2).

Agreed.

 > writeroom-mode is different, however, because it just wants the margins
 > to be a certain width, regardless of what other packages display in them.
 >
 > I would probably use a window parameter that stores the requested margin
 > widths in an alist with the requesting modes as keys, e.g.:
 >
 > ((nlinum 4 . 0) (some-other-mode 2 . 0))

OK.  I thought about doing that because then a mode doesn't have to
remember the margin sizes it requested for the sole purpose to remove
them eventually.

 > (The symbol can be freely chosen by the mode, but it should obviously be
 > properly prefixed.) `set-window-margins' then sets the margins to the
 > sum of the requested values.

Or the requesting mode.  We'd still have to agree first on who's to
decide.

 > As a special case, the symbol can also be t, which indicates that the
 > associated widths are not additive but minimum widths. This is what
 > writeroom-mode would use. So if the window parameter has the value:
 >
 > ((nlinum 4 . 0) (some-other-mode 2 . 0) (t 40 . 40))
 >
 > a call to set-window-margins would set the margins to (40 . 40), because
 > 4+2=6 and 6<40. But if it has the value:
 >
 > ((nlinum 4 . 0) (some-other-mode 2 . 0) (t 4 . 4))
 >
 > `set-window-margins' would set the margins to (6 . 4), because
 > nlinum-mode and some-other-mode request a total width of 6, while the
 > minimum width is 4.

I we already use mode identifiers we can easily add a fourth value to
tell whether the values are additive or minimum.

 > This would require adding an additional argument to set-window-margins
 > for the symbol to be used as a key in the window-margin alist. If the
 > symbol is left out, set-window-margins would behave in the old way,
 > setting window margins to absolute values and ignoring the window-margin
 > alist.
 >
 > Anyway, all of this probably only makes sense if it's actually possible
 > for two modes to display something in the same margin without
 > interfering with each other.

Indeed.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Thu, 26 Nov 2015 09:23:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > One question that came up while reading this is whether it is possible
> > for two modes to display something in the (same) margin.
>
> Can we do that?

Sure, why not?  Here, try this in "emacs -Q":

  (set-window-margins nil 10 10)
  (put-text-property 141 142 'display ((margin left-margin) "Hi, "))
  (put-text-property 151 152 'display ((margin left-margin) "there!"))

When a window's got non-zero width display margin, that margin gets a
portion of the window's glyph matrix allocated for it.  So each glyph
row has a portion that belongs to the margin.  Then any display spec
that writes into the margin produces glyphs which are added to the
margin portion of the glyph row, until all the available width there
is exhausted, at which point any additional text (or images) written
into the margin simply gets discarded (there's no "continuation" or
line-wrapping for display margins).  But until then, you get
effectively the concatenation of everything written into the margins,
in the order the display engine examines the buffer and its associated
display strings/images and overlays.

Re: Window splitting issues with margins

[martin rudalics]

 > When a window's got non-zero width display margin, that margin gets a
 > portion of the window's glyph matrix allocated for it.  So each glyph
 > row has a portion that belongs to the margin.  Then any display spec
 > that writes into the margin produces glyphs which are added to the
 > margin portion of the glyph row, until all the available width there
 > is exhausted, at which point any additional text (or images) written
 > into the margin simply gets discarded (there's no "continuation" or
 > line-wrapping for display margins).  But until then, you get
 > effectively the concatenation of everything written into the margins,
 > in the order the display engine examines the buffer and its associated
 > display strings/images and overlays.

So this discussion is not hypothetical.  Does anyone take care of
inserting spaces between the specs?  If not this is yet another thing
modes had to agree upon.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Thu, 26 Nov 2015 17:58:34 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  > When a window's got non-zero width display margin, that margin gets a
>  > portion of the window's glyph matrix allocated for it.  So each glyph
>  > row has a portion that belongs to the margin.  Then any display spec
>  > that writes into the margin produces glyphs which are added to the
>  > margin portion of the glyph row, until all the available width there
>  > is exhausted, at which point any additional text (or images) written
>  > into the margin simply gets discarded (there's no "continuation" or
>  > line-wrapping for display margins).  But until then, you get
>  > effectively the concatenation of everything written into the margins,
>  > in the order the display engine examines the buffer and its associated
>  > display strings/images and overlays.
> 
> So this discussion is not hypothetical.  Does anyone take care of
> inserting spaces between the specs?

Spaces?  What spaces?

> If not this is yet another thing modes had to agree upon.

Sorry, I don't follow.

Re: Window splitting issues with margins

[martin rudalics]

 >> So this discussion is not hypothetical.  Does anyone take care of
 >> inserting spaces between the specs?
 >
 > Spaces?  What spaces?

Spaces to separate "display specifications" from each other.  Sorry, I
never use them so maybe this was a silly question.

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Thu, 26 Nov 2015 19:04:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  >> So this discussion is not hypothetical.  Does anyone take care of
>  >> inserting spaces between the specs?
>  >
>  > Spaces?  What spaces?
> 
> Spaces to separate "display specifications" from each other.

No, they follow one another, just like normal text in the text area.

Re: Window splitting issues with margins

[martin rudalics]

 >> Spaces to separate "display specifications" from each other.
 >
 > No, they follow one another, just like normal text in the text area.

So two images will appear glued together unless the display
specification itself takes precautions, I presume.  Is there a way to
center or flush-right objects in display margins?

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Fri, 27 Nov 2015 09:26:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  >> Spaces to separate "display specifications" from each other.
>  >
>  > No, they follow one another, just like normal text in the text area.
> 
> So two images will appear glued together unless the display
> specification itself takes precautions, I presume.

Yes.  Just like they will in the text area.

> Is there a way to center or flush-right objects in display margins?

No.  There are no ways to do that in the text area, either, not
without inserting characters or stretches of white space, or something
else that produces glyphs.

Re: Window splitting issues with margins

[martin rudalics]

 >> Is there a way to center or flush-right objects in display margins?
 >
 > No.  There are no ways to do that in the text area, either, not
 > without inserting characters or stretches of white space, or something
 > else that produces glyphs.

Can an object (text, image) in a display margin span multiple lines?

martin

Re: Window splitting issues with margins

[Eli Zaretskii]

> Date: Sat, 28 Nov 2015 11:22:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  >> Is there a way to center or flush-right objects in display margins?
>  >
>  > No.  There are no ways to do that in the text area, either, not
>  > without inserting characters or stretches of white space, or something
>  > else that produces glyphs.
> 
> Can an object (text, image) in a display margin span multiple lines?

No.  Nothing can span multiple screen lines in the margin.

Re: Window splitting issues with margins

[Joost Kremers]

On Fr, Nov 13 2015, martin rudalics <rudalics@gmx.at> wrote:
> The question is whether it makes any sense for two packages to ever
> share one and the same margin.  I doubt that.

Like I said in my other post, there are apparently people wanting to use
linum-mode and writeroom-mode at the same time.

>  > Well, I've been using a modified `window-splittable-p' in my init file
>  > for quite some time and *I* don't have any complaints. ;-)
>
> But you are aware of the fact that ‘window-splittable-p’ is used only by
> the buffer display functions.  All other ‘split-window’ calls (including
> C-x 3) don't care about it.

Yes, I'm aware of that. Those aren't a problem, because writeroom-mode
has a chance to adjust the margins using a function in
window-configuration-change-hook.

-- 
Joost Kremers
Life has its moments

Re: Window splitting issues with margins

[John Wiegley]

>>>>> Joost Kremers <joostkremers@fastmail.fm> writes:

> Like I said in my other post, there are apparently people wanting to use
> linum-mode and writeroom-mode at the same time.

Yes, but is it enough people to justify a change to Emacs core? We might be
talking about tens of people, and a change that would add complexity to Emacs
core (by changing window-splittable-p) for everyone.

If it can be solved this with some Emacs Lisp in either linum-mode or
writeroom-mode, that would be much better.

John

Re: Window splitting issues with margins

[Yuri Khan]

On Fri, Nov 13, 2015 at 2:04 PM, martin rudalics <rudalics@gmx.at> wrote:
> The question is whether it makes any sense for two packages to ever
> share one and the same margin.

There are a lot of things one might want to display in the margin at
the same time.

* Line numbers
* Modification marker bars
* Collapse/expand markers/buttons
* Bookmarks
* Debugger breakpoints and/or current statement arrow
* (in a git blame) Username and/or commit ID and/or date

These are mostly independent and it may make sense to isolate modes
from each other with respect to margin width.