bug#45198: 28.0.50; Sandbox mode

[Mattias Engdegård]

19 dec. 2020 kl. 16.08 skrev Philipp Stephani <p.stephani2@gmail.com>:

> I'd say these two questions are somewhat independent of each other.
> Even with an internal-only interface, people will start to assume that
> reading arbitrary files works.
> I'm personally not a huge fan of such internal interfaces though. They
> are necessary in some cases, but a high-level UI framework like
> Flymake shouldn't need to use them. Besides, since Flymake is released
> as an external package, it should rather not use internal interfaces
> in the first place.

What I meant is that there is no way of knowing whether an API is rubbish or 
not without having put it to use ourselves first (preferably in two or more 
ways), so let's not front-load the design. We know that this is true regardless 
of how good programmers we think we are. 
Flymake would be a natural user, but it must cope with our own demands first.

>> Thanks for the reference, and you may very well be right. A counterpoint is 
>> that since the facility would be enabled by default, a user met with 
>> complaints about perfectly fine code will immediately disable the checks and 
>> thus foil our plan to nudge his coding habits in a desirable direction.
> 
> Maybe, though I wouldn't be so sure. Elisp compilation in Flycheck is
> enabled by default and presumably suffers from the same problems.
> There are also similar problems with other languages: for example,
> when I visit src/lisp.h and enable Flymake, I get 2287 errors, 154
> warnings, and 4002 notices (which is an actual problem since the huge
> number of overlays makes Emacs sluggish - probably Flymake should just
> stop after 20 diagnostics or so...). I totally agree that we need to
> keep the false positive rate low, but I wouldn't say that any nonzero
> rate would make Flymake useless.

There's a difference though: flycheck is installed by someone who wants to use 
it and is presumably ready for some setting-up. In contrast, we are aiming at 
an on-by-default zero-configuration Emacs feature, which means that the bar is 
higher. It's meant precisely for those who would not install and configure 
flycheck, so false positives may have effects opposite the intended.

> I also think that packages shouldn't rely on autoloads from other
> packages. I generally dislike autoloads and think they are overused.
> They make programming unnecessarily brittle because they assume not
> only that the load path is set up correctly, but also that the correct
> loaddefs files are already loaded. Autoloads are probably fine for
> interactive commands to avoid unnecessarily loading rarely-used
> packages, but inter-package dependencies should just use 'require'.

I don't necessarily disagree but it would be interesting to hear what Stefan 
thinks about it. Since it's somewhat of an opinionated tool after all, it's 
squarely within our remit to lay down policy...