"org-notion-print is already defined as something else than a generic function"

[jhilker98]

Hi there!

I wanted to try this package and so I had set up the login in this format in my ~/.authinfo.gpg (on my windows 10 machine, using Doom Emacs installed with chocolatey):

machine notion.so username [email protected] password accountpassword token mysecrettoken

However, when I tried to call any of the functions in org-notion, I got this error (using an empty org-mode file to pull tasks into):

Eager macro-expansion failure: (wrong-type-argument listp :documentation) [2 times]
defclass: Wrong type argument: listp, :documentation
cl-generic-ensure-function: org-notion-print is already defined as something else than a generic function

What do I need to do in order to fix this error? Like I mentioned earlier, I'm currently on Windows 10, and I used chocolatey to install emacs, and I'm using doom emacs.

[richardwesthaver]

hi! sorry for the delay, I will take a look today and report back. be aware that this package is in alpha and I haven't been working on it recently :)

[richardwesthaver]

@jhilker1 could you post the version of emacs and doom you are using? I can't replicate on Emacs 29.0.50 with/without init but there could be compatibility issues if you are on 28 or below.

The error seems to be related to eieio - the :documentation attribute is used in object definitions and org-notion-print is an object method. I just pushed a quick update that adds require for eieio (and for org, which fixes a bug that happens if org-notion.el is loaded before org-mode).

Can you try again with the patch? If that doesn't work, try running emacs with no init emacs -Q.

ty!

[jhilker98]

I'm currently using Emacs v27.2. I'll check the fix tonight! Here's the output of `doom version` : ``` Executing 'doom version' with Emacs 27.2 at 2022-06-10 20:41:02 GNU Emacs v27.2 deef5efafb70f4b171265b896505b92b6eef24e6 Doom core v3.0.0-dev grafted, HEAD -> master, origin/master, origin/HEAD bea3cc1 2022-06-04 15:02:06 +0200 Doom modules v22.06.0-dev grafted, HEAD -> master, origin/master, origin/HEAD bea3cc1 2022-06-04 15:02:06 +0200 ``` Unfortunately, the issue is still persisting.

[richardwesthaver]

@jhilker1 thank you for checking - I’m almost certainly using built-ins that require 28+ - I will comb through the code tonight and see if I can remedy this without significant changes, otherwise I’ll add a version requirement to the header

[jhilker98]

No worries! I'll try my EndeavourOS machine as well since that has a newer version of emacs.

[richardwesthaver]

after skimming I'm only seeing compatibility issues that would affect <28.1 - can you give me an example of a function you're calling? For example do you get error on org-notion-mode and org-notion-get-users?

[richardwesthaver]

closing for now, feel free to reopen with any updates. Thanks!

[jhilker98]

so sorry, I completely forgot! I'll double check tonight.

[jhilker98]

unfortunately my main laptop is in for repairs, but I'll check as soon as it gets back. I'll go ahead and close the issue for now, but will keep you posted on what I find out.

[jhilker98]

Sorry for the delay. I set up a quick vm with just this package - I found that I could get org-notion-mode to work, but when I ran org-notion-users (or any of the other commands besides org-notion-mode) I got this error:

(HTTP 400: Notion-Version header failed validation: Notion-Version header should be defined, instead was `undefined`.)

[richardwesthaver]

@jhilker1 thanks for checking! I will confirm after work today, but it is probably because the org-notion-version constant uses an older value. Try setting it to “2022-06-28”. I will push update after verifying root cause.

I should also have time to continue working on this in the next few weeks so stay tuned!

[jhilker98]

Alright! I'll double check asap.

[richardwesthaver]

@jhilker1 after testing I was unable to reproduce :( - after running org-notion-get-users I see expected output in message buffer. here you can see where the Notion-Version header is defined and the request is dispatched. This is all while using the older API version "2021-08-16" on Emacs 29.0.50. I'll spin up a VM with Emacs 28 when I can to check for backward-compatibility issue but am otherwise stumped

[jhilker98]

I can look into it on emacs 29 as well.

[jhilker98]

hey there, haven't had much luck getting emacs 29 set up, and have been dealing with a lot of heavy stuff recently. I'll keep an eye on it in the meantime but for now I'll go ahead and close the issue, and reopen it if I find anything new.

[jhilker98]

I'm getting the error on any org-notion function, whether `org-notion-mode`, `org-notion-get-users`, etc.

…

On Sat, Jun 11, 2022, 6:00 PM ellis ***@***.***> wrote: after skimming I'm only seeing compatibility issues that would affect <28.1 - can you give me an example of a function you're calling? For example do you get error on org-notion-mode and org-notion-get-users? — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY54OHF7JN5HSFAJUC32F3VOUD7LANCNFSM5X5X4O2Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[peterhoeg]

I'm seeing this today with latest org-notion, latest org and emacs 29.0.90 - and also on doom.

If I use (add-hook 'org-mode-hook #'org-notion-mode) I get the same error as @jhilker98.

If I don't use a hook, but simply try (require 'org-notion) after opening an .org file, I get this:

Debugger entered--Lisp error: (wrong-type-argument symbol "Mixin used to cache object instances based on\n   `..." slot)
  eieio-oref-default(#<org-notion-cache org-notion-cache-25719d4> "Mixin used to cache object instances based on\n   `...")
  eieio-set-defaults(#<org-notion-cache org-notion-cache-25719d4> t)
  eieio-defclass-internal(org-notion-cache (org-notion-class) ((cache :type symbol :allocation :class :documentation "The symbol used to maintain a hashtable\n\11\11 of org-...") (:documentation) ("Mixin used to cache object instances based on\n   `...") (:abstract) (t)) nil)
  byte-code("\300\301\302\303!\"\210\300\304\305\303!\"\210\300\306\304\"\210\307\306\310\311#\210\312\303\313\304#\314\303\315\316\317$\207" [defalias org-notion-cache-p eieio-make-class-predicate org-notion-cache org-notion-cache--eieio-childp eieio-make-child-predicate org-notion-cache-child-p make-obsolete "use (cl-typep ... 'org-notion-cache) instead" "25.1" define-symbol-prop cl-deftype-satisfies eieio-defclass-internal (org-notion-class) ((cache :type symbol :allocation :class :documentation "The symbol used to maintain a hashtable\n\11\11 of org-...") (:documentation) ("Mixin used to cache object instances based on\n   `...") (:abstract) (t)) nil] 6)
  require(org-notion)
  eval-expression((require 'org-notion) nil nil 127)
  funcall-interactively(eval-expression (require 'org-notion) nil nil 127)
  command-execute(eval-expression)

[peterhoeg]

@richardwesthaver can we reopen this please?

[peterhoeg]

And also with emacs 29.0.91

[richardwesthaver]

Hi @peterhoeg sorry I haven't received any notifications for this issue

• the issue you mentioned is a bug I introduce by mistake. this is now fixed
  I would recommend checking the tests for guidance on usage - but this project isn't ready for any real usecase yet