Re: Strange eval behaviour

[Stefan Huchler]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stefan Huchler <stefan.huchler@mail.de> writes:
>
> In case of a macro, it depends on whether the macro is defined when
> compiling.  So you don't get a warning necessarily.  To avoid missing
> dependencies, it's helpful to compile from a separate emacs instance
> (emacs -Q).

yes thats usefull thanks for that tipp again! But to really test it I
think I have to set the server address absolute else I need a
configuration to really test the thing.

Also I am a bit relactend to open to much emacs instances cause I work
in exwm which is basicly emacs as window manager, so I start emacs out
of emacs :) Which itself could theoreticly cause problems. :)


> AFAIR, you had a strange handling of variables in your code: some
> functions had used free variables that were declared nowhere.  Compiling
> is a good way to reveal such problems.

Yes I am a bit a elisp noob but it gets better, so I used to only use
setq and not let(*) at all, so its a bad habbit also in many other
languages you dont have or use so much let constructs.

But te point is, as long as I dont come in conflict with some system
variables it should still work, its no good praktise but it should not
cause bugs. Or do you see how that in that case can create this
behaviour.

I will clean that up if all other bugs are fixed, I even will break that
into 2 commits cause my kodi-remote-keyboard is more solid then the
other mode I have where I can get file lists of series/... .

Its a pretty big patch much bigger than the last version on github was :)




> No.

Well then I did not find the real causation of the problem apperently
cause that was the thing that seemed to make here the difference no .elc
restart does not work, with .elc restart and it works.


> Yes.  It is now more or less consent now that the cl library should not
> be loaded at run-time.  Please use cl-lib and the according cl- prefixed
> functions instead.

so like that:
(require 'cl-lib)
(require 'cl-macs)

?


> No, Stefan suggested to compile so that you get warnings that help you
> find the problems in your code.  Compiling is not required to run code.
> Compiled code is just running faster, and the compiler produces
> excellent warnings.

yes that was my idea about bytecompiling in general not elisp specific,
but if macros dont throw errors cause stuff only get evaluated if its
bytecompiled thats really hard to debug, or it seems at least to me :)