Silent autoloading

Silent autoloading

[Eli Zaretskii]

I noticed that with current CVS, the "Loading FOO..." messages are not
shown in the echo area, when packages are autoloaded.  For example,
visiting a file with a colon in its name loads Tramp (as expected),
but does not display the "Loading tramp..." message.

Is this a bug or a feature?  If the latter, why was it introduced, and
why isn't it mentioned in NEWS?

Re: Silent autoloading

[Glenn Morris]

Eli Zaretskii wrote:

> I noticed that with current CVS, the "Loading FOO..." messages are not
> shown in the echo area, when packages are autoloaded. [...]

> Is this a bug or a feature?  If the latter, why was it introduced, and
> why isn't it mentioned in NEWS?

2007-09-24  Stefan Monnier  <monnier@iro.umontreal.ca>

            * eval.c (do_autoload): Don't output any message.

Prompted by this?

http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01504.html

Re: Silent autoloading

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 08 Nov 2008 16:34:04 -0500
> 
> Eli Zaretskii wrote:
> 
> > I noticed that with current CVS, the "Loading FOO..." messages are not
> > shown in the echo area, when packages are autoloaded. [...]
> 
> > Is this a bug or a feature?  If the latter, why was it introduced, and
> > why isn't it mentioned in NEWS?
> 
> 2007-09-24  Stefan Monnier  <monnier@iro.umontreal.ca>
> 
>             * eval.c (do_autoload): Don't output any message.

Thanks.

> Prompted by this?
> 
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01504.html

Stefan, any insights?  Having Emacs sit silently in the minibuffer for
prolonged periods of time, without saying anything, makes me think it's
stuck, so at the very least let's have an option to get the old
behavior back.

Re: Silent autoloading

[Stefan Monnier]

> Stefan, any insights?  Having Emacs sit silently in the minibuffer for
> prolonged periods of time, without saying anything, makes me think it's
> stuck, so at the very least let's have an option to get the old
> behavior back.

I agree with the basic premise, but I'm wondering what's the
relationship: what kind of machine are you using where loading a .elc
file is not virtually instantaneous?
What's the actual use case where you've seen this problem of having
Emacs sit silently for a prolonged period of time?


        Stefan

Re: Silent autoloading

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 08 Nov 2008 21:22:33 -0500
> 
> > Stefan, any insights?  Having Emacs sit silently in the minibuffer for
> > prolonged periods of time, without saying anything, makes me think it's
> > stuck, so at the very least let's have an option to get the old
> > behavior back.
> 
> I agree with the basic premise, but I'm wondering what's the
> relationship: what kind of machine are you using where loading a .elc
> file is not virtually instantaneous?
> What's the actual use case where you've seen this problem of having
> Emacs sit silently for a prolonged period of time?

emacs -Q
C-x C-f /foo:b

On "windows32 home-c4e4a596f7 2.5.1 2600 i786-pc Intel unknown MinGW",
a 3-GHz single-CPU machine, it takes Emacs 7 seconds to echo the `b'
after the colon.  This is with a cold cache; with warm cache, it's
still 2 seconds, which is annoyingly visible.

On "Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006
x86_64 GNU/Linux", a 2-GHz Dual-Core AMD Opteron(tm) Processor 2214
machine, the numbers are 4 seconds and 3 seconds, accordingly.

Maybe Tramp is a large package, but then "C-x C-f" is a very
frequently used command.

Re: Silent autoloading

[Stefan Monnier]

>> > Stefan, any insights?  Having Emacs sit silently in the minibuffer for
>> > prolonged periods of time, without saying anything, makes me think it's
>> > stuck, so at the very least let's have an option to get the old
>> > behavior back.
>> 
>> I agree with the basic premise, but I'm wondering what's the
>> relationship: what kind of machine are you using where loading a .elc
>> file is not virtually instantaneous?
>> What's the actual use case where you've seen this problem of having
>> Emacs sit silently for a prolonged period of time?

> emacs -Q
> C-x C-f /foo:b

> On "windows32 home-c4e4a596f7 2.5.1 2600 i786-pc Intel unknown MinGW",
> a 3-GHz single-CPU machine, it takes Emacs 7 seconds to echo the `b'
> after the colon.  This is with a cold cache; with warm cache, it's
> still 2 seconds, which is annoyingly visible.

> On "Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006
> x86_64 GNU/Linux", a 2-GHz Dual-Core AMD Opteron(tm) Processor 2214
> machine, the numbers are 4 seconds and 3 seconds, accordingly.

> Maybe Tramp is a large package, but then "C-x C-f" is a very
> frequently used command.

Ah, yes, I see that for Tramp indeed.
How 'bout making Tramp output something before loading itself?


        Stefan

