Re: emacs-25 3722a69: Fix bugs in window resizing code

[martin rudalics <rudalics@gmx.at>]

 > MO is that we should fix all uses of enlarge-window and shrink-window
 > in our sources, and otherwise leave the change in 25.1.  Maybe also
 > document that in NEWS as potentially incompatible behavior.  I don't
 > think we should postpone the bugfix to 26.1, because I don't really
 > believe anything will happen until then that will change the
 > situation: the same problems this could cause now it will cause then.

The history of this is contrived: After changing the behavior of
‘enlarge-window’ to not delete other windows but signal an error
instead, jidanni filed bug#8862 "compilation-window-height no good
anymore".  In the discussion of that bug Stefan said that

    AFAIK, `enlarge-window' did not signal an error when the size was too
    large, so I think it's best to keep being silent, for backward
    compatibility's sake.

which is what I implemented in the sequel (without changing the
documentation in the Emacs manual, though).  Thereafter, Chong decided
to

2011-11-08  Chong Yidong  <cyd@gnu.org>

	* windows.texi
	(Resizing Windows): Simplify introduction.  Don't document
	enlarge-window, shrink-window, enlarge-window-horizontally, and
	shrink-window-horizontally; they are no longer preferred for
	calling from Lisp, and are already documented in the Emacs manual.

but IIRC no instance of ‘enlarge-window’ in the emacs sources was ever
removed.  In fact, it's not easy to do that for "anyone" because, for
example, the semantics of

textmodes/two-column.el:305:6:    (enlarge-window 99999 t))

mentioned by Óscar should be pretty unclear to anyone but the original
author.


In reaction to bug#22723 where Eli said that

    Moreover, doing nothing silently,
    without any error message, sounds sub-optimal UI to me.

I reinstalled the error reporting behavior as of before bug#8862 which
consequently lead to Óscar's reaction in the present thread.


I shortly recapitulate the possible solutions and their disadvantages:

(1) Don't make this function throw an error when a window cannot be made
as large as requested but try to make the window as large as possible.
This was the state before my last change.  Its major disadvantage is
that enlarging the window may fail silently which makes this differ from
most other window commands.  And, obviously no code can rely on this
function to behave predictably either.

(2) Have this function throw an error when a window cannot be made as
large as requested.  This is the present state.  Its major disadvantage
is that packages could rely on this function to never throw an error
except for a short period in 2011.  Even if we manage to fix all
occurrences in the emacs-25 code base, there might be still packages in
the wild that count on the "silent" behavior.

(3) Have this function throw an error in interactive use as in (1) and
behave as (2) in non-interactive use.  The disadvantage of this approach
is that, strictly spoken, we would have to document this function again
in the Elisp manual, describe its different behaviors and support it
until further notice.

We have to decide what to do for emacs-25.

martin