bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge inc


From: Noam Postavsky
Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s
Date: Wed, 08 Nov 2017 08:42:06 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)

martin rudalics <rudalics@gmx.at> writes:

>> Not sure what Alexander is using, but under i3 the problem is simply
>> that the frame doesn't become visible until the user switches to the
>> virtual workspace where Emacs is.  So it's not that we have a visible
>> frame which the window manager fails to inform us about in time, rather
>> the frame just doesn't become visible in time.
>
> But as long as a user doesn't switch to that workspace she won't observe
> that making a new frame is slower. So I seem to be missing something.

She can observe it indirectly via lisp code.

> Anyway, we probably should add to /etc/PROBLEMS lines like
>
> "If a new Emacs frame is supposed to appear on a different virtual
> workspace, Emacs may not be notified about the visibility of the frame
> until the user switches to that workspace.

Hmm, not sure.  This sounds to me like "Emacs may not be notified about
the visibility of the frame until the frame is visible".  Which doesn't
seem like something which belongs in /etc/PROBLEMS.

>> It occurs to me that another possibility is simply to disable the
>> timeout when doing the auto-raise.  We have the timeout due some users'
>> configurations accidentally relying on the fact that a frame will be
>> visible after make-frame returns, but it seems unlikely that anyone
>> would manage to rely on the frame being visible after a call to
>> `message' occurs.
>
> But missing a message from an auto-raising frame does not sound like a
> good idea either.  That is, if the timeout is supposed to catch a
> problem with the Emacs/window manager interaction and to prevent Emacs
> from proceeding until some user decision based on something to be
> shown in a visible frame has been made.

I was operating under the assumption that the timeout is for the benefit
of the user's lisp code, not their interactions with the UI.  Not sure
the timeout would be that helpful for missing messages; under normal
circumstances it's not even hit, and 100ms goes by pretty quickly for a
human...

> I wish we would have had the courage to go through with your first
> solution - omit such waits completely.  I'm still surprised that we had
> so few complaints back then ...

I would still like to phase it out.  Maybe we could set the default to
nil for Emacs 27?





reply via email to

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