From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13522: 24.2; save-buffer removes edited file under some conditions Date: Mon, 14 Mar 2022 19:02:14 +0200 Message-ID: <83bky8jwmh.fsf@gnu.org> References: <87622qaszq.fsf@xvii.vinc17.org> <8735jkye2q.fsf@gnus.org> <83mthsk63c.fsf@gnu.org> <87sfrkwsy5.fsf@gnus.org> <83fsnkk4so.fsf@gnu.org> <20220314152053.GB2381@cventin.lip.ens-lyon.fr> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7496"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 13522@debbugs.gnu.org To: Vincent Lefevre Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 14 18:03:09 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nTo69-0001iG-F5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Mar 2022 18:03:09 +0100 Original-Received: from localhost ([::1]:41832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nTo68-0006CZ-Dt for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Mar 2022 13:03:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTo62-0006B5-Cl for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2022 13:03:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nTo62-0002jy-4Q for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2022 13:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nTo62-00015B-0k for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2022 13:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Mar 2022 17:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13522 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 13522-submit@debbugs.gnu.org id=B13522.16472773554118 (code B ref 13522); Mon, 14 Mar 2022 17:03:01 +0000 Original-Received: (at 13522) by debbugs.gnu.org; 14 Mar 2022 17:02:35 +0000 Original-Received: from localhost ([127.0.0.1]:46171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTo5a-00014M-WA for submit@debbugs.gnu.org; Mon, 14 Mar 2022 13:02:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTo5Z-000145-BT for 13522@debbugs.gnu.org; Mon, 14 Mar 2022 13:02:34 -0400 Original-Received: from [2001:470:142:3::e] (port=46860 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTo5T-0002gw-Rp; Mon, 14 Mar 2022 13:02:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=iPN504dxWKdd01E+bjPpYyTbkc6bUQzthV6ecMevsYA=; b=ZLp75BqM9r3n nwdXc5l1q/I1ljMFgl19Ufw7MVzbmrt+Ax32cTXvpUjyJOc4Q1So9bjHAUySIPB/3tGvdTDtnh34L NyW1WlOiZI+CspCXYF8yannyQqswfbU2m/wRKXmfuCAcVtuov/T6s/tXUnCkmZ40sAverLllikz2j BUUMY0CgLMIZNTZu7/isE9tygtqk+oX0Vya7FaKLxZcP48oiNIR8HO2nlIJdTefIVn2zLak7Mdw5j 3H+xRQoF+OnrjcgEY783ZItuWoWEkEX0EMtiFmoNlx8upyjGd1IwBsP9eZSvrs0qN/cY/g7guym7+ gYScRQ1DaaYWLei4rk2KSg==; Original-Received: from [87.69.77.57] (port=3830 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTo5T-0001ki-BN; Mon, 14 Mar 2022 13:02:27 -0400 In-Reply-To: <20220314152053.GB2381@cventin.lip.ens-lyon.fr> (message from Vincent Lefevre on Mon, 14 Mar 2022 16:20:53 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:228384 Archived-At: > Date: Mon, 14 Mar 2022 16:20:53 +0100 > From: Vincent Lefevre > Cc: Lars Ingebrigtsen , 13522@debbugs.gnu.org > > This is silly. Ctrl-C is *standard* to interrupt commands. When there > is a risk to lose data or to get in an inconsistent state, commands > should trap SIGINT (either to ignore it or to do some cleanup before > exiting). That's what Emacs does. Except that not every processing interrupted in its middle can be restarted and run to its "normal" completion. > Note that in any case, C-x C-c in Emacs does not replace Ctrl-C in the > terminal, as with C-x C-c, Emacs quits with a zero exit status, which > may not be what one wants. Example: in a "svn ci", one may want to > abort the commit without losing the text written in Emacs. Ctrl-C in > the terminal (where "svn ci" has been run) allows one to do that. Emacs is not SVN, and doesn't work in transactions. > In this bug, the issue is actually more important: When one does > C-x C-s, the file has been renamed, which is bad, because the user > may not choose what to do immediately, and many things can happen > in the period, such as a power outage, a network outage, a crash of > the machine, etc. The user may not notice the issue with the file > immediately, so that he may lose the contents (or the changes, e.g. > if the file is handled by a VCS). The file may also be needed by > other software while the user is editing it (for instance, as backup > software, or some application if this is a configuration file). There should be an auto-save file to recover your edits. > > SIGINT is a fatal signal, and our response to fatal signals cannot > > be too fancy. We just auto-save what we can and commit suicide. Even > > that is disliked by some, who say we cannot safely do anything > > non-trivial from a fatal signal handler -- and they are absolutely > > right, we do stuff that invokes undefined behavior. > > SIGINT could be equivalent to something like C-g in Emacs + quit > without saving (a backup of the current buffer can be kept), > exiting with a non-zero exit status. Note that you do not need to > do everything in the signal handler. In general, what is done is > just to set some variable saying that SIGINT has been received. > The abort of the operations is done in the main code. When the program is delivered a fatal signal, the only way to get back to "main code" is longjmp from the signal handler, which is already "not recommended", to say the least. Anyway, what you describe is not what actually happens, AFAIK. Handling a fatal signal and handling C-g are very different in Emacs. But maybe I'm missing something, so I will let others speak up.