autoload seems inconsistent

autoload seems inconsistent

[Stefan Huchler]

I am the author of kodi-remote which is in melpa.

When I manually evaluate the whole kodi-remote.el file all works
fine. But when I install it over melpa and it autoloads something goes
south.

When I start kodi-remote-movies it works but if I open up
kodi-remote-series or kodi-remote or kodi-remote-music I get such
errors:

"kodi-remote-music-mode symbol value as variable is void"

Here is the file:

https://github.com/spiderbit/kodi-remote.el/blob/master/kodi-remote.el

did I fuck up something with the autoload directive, can't figure out
what the problem is.

Re: autoload seems inconsistent

[Noam Postavsky]

On Thu, 14 Mar 2019 at 13:27, Stefan Huchler <stefan.huchler@mail.de> wrote:

> When I manually evaluate the whole kodi-remote.el file all works
> fine. But when I install it over melpa and it autoloads something goes
> south.
>
> When I start kodi-remote-movies it works but if I open up
> kodi-remote-series or kodi-remote or kodi-remote-music I get such
> errors:
>
> "kodi-remote-music-mode symbol value as variable is void"

Do you get any compilation warnings? I guess the problem might be that
you use the kodi-remote-context macro before it's defined.

Re: autoload seems inconsistent

[phillip.lord]

On 2019-03-14 17:25, Stefan Huchler wrote:
> 
> When I start kodi-remote-movies it works but if I open up
> kodi-remote-series or kodi-remote or kodi-remote-music I get such
> errors:
> 
> "kodi-remote-music-mode symbol value as variable is void"
> 
> Here is the file:
> 
> https://github.com/spiderbit/kodi-remote.el/blob/master/kodi-remote.el
> 
> did I fuck up something with the autoload directive, can't figure out
> what the problem is.

Do you not need autoload cookies on the `define-derived-mode' forms 
also? As it
stands, they won't be in the generated autoload file, which would give 
you them "no symbol" error.

Re: autoload seems inconsistent

[Stefan Huchler]

Noam Postavsky <npostavs@gmail.com> writes:

> On Thu, 14 Mar 2019 at 13:27, Stefan Huchler <stefan.huchler@mail.de> wrote:
>
>> When I manually evaluate the whole kodi-remote.el file all works
>> fine. But when I install it over melpa and it autoloads something goes
>> south.
>>
>> When I start kodi-remote-movies it works but if I open up
>> kodi-remote-series or kodi-remote or kodi-remote-music I get such
>> errors:
>>
>> "kodi-remote-music-mode symbol value as variable is void"
>
> Do you get any compilation warnings? I guess the problem might be that
> you use the kodi-remote-context macro before it's defined.

I think I moved that upwards in the file but did not help. But I double
check it.

Re: autoload seems inconsistent

[Stefan Huchler]

phillip.lord@russet.org.uk writes:

> Do you not need autoload cookies on the `define-derived-mode' forms
> also? As it
> stands, they won't be in the generated autoload file, which would give
> you them "no symbol" error.

No I don't need it, but that should not be the problem, when I
bytecompile the file I get some warnings a few about functions called
from cl package at runtime.

And a few variable undefined but in kodi-remote-build-disk-strings and
youtube-operation that should have nothing to do with that.

What seems a bit odd is taht I have such cl warnings in the
draw functions for the main / series and playlist buffers. But that said
the playlist function works despite that.

Is there a problem with cl package required at runtime? I assume it's
not recommend to use them at runtime, but can it produce such problems?

Weird, I have to say I am not to deep into lisp macros and all the
different ways when it get's executed, I mean theoretically I might got
it, but what implications that has I am not so sure.

So macros get's replaced on compile time right? The point is that if I
load the whole file it works, so what is different in the autoload way
of loading the file / package?

Looks like a small problem but I have no idea how to solve it. I guess I
could look at older versions and try to bisect the patch that introduced
the bug, because at some point as far as I know kodi-remote-series
worked with the melpa version :D.

Just a bit hard to do it automatically. Especially if melpa does some
magic with autoloads things, that I don't have in my git folder.

Re: autoload seems inconsistent

[Noam Postavsky]

On Thu, 14 Mar 2019 at 17:13, Stefan Huchler <stefan.huchler@mail.de> wrote:

> Just a bit hard to do it automatically. Especially if melpa does some
> magic with autoloads things, that I don't have in my git folder.

You can try M-x package-install-file, it should do the same autoload generation.

Re: autoload seems inconsistent

[Stefan Monnier]

>> When I manually evaluate the whole kodi-remote.el file all works
>> fine. But when I install it over melpa and it autoloads something goes
>> south.
>>
>> When I start kodi-remote-movies it works but if I open up
>> kodi-remote-series or kodi-remote or kodi-remote-music I get such
>> errors:
>>
>> "kodi-remote-music-mode symbol value as variable is void"
>
> Do you get any compilation warnings? I guess the problem might be that
> you use the kodi-remote-context macro before it's defined.

Definitely looks like the culprit indeed.

While I'm here: you seem to have many more autoloads than needed,
because AFAICT it makes no sense to call kodi-remote-playlists-draw
before any other kodi-remote function.

Autoload cookies should only be placed on those function that can be
called by the user before the file is loaded.  Once one of those
function has been called, the autoload will have caused the file to be
loaded, so the other functions will be available already without any
need for an autoload cookie.

[ For similar reasons I don't think it's useful to make
  kodi-remote-playlists-draw into an interactive function: it only needs
  to be called via `revert-buffer-function`.  ]
  
Other problems in your file: you use CL functions and macros without
doing a (require 'cl), so it risks being miscompiled and/or failing at
run-time if CL wasn't loaded for other reasons (which is more and more
common as packages are slowly moving to the newer cl-lib instead).


        Stefan