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: Sun, 14 Aug 2016 15:11:30 +1000
> 
> > 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.

The function in question keeps the margins at their original size, so
it cannot split the window when doing so leaves no screen space for
buffer text.  The only way to allow it to split such windows is by
resizing the margins.  Otherwise, what does "not make the assumption"
mean in practice?  We cannot rely on the application to resize the
margins, because not every application does that (most don't).

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

Not if the user does something that makes no sense.  We have such
"user errors" in Emacs all over the place.  E.g., when the user tries
to delete the only window of a frame.  This case is no different, IMO.

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

I already agreed that we should probably improve the error message, so
let's not reiterate this particular aspect, as we are in agreement.
IOW, the error message we issue now should no longer be an argument
that what Emacs does in this case is wrong, let alone nonsensical.

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

When we do so, we display hints about the truncation, and allow
horizontal scrolling to display the truncated text.  No such features
are available for the stuff displayed on the margins, it just
disappears without a trace.  The example I provided, with linum-mode,
is a relevant case in point: the line numbers will appear incorrect
and/or corrupted.

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

It is worse because the effect is a corrupted display with no hint to
the user.

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

The error message, when we fix it, will explain 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.

The function in question doesn't change the margins, so it cannot do
its job when no screen estate is left for the text area.  IOW, there's
no assumptions here, only facts.

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

No, it isn't, because we do that in other cases.

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

I'm not sure we want to change window-min-size.  That function is used
for purposes that have nothing to do with splitting the window.  E.g.,
we also use its value when deciding whether a window can be resized,
when fitting window to buffer, etc.

The lowest level function for splitting windows is split-window, so
the change should IMO be either in split-window-right or in
split-window.  Martin, WDYT?

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

See above.

Also, this proposal is incomplete, because it doesn't tell what should
window-splitting functions do when the margins are too wide for one or
both of the two windows after the split.  You explicitly say that you
don't suggest that margins be resized when such windows are split, so
it is not clear what should be done in those cases.

Thanks.