unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
@ 2014-06-02 18:45 Eli Zaretskii
  2014-06-03  7:21 ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2014-06-02 18:45 UTC (permalink / raw)
  To: 17671

In "emacs -Q":

  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
  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

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.

Why cannot Emacs keep the size of that window?



In GNU Emacs 24.3.91.32 (i686-pc-mingw32)
 of 2014-06-02 on HOME-C4E4A596F7
Repository revision: 117194 rgm@gnu.org-20140602011408-hg26p0rgaafsr1n4
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0
 -gdwarf-2 -g3''

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: C/l

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
C-h f l i n e - m o v e - v i s u <tab> <return> C-x 
o <down> <left> <left> <left> <left> <return> <help-echo> 
<help-echo> <down-mouse-1> <help-echo> <drag-mouse-1> 
<help-echo> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <C-right> C-h f <return> C-x o <down> <left> 
<left> <left> <left> <left> <left> <left> <return> 
M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Type C-x 1 to delete the help window.


Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cc-langs cl gv cl-loaddefs cl-lib cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs vc-bzr find-func help-mode easymenu help-fns time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 112220 8108)
 (symbols 32 20442 0)
 (miscs 32 45 181)
 (strings 16 19751 3811)
 (string-bytes 1 616149)
 (vectors 8 12617)
 (vector-slots 4 407577 5294)
 (floats 8 62 499)
 (intervals 28 587 124)
 (buffers 508 16))





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
  2014-06-02 18:45 bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help* Eli Zaretskii
@ 2014-06-03  7:21 ` martin rudalics
  2014-06-03  7:47   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2014-06-03  7:21 UTC (permalink / raw)
  To: Eli Zaretskii, 17671

 >    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.

 >    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.

 > 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.

martin





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
  2014-06-03  7:21 ` martin rudalics
@ 2014-06-03  7:47   ` Eli Zaretskii
  2014-06-03  9:41     ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2014-06-03  7:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: 17671

> Date: Tue, 03 Jun 2014 09:21:56 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  >    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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
  2014-06-03  7:47   ` Eli Zaretskii
@ 2014-06-03  9:41     ` martin rudalics
  2014-06-03 10:54       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2014-06-03  9:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17671

 >> `temp-buffer-resize-mode' would do that automatically.
 >
 > Then perhaps we should turn on that mode by default.

ISTR that some people dislike `temp-buffer-resize-mode'.

 > 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,

... because in that case the window already shows that buffer ...

 > but as soon as another file is displayed in the window
 > above *Help*, we get a resize, is that right?

Only if that window was used by `display-buffer' before.  That window
could have been made very small, for example, when used for displaying
*Help* and in such case people would probably protest that we use a
ridiculously small LRU-window for displaying a buffer.  There was at
least one bug report bemoaning that IIRC.

 > That's a really
 > annoying inconsistency, IMO.

 > 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?

Usually, doing so causes a problem in another area soon.  Maybe we
should not _decrease_ the size of a window when displaying another
buffer in it - this would take care of your use case.

 > 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.

This is really what `temp-buffer-resize-mode' is for.

martin





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
  2014-06-03  9:41     ` martin rudalics
@ 2014-06-03 10:54       ` Eli Zaretskii
  2014-06-03 12:40         ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2014-06-03 10:54 UTC (permalink / raw)
  To: martin rudalics; +Cc: 17671

> Date: Tue, 03 Jun 2014 11:41:53 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 17671@debbugs.gnu.org
> 
> Maybe we should not _decrease_ the size of a window when displaying
> another buffer in it - this would take care of your use case.

Sounds good to me.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
  2014-06-03 10:54       ` Eli Zaretskii
@ 2014-06-03 12:40         ` martin rudalics
  2014-06-03 16:32           ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2014-06-03 12:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17671

 >> Maybe we should not _decrease_ the size of a window when displaying
 >> another buffer in it - this would take care of your use case.
 >
 > Sounds good to me.

OK.  I made the change on the release branch.  Please test it.

Thanks, martin





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help*
  2014-06-03 12:40         ` martin rudalics
@ 2014-06-03 16:32           ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-06-03 16:32 UTC (permalink / raw)
  To: martin rudalics; +Cc: 17671-done

> Date: Tue, 03 Jun 2014 14:40:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 17671@debbugs.gnu.org
> 
>  >> Maybe we should not _decrease_ the size of a window when displaying
>  >> another buffer in it - this would take care of your use case.
>  >
>  > Sounds good to me.
> 
> OK.  I made the change on the release branch.  Please test it.

Thanks, it works just fine.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-06-03 16:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-02 18:45 bug#17671: 24.3.91; RET on a link in *Help* buffer resizes *Help* Eli Zaretskii
2014-06-03  7:21 ` martin rudalics
2014-06-03  7:47   ` Eli Zaretskii
2014-06-03  9:41     ` martin rudalics
2014-06-03 10:54       ` Eli Zaretskii
2014-06-03 12:40         ` martin rudalics
2014-06-03 16:32           ` Eli Zaretskii

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).