GNU bug report logs - #20770
24.5; feature request: support relative path in package.el

Previous Next

To reply to this bug, email your comments to 20770 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Oleh Krehel <ohwoeowho <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; feature request: support relative path in package.el
Date: Mon, 08 Jun 2015 14:25:36 +0200

Suppose I my config directory looks like this:

    elpa/
    etc/
    Makefile
    init.el
    packages.el

The ELPA packages go into elpa/, and packages.el looks like:

    (dolist (package '("slime"))
      (unless (package-installed-p package)
        (package-install package)))

And I install/upgrade my packages with a Makefile:

    emacs -batch -l packages.el 2>&1 | tee etc/log

But now, if I open etc/log, all byte compilation warnings generated by
package.el are relative to elpa/slime-20150601.1411/, so I can't jump to
them if I enable `compilation-mode'.

Obviously, this isn't high priority, but it would be cool if we could
have:

    (defvar package-target-path "."
      "The byte-compilation warnings will target this path.")

So I could set it temporarily to "~/.emacs.d/log/", and then instead of
this:

    In slime-parse-extended-operator-name:
    contrib/slime-enclosing-context.el:45:36:Warning: reference to free
    variable `slime-extended-operator-name-parser-alist'

I could get this:

    In slime-parse-extended-operator-name:
    ../elpa/slime-20150601.1411/contrib/slime-enclosing-context.el:45:36:Warning:
    reference to free variable `slime-extended-operator-name-parser-alist'

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.