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 15:11:00 +0200	[thread overview]
Message-ID: <CAG7Bpaqbj4jhRnXn8=6BiFLJpkb6s4rqe=ELCKLrchaHJ+6YgA@mail.gmail.com> (raw)
In-Reply-To: <ca0ff246-5945-506e-1b10-5617849f9ef7@gutov.dev>

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

I doubt ERT can be changed, it probably sets `debug-on-error' for a reason,
i.e. without it it simply couldn't work. As far as I can tell, the only
good option is to never trigger an error just because a directory looks
like it might be Git, but Git is not installed.

Also consider this from a user point of view. Let's say I have nothing to
do with programming at all and don't have Git installed. Someone emails me
a cool Emacs package as a tarball and accidentally archives `.git' along,
because he is a developer. I unpack it, open some file and now my Emacs
warns me that Git is not installed. But why? I didn't even ask it to do
anything. It *itself* decided to do something (because it saw a `.git'
directory), failed (Git is not installed), and now warns *me*. From my
point of view, if there is a failure for action that wasn't direct result
of user order, Emacs should stay silent.

In other words, I think there are two sane options here:

1) Simply check if Git is installed before doing anything Git-related from
`find-file-hook' callback. If it is not installed, just silently don't do
anything. Reserve errors and warnings until the user actually ask you to do
something Git-related, not simply to open a file.

2) Make sure that this error is always demoted to a warning, even if
`debug-on-error' is t.

I like option 1 better.

Paul

On Wed, 6 Sept 2023 at 14:52, Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 06/09/2023 15:49, Paul Pogonyshev wrote:
> > 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?
>
> But does that mean that VC needs to be changed, or ERT?
>
> E.g. ERT has an interactive mode where it drops into a debugger for the
> user ('d'), but does it need to enable the debugger for its simple runs
> as well?
>

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

  reply	other threads:[~2023-09-06 13:11 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
2023-09-06 12:52                 ` Dmitry Gutov
2023-09-06 13:11                   ` Paul Pogonyshev [this message]
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='CAG7Bpaqbj4jhRnXn8=6BiFLJpkb6s4rqe=ELCKLrchaHJ+6YgA@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).