bug#28945: 25.2; desktop auto save timer does not work

[Eli Zaretskii <eliz@gnu.org>]

> From: Peter Neidhardt <pe.neidhardt@googlemail.com>
> Cc: 28945@debbugs.gnu.org
> Date: Sun, 05 Nov 2017 17:18:07 +0100
> 
> > I tried this recipe, but couldn't reproduce the problem.  I wonder
> > what was missing from my reproduction experiment.  My .emacs for this
> > experiment had only one line:
> >
> >   (desktop-save-mode 1)
> >
> > Is this different from what you tried?  In my case, the timer is still
> > there after restarting Emacs.
> 
> You are right, there is more to trigger the issue:
> 
>   (desktop-save-mode 1)
> 	(global-linum-mode)

You may wish to try the new native display of line numbers in Emacs
26, which doesn't have this problem (and is significantly faster).

> What happens is that during intialization,
> window-configuration-change-hook is mode buffer-local by
> global-linum-mode.  After init, desktop.el loads the desktop session, at
> which point the window-configuration-change-hook is still buffer-local
> and `desktop-read' fails.

Thanks, now everything is clear.

I installed your suggested fix into the release branch, and I'm
marking this bug done.

> >> Lastly, a minor nit: desktop.el adds a lambda to `after-init-hook'; can
> >> we turn this into a named function?
> >
> > Why is that important?  This hook runs long before the user starts
> > interacting with Emacs, so there doesn't seem to be any good reason
> > for the user to look into what this function does.  Or am I missing
> > something?
> 
> It is for debugging problems such as this one.  While investigating
> after-init-hook, I saw that value:
> 										#[0 "\303\211\235\203\304\"\301\305!\210\210	\205\306 \210\307\211\207"
> 												[command-line-args desktop-save-mode inhibit-startup-screen "--no-desktop" delete 0 desktop-read t]
> 												4])
> 
> Thankfully the word "desktop" is mentioned, otherwise it would have been
> hard to get the hunch that something was executed afterwards regarding
> the desktop.
> 
> Function names make for good documentation, they make the
> self-documentation more meaningful.

Yes, but that's an argument against _any_ use of lambda functions in
Emacs (because we don't really have opaque APIs).  So I'm not sure we
need to convert this to a named function.