Emacs pyret package issue with smartparens

[kishvanchee]

Hi, I was trying to set up my (doom) emacs with your package. I received the following error.

Error (pyret-mode-startup-hook): Error running hook "pyret-smartparens-setup" because: (error Keyword argument nil not one of (:trigger :trigger-wrap :actions :when :unless :pre-handlers :post-handlers :wrap :bind :insert :prefix :suffix :skip-match))
Error (pyret-mode-hook): Error running hook "pyret-startup-runner" because: (doom-hook-error pyret-mode-startup-hook pyret-smartparens-setup (error Keyword argument nil not one of (:trigger :trigger-wrap :actions :when :unless :pre-handlers :post-handlers :wrap :bind :insert :prefix :suffix :skip-match)))

I reached out to the maintainer of doom emacs. He was kind enough to help me with the issue. With his permission, I'm quoting his responses below, with the suggestion fix.

The issue is in pyret-smartparens-setup. Change it to https://pastebin.com/KzQ7Fu5D and it'll work fine.

Copy pasting the fix here for reference

(defun pyret-smartparens-setup ()
  (message "Setting up smartparens...")
  (when (require 'smartparens nil 'noerror)
    (sp-local-pair '(pyret-mode) "`" nil :actions nil)
    (sp-local-pair '(pyret-mode) "```" "`​``" :actions '(insert wrap) :unless '(pyret-point-not-at-last-tqs-opener-p))))

Quoting the relevant parts where he debugged and recognized the error

it is an issue with the remote package.

Long story short: a macro (sp-with-modes) is used at compile time before it is defined, leaving it unexpanded in the bytecode and preventing it from injecting arguments into the sp-local-pair calls inside it. The fix is to either load smartparens at top-level (where the byte-compiler will evaluate it), or to avoid the macro altogether and do sp-with-modes's work by hand by passing '(pyret-mode) to each sp-local-pair call.

The latter is better, because the former forces the package to eagerly load smartparens whether or not it's needed. Though it could be wrapped in (eval-when-compile ...) so it's only loaded at compile-time.

I recognize the issue because I know that the byte-compiler expands macros when a package is byte-compiled, and what happens if said macros aren't available during compile time.

I hope this is helpful for other emacs users who might face this issue.

[blerner]

Interesting, thanks for the information! I'll take a look, and if this switch continues to work for me (I don't use doom emacs, and I'd want to make sure it works in most standard emacsen), I'll merge it in.

[kishvanchee]

Thank you. Just confirming, this is not specific to doom emacs. That's why I left the explanations above. Hopefully you can replicate it in your environment with a vanilla config.