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

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: rudalics@gmx.at, 24193@debbugs.gnu.org
> Date: Wed, 10 Aug 2016 01:18:32 +1000
> 
> Eli Zaretskii <eliz@gnu.org> on Tue, 09 Aug 2016 17:56 +0300:
> > I don't think I understand what exactly you expected to happen.  In
> > "emacs -Q" with no margins, "C-x 3" produces 2 windows: one that is
> > 38-column wide, the other 37-column wide.  Since you requested 2 20-
> > column margins, they alone need 40 columns.  How can Emacs produce a
> > window with such margins out of 38 columns it has at its disposal?
> > That isn't enough even for the margins, let alone the text area.
> 
> On the one hand, splitting an 80 column wide window naturally halves the
> window width, and as such the minimum margin width should also be
> halved, so window-min-size is not calculating a logical minimum size.

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.

> On the other hand, I kinda just wanna say whatever 24.5 was, because it
> worked perfectly there and now it's broken. It's hard to see that as
> anything but a regression.

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.

> "Window #<window 1 on *scratch*> too small for splitting (2)" implies
> that the window is 2 columns wide, which is confusing, but the 2 is
> actually just the code author's numbering of error messages.

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.

> > If you have ideas for how to solve this, please tell.
> 
> The gfycat.com link shows the behaviour in 24.5, which works perfectly.
> I'd urge a rollback to the relevant 24.5 code here to prevent this bug
> going into the 25.1 release.

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.

> I understand Emacs is very code-centric, but many people use it also for
> prose writing, and there are several prose packages that set the window
> margins in this same way... olivetti, writeroom-mode, darkroom- mode,
> visual-fill-column... I haven't tested these all but predict a few
> related bugs...

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.

Thanks.