unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Pogonyshev <pogonyshev@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>, 65763@debbugs.gnu.org
Subject: bug#65763: Error opening a file from a Git working directory if Git is not installed
Date: Wed, 6 Sep 2023 14:49:13 +0200	[thread overview]
Message-ID: <CAG7BpaoWA9xnzYu+K=6m5yyTi7oLH7noMZiJLLJtKadQUV719g@mail.gmail.com> (raw)
In-Reply-To: <ce1e3ce0-ca77-1042-96f8-578a3de50bc8@gutov.dev>

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

> 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 <dmitry@gutov.dev> wrote:

> On 06/09/2023 15:13, Eli Zaretskii wrote:
> >> From: Paul Pogonyshev<pogonyshev@gmail.com>
> >> 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.
>

[-- Attachment #2: Type: text/html, Size: 2789 bytes --]

  reply	other threads:[~2023-09-06 12:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-05 18:54 bug#65763: Error opening a file from a Git working directory if Git is not installed Paul Pogonyshev
2023-09-05 19:44 ` Eli Zaretskii
2023-09-05 20:06   ` Paul Pogonyshev
2023-09-05 20:14     ` Paul Pogonyshev
2023-09-06  2:25       ` Eli Zaretskii
2023-09-06  7:29         ` Paul Pogonyshev
2023-09-06 12:13           ` Eli Zaretskii
2023-09-06 12:35             ` Dmitry Gutov
2023-09-06 12:49               ` Paul Pogonyshev [this message]
2023-09-06 12:52                 ` Dmitry Gutov
2023-09-06 13:11                   ` Paul Pogonyshev
2023-09-06 14:31                     ` Dmitry Gutov
2023-09-06 15:46                       ` Eli Zaretskii
2023-09-06 15:59                         ` Dmitry Gutov
2023-09-10  6:26                           ` Eli Zaretskii
2023-09-10 13:21                             ` Dmitry Gutov
2023-09-10 13:40                               ` Eli Zaretskii
2023-09-10 17:36                                 ` Paul Pogonyshev
2023-09-10 17:52                                   ` Eli Zaretskii
2023-09-06 13:06               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAG7BpaoWA9xnzYu+K=6m5yyTi7oLH7noMZiJLLJtKadQUV719g@mail.gmail.com' \
    --to=pogonyshev@gmail.com \
    --cc=65763@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).