GNU bug report logs -
#43243
emacs-elfeed-org, mapc: Symbol’s function definition is void
Previous Next
Reported by: Giovanni Biscuolo <g <at> xelera.eu>
Date: Sun, 6 Sep 2020 14:45:02 UTC
Severity: normal
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43243 in the body.
You can then email your comments to 43243 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Sun, 06 Sep 2020 14:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Giovanni Biscuolo <g <at> xelera.eu>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 06 Sep 2020 14:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I use emacs-elfeed-org to organize my feeds for emacs--elfeed.
After my last upgrade to Emacs 27.1 I get this error in the Messages
buffer when I try to "M-x elfeed":
mapc: Symbol’s function definition is void: org--check-org-structure-template-alist
This is the backtrace:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-function org--check-org-structure-template-alist)
org--check-org-structure-template-alist(org-structure-template-alist)
mapc(org--check-org-structure-template-alist (org-structure-template-alist org-tempo-keywords-alist))
org-tempo-add-templates()
org-tempo--update-maybe()
org-tempo-setup()
run-hooks(change-major-mode-after-body-hook text-mode-hook outline-mode-hook org-mode-hook)
apply(run-hooks (change-major-mode-after-body-hook text-mode-hook outline-mode-hook org-mode-hook))
run-mode-hooks(org-mode-hook)
org-mode()
#f(compiled-function (file) #<bytecode 0x10396bd>)("~/.emacs.d/elfeed.org")
#f(compiled-function (it) #<bytecode 0x2ba910d>)("~/.emacs.d/elfeed.org")
mapcar(#f(compiled-function (it) #<bytecode 0x2ba910d>) ("~/.emacs.d/elfeed.org"))
-mapcat(#f(compiled-function (file) #<bytecode 0x10396bd>) ("~/.emacs.d/elfeed.org"))
rmh-elfeed-org-import-headlines-from-files(("~/.emacs.d/elfeed.org") "elfeed")
rmh-elfeed-org-process(("~/.emacs.d/elfeed.org") "elfeed")
ad-Advice-elfeed(#f(compiled-function () (interactive nil) #<bytecode 0x1012e69>))
apply(ad-Advice-elfeed #f(compiled-function () (interactive nil) #<bytecode 0x1012e69>) nil)
elfeed()
funcall-interactively(elfeed)
call-interactively(elfeed record nil)
command-execute(elfeed record)
execute-extended-command(nil "elfeed" nil)
funcall-interactively(execute-extended-command nil "elfeed" nil)
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
--8<---------------cut here---------------end--------------->8---
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Sun, 06 Sep 2020 15:46:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Giovanni Biscuolo <g <at> xelera.eu> writes:
> I use emacs-elfeed-org to organize my feeds for emacs--elfeed.
>
> After my last upgrade to Emacs 27.1 I get this error in the Messages
> buffer when I try to "M-x elfeed":
[...]
I've filed an issue upstream:
https://github.com/remyhonig/elfeed-org/issues/56
I confirm that rolling back to Emacs 26.3 I have no issues.
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Mon, 28 Sep 2020 03:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 43243 <at> debbugs.gnu.org (full text, mbox):
Hello Giovanni,
Giovanni Biscuolo <g <at> xelera.eu> writes:
> Giovanni Biscuolo <g <at> xelera.eu> writes:
>
>> I use emacs-elfeed-org to organize my feeds for emacs--elfeed.
>>
>> After my last upgrade to Emacs 27.1 I get this error in the Messages
>> buffer when I try to "M-x elfeed":
>
> [...]
>
> I've filed an issue upstream:
> https://github.com/remyhonig/elfeed-org/issues/56
I tried to reproduce this using the following environment:
--8<---------------cut here---------------start------------->8---
guix environment --pure --ad-hoc emacs emacs-elfeed
--8<---------------cut here---------------end--------------->8---
Then launching emacs with 'emacs -q', and running elfeed with M-x
elfeed, and couldn't reproduce the problem.
Are you using a different flavor of Emacs, or just the 'emacs' Guix
package? emacs-next's search path is currently broken, for example.
Thanks,
Maxim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Mon, 28 Sep 2020 08:20:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Maxim,
thank you for your help
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
[...]
> I tried to reproduce this using the following environment:
>
> --8<---------------cut here---------------start------------->8---
> guix environment --pure --ad-hoc emacs emacs-elfeed
> --8<---------------cut here---------------end--------------->8---
>
> Then launching emacs with 'emacs -q', and running elfeed with M-x
> elfeed, and couldn't reproduce the problem.
The problem is with emacs-elfeed-org, not emacs-elfeed :-)
> Are you using a different flavor of Emacs, or just the 'emacs' Guix
> package?
I'm using 'emacs' from Guix.
Thanks, Gio'
[...]
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Tue, 29 Sep 2020 13:47:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 43243 <at> debbugs.gnu.org (full text, mbox):
Hello!
Giovanni Biscuolo <g <at> xelera.eu> writes:
> Hello Maxim,
>
> thank you for your help
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
> [...]
>
>> I tried to reproduce this using the following environment:
>>
>> --8<---------------cut here---------------start------------->8---
>> guix environment --pure --ad-hoc emacs emacs-elfeed
>> --8<---------------cut here---------------end--------------->8---
>>
>> Then launching emacs with 'emacs -q', and running elfeed with M-x
>> elfeed, and couldn't reproduce the problem.
>
> The problem is with emacs-elfeed-org, not emacs-elfeed :-)
Ah! I need glasses :-)
Retrying with emacs-elfeed-org, I also can't reproduce:
--8<---------------cut here---------------start------------->8---
$ guix environment --pure --ad-hoc emacs emacs-elfeed-org -- emacs --batch --eval='(elfeed)'
Loading /gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/dash-autoloads...
Loading /gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/elfeed-autoloads...
Loading /gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/elfeed-org-autoloads...
Loading /gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/org-autoloads...
Loading /gnu/store/6yx7654rwm0bxmi99dyp5ddgll72k2kw-profile/share/emacs/site-lisp/s-autoloads...
--8<---------------cut here---------------end--------------->8---
Can you try to reproduce it again? Perhaps there's some other Emacs
package in your profile which somehow conflicts with it?
Thanks,
Maxim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Tue, 29 Sep 2020 18:14:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Maxim,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
[...]
>> The problem is with emacs-elfeed-org, not emacs-elfeed :-)
>
> Ah! I need glasses :-)
:D
> Retrying with emacs-elfeed-org, I also can't reproduce:
>
> --8<---------------cut here---------------start------------->8---
> $ guix environment --pure --ad-hoc emacs emacs-elfeed-org -- emacs --batch --eval='(elfeed)
[...]
> Can you try to reproduce it again?
OK I did this:
--8<---------------cut here---------------start------------->8---
$ guix environment --pure --ad-hoc emacs emacs-elfeed-org curl
$ emacs
--8<---------------cut here---------------end--------------->8---
In this environment then I "manually" set up elfeed-org in my *scratch*
buffer copying relevant parts from init.el: it worked, I was able to
start elfeed and update my feeds from my elfeed.org file
> Perhaps there's some other Emacs package in your profile which somehow
> conflicts with it?
After the test above I updated my emacs profile and started emacs
daemon, now I'm on emacs 27.1 and, again, if I try to start elfeed I
get:
--8<---------------cut here---------------start------------->8---
File mode specification error: (void-function org--check-org-structure-template-alist) [2 times]
Followed link to /home/giovanni/.dotfolder/emacs/.emacs.d/elfeed.org
mapc: Symbol’s function definition is void: org--check-org-structure-template-alist
--8<---------------cut here---------------end--------------->8---
Tomorrow I'll try to catch what's the conflicting package, now I'm using
this manifest:
[emacs-guix.scm (application/octet-stream, inline)]
[Message part 3 (text/plain, inline)]
Thank you for your help!
Happy hacking! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Tue, 29 Sep 2020 19:46:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 43243 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Tue, 29 Sep 2020 at 20:12, Giovanni Biscuolo <g <at> xelera.eu> wrote:
> File mode specification error: (void-function org--check-org-structure-template-alist) [2 times]
> Followed link to /home/giovanni/.dotfolder/emacs/.emacs.d/elfeed.org
> mapc: Symbol’s function definition is void:
> org--check-org-structure-template-alist
Hum? What is your ’~/.emacs.d/init.el’&co.? The issue seems the
loading order. It could happen with lazy eval &co. Well, this ’alist’
is from ’org.el’, so it appears to me a bit weird.
> Tomorrow I'll try to catch what's the conflicting package, now I'm using
> this manifest:
I have noticed that you use ’ghc-pandoc’. Except if you require
“pandoc” as an Haskell library for linking, what you want is probably
the package ’pandoc’ (introduced by e380ef14cf).
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Fri, 02 Oct 2020 18:09:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi simon
thank you for your support.
I'm not very good in the triage of this bug: after a lot of trial and
error I was almost sure I found a conflicting package (emacs-hl-todo,
required by emacs-magit-todos) BUT I was NOT able to reproduce the bug
in a pure environment
--8<---------------cut here---------------start------------->8---
$ guix environment --pure --ad-hoc emacs emacs-elfeed-org emacs-magit-todos -- emacs --debug-init
--8<---------------cut here---------------end--------------->8---
In that environment's emacs session I get an init.el loading error, but
I'm able to eval-buffer this:
--8<---------------cut here---------------start------------->8---
(require 'elfeed-org)
(elfeed-org)
;; Optionally specify a number of files containing elfeed
;; configuration. If not set then the location below is used.
(setq rmh-elfeed-org-files (list "~/.emacs.d/elfeed.org"))
(global-set-key (kbd "C-x w") 'elfeed)
(setq-default elfeed-search-filter "+unread ")
(add-hook 'elfeed-new-entry-hook
(elfeed-make-tagger :before "9 weeks ago"
:remove 'unread))
--8<---------------cut here---------------end--------------->8---
But I have to do that 4 times since I get this error:
--8<---------------cut here---------------start------------->8---
org-link-set-parameters: Symbol’s function definition is void: org-element-update-syntax [3 times]
--8<---------------cut here---------------end--------------->8---
After that I'm able to open elfeed, with feeds managed by elfeed-org: it
works.
So the problem is something else, probably...
zimoun <zimon.toutoune <at> gmail.com> writes:
> Hi,
>
> On Tue, 29 Sep 2020 at 20:12, Giovanni Biscuolo <g <at> xelera.eu> wrote:
>
>> File mode specification error: (void-function org--check-org-structure-template-alist) [2 times]
>> Followed link to /home/giovanni/.dotfolder/emacs/.emacs.d/elfeed.org
>> mapc: Symbol’s function definition is void:
>> org--check-org-structure-template-alist
>
> Hum? What is your ’~/.emacs.d/init.el’&co.? The issue seems the
> loading order. It could happen with lazy eval &co. Well, this ’alist’
> is from ’org.el’, so it appears to me a bit weird.
Yes, AFAIU it's really a loading order triggered error... and I'm not
able to debug this :-(
My init.el is pretty long and convoluted and without many comments, I'm
attaching it at the end of this message.
Using the attached manifest (emacs-guix.scm), I still the same error:
--8<---------------cut here---------------start------------->8---
mapc: Symbol’s function definition is void: org--check-org-structure-template-alist
--8<---------------cut here---------------end--------------->8---
with the same backtrace reported in the first message of this bug report.
>> Tomorrow I'll try to catch what's the conflicting package, now I'm using
>> this manifest:
>
> I have noticed that you use ’ghc-pandoc’. Except if you require
> “pandoc” as an Haskell library for linking, what you want is probably
> the package ’pandoc’ (introduced by e380ef14cf).
I've now fixed this, thanks!
All the best, Gio'.
[init-redacted.el (application/emacs-lisp, inline)]
[emacs-guix.scm (application/octet-stream, inline)]
[Message part 4 (text/plain, inline)]
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Fri, 02 Oct 2020 19:29:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Giovanni Biscuolo <g <at> xelera.eu> writes:
[...]
>>> File mode specification error: (void-function org--check-org-structure-template-alist) [2 times]
>>> Followed link to /home/giovanni/.dotfolder/emacs/.emacs.d/elfeed.org
>>> mapc: Symbol’s function definition is void:
>>> org--check-org-structure-template-alist
>>
>> Hum? What is your ’~/.emacs.d/init.el’&co.? The issue seems the
>> loading order. It could happen with lazy eval &co. Well, this ’alist’
>> is from ’org.el’, so it appears to me a bit weird.
>
> Yes, AFAIU it's really a loading order triggered error... and I'm not
> able to debug this :-(
I've finally found the conflicting configuration!
[...]
> ;; -*- mode: emacs-lisp -*-
[...]
> (require 'org-tempo)
^ This one
I've commented out this config line in my init.el and now elfeed-org is
running fine
If I try to eval "(require 'org-tempo)" in the *scratch* buffer I get
this backtrace:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-function org--check-org-structure-template-alist)
org--check-org-structure-template-alist(org-structure-template-alist)
mapc(org--check-org-structure-template-alist (org-structure-template-alist org-tempo-keywords-alist))
org-tempo-add-templates()
org-tempo--update-maybe()
org-tempo-setup()
byte-code("\300\301\302\303\304\305%\210\306\307\310\"\210\306\311\312\"\210\313\314!\211\203*\0\211 <at> r\211q\210\310 \210)\1A\266\202\202\25\0\210\315\316!\207" [tempo-define-template "org-include" ((org-tempo--include-file) p >) "<I" "Include keyword" org-tempo-tags add-hook org-mode-hook org-tempo-setup org-tab-before-tab-emulation-hook org-tempo-complete-tag org-buffer-list files provide org-tempo] 6)
require(org-tempo)
(progn (require 'org-tempo))
eval((progn (require 'org-tempo)) t)
elisp--eval-last-sexp(t)
eval-last-sexp(t)
eval-print-last-sexp(nil)
funcall-interactively(eval-print-last-sexp nil)
call-interactively(eval-print-last-sexp nil nil)
command-execute(eval-print-last-sexp)
--8<---------------cut here---------------end--------------->8---
Am I doing something wrong in requiring org-tempo or not?
AFAIU (require 'org-tempo) should be supported:
https://www.gnu.org/software/emacs/manual/html_node/org/Structure-Templates.html
Tomorrow I'll report my findings upstream.
[...]
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Sat, 03 Oct 2020 08:13:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Sorry Simon for the noise, this is just a quick feedback about my
debugging; next messages will be only to debbugs, you know how to track
it :-D
Meanwhile I've learned how to test things in a dedicated environment,
thanks to some interesting tips [1] (I ignored before) adapted to Guix;
this confirms (ça va sanse dire) how powerful Guix is!
Giovanni Biscuolo <g <at> xelera.eu> writes:
[...]
>> Yes, AFAIU it's really a loading order triggered error... and I'm not
>> able to debug this :-(
>
> I've finally found the conflicting configuration!
No, I've actually found a workaround - commenting out "(require
'org-tempo)" in my init.el - that works with my emacs configuration (and
package set) BUT there is absolutely no conflict between org-tempo and
elfeed-org.
I confirm that if I eval "(require 'org-tempo)" I get the previously
reported error and backtrace, I confirm that if I do not remove
(comment) "(require 'org-tempo)" in my "production" init.el elfeed does
not work as reported in the first message of this bug report.
Last but not least, I confirm I had no issues with the same manifest
(I've replaced ghc-pandoc with pandoc but that's tangent) and the same
init.el using Guix Emacs 26.3
So I ceated a directory dedicated to my tests in
~/.emacs-testing.d/test-elfeed, where I put "manifest.scm" and a
"test-elfeed.el" (both attached below, inline).
Well: if I do this
--8<---------------cut here---------------start------------->8---
[~/.emacs-testing.d/test-elfeed]-
giovanni <at> roquette: guix environment --pure --ad-hoc -m manifest.scm -- emacs -q -l test-elfeed.el
--8<---------------cut here---------------end--------------->8---
I get an emacs session with a running elfeed, and "(require 'org-tempo)"
is there.
This is manifest.scm:
[manifest.scm (application/octet-stream, inline)]
[Message part 3 (text/plain, inline)]
This is test-elfeed.el:
[test-elfeed.el (application/emacs-lisp, inline)]
[Message part 5 (text/plain, inline)]
So AFAIU there is no direct conflict between elfeed-org and org-tempo,
that conflict is apparent only in my full init.el configuration (and
package set) and probably is related to a combination of environment and
init.el configuration.
I'm going to investigate more and see what I can do to sort out things.
Happy hacking! Gio'
[1] https://gonewest818.github.io/2020/03/a-standalone-init.el-for-emacs-package-debugging/
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Sat, 03 Oct 2020 12:42:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 43243 <at> debbugs.gnu.org (full text, mbox):
Dear,
On Fri, 02 Oct 2020 at 20:08, Giovanni Biscuolo <g <at> xelera.eu> wrote:
> I'm not very good in the triage of this bug: after a lot of trial and
> error I was almost sure I found a conflicting package (emacs-hl-todo,
> required by emacs-magit-todos) BUT I was NOT able to reproduce the bug
> in a pure environment
[...]
> In that environment's emacs session I get an init.el loading error, but
> I'm able to eval-buffer this:
That's because your init.el and guix.scm do not match. For example, you
are using ’use-package’ inside ’init.el’ without installing it, I mean
it does not appear neither inside ’guix.scm’ –– I do not understand from
where it comes from. Therefore, I am not sure about the option ’–pure’
but the option ’–container’ should raise an error. Do I miss something?
> ;; -*- mode: emacs-lisp -*-
> (unless (require 'guix-emacs nil 'noerror)
> (package-initialize))
> (unless (require 'guix-emacs nil 'noerror)
> ;; package archives
> (when (>= emacs-major-version 24)
> (require 'package)
> (setq package-archives
> '(("GNU_ELPA" . "https://elpa.gnu.org/packages/")
> ("org" . "https://orgmode.org/elpa/")
> ("MELPA_Stable" . "https://stable.melpa.org/packages/")
> ("MELPA" . "https://melpa.org/packages/"))
> package-archive-priorities
> '(("GNU_ELPA" . 15)
> ("org" . 10)
> ("MELPA_Stable" . 5)
> ("MELPA" . 0)))))
From my experience, I do not mix packages from Emacs archives and from
Guix because it often leads to weirdness –– unexpected behaviour at
least… Personally, I have removed the use of all the ‘package.el’
functions and only use packages ’emacs-*’ from Guix and then configure
them using ’with-eval-after-load’.
> (unless (require 'guix-emacs nil 'noerror)
> (use-package emojify
From where the package ’use-package’ comes from?
> :ensure t
> :pin "GNU_ELPA"))
If you use a manifest.scm file, why do you need ’use-package’ and ELPA.
If ’emojify’ is not in Guix, please try to submit a patch – using “guix
import elpa” helps.
> (unless (require 'guix-emacs nil 'noerror)
> (use-package tramp
> :ensure t
> :pin "GNU_ELPA"))
Well, ’use-package’ does lazy evaluations if I remember correctly. So
why do you explicitly ’require’ it just after?
> (require 'tramp)
AFAIU, it should be better to do:
(use-package tramp
:ensure t
:defer t
:pin “GNU_ELPA
:init
;; eval at init time
:config
;; eval at use time
;; your TRAMP config
(setq tramp-remote-path …)
…)
or to add ’emacs-tramp’ to your manifest.scm file and then write:
(with-eval-after-load ’tramp
;; your TRAMP config
(setq tramp-remote-path …)
…)
(Note I do not know about TRAMP, so maybe ’tramp-remote-path’ should be
evaluated at init time and not at use time. Aside the fact that TRAMP
is part of vanilla Emacs, AFAICT.)
> (unless (require 'guix-emacs nil 'noerror)
> (use-package org
> :mode (("\\.org$" . org-mode))
> :ensure org-plus-contrib
> :pin org))
[...]
> (require 'org-id)
> (require 'org-toc)
> (require 'org-tempo)
Because of this mess about evaluating order, I am not sure this is
correct. Instead, you should write something like:
(use-package org
…
:config
(require 'org-tempo))
or instead the ’(require 'org-tempo)’ in your init.el, something like:
(use-package org-tempo
:ensure t
:defer t
:after org)
From my understanding, you are misusing ’use-package’. Or you could
rewrite:
(with-eval-after-load 'org
(require 'org-tempo))
(And I am personally doing that.)
Last, your starting time should be pretty long, right? Hum? IMHO, it
could be really faster if you use ’with-eval-after-load’ or
’(use-package foo :defer t …)’ and so enjoy the speedup by “lazy”
evaluation.
> ;; This file is automatically generated via init.org
> ;; PLEASE do not edit this, edit init.org
> (specifications->manifest
> '("gs-fonts"
> "font-dejavu"
> "font-gnu-freefont"
> "unicode-emoji"
> "emacs"
> "emacs-emojify"
And you have ’(use-package emojify :ensure t)’, it appears to me a bad
idea. And I am pretty sure that leads to issues. Choose if the
packages come from ELPA&co _or_ Guix, IMHO.
> ))
I could have misread, but no ’emacs-use-package’.
Hope that helps,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Sun, 04 Oct 2020 17:22:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 43243 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I resolved this issue: (obviously) It was my fault, please see below.
zimoun <zimon.toutoune <at> gmail.com> writes:
[...]
> Hum? What is your ’~/.emacs.d/init.el’&co.? The issue seems the
> loading order. It could happen with lazy eval &co. Well, this ’alist’
> is from ’org.el’, so it appears to me a bit weird.
This sentence slowly guided me to the solution: I still had
~/.emacs.d/elpa and after I deleted that, the initial error reported in
this bug disappeared, with another one I discovered later.
AFAIU the error was triggered by the fact that my Emacs (on foreign
distro) was still loading some old code from ~/.emacs.d/elpa, installed
using use-package (mixed with Debian packages in some case) before I
migrated to Guix Emacs.
All this confusion comes from the fact that before upgrading to 27.1 I
was using the same version (26.3) installed from Debian and then
migrated to Guix: this way, apart some strange warning I fully
understand only today, my Emacs Guix was running fine as before. So
when I upgraded I misintepreted the situation as coming from some
problem of elfeed-org with 27.1.
Probably we should add a warning in our manual to avoid other users on
foreign distros will get in similar situations: I'd like to help but I'm
not sure I'll be able to find the right words.
Simon: about my strange use of
--8<---------------cut here---------------start------------->8---
(unless (require 'guix-emacs nil 'noerror)
(use-package
--8<---------------cut here---------------end--------------->8---
I think is a tengent here, so if you agree I'd discuss it on guix-users
(IMHO is OT on guix-devel).
Re. this bug, I think the situation is clear now and if you agree I'd
close it.
Thanks a lot! Emacs-Fu panda Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Reply sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
You have taken responsibility.
(Sun, 04 Oct 2020 17:39:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Giovanni Biscuolo <g <at> xelera.eu>
:
bug acknowledged by developer.
(Sun, 04 Oct 2020 17:39:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 43243-done <at> debbugs.gnu.org (full text, mbox):
Hello Giovanni,
Giovanni Biscuolo <g <at> xelera.eu> writes:
> Hello,
>
> I resolved this issue: (obviously) It was my fault, please see below.
>
> zimoun <zimon.toutoune <at> gmail.com> writes:
>
> [...]
>
>> Hum? What is your ’~/.emacs.d/init.el’&co.? The issue seems the
>> loading order. It could happen with lazy eval &co. Well, this ’alist’
>> is from ’org.el’, so it appears to me a bit weird.
>
> This sentence slowly guided me to the solution: I still had
> ~/.emacs.d/elpa and after I deleted that, the initial error reported in
> this bug disappeared, with another one I discovered later.
>
> AFAIU the error was triggered by the fact that my Emacs (on foreign
> distro) was still loading some old code from ~/.emacs.d/elpa, installed
> using use-package (mixed with Debian packages in some case) before I
> migrated to Guix Emacs.
As with other things Guix, mix and match of ad-hoc package management
(e.g., Emacs' native package management) and Guix can cause conflicts.
There is not always a clear solution to these problems.
I don't use Emacs' native package management facility, but if it clashes
with our own use of EMACSLOADPATH and site-start.el, it could be work
looking into (as a fresh bug).
I'll close this one for now.
Thanks!
Maxim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Mon, 05 Oct 2020 12:58:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 43243-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
[...]
>> AFAIU the error was triggered by the fact that my Emacs (on foreign
>> distro) was still loading some old code from ~/.emacs.d/elpa, installed
>> using use-package (mixed with Debian packages in some case) before I
>> migrated to Guix Emacs.
>
> As with other things Guix, mix and match of ad-hoc package management
> (e.g., Emacs' native package management) and Guix can cause conflicts.
> There is not always a clear solution to these problems.
I think the only conflicting code was coming from ~/.emacs.d/elpa and I
did not realized this until yesterday. I still do not fully understad
what is the config option in my init.el loading that code, but it's
tangent here.
> I don't use Emacs' native package management facility, but if it clashes
> with our own use of EMACSLOADPATH and site-start.el, it could be work
> looking into (as a fresh bug).
AFAIU this is not happening.
> I'll close this one for now.
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43243
; Package
guix
.
(Mon, 05 Oct 2020 13:46:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 43243-done <at> debbugs.gnu.org (full text, mbox):
On Mon, 5 Oct 2020 at 14:57, Giovanni Biscuolo <g <at> xelera.eu> wrote:
> >> AFAIU the error was triggered by the fact that my Emacs (on foreign
> >> distro) was still loading some old code from ~/.emacs.d/elpa, installed
> >> using use-package (mixed with Debian packages in some case) before I
> >> migrated to Guix Emacs.
> >
> > As with other things Guix, mix and match of ad-hoc package management
> > (e.g., Emacs' native package management) and Guix can cause conflicts.
> > There is not always a clear solution to these problems.
>
> I think the only conflicting code was coming from ~/.emacs.d/elpa and I
> did not realized this until yesterday. I still do not fully understad
> what is the config option in my init.el loading that code, but it's
> tangent here.
Each time you have
'(use-package foo :ensure t)'
and
'(specifications->manifest (list "emacs-foo"))'
then it is conflicting. Please re-read this message [1].
The option in your init.el loading that code is ':ensure t'. See:
"The :ensure keyword causes the package(s) to be installed
automatically if not already present on your system:"; from the
'use-package' documentation [2].
[1] <http://issues.guix.gnu.org/43243#10>
[2] <https://github.com/jwiegley/use-package#package-installation>
All the best,
simon
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 03 Nov 2020 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 241 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.