It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited, should not be a lot of work, or at least doable. Disable it in your config, get a nerfed-down but shields-up elisp editing mode.
Am I missing anything here? E.g. should I expect pieces of C code that handle completion in elisp mode?
> It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited
Probably, yes. „org-babel“ can execute shell code inside an org document but always asks the user before it does. You can disable this if you want to. No big deal. Should totally work like this in elisp-mode, too.
Would you mind explaining how you could do this?
I expect that the entire mode is implemented in elisp-mode.el. It's based on lisp-data-mode, but I don't expect that to handle macros (should check though).
Looking at elisp-completion-at-point and likely deeper into elisp--completion-local-symbols, I'd try to find where macroxpansion occurs, and make it conditional. Same for the explicit emacs-lisp-macroexpand.
I would also search for `(eval ` in general and maybe put it under a buffer-local flag, too, so that you won't press C-x C-e or C-M-x and execute malicious code by mistake, when you know you're working on a piece of malicious code.
Maybe instead of a defcustom, it should rather be a minor elisp-paranoid-mode which would do all kinds of things to prevent execution of the code in the buffer, or the code the buffer refers to, etc.