Re: Silent autoloading

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 09 Nov 2008 10:06:03 -0500
> 
> > Maybe Tramp is a large package, but then "C-x C-f" is a very
> > frequently used command.
> 
> Ah, yes, I see that for Tramp indeed.
> How 'bout making Tramp output something before loading itself?

I don't mind, but are we going to hunt down every slow-loading package
and add a message to them as well?

Why not the other way around: re-enable the "Loading..." messages by
default and introduce a variable to suppress it?  Then Lisp code that
needed this to be turned off (something with timers, IIUC) could
simply bind that variable to an appropriate value when doing its
thing.

Re: Silent autoloading

[Stefan Monnier]

>> > Maybe Tramp is a large package, but then "C-x C-f" is a very
>> > frequently used command.
>> Ah, yes, I see that for Tramp indeed.
>> How 'bout making Tramp output something before loading itself?
> I don't mind, but are we going to hunt down every slow-loading package
> and add a message to them as well?

> Why not the other way around: re-enable the "Loading..." messages by
> default and introduce a variable to suppress it?  Then Lisp code that
> needed this to be turned off (something with timers, IIUC) could
> simply bind that variable to an appropriate value when doing
> its thing.

No Lisp code needs it to be turned off.  It's just off because there's
no clear reason to have it turned on in most cases, and in some cases
those messages are annoying.

You're complaining about Emacs freezing for a little while without
giving any clue to the user about what's going on.  That's indeed
a problem.  But this rarely happens for autoloading, and in many cases
it happens independently from autoloading.

Maybe the right solution is to link this to the hourglass-mouse-cursor:
have a global variable busy-message, and when the
hourglass timer expires, not only we should change the mouse-cursor to
an hourglass, but we should also output the message currently stored in
`busy-message'.
This way, loading a file could set this var to "Loading <foo>..." and if
the loading takes a while (and only in this case), you'd get the
relevant message.  This would happen to work for autoloading as well as
for `require' and any other way to load a file.  And it could be used
in other situations (e.g. "Building completion table...").


        Stefan

Re: Silent autoloading

[Lennart Borgman]

On Mon, Nov 10, 2008 at 2:51 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> You're complaining about Emacs freezing for a little while without
> giving any clue to the user about what's going on.  That's indeed
> a problem.  But this rarely happens for autoloading, and in many cases
> it happens independently from autoloading.
>
> Maybe the right solution is to link this to the hourglass-mouse-cursor:
> have a global variable busy-message, and when the
> hourglass timer expires, not only we should change the mouse-cursor to
> an hourglass, but we should also output the message currently stored in
> `busy-message'.
> This way, loading a file could set this var to "Loading <foo>..." and if
> the loading takes a while (and only in this case), you'd get the
> relevant message.  This would happen to work for autoloading as well as
> for `require' and any other way to load a file.  And it could be used
> in other situations (e.g. "Building completion table...").

That would be good.

Re: Silent autoloading

[Eli Zaretskii]

> Date: Mon, 10 Nov 2008 09:37:18 +0100
> From: "Lennart Borgman" <lennart.borgman@gmail.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, rgm@gnu.org, michael.albinus@gmx.de, 
> 	emacs-devel@gnu.org
> 
> On Mon, Nov 10, 2008 at 2:51 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
> > Maybe the right solution is to link this to the hourglass-mouse-cursor:
> > have a global variable busy-message, and when the
> > hourglass timer expires, not only we should change the mouse-cursor to
> > an hourglass, but we should also output the message currently stored in
> > `busy-message'.
> > This way, loading a file could set this var to "Loading <foo>..." and if
> > the loading takes a while (and only in this case), you'd get the
> > relevant message.  This would happen to work for autoloading as well as
> > for `require' and any other way to load a file.  And it could be used
> > in other situations (e.g. "Building completion table...").
> 
> That would be good.

Except that, I think, it won't work on Windows, where atimer is not
supported.

And what about Emacs on a tty, where there's no
hourglass-mouse-cursor?

Re: Silent autoloading

[Lennart Borgman]

On Mon, Nov 10, 2008 at 9:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Except that, I think, it won't work on Windows, where atimer is not
> supported.

Can it be implemented?

Re: Silent autoloading

[Eli Zaretskii]

> Date: Mon, 10 Nov 2008 21:19:47 +0100
> From: "Lennart Borgman" <lennart.borgman@gmail.com>
> Cc: rgm@gnu.org, michael.albinus@gmx.de, monnier@iro.umontreal.ca,
> 	emacs-devel@gnu.org
> 
> On Mon, Nov 10, 2008 at 9:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Except that, I think, it won't work on Windows, where atimer is not
> > supported.
> 
> Can it be implemented?

Windows doesn't have SIGALRM signal, so implementation is not easy.
But I should look at the code, maybe it's already done.

Re: Silent autoloading

[Stefan Monnier]

