Largely this problem which is core to Emacs in the sense it literally is "An Elegant Weapon For A More Civilized Time" due to its age. There is no concept of sandboxing anything in Emacs. You do get an alert sometimes when you change Theme's since they have a notion of totally executable code. Maybe a better solution would be to make a subset of elisp that artifacts be coded in which are sandboxed.

▲

d0mine 7 months ago | parent | next [-]

No sandboxing is not a bug, it is the feature that makes emacs into elisp platform, and not just another editor that has defined API for extensions.

▲

taeric 7 months ago | parent | prev [-]

This problem is specific to elisp evaluation. It is rare that you would want to work in elisp code and not be modifying your currently running emacs.

If you are working on code for any other language, it is probably using an LSP or other form of child processes, right?

▲

taeric 7 months ago | parent | next [-]

(Adding as a very late edit on the above. I didn't mean that this problem cannot exist in other settings, which I can see is what folks probably read me as meaning. I just meant the problem in this overall story is specific to elisp because it is core to emacs.)

▲

VyseofArcadia 7 months ago | parent | prev [-]

Well I wouldn't say any other language. Common Lisp for example you have a currently running lisp instance that you are modifying.

You can pretty easily set up Emacs to work that way for any language with a REPL.

	▲	taeric 7 months ago \| parent [-]
		Fair, though with the CL/Python/Whatever you would have to have a session started before visiting the file. I suppose with the newer eglot and friends, it could reach out using LSP as soon as you enter a project directory? At that point, I'd assume similar attacks exist in those contexts, too? Maybe protected by some sandboxing in the LSP side?