emms-patches
[Top][All Lists]
Advanced

[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





reply via email to

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