Open jave opened 3 years ago
Thanks, this is great to know. I've quickly tried shx with ielm and I see the problem happening. I'll add a change to at least inhibit shx-global-mode in ielm buffers this weekend -- it will amount to redefining shx--global-on
as:
(defun shx--global-on ()
"Call the function `shx-mode' if appropriate for the buffer."
(when (and (derived-mode-p 'comint-mode)
(not (eq major-mode 'inferior-emacs-lisp-mode)))
(shx-mode +1)))
Similar issue happened for sly, which was a fork of slime and use comint-mode to redesign their repl.
screenshot:
Thanks! There might be a way to get shx to cooperate with these modes, but for now I'll add sly to the exceptions too.
for c20495c, I think it should be sly-mrepl-mode
.
I wasn't able to locate the definition of sly-mrepl-mode to confirm, but I think the root cause was that shx shadows the RET binding which these modes (and probably others) require.
You can find out definition of sly-mrepl-mode
here, the keymap it uses is sly-mrepl-mode-map, which RET
is bind to sly-mrepl-return
root cause was that shx shadows the RET binding which these modes (and probably others) require.
Sounds reasonable. Now shx
works for sly
now, thanks.
I used m-x shx-global-mode, which interferes with m-x ielm.
ielm will behave very oddly, outputing streams of hex rather than doing anything useful.
Is there a way to inhibit shx-global-mode in ielm buffers?