From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Huchler Newsgroups: gmane.emacs.help Subject: Re: Strange eval behaviour Date: Fri, 18 Nov 2016 17:51:17 +0100 Message-ID: <87shqo68ai.fsf@mail.de> References: <87vavrul0k.fsf@mail.de> <878tsl1p7b.fsf@mail.de> <878tshjyvy.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1479488851 26371 195.159.176.226 (18 Nov 2016 17:07:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Nov 2016 17:07:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Nov 18 18:07:26 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7mdI-0005Wd-ET for geh-help-gnu-emacs@m.gmane.org; Fri, 18 Nov 2016 18:07:24 +0100 Original-Received: from localhost ([::1]:38072 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7mdL-0000jj-QH for geh-help-gnu-emacs@m.gmane.org; Fri, 18 Nov 2016 12:07:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7mO2-0007R4-S1 for help-gnu-emacs@gnu.org; Fri, 18 Nov 2016 11:51:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7mNz-0000I3-Qb for help-gnu-emacs@gnu.org; Fri, 18 Nov 2016 11:51:38 -0500 Original-Received: from [195.159.176.226] (port=38874 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c7mNz-0000H8-Jg for help-gnu-emacs@gnu.org; Fri, 18 Nov 2016 11:51:35 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1c7mNl-0004HP-7F for help-gnu-emacs@gnu.org; Fri, 18 Nov 2016 17:51:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:tFDdQc857WxPB0GDDDNxRClgNuM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-Mailman-Approved-At: Fri, 18 Nov 2016 12:06:45 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:111742 Archived-At: Michael Heerdegen writes: > Stefan Huchler 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 :)