> Another option, though, is to rewrite the ERT tests in question: e.g. to > bind vc-handled-backends to nil, or to some other value if the presence > of certain VC programs is known and expected in advance. Test in question does not need or use Git in any way. It fails only because Emacs under it decides to die with an exception when Git is not installed, `debug-on-error' happens to be t (because of ERT, test itself doesn't even set it explicitly) and current directory is structured in a particular way. It feels conceptually wrong to require all tests that open files to rebind `vc-handled-backends'. This is not what they are testing. It also depends on knowing particular Emacs quirks (which I, for example, didn't know one day earlier). If those were to change in some way, would all tests everywhere need to accomodate? Paul On Wed, 6 Sept 2023 at 14:35, Dmitry Gutov wrote: > On 06/09/2023 15:13, Eli Zaretskii wrote: > >> From: Paul Pogonyshev > >> Date: Wed, 6 Sep 2023 09:29:59 +0200 > >> Cc:65763@debbugs.gnu.org > >> > >> The problem appears to be only with `debug-on-error'. However, there > are cases where you cannot > >> control it at all, e.g. with ERT (probably also Buttercup or any other > testing framework). In effect, an > >> ERT test fails for a "random" reason, depending on which machine it is > executed, i.e. it fails inside > >> that Docker container. > > I see. > > > > Well, we could then protect the execution of the problematic form "by > > hand" by using condition-case-unless-debug. Dmitry, WDYT? > > Maybe the solution is to use the straight condition-case rather than > condition-case-unless-debug? Because otherwise as long as > condition-case-unless-debug is used, we would always have this problem. > > Rewriting with-demoted-errors is not an option, of course, but we could > create a special, shorted version of it for vc. > > Another option, though, is to rewrite the ERT tests in question: e.g. to > bind vc-handled-backends to nil, or to some other value if the presence > of certain VC programs is known and expected in advance. >