bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

Eli Zaretskii <eliz@gnu.org> on Tue, 09 Aug 2016 18:53 +0300:
> Decreasing the width of the margins when splitting a window causes
> worse problems: if the smaller margin cannot display the stuff (text,
> image, etc.) that the application wants to display there, that stuff
> will be truncated, or not shown at all.  E.g., the line numbers shown
> by linum-mode will become truncated if the margins are made narrower
> than what linum-mode needs.  Worse, linum-mode recalculates the margin
> width from time to time, and so it will try to enlarge the margin,
> making the text area smaller than it can possibly be.  These are
> catastrophic failures that we cannot impose on Lisp applications.

I'm not suggesting that Emacs resize the margins, just that Emacs ought
not make the assumption that wide margins mean that splitting the window
is unsafe.

I think your ordering of priorities is a bit off. The top priority here
is that the user needs to be able to press C-x 3 and have the window
split in this use case. e.g. If the user has a window 204 columns wide
with margins each set at 62 columns (with a remaining text body width of
80 columns), attempts to split that window with C-x 3 and receives a
"Window X too small for splitting" error, given that the window is quite
wide and Emacs is saying it's too small, the user's justifiable
assumption is that Emacs is broken.

Also, buffer contents is truncated all the time... Whenever a line
exceeds the window width and truncate lines is t then we get a $ with
truncated text. I don't get your concern here, and especially why
truncating content is worse than breaking core Emacs functionality (C-x
3) with these use cases...

> From my POV, the 24.x behavior was broken, see above.  We changed that
> to avoid those problems.  An application that sets a margin of a
> certain width has every right to expect Emacs not to change that.

Your POV is valid as someone focused on the code, but here it's a
different POV to that of a user, who sees a large window and expects
splitting it to work, because it did in 24.x, so why not now.

Really, Emacs is making a false assumption here, which is that when I
split the window I am not also somehow controlling the margin width (in
this case, with one of a variety of minor modes). So this attempt to
perform some user mind-reading is the root of the design failure.

When Emacs doesn't know, Emacs ought to adopt the position "idk?" and
just do what it's told. When you assume you make an ass of u & Emacs.

> If the error message is unclear, we can and should improve it.  But I
> don't think this is the main issue at hand here.

Yeah it seems the author wants to include something like an error code,
which here is misleading because it resembles (list 2).

> Sorry, rolling this back is out of the question.  The current behavior
> was discussed at length, and was introduced to fix problems that I
> think are much worse.

So too should failing in a common use-case be out of the question.

It would appear that these discussions adopted a very ungracious view of
the mentioned prose-writing packages, that is, rather than find a
solution for both cases, that these packages should just fail?

> Emacs cannot possibly know that the application which set the margins
> can cope with decreasing the margins.  Only the application (or the
> user) know that.
>
> Anyway, I think these particular modes were also discussed in the
> context of this change in behavior.  I think one way of dealing with
> this issue in the modes you mention is to bind "C-x 3" to a
> specialized command that reduces the margins before it calls window-
> split.  An application can do this because it knows its features and
> limitations; Emacs core cannot.

I think rebinding C-x 3 is a messy solution. The problem isn't really
with split-window-right, it's with window-min-size.

For example, one use-case I've come up against a lot is when working
with a text file under git version control with olivetti on (which
automatically sets the margins quite wide) in a single window.
Activating magit would usually split the window horizontally, but
because of the wide margins, the window will split vertically.

This behaviour is not a big deal, but the user expectation when
looking at a wide window with wide margins containing lots of empty
space is that the window ought to split horizontally. Other results
look a bit off.

An idea I just thought of, so feel free to poke holes in it, is to
introduce a local variable, something like window-margins-resizable,
which defaults to nil, but could also be t left or right. This
alleviates the problem of Emacs needing to read the user's mind when it
comes to whether the margins really are too big to split the window or
being controlled otherwise.

Thoughts?