this post was submitted on 31 Oct 2023
1 points (100.0% liked)

Emacs

311 readers
3 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
[email protected]
[email protected]
1
M-: (AKA M-x eval-expression) does nothing upon hitting RET. What could cause this? (alien.top)
submitted 1 year ago by [email protected] to c/[email protected]
2 comments fedilink hide all child comments
 

When I hit the "enter" key, it just goes to the next line and doesn't evaluate the expression.

I tried searching to see if anyone else had experienced this, but I can't find anything. My bad if this is a simple question, but I just haven't been able to figure it out.

It's inconvenient, because oftentimes, there is no M-x equivalent of an S-expression, so I have no way to do something that requires a call to an Emacs Lisp function.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (1 children)

We're expecting RET to perform minibuffer-exit. That's the default keybinding from minibuffer-mode-map. Perhaps another keybinding (from another minor-mode keymap, say) is overriding the minibuffer's RET binding.

it just goes to the next line

Hmmm, this sounds familiar. I had this problem last year.

Do you have Paredit mode enabled in the minibuffer? (You might look at the value of eval-expression-minibuffer-setup-hook.)

The paredit-mode-map has the paredit-RET command bound to RET instead. This command usually puts a new line in place.

[–] [email protected] 1 points 1 year ago

It was exactly this. I had a setup hook that was messing it up. Disabling it fixed the issue. Thanks for this post! This was the hook:

(defun nconc-safe (ls1 ls2)
  (let ((tail ls1))
    (while (and (cdr tail) (not (eq tail ls2)))
      (setq tail (cdr tail)))
    (unless (eq tail ls2)
      (if (null tail)
          (setq ls1 ls2)
        (setcdr tail ls2)))
    ls1))

(defun my-paredit-hook ()
  (enable-paredit-mode)
  (nconc-safe paredit-commands
              '("Extreme Barfage & Slurpage"
                (("C-M-)")
                 'paredit-slurp-all-the-way-forward
                 ("(foo (bar |baz) quux zot)"
                  "(foo (bar |baz quux zot))")
                 ("(a b ((c| d)) e f)"
                  "(a b ((c| d)) e f)")
                 )
                (("C-M-}" "M-F")
                 'paredit-barf-all-the-way-forward
                 ("(foo (bar |baz quux) zot)"
                  "(foo (bar|) baz quux zot)")
                 )
                (("C-M-(")
                 'paredit-slurp-all-the-way-backward
                 ("(foo bar (baz| quux) zot)"
                  "((foo bar baz| quux) zot)")
                 ("(a b ((c| d)) e f)"
                  "(a b ((c| d)) e f)")
                 )
                (("C-M-{" "M-B")
                 'paredit-barf-all-the-way-backward
                 ("(foo (bar baz |quux) zot)"
                  "(foo bar baz (|quux) zot)")))))

;; Commenting out this line solved the issue
;;(add-hook 'eval-expression-minibuffer-setup-hook #'my-paredit-hook)

I think it must have been that (enable-paredit-mode) overrode the RET binding.