--- Begin Message ---
|
Subject: |
23.0.60; window-size-change-functions sometimes not called |
|
Date: |
Sat, 30 Aug 2008 13:13:57 -0400 |
Let size1.el consist of the following forms:
(defun my-size-change-function (frame)
(with-temp-file "sizelog"
(insert (format "size changed at %s - %s\n" (current-time) frame))))
(add-hook 'window-size-change-functions 'my-size-change-function)
(scroll-bar-mode -1)
(setq mylist nil)
(dotimes (i 100)
(setq mylist (cons "this is a longer test string" mylist)))
When I do:
*) $ emacs -Q size1.el -f eval-buffer
*) M-: mylist
*) $ cat sizelog
then I see in this created log file that window-size-change-functions
were called as expected:
size changed at (18617 32068 355364) - #<frame address@hidden>
When I then switch back to the Emacs X11 window and press any key, the
enlarged echo area shrinks away again, and the window showing size1.el
grows. However, I see from the unchanged log file that the functions in
window-size-change-functions were not called. This happens only when
scroll-bar-mode is disabled (which the above code does).
In GNU Emacs 23.0.60.7 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
of 2008-08-30 on v254-034.vps.tuwien.ac.at
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
--- 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 ---