emacs-devel
[Top][All Lists]
Advanced

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

Window splitting issues with margins


From: Joost Kremers
Subject: Window splitting issues with margins
Date: Thu, 12 Nov 2015 14:04:08 +0100
User-agent: mu4e 0.9.13; emacs 24.5.50.1

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



reply via email to

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