[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34138: 27.0.50; Delayed display of PDF file images

From: martin rudalics
Subject: bug#34138: 27.0.50; Delayed display of PDF file images
Date: Thu, 24 Jan 2019 10:08:53 +0100

>> Strictly spoken, all of these abuse the concept of hooks.  Making a
>> new window, putting an overlay there, setting some properties are
>> deterministic actions.  Why do we have to do them from the hook?
> I don't know the answer, perhaps Andreas could explain his perspective
> on this.

Many people (including me) do not understand the essence of most hooks
so they just replicate usage patterns from some other source.  While
the original idea of the hook often gets lost this way, packages work
in some way or the other satisfactorily.

> Maybe this means what is now run_window_configuration_change_hook
> should be divided into 2 parts: one that only reacts to changes in
> dimensions, the other that reacts to new windows and changes in
> window-buffer?  The former will want to run at the end of redisplay,
> the latter at the beginning, I think.

This would double the potential ways of interleaved running of
functions on the hook.  I'd rather not do that.

>> (1) Make the window.
>> (2) Run 'image-mode-reapply-winprops'.
>> (3) Run 'pdf-view-new-window-function'.
>> (4) Continue with overlays and properties set up.
>> (5) Redisplay, eventually.
>> If anything in (4) needs anything done in (2) and (3), running the
>> hooks earlier in redisplay won't help.
> I'm not sure I understand why, perhaps because I don't have a clear
> idea what you mean by "continuing with overlays".  Please tell more.

When I say that steps (1)--(3) are deterministic I meant that making
the window is guaranteed to have run (2) and (3) before any action in
(4) gets executed.  In (4) the application may run arbitrary code with
the guarantee that the overlay from (3) and the "winprops" from (2)
have been installed.  Running 'window-configuration-change-hook' from
redisplay means this guarantee no longer holds.

>> Note: We can always restore the emacs 26 (better emacs 25) way
>> 'window-configuration-change-hook' is run.  That won't affect the
>> remaining hooks and prevent scenarios as the one found here.
> What are the disadvantages of doing that?

That we again run the hook even if nothing has changed and do not
catch many possible changes.  Hence well-behaved users of that hook
would get punished.

I'm not sure whether I would care personally.  We never reached a
common agreement on what a window configuration change is and when it
happens.  So while the hook represents bad design (IMHO) and nobody
should ever have used it, there never existed a viable alternative to
accomplish what it provided in the past.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]