[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28945: 25.2; desktop auto save timer does not work
From: |
Eli Zaretskii |
Subject: |
bug#28945: 25.2; desktop auto save timer does not work |
Date: |
Sat, 11 Nov 2017 11:58:38 +0200 |
> 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.