[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emms-patches] Re: [PATCH] lisp/emms-cache.el: Initialize cache immediat
From: |
David Engster |
Subject: |
[Emms-patches] Re: [PATCH] lisp/emms-cache.el: Initialize cache immediately instead of using after-init-hook. |
Date: |
Fri, 12 Mar 2010 22:02:02 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.92 (gnu/linux) |
Lucas Bonnet <address@hidden> writes:
> David Engster <address@hidden> writes:
>
>> * emms-cache.el (emms-cache): Call emms-cache-restore directly instead
>> of using after-init-hook.
>> ---
>> Further comments on this patch: I think using the after-init-hook to
>> restore the cache is problematic. If you happen to call up EMMS later,
>> be it manually or through some means like idle-require, the cache won't
>> be restored from the cache file. Therefore, I'd like to suggest to
>> restore the cache immediately when EMMS is initialized. I currently
>> don't see any advantage to do this in the after-init-hook, but if I'm
>> missing something here, please let me know.
>
> Hmm, you mean that some process would alter the cache file outside of
> Emacs, after the initialization, meaning that EMMS will keep using the
> dirty cache? Or did I get it completely wrong?
No, I meant the first initialization of the cache from the saved cache
file, directly after starting up Emacs. The reason I stumbled upon this
is that I usually fire up EMMS later through an interactive function
like this:
(defun my-emms-init ()
(interactive)
(require 'emms-setup)
(emms-devel)
(emms-default-players)
(require 'emms-player-mpd)
;; and so on ...
)
I do this for several reasons, the most important one being that I
sometimes don't have my music directory mounted when I start Emacs, so I
want to start up EMMS later without the need to restart Emacs or to
completely rebuild the cache.
However, since the cache is only initialized in the 'after-init-hook',
you currently cannot init the cache in an interactive function that is
called after the after-init-hook has run. And as I mention above, I also
don't see any advantage to do this in the after-init-hook in the first
place - it really just leads to unexpected behavior, IMHO.
Regards,
David