--- Begin Message ---
Subject: |
25.0.50; window-size-change-functions not called after mini-window resize |
Date: |
Sun, 23 Aug 2015 22:06:45 +0000 |
This is possibly only a documentation issue.
Recipe: eval
(progn (push (lambda (&rest args) (message "window size changed"))
window-size-change-functions)
(message (make-string 3000 ?*)))
Expected result: a "window size changed" message.
Actual result: no such message.
The symptom is that the window size change function is not run after a
mini-window size change.
So far, I can produce this behavior only when the minibuffer or echo
area grows to several lines; when it shrinks afterwards, my window size
change function is called. I cannot reproduce the behavior with other
windows.
Is this a bug? The documentation says:
[...] to be called if the size of any window changes for any reason.
Please correct me if I'm wrong, but when the minibuffer/echo area gets
resized (and the windows on top of it, too), that counts as a change of
size, I would say.
If this is merely a documentation issue, the exception should be noted
in the manual.
Analysis:
First, some warnings:
- `window_resize_apply' and `Fwindow_resize_apply' (aka
`window-resize-apply') are two different functions
- `resize-mini-window' and `resize-mini-window-internal' are called
only when the mini-window is explicitly resized by a Lisp call of
`resize-mini-window'. Implicit resizes as a consequence of having
too much text in the echo area do not appear to call it.
The problem is that FRAME_WINDOW_SIZES_CHANGED (f) is not set to true
after a mini-window resize. Fwindow_resize_apply would set this flag,
but window_resize_apply does not.
If this behavior is deliberate, I believe it is inconsistent to set
FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'.
Suggested solution:
Trivial. Add FRAME_WINDOW_SIZES_CHANGED (f) = true to all callers of
window_resize_apply.
In GNU Emacs 25.0.50.51 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
of 2015-08-23 on ...
Repository revision: bfb06826feac9151877069590d5dc91b60337b6b
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description: Debian GNU/Linux unstable (sid)
Configured using:
`configure 'CFLAGS=-O0 -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-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
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message dired 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 help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils misearch multi-isearch time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded 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
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 81668 9633)
(symbols 48 19040 0)
(miscs 40 42 136)
(strings 32 13288 4444)
(string-bytes 1 380166)
(vectors 16 11279)
(vector-slots 8 414205 3702)
(floats 8 131 186)
(intervals 56 190 0)
(buffers 976 11)
(heap 1024 18666 1015))
0001-Call-window-size-change-functions-after-mini-window-.patch
Description: Text Data
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#19576: write-file writes the wrong buffer |
Date: |
Sat, 21 Nov 2015 18:02:39 +0200 |
> Date: Sat, 21 Nov 2015 15:56:58 +0000
> Cc: address@hidden, address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
>
> Hello, Eli.
>
> On Sat, Nov 21, 2015 at 01:35:02PM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 19 Nov 2015 18:03:39 +0200
> > > From: Eli Zaretskii <address@hidden>
> > > Cc: address@hidden, address@hidden, address@hidden
>
> > > > Date: Wed, 18 Nov 2015 23:23:04 +0000
> > > > Cc: martin rudalics <address@hidden>, address@hidden, address@hidden,
> > > > address@hidden
> > > > From: Alan Mackenzie <address@hidden>
>
> > > > > Could you try a simpler patch below? It seems to fix both your test
> > > > > case and the one originally reported in bug#21333.
>
> > > > It does indeed fix my test case (I haven't tried it on #21333). However
> > > > it violates the specification of window-size-change-functions, which
> > > > says that the hook is called _before_ redisplay, not after it has
> > > > started. I suppose one could argue over what "redisplay" means here,
> > > > but intuitively I would say it is the putting of glyphs into matrices.
>
> > > "Redisplay" is indeed not defined well enough, but the only reasonable
> > > interpretation of "before redisplay" is that it happens before the
> > > call to redisplay_internal. And this is false for your suggested
> > > solution as well. It is false even by your definition, because
> > > prepare_menu_bars already manipulates the glyph matrices, the ones it
> > > creates for the tool bar (and also menu bar on some display types).
> > > And display_echo_area also manipulates glyph matrices (it calls
> > > try_window).
>
> > > Which is only logical for an event that by itself is triggered as part
> > > of redisplay! It's redisplay that decides to resize the mini-window,
> > > so calling the hook after that decision _cannot_ possibly count as
> > > being "before redisplay".
>
> > > IOW, once we, by popular demand, decided to call
> > > window-size-change-functions when the mini-window is resized, we
> > > invalidated that specification. All the other callers of this hook
> > > are not part of a redisplay cycle, but this one is, and cannot be
> > > anywhere else.
>
> > > So no matter what change we eventually install, the documentation of
> > > the hook needs to be amended to say that it's called "before redisplay
> > > or at the beginning of a redisplay cycle", and maybe also mention that
> > > the second case is when the mini-window is resized.
>
> > No further comments, so I've committed the changes I posted here
> > earlier. I also modified the documentation to be consistent with what
> > the code does.
>
> Thanks.
>
> > Please tell me if this bug and bug#21333 could now be closed, or if
> > there are any leftovers.
>
> I don't think this fix concerns #19576. The discussion of #21869 seems,
> somehow, to have moved to here.
>
> But I think that #21333 can be closed, and #21869 certainly can be; both
> of these were about window-size-change-functions not getting called for
> echo area size changes.
Closing.
--- End Message ---