From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-25 3722a69: Fix bugs in window resizing code Date: Wed, 02 Mar 2016 17:54:09 +0200 Message-ID: <8337s87u5a.fsf@gnu.org> References: <20160218102715.15576.42604@vcs.savannah.gnu.org> <87si0bj85l.fsf@wanadoo.es> <56D54DB4.1080502@gmx.at> <878u22jksw.fsf@wanadoo.es> <56D5CB91.4060108@gmx.at> <83egbu6rp7.fsf@gnu.org> <56D6A2DA.4080208@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1456934069 30760 80.91.229.3 (2 Mar 2016 15:54:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2016 15:54:29 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 02 16:54:28 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 1ab96a-0000Tx-5s for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2016 16:54:28 +0100 Original-Received: from localhost ([::1]:57233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ab96Z-0005R8-LR for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2016 10:54:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ab96V-0005Ql-2j for emacs-devel@gnu.org; Wed, 02 Mar 2016 10:54:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ab96O-0004Mo-Tz for emacs-devel@gnu.org; Wed, 02 Mar 2016 10:54:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ab96O-0004Mk-QN; Wed, 02 Mar 2016 10:54:16 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3412 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ab96O-0000xE-23; Wed, 02 Mar 2016 10:54:16 -0500 In-reply-to: <56D6A2DA.4080208@gmx.at> (message from martin rudalics on Wed, 02 Mar 2016 09:22:50 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:200864 Archived-At: > Date: Wed, 02 Mar 2016 09:22:50 +0100 > From: martin rudalics > CC: ofv@wanadoo.es, emacs-devel@gnu.org > > (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. Thanks for this clear summary. If (3) can be done easily and reliably, I think it's the best alternative. That it might need documentation changes shouldn't frighten us.