>> > Maybe the right solution is to link this to the hourglass-mouse-cursor:
>> > have a global variable busy-message, and when the
>> > hourglass timer expires, not only we should change the mouse-cursor to
>> > an hourglass, but we should also output the message currently stored in
>> > `busy-message'.
>> > This way, loading a file could set this var to "Loading <foo>..." and if
>> > the loading takes a while (and only in this case), you'd get the
>> > relevant message.  This would happen to work for autoloading as well as
>> > for `require' and any other way to load a file.  And it could be used
>> > in other situations (e.g. "Building completion table...").
>> That would be good.
> Except that, I think, it won't work on Windows, where atimer is not
> supported.

It has timers as well (e.g. those used for hourglass).  I'd think that
we would want to really integrate this directly within the hourglass
code, i.e. consider it as another form of "hourglass icon".  I.e hook
into show_hourglass/hide_hourglass.

> And what about Emacs on a tty, where there's no
> hourglass-mouse-cursor?

Indeed, currently Emacs on ttys doesn't use the hourglass timer because
it has no way to display the hourglass mouse cursor, so this proposition
would imply enabling it for ttys as well, where show_hourglass wouldn't
actually show an hourglass-mouse-cursor, but would still show the
busy-message.


        Stefan

Re: Silent autoloading

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You're complaining about Emacs freezing for a little while without
> giving any clue to the user about what's going on.  That's indeed
> a problem.  But this rarely happens for autoloading, and in many cases
> it happens independently from autoloading.
>
> Maybe the right solution is to link this to the hourglass-mouse-cursor:
> have a global variable busy-message, and when the
> hourglass timer expires, not only we should change the mouse-cursor to
> an hourglass, but we should also output the message currently stored in
> `busy-message'.
> This way, loading a file could set this var to "Loading <foo>..." and if
> the loading takes a while (and only in this case), you'd get the
> relevant message.  This would happen to work for autoloading as well as
> for `require' and any other way to load a file.  And it could be used
> in other situations (e.g. "Building completion table...").

I was offline the last three weeks, so I'm still synchronizing. Has
something been done this way, or shall I add a message when loading Tramp?

>         Stefan

Best regards, Michael.

Re: Silent autoloading

[Stefan Monnier]

>> You're complaining about Emacs freezing for a little while without
>> giving any clue to the user about what's going on.  That's indeed
>> a problem.  But this rarely happens for autoloading, and in many cases
>> it happens independently from autoloading.
>> 
>> Maybe the right solution is to link this to the hourglass-mouse-cursor:
>> have a global variable busy-message, and when the
>> hourglass timer expires, not only we should change the mouse-cursor to
>> an hourglass, but we should also output the message currently stored in
>> `busy-message'.
>> This way, loading a file could set this var to "Loading <foo>..." and if
>> the loading takes a while (and only in this case), you'd get the
>> relevant message.  This would happen to work for autoloading as well as
>> for `require' and any other way to load a file.  And it could be used
>> in other situations (e.g. "Building completion table...").

> I was offline the last three weeks, so I'm still synchronizing. Has
> something been done this way, or shall I add a message when loading Tramp?

Nothing has been done in this way yet.  Could you add a message for now?


        Stefan

Re: Silent autoloading

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I agree with the basic premise, but I'm wondering what's the
> relationship: what kind of machine are you using where loading a .elc
> file is not virtually instantaneous?

Loading a .elc can take arbitrary time since it can contain arbitrary
code.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Silent autoloading

[Stefan Monnier]

>> I agree with the basic premise, but I'm wondering what's the
>> relationship: what kind of machine are you using where loading a .elc
>> file is not virtually instantaneous?

> Loading a .elc can take arbitrary time since it can contain arbitrary
> code.

Yes, that's the difference between theory and practice.


        Stefan

Re: Silent autoloading

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I agree with the basic premise, but I'm wondering what's the
>>> relationship: what kind of machine are you using where loading a .elc
>>> file is not virtually instantaneous?
>
>> Loading a .elc can take arbitrary time since it can contain arbitrary
>> code.
>
> Yes, that's the difference between theory and practice.

Tramp needs to initialize variables. For example, setting
`tramp-default-method' might call `executable-find' or
'w32-window-exists-p', which consumes time.

I don't know, whether it is worth to perform it via `eval-when-compile',
because the result might be different every single start of Emacs.

>         Stefan

Best regards, Michael.

Re: Silent autoloading

[Stefan Monnier]

> Tramp needs to initialize variables. For example, setting
> `tramp-default-method' might call `executable-find' or
> 'w32-window-exists-p', which consumes time.

> I don't know, whether it is worth to perform it via `eval-when-compile',
> because the result might be different every single start of Emacs.

Doing it at compile time would be wrong, indeed.  Tramp's load time is
not a bug.  Of course, if you can improve it that's good.


        Stefan