Generated autoloads file is broken

[dimitri]

Generated autoloads file is broken

[dimitri]

Dave, any chance you beat me to fix this? I'll have a look in the evening...

[purcell]

BTW, my el-get config is here: https://github.com/purcell/emacs.d/blob/master/init-el-get.el

[dimitri]

Ok my first thinking reading your el-get-sources was to get them all in:

(let ((n (remove nil
         (mapcar (lambda (s)
               (unless
                   (file-exists-p (format "~/dev/emacs/el-get/recipes/%s.el" (el-get-source-name s))) s))
             (loop for r in purcell-el-get-sources when (not (symbolp r)) collect r)))))
  (loop for s in n
    do (with-temp-file (format "~/temp/purcell-el-get-recipes/%s.el" (el-get-source-name s))
         (insert (prin1-to-string s)))))

Now, Dave, are you reading and having some time to look at the autoload issue? :)

[dabrahams]

• I'm reading
• Don't have much time but since there's claimed to be a bug in my code I will try
• I don't understand the nature of the problem. If there's an "offending autoload" then isn't this a problem in the diff-git package?
• If someone could explain what they understand so far about the problem it might help

[purcell]

I think it's explained quite well above -- note that the problem is not specific to the diff-git recipe.

Essentially, with this set of el-get recipes, start-up is fine unless the autoloads have already been generated, at which point errors like the above happen.

Now, I've (since) hacked el-get locally to disable the autoload functionality completely, but I'm happy to help track down what's wrong; it'd just be good to get some pointers.

[dimitri]

Could we get a defvar el-get-manage-autoload (or a better name) in the main el-get, so that users can disable the feature? I'm not sure if we want to add a property to be able to do that per package like with :compile and el-get-byte-compile, though.

[dabrahams]

@purcell: Can you produce a minimal (preferably runnable via emacs -Q) example that demonstrates this problem? If so, I can probably fix it quickly.

@dimitri: I'd rather not address a bug by giving users the option to turn off the feature.

[purcell]

Okay, so with the latest el-get I no longer get the issue when I turn off my disable-autoloads hack. I do, however, get a problem with session.el (http://www.emacswiki.org/emacs/session.el) -- it results in a loaddefs file containing (defunx session-initialize ...), where defunx is a non-autoloaded macro defined in session.el... yuck! But that's not an el-get issue, since el-get's just calling the usual update-directory-autoloads function.

So I'll go ahead and close this issue.

Regarding the option to disable autoloads, I agree this would have been the wrong way to tackle this issue, but I'd like such an option anyway. At the very least, being able to define :autoload nil or similar in a recipe would allow the handling of libraries like session.el which work perfectly well when required, but fail when autoloaded.

[dimitri]

I'd like to be able to disable autoloads too, for giving the choice to users. That's independant of whether there's bugs in the autoloads code or not.