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

["Óscar Fuentes" <ofv@wanadoo.es>]

martin rudalics <rudalics@gmx.at> writes:

>>>      (shrink-window, enlarge-window): Fix bug#22723 where windows
>>>      with preserved size would not get resized.  Also now signal an
>>>      error when the window cannot be shrunk or enlarged as requested.
>>
>> [snip]
>>
>>> +      (error "Cannot shrink selected window")))))
>>
>> I was surprised to see my code failing because of this change. Throwing
>> an error on a case where previously nothing was done amounts to an API
>> change. My code was fixed by wrapping the call to enlarge-window with
>> ignore-errors, but I'm worried about all the code out there.
>
> Sorry, but this fix was motivated by the following explanation in the
> Emacs manual:
>
>       The command `C-x ^' (`enlarge-window') makes the selected window one
>    line taller, taking space from a vertically adjacent window without
>    changing the height of the frame.  With a positive numeric argument,
>    this command increases the window height by that many lines; with a
>    negative argument, it reduces the height by that many lines.  If there
>    are no vertically adjacent windows (i.e., the window is at the full
>    frame height), that signals an error.  The command also signals an
>    error if you attempt to reduce the height of any window below a certain
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    minimum number of lines, specified by the variable `window-min-height'
>    (the default is 4).
>
>       Similarly, `C-x }' (`enlarge-window-horizontally') makes the
>    selected window wider, and `C-x {' (`shrink-window-horizontally') makes
>    it narrower.  These commands signal an error if you attempt to reduce
>                                                        ^^^^^^^^^^^^^^^^^
>    the width of any window below a certain minimum number of columns,
>    ^^^^^^^^^^^^^^^^^^^^^^^
>    specified by the variable `window-min-width' (the default is 10).

Please note that the above talks about reducing window dimensions below
a threshold. Also, it is about interactive use.

> We can easily change that to not signal an error but then behaviors like
> the one reported by Eli will get passed by unnoticed.  Emacsen < 23
> silently could delete windows when you made them too small with these
> commands.  This was deprecated but IIRC no one ever expressed a
> preference as to how these functions _should_ behave when there is not
> enough space.  Suggestions welcome.
>
> Personally, I'd never use ‘enlarge-window’ and ‘shrink-window’ in Lisp
> code.  IMO these are for interactive use only (supported by the fact
> that neither of these functions is documented in the Elisp manual).

`enlarge-window' appears on several places on the Elisp sources,
including calls like

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

which now will result on a error.

To be clear, I have nothing against throwing an error on the interactive
case, but against throwing the error on the non-interactive one. That's
what constitutes an API change on my book.

So I would suggest to remove the `error' and consider where and when to
add it after the release, after studying the code in the wild.