Hacker News Reader

Comment by screcth | Hacker News Reader

The problem here is that Emacs is the Elisp interpreter. They are the same thing.

Emacs would have to start another process for Elisp analysis and code completion. That would be a massive reachitecture of the system.

View on HN

Wouldn't it be sufficient to "just" write a kind of context manager that watches the macro expansion and then looks at each step what's being done and divvies that up into safe and unsafe execution, so that at least the example of the article

  (rx (eval (call-process "touch" nil nil nil "/tmp/owned")))

doesn't just automatically run? Obviously it's a lot of work depending on how sophisticated you want that to be but you probably don't need to rearchitect much.

For folks that have never poked around in emacs, the specific difficulty will be that the odds are very high that if you are in an emacs lisp file, you are almost certainly going to want to edit what emacs itself is doing.

I'm specifically talking about scenarios such as "you set debug-on-error."

To that end, the proposal would probably be something like "flymake/flycheck" use a child emacs process to query the code, but the user evaluating the code would still be done in the main emacs?

Reply on news.ycombinator.com