unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ofv@wanadoo.es, emacs-devel@gnu.org
Subject: Re: emacs-25 3722a69: Fix bugs in window resizing code
Date: Wed, 02 Mar 2016 09:22:50 +0100	[thread overview]
Message-ID: <56D6A2DA.4080208@gmx.at> (raw)
In-Reply-To: <83egbu6rp7.fsf@gnu.org>

 > 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




  reply	other threads:[~2016-03-02  8:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160218102715.15576.42604@vcs.savannah.gnu.org>
     [not found] ` <E1aWLnn-000448-7K@vcs.savannah.gnu.org>
2016-03-01  1:31   ` emacs-25 3722a69: Fix bugs in window resizing code Óscar Fuentes
2016-03-01  8:07     ` martin rudalics
2016-03-01 15:10       ` Óscar Fuentes
2016-03-01 17:04         ` martin rudalics
2016-03-01 17:20           ` Eli Zaretskii
2016-03-02  8:22             ` martin rudalics [this message]
2016-03-02  9:28               ` martin rudalics
2016-03-02 15:54               ` Eli Zaretskii
2016-03-04  7:48                 ` martin rudalics
2016-03-04  8:28                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D6A2DA.4080208@gmx.at \
    --to=rudalics@gmx.at \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).