Ken Brown via Cygwin-apps writes: > I'm not sure the rebase of the emacs user directory has to be > ephemeral.
That would just be a POC to show that it works in a general sense. > First of all, I think we should make /var/lib/rebase/user.d/<username> > work as documented. No, that won't help and I should actually remove that facility since it can't be fixed. The user directory can not assumed to be even accessible when setup runs. So anything involving a user directory must be run under that user account, after setup has completed. Anything that can be done via setup should be done with packages (and those can already use the dynpath.d facility). > Users could list their emacs user directory there, and people who > build emacs themselves could also list their emacs build directory. > That way things could be kept reasonably stable in the long run via > the autorebase postinstall script. Implicit in this is that the > results of all these rebases would be stored in the user's rebase > database. The question of where to store the result is not really important at the moment. We can just re-generate the intended result each time; if and only if that works should we then optimize via caching. > After each compilation, but before the new .eln file is loaded, emacs > could call rebaselst with suitable arguments to rebase that new file > (and add it to the user database). Yes, something like that or something else with similar effect. But first we need to figure out if we can get it working at all. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
