From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: using use-package Date: Thu, 13 Aug 2015 16:31:03 -0400 Organization: A noiseless patient Spider Message-ID: References: <67cb463e-41f6-4f37-91ee-15d0fdb5ba9f@googlegroups.com> <20150812180621.32265.2E673ABE@ahiker.mooo.com> <20150813072506.GA21389@tuxteam.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439498126 6927 80.91.229.3 (13 Aug 2015 20:35:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2015 20:35:26 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 13 22:35:26 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZPzDh-0006b4-4n for geh-help-gnu-emacs@m.gmane.org; Thu, 13 Aug 2015 22:35:25 +0200 Original-Received: from localhost ([::1]:44058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPzDg-0001E7-G2 for geh-help-gnu-emacs@m.gmane.org; Thu, 13 Aug 2015 16:35:24 -0400 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!feeder.erje.net!1.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 45 Injection-Info: mx02.eternal-september.org; posting-host="6551a55313eeb1483cdfad32ce9cec6d"; logging-data="16468"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1IyLkNPPNlrfqdRdbDW80" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:2Kk1FUTo8qDjQrXDt0H2frhPe+Q= sha1:Kl3Fx1HSGF3ws4zHLhZ+RuLeon0= Original-Xref: usenet.stanford.edu gnu.emacs.help:214268 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106552 Archived-At: >> Please do keep us informed of those problems: it's indeed very important >> to make package.el more robust. > My hunch now is that the package brought with it an .elc file (probably > magit.elc) compiled with the wrong Emacs version. Sounds unlikely both because of the way the ELPA package gets built and because many other people would have bumped into this problem. > Removing all .elc and recompiling the directory seems to succeed (I've > ditched magit now for anoter reason -- it doesn't like my git 1.7.x > and wants 1.9.x, I'd have to resort to an older magit, sigh). > I'll try to verify (or falsify) my hunch. My crystal ball tells me that you upgraded Magit from an Emacs where the previous Magit was already loaded, and the old (loaded) version interfered while byte-compiling the new version. [ The typical interference, looks like this: Emacs tries to compile foo-1.el which does (require 'foo-2) to get some macros, but (the old) `foo-2' is already loaded so we end up using the old version of the macros (or the macros may simply not be defined at all). ] This is a problem in package.el that hit Helm pretty badly, apparently. We have a tentative patch for that in Emacs-25. This said, if you've erased the old problematic .elc files it'll be difficult to verify/falsify my hunch. Tho maybe if you can re-install the previous version of Magit, then run Emacs, then use Magit, then in that same Emacs session upgrade Magit, you might be able to reproduce the problem. >> We should probably also add a package-(re)compile command (after all, >> the compilation step is conceptually independent from the actual >> installation). > Perhaps there should be a way for Emacs to find out that an .elc file > doesn't match the current binary interface (I've been stumped by > "wrong" .elc files (i.e such compiled by an Emacs with different > byte code conventions) more than once). Normally byte-code is upward compatible, so the problem is only if you compile with Emacs-NN and then use that file with Emacs-MM where MM