GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Bastien <bzg <at> gnu.org>, 45198 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, João Távora <joaotavora <at> gmail.com>
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Tue, 22 Dec 2020 12:12:03 +0100

Am Sa., 19. Dez. 2020 um 18:19 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 19 dec. 2020 kl. 16.08 skrev Philipp Stephani <p.stephani2 <at> 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.

I agree, but we should use the time until Emacs 28 gets released to
gain experience with the API as well, so we should design the API
rather sooner than later, because once Emacs 28 is released, we can't
change it any more in incompatible ways.

> 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.

Yes, we should aim for a low false-positive rate, but it doesn't have
to be zero.
As I said, the false-positive rate (or rather, false-discovery rate)
for C currently is often 100%, so maybe we should start with that
first.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.