GNU bug report logs -
#17671
24.3.91; RET on a link in *Help* buffer resizes *Help*
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Mon, 2 Jun 2014 18:47:02 UTC
Severity: normal
Found in version 24.3.91
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17671 in the body.
You can then email your comments to 17671 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17671
; Package
emacs
.
(Mon, 02 Jun 2014 18:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 02 Jun 2014 18:47:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17671
; Package
emacs
.
(Tue, 03 Jun 2014 07:23:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 17671 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17671
; Package
emacs
.
(Tue, 03 Jun 2014 07:49:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 17671 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 03 Jun 2014 09:21:56 +0200
> From: martin rudalics <rudalics <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17671
; Package
emacs
.
(Tue, 03 Jun 2014 09:43:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 17671 <at> debbugs.gnu.org (full text, mbox):
>> `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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17671
; Package
emacs
.
(Tue, 03 Jun 2014 10:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 17671 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 03 Jun 2014 11:41:53 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 17671 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17671
; Package
emacs
.
(Tue, 03 Jun 2014 12:41:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 17671 <at> debbugs.gnu.org (full text, mbox):
>> 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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 03 Jun 2014 16:33:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
bug acknowledged by developer.
(Tue, 03 Jun 2014 16:33:03 GMT)
Full text and
rfc822 format available.
Message #25 received at 17671-done <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 03 Jun 2014 14:40:39 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 17671 <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 02 Jul 2014 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 75 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.