From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: emacs-25 3722a69: Fix bugs in window resizing code Date: Tue, 01 Mar 2016 16:10:39 +0100 Message-ID: <878u22jksw.fsf@wanadoo.es> References: <20160218102715.15576.42604@vcs.savannah.gnu.org> <87si0bj85l.fsf@wanadoo.es> <56D54DB4.1080502@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1456845064 26209 80.91.229.3 (1 Mar 2016 15:11:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Mar 2016 15:11:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 01 16:10:52 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aalwq-0008G5-4i for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2016 16:10:52 +0100 Original-Received: from localhost ([::1]:50214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aalwp-0005Y7-EQ for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2016 10:10:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aalwk-0005Vk-1n for emacs-devel@gnu.org; Tue, 01 Mar 2016 10:10:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aalwg-0008GA-Rf for emacs-devel@gnu.org; Tue, 01 Mar 2016 10:10:45 -0500 Original-Received: from relaycp04.dominioabsoluto.net ([217.116.26.100]:33593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aalwg-0008Fo-Bp for emacs-devel@gnu.org; Tue, 01 Mar 2016 10:10:42 -0500 Original-Received: from smtp.movistar.es (smtp08.acens.net [86.109.99.132]) by relaycp04.dominioabsoluto.net (Postfix) with ESMTP id A12A36447C; Tue, 1 Mar 2016 16:10:40 +0100 (CET) X-CTCH-RefID: str=0001.0A0B0205.56D5B0F0.0225, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Original-Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BAF155018F11E1; Tue, 1 Mar 2016 15:10:40 +0000 In-Reply-To: <56D54DB4.1080502@gmx.at> (martin rudalics's message of "Tue, 01 Mar 2016 09:07:16 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 217.116.26.100 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:200845 Archived-At: martin rudalics 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 =E2=80=98enlarge-window=E2=80=99 and =E2=80=98s= hrink-window=E2=80=99 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.