From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help* Date: Tue, 03 Jun 2014 10:47:52 +0300 Message-ID: <837g4ya0yf.fsf@gnu.org> References: <83k38z9mlr.fsf@gnu.org> <538D7794.7050303@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1401781765 4854 80.91.229.3 (3 Jun 2014 07:49:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Jun 2014 07:49:25 +0000 (UTC) Cc: 17671@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 03 09:49:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WrjTB-0002wi-VG for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jun 2014 09:49:18 +0200 Original-Received: from localhost ([::1]:50814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrjTB-00031c-Es for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jun 2014 03:49:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrjT2-00030Q-HY for bug-gnu-emacs@gnu.org; Tue, 03 Jun 2014 03:49:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrjSw-000712-Ef for bug-gnu-emacs@gnu.org; Tue, 03 Jun 2014 03:49:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrjSw-00070v-BI for bug-gnu-emacs@gnu.org; Tue, 03 Jun 2014 03:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WrjSv-000879-UF for bug-gnu-emacs@gnu.org; Tue, 03 Jun 2014 03:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Jun 2014 07:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17671-submit@debbugs.gnu.org id=B17671.140178169031107 (code B ref 17671); Tue, 03 Jun 2014 07:49:01 +0000 Original-Received: (at 17671) by debbugs.gnu.org; 3 Jun 2014 07:48:10 +0000 Original-Received: from localhost ([127.0.0.1]:41572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WrjS5-00085b-Rb for submit@debbugs.gnu.org; Tue, 03 Jun 2014 03:48:10 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:44591) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WrjS2-00084z-JN for 17671@debbugs.gnu.org; Tue, 03 Jun 2014 03:48:08 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N6L00I001LTML00@a-mtaout22.012.net.il> for 17671@debbugs.gnu.org; Tue, 03 Jun 2014 10:47:59 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6L00IMJ1NZ0Q90@a-mtaout22.012.net.il>; Tue, 03 Jun 2014 10:47:59 +0300 (IDT) In-reply-to: <538D7794.7050303@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:89930 Archived-At: > Date: Tue, 03 Jun 2014 09:21:56 +0200 > From: martin rudalics > > > C-h f line-move-visual RET > > C-x o > > move to the link under "simple.el" and type RET > > drag the mode line so that the lower window showing *Help* becomes > > smaller > > `temp-buffer-resize-mode' would do that automatically. Then perhaps we should turn on that mode by default. > > move cursor to the first call to vertical-motion > > C-h f RET > > C-x o > > move to the link under "C source code" and type RET > > the window showing *Help* is resized back to half the frame > > It's due to this code in `display-buffer-use-some-window': > > ;; If the window was used by `display-buffer' before, try to > ;; resize it to its old height but don't signal an error. > (when (and (listp quad) > (integerp (nth 3 quad)) > (/= (nth 3 quad) (window-total-height window))) > (condition-case nil > (window-resize window (- (nth 3 quad) (window-total-height window))) > (error nil))) > > > This is annoying. I like my *Help* windows to be small, but many > > times (but not always) they are resized when I need to request > > documentation of something else. > > In the case at hand the *Help* window gets resized _implicitly_ because > the _other_ window is resized so the behavior is not tied to using help. So this means that as long as the links in *Help* point to the same file which is already displayed in the window above *Help*, the size will stick, but as soon as another file is displayed in the window above *Help*, we get a resize, is that right? That's a really annoying inconsistency, IMO. > > Why cannot Emacs keep the size of that window? > > I can't remember. Maybe to assure that the window used for displaying > `vertical-motion' is reasonably large (after all you could have dragged > the mode line to make the window showing *Help* larger). Maybe simply > to assure that when the same or a similar buffer is displayed in that > window again, one can continue to work with its previous size (I vaguely > remember that you requested something similar once wrt the position of > `point' in such case). Maybe it was also completlely unmotivated. > > We can either remove that part or make it customizable. Since I never > use `display-buffer-use-some-window' I can't judge how offending the > behavior is. Is it possible to do something special for the specific scenario I described, i.e. when a *Help* link causes a buffer to be displayed? Or maybe the window showing *Help* should be small by default; taking half of its frame is really gross, IMO. It is especially annoying in "emacs -Q", which starts with a small frame.