Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths)

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Trust a file = loaded in the host Emacs - some known exceptions, right?

I think rather than "loaded in the host Emacs" it'll have to be "in
load-path", because Emacs is generally very liberal about automatically
loading files from load-path, so anything in load-path is
pretty much already trusted.

[ I think someone™ should sit down and think hard about this in general
  (not only in the context of flymake), because "in load-path" is not as
  clearly defined as we might think, since we also sometimes load files
  from subdirectories within load-path.
  And hopefully, this someone should be well intentioned ;-)  ]

> So as soon as I load eglot.el, or eglot.elc in the host Emacs, it would
> start working?

Right, or even as soon as eglot is in your load-path.

> If so, I could live with that.  Until it starts working it could issue
> some diagnostics saying "this macro is not known to be safe, so not
> checking".

Sounds OK, yes.

> Now, how would you transmit this information about safe and unsafe
> macros to from the host Emacs to the slave byte-compiling Emacs which is
> a separate process?  Via command-line parameters, an .el generated on
> the fly (we already do this for the flymake'd file, btw), or something
> else?

If we use "in load-path" as the main criterion, then I think this
question is a non-issue, right?

> At least, the way I understand your solution for the "safe/unsafe" macro
> problem it still doesn't seem to fix the fact that as soon as I type
> "(launch-nuke)" into some already loaded macro in eglot.el, nukes are
> potentially going to be launched by some unsuspecting macro-expansion
> down below.

Yup.  That's the problem with the use of trust as a proxy for safety.
I think if we switch to Haskell or Coq instead of Elisp we
could make all those problems disappear ;-)


        Stefan